diff options
Diffstat (limited to 'doc/rfc/rfc9493.txt')
| -rw-r--r-- | doc/rfc/rfc9493.txt | 924 |
1 files changed, 924 insertions, 0 deletions
diff --git a/doc/rfc/rfc9493.txt b/doc/rfc/rfc9493.txt new file mode 100644 index 0000000..ab3ae88 --- /dev/null +++ b/doc/rfc/rfc9493.txt @@ -0,0 +1,924 @@ + + + + +Internet Engineering Task Force (IETF) A. Backman, Ed. +Request for Comments: 9493 Amazon +Category: Standards Track M. Scurtescu +ISSN: 2070-1721 Coinbase + P. Jain + Fastly + December 2023 + + + Subject Identifiers for Security Event Tokens + +Abstract + + Security events communicated within Security Event Tokens may support + a variety of identifiers to identify subjects related to the event. + This specification formalizes the notion of Subject Identifiers as + structured information that describes a subject and named formats + that define the syntax and semantics for encoding Subject Identifiers + as JSON objects. It also establishes a registry for defining and + allocating names for such formats as well as the JSON Web Token (JWT) + "sub_id" Claim. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9493. + +Copyright Notice + + Copyright (c) 2023 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. + +Table of Contents + + 1. Introduction + 2. Notational Conventions + 2.1. Definitions + 3. Subject Identifiers + 3.1. Identifier Formats versus Principal Types + 3.2. Identifier Format Definitions + 3.2.1. Account Identifier Format + 3.2.2. Email Identifier Format + 3.2.3. Issuer and Subject Identifier Format + 3.2.4. Opaque Identifier Format + 3.2.5. Phone Number Identifier Format + 3.2.6. Decentralized Identifier (DID) Format + 3.2.7. Uniform Resource Identifier (URI) Format + 3.2.8. Aliases Identifier Format + 4. Subject Identifiers in JWTs + 4.1. JWT "sub_id" Claim + 4.2. JWT "sub_id" Claim and "iss_sub" Subject Identifier + 5. Considerations for Specifications that Define Identifier + Formats + 6. Privacy Considerations + 6.1. Identifier Correlation + 7. Security Considerations + 8. IANA Considerations + 8.1. Security Event Identifier Formats Registry + 8.1.1. Registration Template + 8.1.2. Initial Registry Contents + 8.1.3. Guidance for Expert Reviewers + 8.2. JSON Web Token Claims Registration + 8.2.1. Registry Contents + 9. References + 9.1. Normative References + 9.2. Informative References + Acknowledgements + Authors' Addresses + +1. Introduction + + As described in Section 1.2 of [RFC8417] ("Security Event Token + (SET)"), subjects related to security events may take a variety of + forms, including but not limited to a JWT [RFC7519] principal, an IP + address, a URL, etc. Different types of subjects may need to be + identified in different ways (e.g., a user might be identified by an + email address, a phone number, or an account number). Furthermore, + even in the case where the type of the subject is known, there may be + multiple ways by which a given subject may be identified. For + example, an account may be identified by an opaque identifier, an + email address, a phone number, a JWT "iss" Claim and "sub" Claim, + etc., depending on the nature and needs of the transmitter and + receiver. Even within the context of a given transmitter and + receiver relationship, it may be appropriate to identify different + accounts in different ways, for example, if some accounts only have + email addresses associated with them while others only have phone + numbers. Therefore, it can be necessary to indicate within a SET the + mechanism by which a subject is being identified. + + To address this problem, this specification defines Subject + Identifiers as JSON [RFC8259] objects containing information + identifying a subject and defines Identifier Formats as named sets of + rules describing how to encode different kinds of subject-identifying + information (e.g., an email address or an issuer and subject pair) as + a Subject Identifier. + + Below is a non-normative example of a Subject Identifier that + identifies a subject by email address, using the Email Identifier + Format. + + { + "format": "email", + "email": "user@example.com" + } + + Figure 1: Example: Subject Identifier Using the Email Identifier + Format + + Subject Identifiers are intended to be a general-purpose mechanism + for identifying subjects within JSON objects, and their usage need + not be limited to SETs. Below is a non-normative example of a JWT + that uses a Subject Identifier in the JWT "sub_id" Claim (defined in + this specification) to identify the JWT Subject. + + { + "iss": "issuer.example.com", + "sub_id": { + "format": "phone_number", + "phone_number": "+12065550100" + } + } + + Figure 2: Example: JWT Using a Subject Identifier with the JWT + "sub_id" Claim + + Usage of Subject Identifiers also need not be limited to identifying + JWT Subjects. They are intended as a general-purpose means of + expressing identifying information in an unambiguous manner. Below + is a non-normative example of a SET containing a hypothetical + security event describing the interception of a message, using + Subject Identifiers to identify the sender, intended recipient, and + interceptor. + + { + "iss": "issuer.example.com", + "iat": 1508184845, + "aud": "aud.example.com", + "events": { + "https://secevent.example.com/events/message-interception": { + "from": { + "format": "email", + "email": "alice@example.com" + }, + "to": { + "format": "email", + "email": "bob@example.com" + }, + "interceptor": { + "format": "email", + "email": "eve@example.com" + } + } + } + } + + Figure 3: Example: SET with an Event Payload Containing Multiple + Subject Identifiers + +2. Notational 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. + +2.1. Definitions + + This specification utilizes terminology defined in [RFC8259] and + [RFC8417]. + + Within this specification, the terms "Subject" and "subject" refer + generically to anything being identified via one or more pieces of + information. The term "JWT Subject" refers specifically to the + subject of a JWT (i.e., the subject that the JWT asserts claims + about). + +3. Subject Identifiers + + A Subject Identifier is a JSON object [RFC8259] whose contents may be + used to identify a subject within some context. An Identifier Format + is a named definition of a set of information that may be used to + identify a subject and the rules for encoding that information as a + Subject Identifier; these rules define the syntax and semantics of + Subject Identifiers. A Subject Identifier MUST conform to a specific + Identifier Format and MUST contain a "format" member whose value is + the name of that Identifier Format. + + Every Identifier Format MUST have a unique name registered in the + IANA "Security Event Identifier Formats" registry established in + Section 8.1 or a Collision-Resistant Name as defined in [RFC7519]. + Identifier Formats that are expected to be used broadly by a variety + of parties SHOULD be registered in the "Security Event Identifier + Formats" registry. + + An Identifier Format MAY describe more members than are strictly + necessary to identify a subject and MAY describe conditions under + which those members are required, optional, or prohibited. The + "format" member is reserved for use as described in this + specification; Identifier Formats MUST NOT declare any rules + regarding the "format" member. + + Every member within a Subject Identifier MUST match the rules + specified for that member by this specification or by a Subject + Identifier's Identifier Format. A Subject Identifier MUST NOT + contain any members prohibited or not described by its Identifier + Format and MUST contain all members required by its Identifier + Format. + +3.1. Identifier Formats versus Principal Types + + Identifier Formats define how to encode identifying information for a + subject. Unlike Principal Types, they do not define the type or + nature of the subject itself. For example, while the Email + Identifier Format declares that the value of the "email" member is an + email address, a subject in a security event that is identified by an + Email Subject Identifier could be an end user who controls that email + address, the mailbox itself, or anything else that the transmitter + and receiver both understand to be associated with that email + address. Consequently, Subject Identifiers remove ambiguity around + how a subject is being identified and how to parse an identifying + structure, but they do not remove ambiguity around how to resolve + that identifier for a subject. For example, consider a directory + management API that allows callers to identify users and groups + through both opaque unique identifiers and email addresses. Such an + API could use Subject Identifiers to disambiguate between which of + these two types of identifiers is in use. However, the API would + have to determine whether the subject is a user or group via some + other means, such as by querying a database, interpreting other + parameters in the request, or inferring the type from the API + contract. + +3.2. Identifier Format Definitions + + The following Identifier Formats are registered in the IANA "Security + Event Identifier Formats" registry established in Section 8.1. + + Since the Subject Identifier Format conveys semantic information, + applications SHOULD choose the most specific possible format for the + identifier in question. For example, an email address can be + conveyed using a "mailto:" URI and the URI Identifier Format, but + since the value is known to be an email address, the application + should prefer to use the Email Identifier Format instead. + +3.2.1. Account Identifier Format + + The Account Identifier Format identifies a subject using an account + at a service provider, identified with an "acct" URI as defined in + [RFC7565]. An account is an arrangement or agreement through which a + user gets access to a service and gets a unique identity with the + service provider. Subject Identifiers in this format MUST contain a + "uri" member whose value is the "acct" URI for the subject. The + "uri" member is REQUIRED and MUST NOT be null or empty. The Account + Identifier Format is identified by a value of "account" in the + "format" member. + + Below is a non-normative example Subject Identifier for the Account + Identifier Format: + + { + "format": "account", + "uri": "acct:example.user@service.example.com" + } + + Figure 4: Example: Subject Identifier for the Account Identifier + Format + +3.2.2. Email Identifier Format + + The Email Identifier Format identifies a subject using an email + address. Subject Identifiers in this format MUST contain an "email" + member whose value is a string containing the email address of the + subject, formatted as an "addr-spec" as defined in Section 3.4.1 of + [RFC5322]. The "email" member is REQUIRED and MUST NOT be null or + empty. The value of the "email" member MUST identify a mailbox to + which email may be delivered, in accordance with [RFC5321]. The + Email Identifier Format is identified by the name "email". + + Below is a non-normative example Subject Identifier in the Email + Identifier Format: + + { + "format": "email", + "email": "user@example.com" + } + + Figure 5: Example: Subject Identifier in the Email Identifier Format + +3.2.2.1. Email Canonicalization + + Many email providers will treat multiple email addresses as + equivalent. While the domain portion of an email address [RFC5322] + is consistently treated as case-insensitive per [RFC1034], most + providers treat the local part of the email address as case- + insensitive as well and consider "user@example.com", + "User@example.com", and "USER@example.com" as the same email address. + Some providers also treat dots (".") as optional; for example, + "user.name@example.com", "username@example.com", + "u.s.e.r.name@example.com", and "u.s.e.r.n.a.m.e@example.com" might + all be treated as equivalent. This has led users to view these + strings as equivalent, driving service providers to implement + proprietary email canonicalization algorithms to ensure that email + addresses entered by users resolve to the same canonical string. + Email canonicalization is not standardized, and there is no way for + the event recipient to determine the mail provider's canonicalization + method. Therefore, the recipient SHOULD apply its own + canonicalization algorithm to incoming events in order to reproduce + the translation done by the local email system. + +3.2.3. Issuer and Subject Identifier Format + + The Issuer and Subject Identifier Format identifies a subject using a + pair of "iss" and "sub" members, analogous to how subjects are + identified using the JWT "iss" and "sub" Claims in OpenID Connect + [OpenID.Core] ID Tokens. These members MUST follow the formats of + the "iss" member and "sub" member defined by [RFC7519], respectively. + Both the "iss" member and the "sub" member are REQUIRED and MUST NOT + be null or empty. The Issuer and Subject Identifier Format is + identified by the name "iss_sub". + + Below is a non-normative example Subject Identifier in the Issuer and + Subject Identifier Format: + + { + "format": "iss_sub", + "iss": "https://issuer.example.com/", + "sub": "145234573" + } + + Figure 6: Example: Subject Identifier in the Issuer and Subject + Identifier Format + +3.2.4. Opaque Identifier Format + + The Opaque Identifier Format describes a subject that is identified + with a string with no semantics asserted beyond its usage as an + identifier for the subject, such as a Universally Unique Identifier + (UUID) or hash used as a surrogate identifier for a record in a + database. Subject Identifiers in this format MUST contain an "id" + member whose value is a JSON string containing the opaque string + identifier for the subject. The "id" member is REQUIRED and MUST NOT + be null or empty. The Opaque Identifier Format is identified by the + name "opaque". + + Below is a non-normative example Subject Identifier in the Opaque + Identifier Format: + + { + "format": "opaque", + "id": "11112222333344445555" + } + + Figure 7: Example: Subject Identifier in the Opaque Identifier Format + +3.2.5. Phone Number Identifier Format + + The Phone Number Identifier Format identifies a subject using a + telephone number. Subject Identifiers in this format MUST contain a + "phone_number" member whose value is a string containing the full + telephone number of the subject, including an international dialing + prefix, formatted according to E.164 [E164]. The "phone_number" + member is REQUIRED and MUST NOT be null or empty. The Phone Number + Identifier Format is identified by the name "phone_number". + + Below is a non-normative example Subject Identifier in the Phone + Number Identifier Format: + + { + "format": "phone_number", + "phone_number": "+12065550100" + } + + Figure 8: Example: Subject Identifier in the Phone Number + Identifier Format + +3.2.6. Decentralized Identifier (DID) Format + + The Decentralized Identifier (DID) Format identifies a subject using + a DID URL as defined in [DID]. Subject Identifiers in this format + MUST contain a "url" member whose value is a DID URL for the DID + Subject being identified. The value of the "url" member MUST be a + valid DID URL and MAY be a bare DID. The "url" member is REQUIRED + and MUST NOT be null or empty. The Decentralized Identifier Format + is identified by the name "did". + + Below are non-normative example Subject Identifiers for the + Decentralized Identifier Format: + + { + "format": "did", + "url": "did:example:123456" + } + + Figure 9: Example: Subject Identifier for the Decentralized + Identifier Format, Identifying a Subject with a Bare DID + + { + "format": "did", + "url": "did:example:123456/did/url/path?versionId=1" + } + + Figure 10: Example: Subject Identifier for the Decentralized + Identifier Format, Identifying a Subject with a DID URL with Non- + empty Path and Query Components + +3.2.7. Uniform Resource Identifier (URI) Format + + The Uniform Resource Identifier (URI) Format identifies a subject + using a URI as defined in [RFC3986]. This Identifier Format makes no + assumptions or guarantees with regard to the content, scheme, or + reachability of the URI within the field. Subject Identifiers in + this format MUST contain a "uri" member whose value is a URI for the + subject being identified. The "uri" member is REQUIRED and MUST NOT + be null or empty. The URI Format is identified by the name "uri". + + Below are non-normative example Subject Identifiers for the URI + Format: + + { + "format": "uri", + "uri": "https://user.example.com/" + } + + Figure 11: Example: Subject Identifier for the URI Format, + Identifying a Subject with a Website URI + + { + "format": "uri", + "uri": "urn:uuid:4e851e98-83c4-4743-a5da-150ecb53042f" + } + + Figure 12: Example: Subject Identifier for the URI Format, + Identifying a Subject with a Random URN + +3.2.8. Aliases Identifier Format + + The Aliases Identifier Format describes a subject that is identified + with a list of different Subject Identifiers. It is intended for use + when a variety of identifiers have been shared with the party that + will be interpreting the Subject Identifier, and it is unknown which + of those identifiers they will recognize or support. Subject + Identifiers in this format MUST contain an "identifiers" member whose + value is a JSON array containing one or more Subject Identifiers. + Each Subject Identifier in the array MUST identify the same entity. + The "identifiers" member is REQUIRED and MUST NOT be null or empty. + It MAY contain multiple instances of the same Identifier Format + (e.g., multiple Email Subject Identifiers) but SHOULD NOT contain + exact duplicates. This format is identified by the name "aliases". + + "aliases" Subject Identifiers MUST NOT be nested, i.e., the + "identifiers" member of an "aliases" Subject Identifier MUST NOT + contain a Subject Identifier in the Aliases Identifier Format. + + Below is a non-normative example Subject Identifier in the Aliases + Identifier Format: + + { + "format": "aliases", + "identifiers": [ + { + "format": "email", + "email": "user@example.com" + }, + { + "format": "phone_number", + "phone_number": "+12065550100" + }, + { + "format": "email", + "email": "user+qualifier@example.com" + } + ] + } + + Figure 13: Example: Subject Identifier in the Aliases Identifier + Format + +4. Subject Identifiers in JWTs + +4.1. JWT "sub_id" Claim + + The JWT "sub" Claim is defined in Section 4.1.2 of [RFC7519] as + containing a string value; therefore, it cannot contain a Subject + Identifier (which is a JSON object) as its value. This document + defines the JWT "sub_id" Claim, in accordance with Section 4.2 of + [RFC7519], as a common claim that identifies the JWT Subject using a + Subject Identifier. When present, the value of this claim MUST be a + Subject Identifier that identifies the subject of the JWT. The JWT + "sub_id" Claim MAY be included in a JWT, whether or not the JWT "sub" + Claim is present. When both the JWT "sub" and "sub_id" Claims are + present in a JWT, they MUST identify the same subject, as a JWT has + one and only one JWT Subject. + + When processing a JWT with both JWT "sub" and "sub_id" Claims, + implementations MUST NOT rely on both claims to determine the JWT + Subject. An implementation MAY attempt to determine the JWT Subject + from one claim and fall back to using the other if it determines it + does not understand the format of the first claim. For example, an + implementation may attempt to use "sub_id" and fall back to using + "sub" upon finding that "sub_id" contains a Subject Identifier with a + format that is not recognized by the implementation. + + Below are non-normative examples of JWTs containing the JWT "sub_id" + Claim: + + { + "iss": "issuer.example.com", + "sub_id": { + "format": "email", + "email": "user@example.com" + } + } + + Figure 14: Example: JWT Containing a JWT "sub_id" Claim and No + "sub" Claim + + { + "iss": "issuer.example.com", + "sub": "user@example.com", + "sub_id": { + "format": "email", + "email": "user@example.com" + } + } + + Figure 15: Example: JWT Where the JWT "sub" and "sub_id" Claims + Identify the JWT Subject Using the Same Identifier + + { + "iss": "issuer.example.com", + "sub": "liz@example.com", + "sub_id": { + "format": "email", + "email": "elizabeth@example.com" + } + } + + Figure 16: Example: JWT Where the JWT "sub" and "sub_id" Claims + Identify the JWT Subject Using Different Values of the Same + Identifier Type + + { + "iss": "issuer.example.com", + "sub": "user@example.com", + "sub_id": { + "format": "account", + "uri": "acct:example.user@service.example.com" + } + } + + Figure 17: Example: JWT Where the JWT "sub" and "sub_id" Claims + Identify the JWT Subject via Different Types of Identifiers + +4.2. JWT "sub_id" Claim and "iss_sub" Subject Identifier + + The JWT "sub_id" Claim MAY contain an "iss_sub" Subject Identifier. + In this case, the JWT's "iss" Claim and the Subject Identifier's + "iss" member MAY be different. For example, an OpenID Connect + [OpenID.Core] client may construct such a JWT when sending JWTs back + to its OpenID Connect Identity Provider in order to identify the JWT + Subject using an identifier known to be understood by both parties. + Similarly, the JWT's "sub" Claim and the Subject Identifier's "sub" + member MAY be different. For example, this may be used by an OpenID + Connect client to communicate the JWT Subject's local identifier at + the client back to its Identity Provider. + + Below are non-normative examples of a JWT where the JWT "iss" Claim + and "iss" member within the JWT "sub_id" Claim are the same and a JWT + where they are different. + + { + "iss": "issuer.example.com", + "sub_id": { + "format": "iss_sub", + "iss": "issuer.example.com", + "sub": "example_user" + } + } + + Figure 18: Example: JWT with an "iss_sub" Subject Identifier + Where the JWT Issuer and JWT Subject Issuer Are the Same + + { + "iss": "client.example.com", + "sub_id": { + "format": "iss_sub", + "iss": "issuer.example.com", + "sub": "example_user" + } + } + + Figure 19: Example: JWT with an "iss_sub" Subject Identifier + Where the JWT Issuer and JWT Subject Issuer Are Different + + { + "iss": "client.example.com", + "sub": "client_user", + "sub_id": { + "format": "iss_sub", + "iss": "issuer.example.com", + "sub": "example_user" + } + } + + Figure 20: Example: JWT with an "iss_sub" Subject Identifier + Where the JWT "iss" and "sub" Claims Differ from the JWT + Subject's "iss" and "sub" Members + +5. Considerations for Specifications that Define Identifier Formats + + Identifier Format definitions MUST NOT make assertions or + declarations regarding the subject being identified by the Subject + Identifier (e.g., an Identifier Format cannot be defined as + specifically identifying human end users). Such statements are + outside the scope of Identifier Formats and Subject Identifiers. + Expanding that scope for some Identifier Formats but not others would + harm interoperability because applications that depend on this + expanded scope to disambiguate the subject type would be unable to + use Identifier Formats that do not provide such rules. + +6. Privacy Considerations + +6.1. Identifier Correlation + + The act of presenting two or more identifiers for a single subject + together (e.g., within an "aliases" Subject Identifier or via the JWT + "sub" and "sub_id" Claims) may communicate more information about the + subject than was intended. For example, the entity to which the + identifiers are presented now knows that both identifiers relate to + the same subject and may be able to correlate additional data based + on that. When transmitting Subject Identifiers, the transmitter + SHOULD take care that they are only transmitting multiple identifiers + together when it is known that the recipient already knows that the + identifiers are related (e.g., because they were previously sent to + the recipient as claims in an OpenID Connect ID Token) or when + correlation is essential to the use case. Implementers must consider + such risks, and specifications that use Subject Identifiers must + provide appropriate privacy considerations of their own. + + The considerations described in Section 6 of [RFC8417] also apply + when Subject Identifiers are used within SETs. The considerations + described in Section 12 of [RFC7519] also apply when Subject + Identifiers are used within JWTs. + +7. Security Considerations + + This specification does not define any mechanism for ensuring the + confidentiality or integrity of a Subject Identifier. Where such + properties are required, implementations MUST use mechanisms provided + by the containing format (e.g., integrity protecting SETs or JWTs + using JSON Web Signature (JWS) [RFC7515]) or at the transport layer + or other layer in the application stack (e.g., using TLS [RFC8446]). + + Further considerations regarding confidentiality and integrity of + SETs can be found in Section 5.1 of [RFC8417]. + +8. IANA Considerations + +8.1. Security Event Identifier Formats Registry + + This document defines Identifier Formats, for which IANA has created + and maintains a new registry titled "Security Event Identifier + Formats". Initial values for the "Security Event Identifier Formats" + registry are given in Section 3. Future assignments are to be made + through the Specification Required registration policy [BCP26] and + shall follow the template presented in Section 8.1.1. + + 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. + +8.1.1. Registration Template + + Format Name: + The name of the Identifier Format, as described in Section 3. The + name MUST be an ASCII string consisting only of lowercase + characters ("a" - "z"), digits ("0" - "9"), underscores ("_"), and + hyphens ("-") and SHOULD NOT exceed 20 characters in length. + + Format Description: + A brief description of the Identifier Format. + + Change Controller: + For formats defined in documents published by the IETF or its + working groups, list "IETF". For all other formats, list the name + of the party responsible for the registration. Contact + information, such as mailing address, email address, or phone + number, must also be provided. + + Reference: + A reference to the document or documents that define the + Identifier Format. The reference document(s) MUST specify the + name, format, and meaning of each member that may occur within a + Subject Identifier of the defined format as well as whether each + member is optional, required, or conditional and the circumstances + under which these optional or conditional fields would be used. + URIs that can be used to retrieve copies of each document SHOULD + be included. + +8.1.2. Initial Registry Contents + +8.1.2.1. Account Identifier Format + + Format Name: account + Format Description: Subject Identifier based on "acct" URI + Change Controller: IETF + Reference: Section 3 of RFC 9493 + +8.1.2.2. Email Identifier Format + + Format Name: email + Format Description: Subject Identifier based on an email address + Change Controller: IETF + Reference: Section 3 of RFC 9493 + +8.1.2.3. Issuer and Subject Identifier Format + + Format Name: iss_sub + Format Description: Subject Identifier based on an issuer and + subject + Change Controller: IETF + Reference: Section 3 of RFC 9493 + +8.1.2.4. Opaque Identifier Format + + Format Name: opaque + Format Description: Subject Identifier based on an opaque string + Change Controller: IETF + Reference: Section 3 of RFC 9493 + +8.1.2.5. Phone Number Identifier Format + + Format Name: phone_number + Format Description: Subject Identifier based on a phone number + Change Controller: IETF + Reference: Section 3 of RFC 9493 + +8.1.2.6. Decentralized Identifier Format + + Format Name: did + Format Description: Subject Identifier based on a decentralized + identifier (DID) + Change Controller: IETF + Reference: Section 3 of RFC 9493 + +8.1.2.7. Uniform Resource Identifier Format + + Format Name: uri + Format Description: Subject Identifier based on a Uniform Resource + Identifier (URI) + Change Controller: IETF + Reference: Section 3 of RFC 9493 + +8.1.2.8. Aliases Identifier Format + + Format Name: aliases + Format Description: Subject Identifier that groups together multiple + different Subject Identifiers for the same subject + Change Controller: IETF + Reference: Section 3 of RFC 9493 + +8.1.3. Guidance for Expert Reviewers + + The Expert Reviewer is expected to review the documentation + referenced in a registration request to verify its completeness. The + Expert Reviewer must base their decision to accept or reject the + request on a fair and impartial assessment of the request. If the + Expert Reviewer has a conflict of interest, such as being an author + of a defining document referenced by the request, they must recuse + themselves from the approval process for that request. + + Identifier Formats need not be generally applicable and may be highly + specific to a particular domain; it is expected that formats may be + registered for niche or industry-specific use cases. The Expert + Reviewer should focus on whether the format is thoroughly documented + and whether its registration will promote or harm interoperability. + In most cases, the Expert Reviewer should not approve a request if + the registration would contribute to confusion or amount to a synonym + for an existing format. + +8.2. JSON Web Token Claims Registration + + This document defines the JWT "sub_id" Claim, which IANA has + registered in the "JSON Web Token Claims" registry [IANA.JWT.Claims] + established by [RFC7519]. + +8.2.1. Registry Contents + + Claim Name: sub_id + Claim Description: Subject Identifier + Change Controller: IETF + Reference: Section 4.1 of RFC 9493 + +9. References + +9.1. Normative References + + [BCP26] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, June 2017. + + <https://www.rfc-editor.org/info/bcp26> + + [DID] Sporny, M., Ed., Guy, A., Ed., Sabadello, M., Ed., Reed, + D., Ed., Longley, D., Steele, O., and C. Allen, + "Decentralized Identifiers (DIDs) v1.0", July 2022, + <https://www.w3.org/TR/did-core/>. + + [E164] ITU-T, "E.164: The international public telecommunication + numbering plan", ITU-T Recommendation E.164, November + 2010, <https://www.itu.int/rec/T-REC-E.164-201011-I/en>. + + [IANA.JWT.Claims] + IANA, "JSON Web Token Claims", + <https://www.iana.org/assignments/jwt>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, DOI 10.17487/RFC3986, January 2005, + <https://www.rfc-editor.org/info/rfc3986>. + + [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + DOI 10.17487/RFC5321, October 2008, + <https://www.rfc-editor.org/info/rfc5321>. + + [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, + DOI 10.17487/RFC5322, October 2008, + <https://www.rfc-editor.org/info/rfc5322>. + + [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token + (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, + <https://www.rfc-editor.org/info/rfc7519>. + + [RFC7565] Saint-Andre, P., "The 'acct' URI Scheme", RFC 7565, + DOI 10.17487/RFC7565, May 2015, + <https://www.rfc-editor.org/info/rfc7565>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data + Interchange Format", STD 90, RFC 8259, + DOI 10.17487/RFC8259, December 2017, + <https://www.rfc-editor.org/info/rfc8259>. + + [RFC8417] Hunt, P., Ed., Jones, M., Denniss, W., and M. Ansari, + "Security Event Token (SET)", RFC 8417, + DOI 10.17487/RFC8417, July 2018, + <https://www.rfc-editor.org/info/rfc8417>. + +9.2. Informative References + + [OpenID.Core] + Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., and + C. Mortimore, "OpenID Connect Core 1.0 incorporating + errata set 1", November 2014, + <https://openid.net/specs/openid-connect-core-1_0.html>. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, + <https://www.rfc-editor.org/info/rfc1034>. + + [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web + Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May + 2015, <https://www.rfc-editor.org/info/rfc7515>. + + [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol + Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, + <https://www.rfc-editor.org/info/rfc8446>. + +Acknowledgements + + The authors would like to thank the members of the IETF Security + Events Working Group, as well as those of the OpenID Shared Signals + and Events Working Group, whose work provided the original basis for + this document. We would also like to acknowledge Aaron Parecki, + Denis Pinkas, Justin Richer, Mike Jones, and other members of the + working group for reviewing this document. + +Authors' Addresses + + Annabelle Backman (editor) + Amazon + Email: richanna@amazon.com + + + Marius Scurtescu + Coinbase + Email: marius.scurtescu@coinbase.com + + + Prachi Jain + Fastly + Email: prachi.jain1288@gmail.com |