]>

United States brent.zundel@gmail.com

Microsoft Corporation

United States pamela.dingle@microsoft.com

Self-Issued Consulting

United States michael_b_jones@hotmail.com https://self-issued.info/

Security Secure Patterns for Internet CrEdentials URI URN Enterprise Entity Identifiers 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 The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Secure Patterns for Internet CrEdentials Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

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.

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 when, and only when, they appear in all capitals, as shown here.

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).

Core Concepts Every GLUE URN MUST contain the following components:

• The Authority Identifier
• The External Identifier

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.

GLUE URNs GLUE URNs comply with . 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 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 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 . There is a limit of 1000 characters for an External Identifier. The ABNF for External Identifiers is: external-identifier = ( ALPHA / DIGIT / "-" ) *999( ALPHA / DIGIT / "+" / "-" / "." ) Combining these, the ABNF 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 . 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 . The External Identifier MUST be the identifier assigned to the organization by the External Authority.

GLUE Authority Identifiers This section defines the GLUE Authority Identifiers listed in . 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 .

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.

LEI URNs 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".

Security Considerations The security considerations inherent to using URNs apply. Security considerations for URNs can be found in . 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.

Privacy Considerations

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.

IANA Considerations

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 () 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.

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.

Initial Registry Contents

gln

Authority Identifier:

gln

URN:

urn:glue:gln

Organization:

GS1

Transformation Rules:

N/A

Change Controller:

IETF

Specification Document(s):

of this specification,

lei

Authority Identifier:

lei

URN:

urn:glue:lei

Organization:

GLEIF

Transformation Rules:

Convert uppercase characters to lowercase.

Change Controller:

IETF

Specification Document(s):

of this specification, ,

duns

Authority Identifier:

duns

URN:

urn:glue:duns

Organization:

Dun & Bradstreet

Transformation Rules:

Delete hyphen characters.

Change Controller:

IETF

Specification Document(s):

of this specification,

pen

Authority Identifier:

pen

URN:

urn:glue:pen

Organization:

Private Enterprise Numbers

Transformation Rules:

N/A

Change Controller:

IETF

Specification Document(s):

of this specification, ,

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):

of this specification,

URN Namespace Registration This specification registers the following URN namespace in the IANA "Formal URN Namespaces" registry established by .

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 of [[ this specification ]]

Assignment:

Specification Required () 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

References Normative References Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFCs 2141 and 3406. n.d. n.d. n.d. n.d. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. This document describes how Private Enterprise Numbers (PENs) are registered by IANA. It shows how to request a new PEN and how to modify a current PEN. It also gives a brief overview of PEN uses. n.d. This document describes an Enterprise Number (also known as SMI Network Management Private Enterprise Code) for use in documentation. This memo provides information for the Internet community.

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

• Addressed urn:glue registration feedback by Dale Worley about identifier uniqueness and defining Transformation Rules, when needed.
• Addressed urn:glue registration feedback by Peter Saint-Andre about using "URN" rather than "URI", applying suggested language about when multiple External Authorities have issued identifiers for the same organization, and correcting issues with the registry descriptions.

-07

• Registered urn:glue per Amanda Baber's instructions.

-06

• Addressed Deb Cooley's review comments, specifically:
  • Reworked term definitions.
  • Added security consideration about uniqueness of GLUE URIs.
  • Updated registration instructions to include a criterion about an existing organizational registry operated by an External Authority identified by the proposed Authority Identifier.
• Addressed Mohamed Boucadair's review comments, specifically:
  • Used neutral language "organization" that doesn't assume that all organizations are businesses.
  • Reworded confusing text about uniqueness.
  • Made the RFC 5234 reference normative.
• Addressed Erik Kline's review comments, specifically:
  • Expanded LEI on first use to Legal Entity Identifier (LEI).
  • Included instructions to the designated experts about ensuring that the registration references an existing organizational registry operated by an External Authority identified by the proposed Authority Identifier.

-05

• Added ISO/IEC 6523 identifiers.
• The first character of the Authority Identifier may be a digit.
• Fixed wording in IANA Considerations.
• Limited character set to US-ASCII.
• Fixed multiple nits from WGLC.

-04

• Applied review suggestions from Martin Thomson, specifically:
  • Added references for each registered Authority Identifier.
  • Added size limits for Authority Identifiers and External Identifiers.
  • Added a note about LEI URNs.

-03

• Use the urn:glue URN namespace and delete the urn:ietf:spice URN namespace.
• Addressed early IANA feedback.

-02

• Improved several descriptions in the specification.

-01

• Updated Brent's affiliation.

-00

• Initial working group draft, based on draft-zundel-spice-glue-id-02