sub_
Registry Context
Identifies the subject of a JWT using a structured Subject Identifier.
Technical Summary
The "sub_id" claim contains a JSON Subject Identifier conforming to a named Identifier Format. It can appear with or without the "sub" claim; if both appear, they identify the same JWT subject.
When Used
When the JWT subject needs to be identified using structured information that cannot be represented by the string-valued "sub" claim.
Normative Requirements
Identifier Format definer
RFC 9493 - Section 3
use a unique format name registered in the Security Event Identifier Formats registry or a Collision-Resistant Name.
Section 3 explicitly uses MUST for every Identifier Format name.
JWT processor
RFC 9493 - Section 4.1
rely on both the "sub" and "sub_id" claims to determine the JWT subject.
Condition: when both claims are present
The section explicitly uses MUST NOT for reliance on both claims.
RFC 9493 - Section 4.1
attempt to determine the JWT subject from one claim and fall back to the other if the first claim's format is not understood.
Condition: when both "sub" and "sub_id" are present
The section explicitly uses MAY for this fallback behavior.
JWT producer
RFC 9493 - Section 4.1
set the "sub_id" value to a Subject Identifier that identifies the subject of the JWT.
Condition: when the "sub_id" claim is present
The section explicitly uses MUST for the claim value and its identification of the JWT subject.
RFC 9493 - Section 4.1
ensure that the "sub" and "sub_id" claims identify the same subject.
Condition: when both claims are present
The section explicitly uses MUST because a JWT has only one JWT Subject.
RFC 9493 - Section 4.1
include the "sub_id" claim regardless of whether the JWT also contains the "sub" claim.
The section explicitly permits inclusion whether or not "sub" is present using MAY.
Subject Identifier producer
RFC 9493 - Section 3
include members prohibited or not described by the applicable Identifier Format.
Section 3 explicitly uses MUST NOT for prohibited or undescribed members.
RFC 9493 - Section 3
make the Subject Identifier conform to a specific Identifier Format and include a "format" member naming that format.
Section 3 explicitly uses MUST for format conformance and the "format" member.
RFC 9493 - Section 3
ensure every member matches the rules defined by RFC 9493 or the applicable Identifier Format.
Section 3 explicitly uses MUST for member conformance.
RFC 9493 - Section 3
include every member required by the applicable Identifier Format.
Section 3 explicitly uses MUST for required members.
Subject Identifier transmitter
RFC 9493 - Section 6.1
transmit multiple identifiers together only when the recipient is known already to understand their relationship or when correlation is essential.
Condition: when presenting multiple identifiers for one subject, including through both "sub" and "sub_id"
Section 6.1 explicitly uses SHOULD to limit transmission of correlated identifiers.
Validation Guidance
When "sub_id" is present, require a JSON Subject Identifier that identifies the JWT subject.
Permit "sub_id" whether or not "sub" is present.
If both "sub" and "sub_id" are present, verify that they identify the same subject.
Do not require successful processing of both claims to determine the JWT subject; permit one-claim processing with fallback when appropriate.
Validate that "sub_id" contains a "format" member naming a valid Identifier Format and that all other members conform to that format, with no prohibited, undescribed, or missing required members.
Flag unnecessary disclosure of both "sub" and "sub_id" when the recipient is not already known to understand their relationship and correlation is not essential.
Reference
Details
- Entry Id
sub_id - Claim Name
sub_id - Claim Description
Subject Identifier- Change Controller
IETF- Reference
RFC9493 - Section 4.1