| Internet-Draft | SPICE GLUE | February 2025 |
| Zundel, et al. | Expires 1 September 2025 | [Page] |
This specification establishes an IETF URN namespace for GLobal Unique Enterprise (GLUE) Identifiers. It also establishes an IETF URN namespace for identifiers defined by the IETF Secure Patterns for Internet CrEdentials (SPICE) working group. The GLUE URN namespace is within the SPICE URN namespace.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://mesur-io.github.io/draft-zundel-spice-glue-id/draft-zundel-spice-glue-id.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-zundel-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/mesur-io/draft-zundel-spice-glue-id.¶
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 1 September 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Enterprise entity identifiers are myriad. 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.¶
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.¶
This specification uses the following terms:¶
a URI that uses the GLUE URN namespace established in this specification.¶
an organization that allocates External Identifiers for GLUE URIs using the Authority Identifier(s) over which they have jurisdiction.¶
identifier for the External Authority responsible for assigning the External Identifier used in GLUE URIs.¶
identifier assigned by an External Authority to identify a particular organization within GLUE URNs over which it has jurisdiction.¶
Every GLUE URI MUST contain the following components:¶
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 might be necessary at the GLUE URI level. Such namespacing SHOULD be done on the Authority Identifier as part of the registration process.¶
That is, the different namespaces would be considered either different schemes operated by the same authority, or the same scheme operated by different authorities. In either case a unique Authority Identifier would be necessary for each.¶
For example, assume there is an External Authority FEA that provides identifiers for organizational entities in USA and Canada. The identifiers in the USA are unique, and the identifiers in Canada are unique, but there is no guarantee that an organizational entity in Canada will not be assigned the same identifier as an organizational entity in the USA. Upon registration of FEA as an Authority Identifier, it would be necessary to separately register FEA-USA and FEA-Can to provide differentiation between the two sets of External Identifiers.¶
All GLUE URIs comply with [RFC3986].
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 Section 7.2. The External Identifier MUST be the identifier assigned to the organization by the External Authority.¶
There are no additional security considerations beyond those already inherent to using URNs. Security considerations for URNs can be found in [RFC2141].¶
There are some corporate identifiers that make use of personal identifiers. This is the case for some registered sole-proprietor businesses in the United States, where the business identifier may be the same as the social-security-number of the business owner.¶
It is possible for such 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 evaluate the privacy characteristics of each identification scheme represented by an Authority Identifier and to appropriately handle any GLUE URI which violates privacy policies.¶
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 [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: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.¶
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.¶
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 ("-").¶
Brief description of the purpose of the SPICE URN.¶
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.¶
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.¶
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.¶
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 ("-").¶
The URN within the "urn:ietf:spice:glue:" namespace consisting of "urn:ietf:spice:glue:" followed by the Authority Identifier.¶
The organization responsible for the Authority Identifier.¶
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.¶
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.¶
Martin Thomson and Alexander (A.J.) Stein contributed to this specification.¶
-02¶
Per working group feedback, use an IETF URN namespace for GLUE URIs.¶
Also establish an IETF URN namespace for identifiers defined by the SPICE working group, which the GLUE namespace is within.¶
Refer to "organizational identification schemes" rather than "company identification schemes".¶
Added Security Considerations.¶
Added Michael B. Jones as an author.¶
-01¶
Added Uniqueness and Naming Section.¶
Added Privacy Considerations.¶
Added Pamela Dingle as an author.¶
-00¶
Initial individual draft¶