Internet-Draft SPICE GLUE March 2026
Zundel, et al. Expires 16 September 2026 [Page]
Workgroup:
Secure Patterns for Internet CrEdentials
Internet-Draft:
draft-ietf-spice-glue-id-08
Published:
Intended Status:
Standards Track
Expires:
Authors:
B. W. Zundel
P. Dingle
Microsoft Corporation
M. B. Jones
Self-Issued Consulting

GLobal Unique Enterprise (GLUE) Identifiers

Abstract

This specification establishes a URN namespace for GLobal Unique Enterprise (GLUE) Identifiers. This enables URN identifiers to be used for businesses and organizations. It enables organizational identities from existing authorities to be represented within this URN namespace.

About This Document

This note is to be removed before publishing as an RFC.

The latest revision of this draft can be found at https://ietf-wg-spice.github.io/draft-ietf-spice-glue-id/draft-ietf-spice-glue-id.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-spice-glue-id/.

Discussion of this document takes place on the Secure Patterns for Internet CrEdentials Working Group mailing list (mailto:spice@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/spice/. Subscribe at https://www.ietf.org/mailman/listinfo/spice/.

Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-spice/draft-ietf-spice-glue-id.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 16 September 2026.

▲

Table of Contents

1. Introduction

There are myriad entity identifier types for businesses and organizations. With the increasing use of digital credentials, there is a need for a common methodology for expressing these identifiers such that claims about and by such entities can be made in a consistent and interoperable manner.

This specification establishes a URN namespace that standardizes the expression of existing organizational entity identifiers by providing a common representation format. It also establishes an IANA registry for managing how existing organizational entity identification mechanisms relate to this namespace.

Any organizational entity identifier whose identification mechanism has been registered as an Authority Identifier in the registry may be represented as a GLUE URN.

1.1. Requirements Notation and Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

1.2. Terminology

This specification uses the following terms:

GLUE URN:

a URN that uses the GLUE URN namespace established in this specification.

Authority Identifier:

identifier for the External Authority responsible for assigning the External Identifiers used in GLUE URNs over which it has jurisdiction.

External Identifier:

identifier assigned by an External Authority to identify a particular organization within GLUE URNs with Authority Identifier(s) over which it has jurisdiction.

External Authority:

an organization that allocates External Identifiers over which it has jurisdiction that are used in GLUE URNs with its Authority Identifier(s).

2. Core Concepts

Every GLUE URN MUST contain the following components:

2.1. Uniqueness and Namespacing

Each GLUE URN is globally unique identifier. An organization can be identified by multiple GLUE URNs, but each distinct GLUE URN can only refer to a single organization. If multiple External Authorities have issued identifiers for the same organization (e.g., the organization has both a Dun & Bradstreet number and a Private Enterprise Number), then the same organization can be identified by GLUE URNs differentiated by the Authority Identifier.

It is assumed that most registered organizational entity identification schemes already handle any namespacing necessary to achieve uniqueness as part of the External Identifier. However, if collisions are possible within the set of possible external identifiers for an Authority Identifier scheme, then further namespacing is necessary at the GLUE URN level. Such namespacing could be done by allocating multiple Authority Identifiers. The combination of the Authority Identifier and the External Identifier MUST result in a unique GLUE URN.

For example, assume there is an External Authority FEA that provides identifiers for organizations in Singapore and South Korea. The identifiers issued in Singapore are unique within Singapore, and the identifiers issued in South Korea are unique within South Korea, but there is no guarantee that an organization in Singapore will not be assigned the same identifier as an organization in South Korea. Upon registration of FEA as an Authority Identifier, it would be necessary to separately register two different Authority Identifiers (e.g., FEA-SG and FEA-KR) to provide differentiation between the two sets of External Identifiers.

3. GLUE URNs

GLUE URNs comply with [RFC8141]. They begin with "urn:glue:" and are followed by an Authority Identifier, a colon character (":"), and the External Identifier allocated by the authority.

Authority Identifiers consist of a sequence of characters beginning with a letter or digit and followed by any combination of letters, digits, plus ("+"), hyphen ("-"), or period ("."). Although Authority Identifiers are case-insensitive, the canonical form is lowercase and documents that specify Authority Identifiers must do so with lowercase letters. An implementation should accept uppercase letters as equivalent to lowercase in Authority Identifier names (e.g., allow "EXAMPLE" as well as "example") for the sake of robustness but should only produce lowercase Authority Identifier names for consistency. There is a limit of 50 characters for the length of an Authority Identifier. The ABNF [RFC5234] for Authority Identifiers is:

authority-identifier = (ALPHA/DIGIT) *49( ALPHA / DIGIT / "+" / "-" / "." )

External Identifiers consist of a sequence of characters beginning with a letter or digit or hyphen ("-") and followed by any combination of letters, digits, plus ("+"), hyphen ("-"), or period ("."). A digit or hyphen is allowed as the first character to permit the case where the External Identifier is the representation of a number. It is specific to the Authority Identifier whether the External Identifiers are case-insensitive or case-sensitive. When they are case-insensitive, the canonical form is lowercase and documents that specify External Identifiers MUST do so with lowercase letters. Always using the canonical form of these URNs means that code performing comparisons need not be aware of whether External Identifiers are case-sensitive or not; case-sensitive comparisons can always be performed on the namespace specific string.

While the original representation of some External Identifiers may contain characters that are ignored, these MUST be omitted when used in GLUE URNs. For instance, Dun & Bradstreet [DUNS] identifiers sometimes contain hyphen characters that are ignored. The DUNS numbers 12-345-6789 and 123456789 are considered to be equivalent. The latter form without the ignored characters MUST be used as the External Identifier in GLUE URNs.

Finally, documents that define a new Authority Identifier type MUST NOT allow the representation of an External Identifier to contain the colon character. Specifications MUST define a substitute character, such as period, that is used in place of a colon in External Identifiers. Any substitution can be specified in the Transformation Rules in the IANA registration for an Authority Identifier; see Section 7.1.

There is a limit of 1000 characters for an External Identifier. The ABNF [RFC5234] for External Identifiers is:

external-identifier = ( ALPHA / DIGIT / "-" ) *999( ALPHA / DIGIT / "+" / "-" / "." )

Combining these, the ABNF [RFC5234] for a GLUE URN is:

glue-urn = "urn:glue:" authority-identifier ":" external-identifier

For example, the following is a GLUE URN using the Authority Identifier "pen" and the External Identifier "32473". This example uses the Enterprise Number "32473" reserved for documentation in [RFC5612].

urn:glue:pen:32473

A GLUE URN is defined over the restricted US-ASCII syntax specified in this section. Percent-encoding is not permitted. Consequently, GLUE URNs do not support representation of External Identifiers that use non-ASCII characters. This specification is therefore limited to identifier systems whose representations can be expressed fully within the permitted character set.

The Authority Identifier MUST be registered in the GLUE URN Authority Identifier registry defined in Section 7.1. The External Identifier MUST be the identifier assigned to the organization by the External Authority.

4. GLUE Authority Identifiers

This section defines the GLUE Authority Identifiers listed in Table 1.

Table 1: Defined GLUE Authority Identifiers
Organization Authority Identifier External Authority Specification
GS1 gln https://www.gs1.org/standards/id-keys/gln
GLEIF lei https://www.iso.org/standard/78829.html
Dun & Bradstreet duns https://www.dnb.com/duns.html
Private Enterprise Numbers pen https://www.iana.org/assignments/enterprise-numbers
ISO/IEC 6523 iso6523 https://www.iso.org/standard/82246.html

These are registered in the GLUE Authority Identifier URN Registry in Section 7.1.

4.1. Equivalence to Similar URNs

A GLUE URN is an identifier in a distinct URN namespace. By default, a GLUE URN is not equivalent to any other URN, including a URN defined by the referenced authority's own namespace. Equivalence between a GLUE URN and a non-GLUE URN exists only when explicitly specified for a given Authority Identifier. Implementations and relying parties MUST NOT assume equivalence between GLUE URNs and non-GLUE URNs unless such equivalence is explicitly defined by the authority and the party understands that particular Authority Identifier and the specified equivalance.

4.1.1. LEI URNs

[LEI-IANA] registers a URN namespace for Legal Entity Identifiers (LEIs). This means that LEIs can be represented as URNs in at least two ways. Therefore there is an equivalence between a GLUE URN with an "lei" Authority Identifier and an LEI URN, provided the 20-digit LEI Code of the LEI URN is identical to the External Identifier of the GLUE URN. For example, "urn:lei:inr2ejn1eran0w5zp974" is equivalent to "urn:glue:lei:inr2ejn1eran0w5zp974".

5. Security Considerations

The security considerations inherent to using URNs apply. Security considerations for URNs can be found in [RFC8141].

The global uniqueness of GLUE URNs prevents situations in which the same identifier is allocated in different local namespaces and cannot be disambiguated when used. For instance both Canadian and Singaporean organization registries might use the local identifier "42", but with these referring to different organizations. Embedding these local identifiers in GLUE URNs enables disambiguation.

6. Privacy Considerations

6.1. Private Identifiers as Corporate Identifiers

There are some corporate identifiers that make use of personal identifiers. For example, this is the case for some registered sole-proprietor businesses in the United States, where the Tax ID may be the same as the Social Security Number (SSN) of the business owner. Where the Tax ID uniquely identifies the business, the SSN uniquely identifies an individual.

It is possible for such business identifiers to be represented as GLUE URNs. An identifier's expression as a GLUE URN does not change the privacy characteristics of that identifier. The same cautions and concerns need to be taken with the GLUE URN representation as with the original identifier.

Implementers storing or evaluating GLUE URNs are encouraged to be aware the privacy characteristics of each identification scheme represented by an Authority Identifier and to appropriately handle any GLUE URN which violates privacy policies.

7. IANA Considerations

7.1. GLUE Authority Identifier Registry

This specification establishes the IANA "GLUE Authority Identifier" registry creating a URN namespace for Authority Identifiers for GLobal Unique Enterprise (GLUE) Identifiers.

Each entry registers an Authority Identifier within the "urn:glue:" namespace. The organization responsible for the Authority Identifier is recorded.

IANA is requested to create the "GLobal Unique Enterprise (GLUE) Identifiers" registry group located at https://www.iana.org/assignments/glue-identifiers/ and place this registry there.

Values are registered on a Specification Required (Section 4.6 of [RFC8126]) basis after a two-week review period on the spice-ext-review@ietf.org mailing list, on the advice of one or more Designated Experts. However, to allow for the allocation of values prior to publication of the final version of a specification, the Designated Experts may approve registration once they are satisfied that the specification will be completed and published. However, if the specification is not completed and published in a timely manner, as determined by the Designated Experts, the Designated Experts may request that IANA withdraw the registration.

Registration requests sent to the mailing list for review should use an appropriate subject (e.g., "Request to register URN urn:glue:example").

Within the review period, the Designated Experts will either approve or deny the registration request, communicating this decision to the review list and IANA. The Designated Experts verify that a specification exists. Experts are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely aesthetically displeasing or architecturally dubious).

Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. If the designated experts are not responsive, the registration requesters should contact IANA to escalate the process.

