Code change:
Updated the text to more clearly profile the token exchange specification for use with Transaction Tokens.
In PR , the token exchange parameter is profiled to carry the purpose or intent of the transaction and its value is copied into the claim of the resulting Txn-Token. Is this how we want to handle the 'purp' claim?
I propose that the draft should allow value of the claim in the TraT request be independent of the claim in the TraT, because the requesting service may not know sufficient details about how the TraT is actually going to be used. For example, the requester may say the is "buy stock", whereas the claim could have a value like "equity trade"
Ok, so allow the TTS to transform the input scope to the appropriate value (if necessary). I'm ok with that.
Recommended change that the TTS MUST take the value of the parameter to determine the claim of the TraT.
Based on this feedback, the claim is being made REQUIRED.
Should we allow the use of and to be used as a means of client authentication for the Transaction Token Service? If not, should explicitly prohibit the use of these parameters in the profile of the Token Exchange spec.
Since RFC8693 (Token Exchange) refers to the as "A security token that represents the identity of the acting party", we should not use it in the TraT request. I thought we wanted to have some way to convey the inbound token to the TraT service, and that's why we were using , but that is inconsistent with RFC8693. I think we should neither require nor disallow the use of because some implementations may want that for client auth, and some implementations may want to do something else (e.g. mTLS) for client auth.
This is kind of what the spec says today. It's not required and up to the implementation. It is just referenced as an example. However, I'm fine removing the example and just being silent in the spec on the topic.
Recommendation to update example and be silent on use of and . Add a section to Security Considerations to talk about client authentication and add some non-normative examples.
Removed the additional text regarding possible client authentication methods and just left it that the client MUST authenticate itself to the Transaction Token Service and that the specific client authentication method is out of scope for this specification.
PR raised a number of issues around processing of authorization details How are these details determined by the Transaction Token Service (i.e. where do they come from)? Should all the claims be visible to all workloads? or should they be restricted to a subset of workloads? Who is authoritative for specifying the claims of the object
Some thoughts: I think the spec should be un-opinionated about how the TraT service generates the value of claim. I can see in some instances that the requester has more control over what goes into the claim, and in some cases, the TraT service has more control. A TraT service could implement selective disclosure, although we could recommend in the spec that one should implement it by encrypting certain fields. Stating this makes the actual mechanism for selective disclosure outside the scope of the spec. I believe the TraT service MUST be authoritative for the claims of the object, because it is signing the TraT.
Regarding (1) -- I think we still need a way for the client to pass in data to the TTS that it can use to generate the values. Even if how all that works is out of scope for the specificatio. Regarding (2) and (3) -- I'm ok with leaving the rules out of scope for the specification. The TTS will be authoritative for the resulting object and whether it should be protected in some way or not. I am curious to hear from others as to their thoughts.
Suggestion to rename to and then add a processing rule to the effect of... "The TTS SHOULD propagate the data from the object into claims in the object as authorized by the TTS authorization policy for the requesting client"
This has been fixed AFAIK. Please reopen the issue if it hasn't been fixed by George's PR.
I suspect in many cases the AS that issues an accesstoken used to obtain an Txn-Token is going to be different than the Transaction Token Service. In that context, the issuer of the 'subject' of the transaction token is different than the issuer of the transaction token itself. Section 3.2.3 of RFC 9493 allows for the specification of an issuer and sub within the object. Should we require this format? or just leave out of scope of the specification what values are present in the claim of the transaction token?
I would definitely not require that format. And would again suggest that RFC 9493 isn't needed in the Txn-Token context and good enough.
My concern with relying on the JWT's subject is that the Transaction Token is issued by the Transaction Token Service which is potentially different than the AS that say issued the access token from which the claim is determined. In that context, I think the Transaction Token should carry the issuer of the claim which means the default and claims of the JWT are not sufficient. Or if the entity requesting the Transaction token is the service that receives inbound mail, and that service wants a transaction token with a purpose of , is the Transaction Token Service the correct issuer of the which is an email address?
I feel like there might be an undue emphasis on a relationship between and that doesn't truly exist. RFC7519 only mentions uniqueness in the context of an issuer URL but not ownership or correctness or semantic meaning.
In the context of OpenID and id_tokens there is a clear relationship between the and the such that the globally unique identification is the combination of and . I've always viewed the relationship of those two claims in that light. Maybe that is an OpenID Connect centric view.
Yeah, I am somewhat familiar with OpenID Connect ;) But this isn't OpenID Connect. With a Transaction Token the subject just needs to be identified within a single trust domain.
So that assumes that the claim MUST be unique within the single trust domain as identified by the claim. This might require the Transaction Token Service (TTS) to do some sort of identifier transformation as well as requiring both the AS and the TTS to both be authoritative for the claim value. This is easy if the AS is managing the transaction token request endpoint but if the TTS is it's own service and deployed in a distributed way, would that still be true? I can see the TTS being authoritative for the single trust domain but not necessarily for the identifier. However, I'm ok with moving in the direction you are suggesting Brian; I just want to make sure we aren't prohibiting some deployments by making that simplification.
From discussion... 'iss' claim is optional be clear that there is no relationship between iss and sub claim sub is unique within context of the 'aud' or trust domain go back just supporting the claim (no sub_id)
Added a new commit to PR to address this issue.
A few months ago, I also suggested to support the sub claim as per JWT RFC. 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

Related discussion:
text: 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: