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: the computational entity that requested the Txn-Token.  This entity MUST be within the Trust Domain of the Txn-Token. <del> 5.2.2.2. The Txn-Token MAY contain a "purp" claim, whose value specifies the purpose of the transaction.  The format of this claim is a JSON string. 5.2.3. </del> <ins> 5.2.2. </ins> The figure below figleaftxtokenbody shows a non-normative example of the JWT body of a Txn-Token: 6. <del> A Txn-Token Service provides a OAuth 2.0 Token Exchange RFC8693 endpoint that can respond to Txn-Token issuance requests.  The token exchange requests it supports require extra parameters than those defined in the OAuth 2.0 Token Exchange RFC8693 specification.  The unique properties of the Txn-Token requests and responses are described below.  The Txn-Token Service MAY optionally support other OAuth 2.0 endpoints and features, but that is not a requirement for it to be a Txn-Token Service. </del> <ins> A Txn-Token Service defines a profile of the OAuth 2.0 Token Exchange RFC8693 endpoint that can respond to Txn-Token issuance requests. This profile of the OAuth 2.0 Token Exchange RFC8693 specification MUST be used to obtain Txn-Tokens.  The unique properties of the Txn- Token requests and responses are described below.  The Txn-Token Service MAY optionally support other OAuth 2.0 endpoints and features, but that is not a requirement for it to be a Txn-Token Service. </ins> <del> Each Trust Domain MUST have exactly one Txn-Token Service. </del> <ins> Each Trust Domain MUST have exactly one logical Txn-Token Service. </ins> 7. A workload requests a Txn-Token from a Transaction Token Service <del> using OAuth 2.0 Token Exchange RFC8693.  The request to obtain a Txn- </del> <ins> using a profile of the OAuth 2.0 Token Exchange RFC8693.  Txn-Tokens may be requested for both externally originating or internally originating requests.  The profile describes how required and optional context can be provided to the Transaction Token Service in order for the Txn-Token to be issued.  The request to obtain a Txn- </ins> Token using this method is called a Txn-Token Request, and a <del> successful response is called a Txn-Token Response.  A Txn-Token Request is a Token Exchange Request, as described in Section 2.1 of RFC8693 with additional parameters.  A Txn-Token Response is a OAuth 2.0 token endpoint response, as described in Section 5 of RFC6749, where the "token_type" in the response has the value "txn_token". </del> <ins> successful response is called a Txn-Token Response.  The Txn-Token profile of the OAuth 2.0 Token Exchange RFC8693 is described below. </ins> 7.1. <del> A Txn-Token Request is an OAuth 2.0 Token Exchange Request, as described in Section 2.1 of RFC8693, with an additional parameter in the request.  The following parameters are required in the Txn-Token Request by the OAuth 2.0 Token Exchange specification RFC8693: The "audience" value MUST be set to the Trust Domain name The "requested_token_type" value MUST be "urn:ietf:params:oauth:token-type:txn_token" The "subject_token" value MUST be the external token received by the workload that authorized the call </del> <ins> A workload requesting a Txn-Token must provide the Transaction Token Service with proof of its identity (client authentication), the purpose of the Txn-Token and optionally any additional context relating to the transaction being performed.  Most of these elements are provided by the OAuth 2.0 Token Exchange specification and the rest are defined as new parameters.  Additionally, this profile defines a new token type URN "urn:ieft:params:oauth:token-type:txn- token" which is used by the requesting workload to identify that it is requesting the Txn-Token Response to contain a Txn-Token. To request a Txn-Token the workload invokes the OAuth 2.0 RFC6749 token endpoint with the following parameters: * "grant_type" REQUIRED.  The value MUST be set to "urn:ietf:params:oauth:grant- type:token-exchange" * "audience" REQUIRED.  The value MUST be set to the Trust Domain name * "scope" REQUIRED.  A space-delimited list of case-sensitive strings where the value(s) MUST represent the specific purpose or intent of the transaction.  * "requested_token_type" REQUIRED.  The value MUST be "urn:ietf:params:oauth:token-type:txn- token" * "subject_token" REQUIRED.  The value MUST be a token representing the subject of the transaction.  This could be an OAuth access_token received by an API Gateway or a JWT assertion constructed by a workload initiating a transaction or another form of token as identified by "subject_token_type".  * "subject_token_type" REQUIRED.  The value MUST indicate the type of the token present in the "subject_token" parameter The following additional parameters MAY be present in a Txn-Token Request: </ins> <del> The "subject_token_type" value MUST be present and indicate the type of the authorization token present in the "subject_token" parameter </del> <ins> "request_context" OPTIONAL.  This parameter contains a base64url encoded JSON object which represents the context of this transaction.  The parameter SHOULD be present and how the Transaction Token Service uses this parameter is out of scope for this specification. </ins> <del> The following additional parameter MUST be present in a Txn-Token Request: </del> <ins> "request_details" OPTIONAL.  This parameter contains a base64url encoded JSON object which represents additional details of the transaction that MUST remain immutable throughout the processing of the transaction by multiple workloads. </ins> <del> A parameter named "rctx" , whose value is a JSON object.  This object contains the request context, i.e. any information the Transaction Token Service needs to understand the context of the incoming request </del> <ins> The requesting workload MUST authenticate its identity to the Transaction Token Service.  The exact client authentication mechanism used is outside the scope of this specification. </ins> figtxtokenrequest shows a non-normative example of a Txn-Token Request. 7.2. <ins> When the Transaction Token Service receives a Txn-Token Request it MUST validate the requesting workload client authentication and determine if that workload is authorized to obtain the Txn-Tokens with the requested values.  The authorization policy for determining such issuance is out of scope for this specification. Next, the Transaction Token Service MUST validate the "subject_token" and determine the value to specify as the "sub" of the issued Txn- Token.  The Txn-Token Service MUST ensure the "sub" value is unique within the trust domain defined by the "aud" claim. The Transaction Token Service MUST set the "iat" claim to the time of issuance of the Txn-Token.  The Transaction Token Service MUST set the "aud" claim to a Trust Domain of the Transaction Token Service. If the Transaction Token Service supports multiple trust domains, then it MUST determine the correct "aud" value for this request.  The Transaction Token Service MUST set the "exp" claim to the expiry time of the Txn-Token.  The Transaction Token Service MUST set the "txn" claim to a unique ID specific to this transaction. The Transaction Token Service MAY set the "iss" claim of the Txn- Token to a value defining the entity that signed the Txn-Token.  This claim MUST be ommitted if not set. The Transaction Token Service MUST evaluate the value specified in the "scope" parameter of the request to determine the "purp" claim of the issued Txn-Token. If a "request_context" parameter is present in the Txn-Token Request, the data SHOULD be added to the "rctx" object of the Txn-Token.  In addition, the Transaction Token Service SHOULD add the authenticated requesting workload identifier in the "rctx" object as the "req_wl" claim. If a "request_details" parameter is present in the Txn-Token Request, then the Transaction Token Service SHOULD propagate the data from the "request_details" object into the claims in the "azd" object as authorized by the Transaction Token Service authorization policy for the requesting client. The Transaction Token Service MAY provide additional processing and verification that is outside the scope of this specification. 7.3. </ins> A successful response to a Txn-Token Request by a Transaction Token Service is called a Txn-Token Response.  If the Transaction Token Service responds with an error, the error response is as described in Section 5.2 of RFC6749.  The following describes required values of a Txn-Token Response: <del> The "token_type" value MUST be set to "txn_token" </del> <ins> The "token_type" value MUST be set to "N_A" per guidance in OAuth 2.0 Token Exchange </ins> <del> The "access_token" value MUST be the Txn-Token </del> <ins> The "access_token" value MUST be the Txn-Token JWT The "issued_token_type" value MUST bet set to "urn:ieft:params:oauth:token-type:txn-token" </ins> The response MUST NOT include the values "expires_in", "refresh_token" and "scope"