Criteria that should be applied by the Designated Experts includes determining whether the proposed registration duplicates existing functionality, determining whether it is likely to be of general applicability or whether it is useful only for a single application, and whether the registration references an existing organizational registry operated by an External Authority identified by the proposed Authority Identifier.

IANA must only accept registry updates from the Designated Experts and should direct all requests for registration to the review mailing list.

It is suggested that multiple Designated Experts be appointed who are able to represent the perspectives of different applications using this specification, in order to enable broadly-informed review of registration decisions. In cases where a registration decision could be perceived as creating a conflict of interest for a particular Expert, that Expert should defer to the judgment of the other Experts.

The reason for the use of the mailing list is to enable public review of registration requests, enabling both Designated Experts and other interested parties to provide feedback on proposed registrations. The reason to allow the Designated Experts to allocate values prior to publication as a final specification is to enable giving authors of specifications proposing registrations the benefit of review by the Designated Experts before the specification is completely done, so that if problems are identified, the authors can iterate and fix them before publication of the final specification.

7.1.1. Registration Template

Authority Identifier:

identifier for the External Authority responsible for assigning the External Identifier used in GLUE URNs. This identifier is not case sensitive and any letters MUST be expressed in lowercase characters. It MUST consist of a sequence of characters with a mazimum length of 50, beginning with a letter and followed by any combination of letters, digits, plus ("+"), period ("."), or hyphen ("-").

