Code change:
5.2. <del> 5.2.1. The JWT body MUST have the following claims: </del> <ins> The transaction token body follows the JWT format and includes existing JWT claims as well as defines new claims.  These claims are described below: </ins> <del> An "iss" claim, whose value is a URN RFC8141 that uniquely identifies the workload or the Txn-Token Service that created the Txn-Token. </del> <ins> OPTIONAL The "iss" claim as defined in RFC7519 is not required as Txn-Tokens are bound to a single trust domain as defined by the "aud" claim and often the signing keys are known.  The "iss" claim MUST be used in cases where the signing keys are not predetermined or it is desired that the Txn-Token Service signs with unique keys. </ins> <del> An "iat" claim, whose value is the time at which the Txn-Token was created. </del> <ins> REQUIRED The issued at time of the Txn-Token as defined in </ins> <del> An "aud" claim, whose value is a URN RFC8141 that uniquely identifies the audience of the Txn-Token.  This MUST identify the trust domain in which the Txn-Token is used. </del> <ins> REQUIRED This claim, defined in RFC7519, contains the trust domain in which the Txn-Token is valid </ins> <del> An "exp" claim, whose value is the time at which the Txn-Token expires. </del> <ins> REQUIRED Expiry time of the Txn-Token as defined in </ins> <del> A "txn" claim, whose value is the unique transaction identifier as defined in Section 2.2 of RFC8417.  When used in the transaction token, it identifies the entire call chain. </del> <ins> REQUIRED A unique transaction identifier as defined in Section 2.2 of RFC8417.  When used in the transaction token, it identifies the entire call chain. </ins> <del> A "sub_id" claim, whose value is the unique identifier of the user or workload on whose behalf the call chain is being executed.  The format of this claim MAY be a Subject Identifier as specified in SubjectIdentifiers. </del> <ins> REQUIRED A unique identifier for the subject as defined by the "aud" trust domain.  Unlike OpenID Connect, the "sub" claim is NOT associated with the "iss" claim. </ins> <del> An "azd" claim, whose value is a JSON object that contains values that remain constant in the call chain. </del> <ins> REQUIRED A string defining the purpose or intent of this transaction. </ins> <del> 5.2.2. </del> <ins> OPTIONAL A JSON object that conatains values that remain immutable throughout the call chain. </ins> <del> The JWT body MAY have the following claims: </del> <ins> OPTIONAL A JSON object that describes the environmental context of the requested transaction. </ins> <del> 5.2.2.1. </del> <ins> 5.2.1. </ins> <del> The Txn-Token MAY contain an "req_ctx" claim, whose value is a JSON object the describes the requester context of the transaction.  This MAY include the IP address information of the originating user, as well as information about the computational entity that requested the Txn-Token. </del> <ins> The Txn-Token SHOULD contain an "rctx" claim.  This MAY include the IP address information of the originating user, as well as information about the computational entity that requested the Txn- Token. </ins> <del> The JSON value of the "req_ctx" claim MAY include any values the Txn- </del> <ins> The JSON value of the "rctx" claim MAY include any values the Txn- </ins> Token Service determines are interesting to downstream services that rely on the Txn-Token.  The following claims are defined so that if they are included, they have the following meaning:

Related discussion:
text: As the current spec has replaced sub_id with sub, I appreciate that the sub claim is supported now.
Hi Kai, Thanks so much for your input in this process. Atul
Since we have removed sub_ids now, I will close this issue.
Wkn