Subject Identifiers for Security Event Tokens
Extracted elements (24)
Identifier Formats define how to encode identifying information but do not define the type or nature of the subject itself. This separation is intentional: expanding scope for some formats but not others would harm interoperability for applications that depend on subject-type disambiguation.
The "aliases" format exists for use when a variety of identifiers have been shared with the interpreting party and it is unknown which they will recognize or support. It intentionally allows multiple instances of the same Identifier Format (e.g., two email addresses) but SHOULD NOT contain exact duplicates.
The JWT "sub" Claim is defined in RFC 7519 as a string and cannot contain a JSON object; this motivated defining the separate "sub_id" Claim to carry Subject Identifiers. Both claims MAY coexist, enabling gradual adoption by implementations that may fall back from "sub_id" to "sub".
Email canonicalization is not standardized: many providers treat the local part as case-insensitive and may treat dots as optional. Recipients SHOULD apply their own canonicalization algorithm to incoming events to reproduce translations done by the local email system.
"aliases" Subject Identifiers MUST NOT be nested: the "identifiers" member of an "aliases" Subject Identifier MUST NOT contain another Subject Identifier in the Aliases Identifier Format.
Applications SHOULD choose the most specific possible Identifier Format for a given identifier. For example, an email address that could be conveyed as a "mailto:" URI SHOULD instead use the Email Identifier Format rather than the URI Format.
Every Identifier Format MUST have a unique name registered in the IANA "Security Event Identifier Formats" registry or a Collision-Resistant Name as defined in RFC 7519. Formats expected to be used broadly SHOULD be registered in the IANA registry.
Every member within a Subject Identifier MUST match the rules specified for that member by the Identifier Format. A Subject Identifier MUST NOT contain any members prohibited or not described by its Identifier Format and MUST contain all required members.
Identifier Format definitions MUST NOT make assertions or declarations regarding the type or nature of the subject being identified (e.g., cannot declare that a format specifically identifies human end users), as such statements are outside the scope of Identifier Formats.
When both the JWT "sub" and "sub_id" Claims are present in a JWT, they MUST identify the same subject. Implementations MUST NOT rely on both claims simultaneously to determine the JWT Subject.
Presenting two or more identifiers for a single subject together (e.g., in an "aliases" Subject Identifier or via "sub" and "sub_id") may communicate more information than intended, enabling correlation. Transmitters SHOULD only send multiple identifiers together when the recipient is already known to know they are related, or when correlation is essential.
A Subject Identifier is a JSON object whose contents may be used to identify a subject within some context. It MUST conform to a specific Identifier Format and MUST contain a "format" member whose value is the name of that Identifier Format.
The Account Identifier Format (name: "account") identifies a subject using an "acct" URI as defined in RFC 7565. It MUST contain a "uri" member whose value is the "acct" URI; the member is REQUIRED and MUST NOT be null or empty.
The Aliases Identifier Format (name: "aliases") groups multiple Subject Identifiers for the same subject in an "identifiers" JSON array. Each identifier MUST identify the same entity; "aliases" Subject Identifiers MUST NOT be nested.
The Decentralized Identifier Format (name: "did") identifies a subject using a DID URL as defined in the W3C DID specification. The "url" member is REQUIRED, MUST NOT be null or empty, MUST be a valid DID URL, and MAY be a bare DID.
The Email Identifier Format (name: "email") identifies a subject using an email address formatted as an "addr-spec" per RFC 5322. The "email" member is REQUIRED, MUST NOT be null or empty, and MUST identify a mailbox to which email may be delivered per RFC 5321.
The Issuer and Subject Identifier Format (name: "iss_sub") identifies a subject using a pair of "iss" and "sub" members following the formats defined by RFC 7519. Both members are REQUIRED and MUST NOT be null or empty.
The JWT "sub_id" Claim is defined as a common claim that identifies the JWT Subject using a Subject Identifier (a JSON object). When present, its value MUST be a Subject Identifier that identifies the subject of the JWT.
The Opaque Identifier Format (name: "opaque") identifies a subject with a string with no asserted semantics beyond its use as an identifier (e.g., a UUID or hash). It MUST contain an "id" member that is a non-null, non-empty JSON string.
The Phone Number Identifier Format (name: "phone_number") identifies a subject using a full telephone number including international dialing prefix, formatted according to E.164. The "phone_number" member is REQUIRED and MUST NOT be null or empty.
The URI Format (name: "uri") identifies a subject using a URI as defined in RFC 3986, making no assumptions about scheme or reachability. The "uri" member is REQUIRED and MUST NOT be null or empty.
This document establishes the IANA "Security Event Identifier Formats" registry with eight initial entries (account, email, iss_sub, opaque, phone_number, did, uri, aliases). Future assignments use the Specification Required policy.
This document registers the JWT "sub_id" Claim in the IANA "JSON Web Token Claims" registry established by RFC 7519, with claim description "Subject Identifier" and change controller IETF.
This specification defines no mechanism for ensuring confidentiality or integrity of a Subject Identifier. Where such properties are required, implementations MUST use mechanisms provided by the containing format (e.g., JWS for SETs or JWTs) or at the transport or application layer (e.g., TLS).