]>

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 an IETF URN namespace for GLobal Unique Enterprise (GLUE) Identifiers. It also establishes an IETF URN namespace for identifiers addressing the requirements identified by the IETF Secure Patterns for Internet CrEdentials (SPICE) working group. 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 a myriad of 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 an IETF URN namespace that standardizes the expression of existing organizational entity identifiers by providing a common representation format. It also establishes a 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 URI.

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

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

External Authority:

an organization that allocates External Identifiers for GLUE URIs using the Authority Identifier(s) over which they have jurisdiction.

Authority Identifier:

identifier for the External Authority responsible for assigning the External Identifier used in GLUE URIs.

External Identifier:

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

Core Concepts Every GLUE URI MUST contain the following components:

• The Authority Identifier
• The External Identifier

Uniqueness and Namespacing Each GLUE URI MUST be globally unique. It is assumed that most registered organizational entity identification schemes already handle any necessary namespacing 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 URI level. Such namespacing MUST be done on the Authority Identifier. The combination of the namespacing and the authority MUST result in a unique Authority Identifier. 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 URIs All GLUE URIs comply with . They begin with urn:ietf:spice: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 and followed by any combination of letters, digits, plus ("+"), period ("."), or hyphen ("-"). 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. The ABNF [RFC5234] for Authority Identifiers is: authority-identifier = ALPHA *( 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 ("+"), period ("."), or hyphen ("-"). 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. The ABNF [RFC5234] for External Identifiers is: external-identifier = ( ALPHA / DIGIT / "-" ) *( ALPHA / DIGIT / "+" / "-" / "." ) Combining these, the ABNF [RFC5234] for a GLUE URI is: glue-uri = "urn:ietf:spice:glue:" authority-identifier ":" external-identifier For example, the following is a GLUE URI using the Authority Identifier "example" and the External Identifier "42": urn:ietf:spice:glue:example:42 The Authority Identifier MUST be registered in the GLUE URI 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 following 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/

They are registered in the GLUE Authority Identifier URN Registry in .

Security Considerations There are no additional security considerations beyond those already inherent to using URNs. Security considerations for URNs can be found in .

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 URIs. An identifier's expression as a GLUE URI does not change the privacy characteristics of that identifier. The same cautions and concerns need to be taken with the GLUE URI representation as with the original identifier. Implementers storing or evaluating GLUE URIs are encouraged to be aware the privacy characteristics of each identification scheme represented by an Authority Identifier and to appropriately handle any GLUE URI which violates privacy policies.

IANA Considerations This section establishes two registries and populates them with their initial contents. The following registration procedure is used for the registries established by this specification. 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:ietf:spice:example" or "Request to register URN urn:ietf:spice: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. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. The IANA escalation process is followed when the Designated Experts are not responsive within 14 days. 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 makes sense. 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.

SPICE URN Registry This specification establishes the IANA "SPICE URN" registry creating a URN namespace for identifiers needed by the IETF Secure Patterns for Internet CrEdentials (SPICE) working group. The registry records the URN and a reference to the specification that defines it.

Registration Template

URN:

The URN requested within the "urn:ietf:spice:" namespace. The identifier following "urn:ietf:spice:" and before any following colon (":") character is not case sensitive and any letters MUST be expressed in lowercase characters. This identifier MUST consist of a sequence of characters beginning with a letter and followed by any combination of letters, digits, plus ("+"), period ("."), or hyphen ("-").

Description:

Brief description of the purpose of the SPICE URN.

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, home page URI) may also be included.

Specification Document(s):

Reference to the document or documents that specify the URN 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

urn:ietf:spice:glue

• URN: urn:ietf:spice:glue
• Description: GLUE URN namespace
• Change Controller: IETF
• Specification Document(s): of this specification

GLUE Authority Identifier URN Registry This specification establishes the IANA "GLUE Authority Identifier URN" registry creating a URN namespace for Authority Identifiers for GLobal Unique Enterprise (GLUE) Identifiers. Each entry registers the URN for an Authority Identifier within the "urn:ietf:spice:glue:" namespace. The organization responsible for the Authority Identifier is recorded.

Registration Template

Authority Identifier:

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

URN:

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

Organization:

The organization responsible for the Authority Identifier.

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, home page URI) 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:ietf:spice:glue:gln
• Organization: GS1
• Change Controller: IETF
• Specification Document(s): of this specification

lei

• Authority Identifier: lei
• URN: urn:ietf:spice:glue:lei
• Organization: GLEIF
• Change Controller: IETF
• Specification Document(s): of this specification

duns

• Authority Identifier: duns
• URN: urn:ietf:spice:glue:duns
• Organization: Dun & Bradstreet
• Change Controller: IETF
• Specification Document(s): of this specification

pen

• Authority Identifier: pen
• URN: urn:ietf:spice:glue:pen
• Organization: Private Enterprise Numbers
• Change Controller: IETF
• Specification Document(s): of this specification

References Normative References A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] 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 Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document sets forward the canonical syntax for URNs. [STANDARDS-TRACK] 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.

Acknowledgments Alexander (A.J.) Stein and Martin Thomson contributed to this specification.

Document History -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