URN:

The URN within the "urn:glue:" namespace consisting of "urn:glue:" followed by the Authority Identifier.

Organization:

The organization responsible for the Authority Identifier.

Transformation Rules:

Syntactic transformations applied to the original External Identifiers when creating the GLUE URN, or "N/A" if none.

Change Controller:

For IETF stream RFCs, use "IETF". For others, give the name of the responsible party. Other details (e.g., postal address, e-mail address, or home page URL) may also be included.

Specification Document(s):

Reference to the document or documents that specify the Authority Identifier to be registered, preferably including URLs that can be used to retrieve the documents. An indication of the relevant sections may also be included, but is not required.

7.1.2. Initial Registry Contents

7.1.2.1. gln
Authority Identifier:

gln

URN:

urn:glue:gln

Organization:

GS1

Transformation Rules:

N/A

Change Controller:

IETF

Specification Document(s):

Section 4 of this specification, [GLN]

7.1.2.2. lei
Authority Identifier:

lei

URN:

urn:glue:lei

Organization:

GLEIF

Transformation Rules:

Convert uppercase characters to lowercase.

Change Controller:

IETF

Specification Document(s):

Section 4 of this specification, [LEI], [LEI-IANA]

7.1.2.3. duns
Authority Identifier:

duns

URN:

urn:glue:duns

Organization:

Dun & Bradstreet

Transformation Rules:

Delete hyphen characters.

Change Controller:

IETF

Specification Document(s):

Section 4 of this specification, [DUNS]

7.1.2.4. pen
Authority Identifier:

pen

URN:

urn:glue:pen

Organization:

Private Enterprise Numbers

Transformation Rules:

N/A

Change Controller:

IETF

Specification Document(s):

Section 4 of this specification, [PEN], [RFC9371]

7.1.2.5. iso6523
Authority Identifier:

iso6523

URN:

urn:glue:iso6523

Organization:

ISO/IEC 6523

Transformation Rules:

Substitute period for any colon characters.

Change Controller:

IETF

Specification Document(s):

Section 4 of this specification, [ISO6523]

7.2. URN Namespace Registration

This specification registers the following URN namespace in the IANA "Formal URN Namespaces" registry [IANA.URN] established by [RFC8141].

7.2.1. urn:glue

Namespace Identifier:

glue

Version:

1

Date:

2026-03-02

Registrant:

IETF

Purpose:

GLobal Unique Enterprise (GLUE) identifier namespace, established by [[ this specification ]]

Syntax:

As specified in the glue-urn ABNF entry in Section 3 of [[ this specification ]]

Assignment:

Specification Required (Section 4.6 of [RFC8126]) basis

Security and Privacy:

GLUE URNs are public identifiers for public entities.

Interoperability:

GLUE URNs encapsulate other existing identifier namespaces. Therefore, they provide a globally unique equivalent to identifiers within those local namespaces. Some of those namespaces may also utilize URNs.

Resolution:

Resolution of GLUE URNs, which are identifiers, is not performed.

Documentation:

[[ this specification ]]

Additional Information:

N/A

Revision Information:

N/A

8. References

8.1. Normative References

[DUNS]
"D-U-N-S Numbers", n.d., <https://www.dnb.com/duns.html>.
[GLN]
"Global Location Nymber (GLN)", n.d., <https://www.gs1.org/standards/id-keys/gln>.
[ISO6523]
"ISO/IEC 6523-1:2023. Information technology — Structure for the identification of organizations and organization parts, Part 1: Identification of organization identification schemes", , <https://www.iso.org/standard/82246.html>.
[LEI]
"Legal Entity Identifier (LEI)", , <https://www.iso.org/standard/78829.html>.
[LEI-IANA]
"LEI Namespace Identifier", n.d., <https://www.iana.org/assignments/urn-formal/lei>.
[PEN]
"Private Enterprise Numbers", n.d., <https://www.iana.org/assignments/enterprise-numbers>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5234]
Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, , <https://www.rfc-editor.org/rfc/rfc5234>.
[RFC8141]
Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, , <https://www.rfc-editor.org/rfc/rfc8141>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.

8.2. Informative References

[IANA.URN]
"Formal URN Namespaces", n.d., <https://www.iana.org/assignments/urn-namespaces/>.
[RFC5612]
Eronen, P. and D. Harrington, "Enterprise Number for Documentation Use", RFC 5612, DOI 10.17487/RFC5612, , <https://www.rfc-editor.org/rfc/rfc5612>.
[RFC8126]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/rfc/rfc8126>.
[RFC9371]
Baber, A. and P. Hoffman, "Registration Procedures for Private Enterprise Numbers (PENs)", RFC 9371, DOI 10.17487/RFC9371, , <https://www.rfc-editor.org/rfc/rfc9371>.

Acknowledgments

Amanda Baber, Carsten Bormann, Mohamed Boucadair, Tim Bray, Deb Cooley, Patrik Fältström, Arnt Gulbrandsen, Sue Hares, John Klensin, Erik Kline, Martin Lindström, Rohan Mahy, James Manger, Peter Saint-Andre, Orie Steele, Alexander (A.J.) Stein, Martin Thomson, Éric Vyncke, Dale Worley, and Peter Yee contributed to this specification.

Document History

-08

-07

-06

-05

-04

-03

-02

-01

-00

Authors' Addresses

Brent W. Zundel
United States
Pamela Dingle
Microsoft Corporation
United States
Michael B. Jones
Self-Issued Consulting
United States
URI: https://self-issued.info/