jiebi/CodeConvo huggingface dataset:
Code change:
Added text to address issue
The following text in 2.2.2 is too open ended and should be refactored. First, the text should include specific guidance on replacement tokens to require scopes to remain the same or be down-scoped on replacement. Second, the draft should include a mechanism to ensure that scopes cannot be increased, or an increase in scope can be detected by downstream services. Finally, add text to the security considerations section regarding the risks of replacement tokens and/or a malicious txn-token-sts.
As far as I understand it, replacement txn-tokens is just a profile to Token Exchange. The Token Exchange RFC defines that an issued token can only have the same or a smaller scope than the presented token. I would assume this applies to replacement tokens as well. If the replacement token mechanism is intended to deviate from Token Exchange in this regard, this should probably be mentioned specifically.
NAME please review PR and see if I addressed your comments.
Completed. Looks good to me.
LGTM.

Related discussion:
text: specification RFC8693 are also not used in Txn-Token responses.  The "expires_in" is not required since the issued token has an "exp" field, which indicates the token lifetime.  The "scope" field is <del> omitted from the request and therefore omitted in the response. </del> <ins> omitted from the response in favor of the "purp" claim in the Txn- Token. </ins> 9.2.
Code change:
Added text to address issue
The following text in 2.2.2 is too open ended and should be refactored. First, the text should include specific guidance on replacement tokens to require scopes to remain the same or be down-scoped on replacement. Second, the draft should include a mechanism to ensure that scopes cannot be increased, or an increase in scope can be detected by downstream services. Finally, add text to the security considerations section regarding the risks of replacement tokens and/or a malicious txn-token-sts.
As far as I understand it, replacement txn-tokens is just a profile to Token Exchange. The Token Exchange RFC defines that an issued token can only have the same or a smaller scope than the presented token. I would assume this applies to replacement tokens as well. If the replacement token mechanism is intended to deviate from Token Exchange in this regard, this should probably be mentioned specifically.
NAME please review PR and see if I addressed your comments.
Completed. Looks good to me.
LGTM.

Related discussion:
text: request.  The "actor_token" MUST authenticate the identity of the requesting workload. <ins> 9.4. Validation of a replacement Txn-Token, as well as any Txn-Token, is critical to the security of the entire transaction invocation sequence.  Only Txn-Tokens issued by a trusted Transaction Token Service may be trusted, so verification of the Txn-Token signature is required.  For replacement transaction tokens, not only must the JWT signature be verified but also the workload identity of the workload requesting the replacement Txn-Token. 9.5. The authorization model within a trust domain boundary is most often quite different from the authorization model (e.g.  OAuth scopes) used with client external to the trust domain.  This makes managing unintentional scope increase a critical aspect of the Transaction Token Service.  The TTS MUST ensure that the requested purpose ("scope") of the Txn-Token is equal or less than the scope(s) identified in the "subject_token".  This is also true of requesting a replacement Txn-Token.  The TTS MUST ensure there is not unintentional increase in authorization scope. </ins> 10. 10.1.
Code change:
Added text to address issue regarding the value of the claim within the Txn-Token
From Yaron's
Text from Yaron's email: : I think txn should be OPTIONAL. While it is very useful, there may be architectural reasons why transaction ID issuance in an organization is independent of transaction tokens.
I'm curious to the use cases? I'd prefer a way to make the claim REQUIRED and allow an organization to provide it's own value in that context. Maybe we could go with RECOMMENDED? This is one of those cases where people who know what they are doing can potentially remove it or possibly provide a "N_A" value and it will be fine. However, if it's OPTIONAL most developers will not specify the value and then they will lose a lot of value from the Transaction Token.
No specific use cases, it's just that we're assuming that an organization can easily integrate its (preexisting) transaction ID-issuing service with this one. Sometimes it can, sometimes it can't. I'm good with RECOMMENDED.
NAME please review PR which addresses this issue

Related discussion:
text: REQUIRED A unique transaction identifier as defined in Section 2.2 of RFC8417.  When used in the transaction token, it identifies the <del> entire call chain. </del> <ins> entire call chain.  It is strongly RECOMMENDED to provide an identifier unique within the trust domain.  If providing such an identifier is not possible, then a fixed value of "N_A" MAY be supplied. </ins> REQUIRED A unique identifier for the subject within the context of the "aud" trust domain.  Unlike OpenID Connect, the "sub" claim is
Code change:
Added a section to clarify the intent of the claim and how it is different from scope values addressing issue .
From Yaron's : need a lot more discussion of this claim, also it may be OPTIONAL too. Also, why not call it "scope" if that's what it is?
From NAME In an external to internal flow, the scopes tend to be broad. The TraT can be set to a more specific to narrow the use of the TraT. We could call it scope, but it could be confused with the OAuth scope One could set the value to the actual API that was called to be very specific We should add a sub-section to describe the above in the draft.

Related discussion:
text: 5.2.1. <ins> The "purp" claim captures the exact purpose of this particular transaction.  This is often much narrower than a scope value issued to an external client.  This is due to the fact that in most cases, the authorization model within the trust domain is quite different than the authorization model used with clients external to the trust domain.  To that end, it is intentional to separate the concept of scope (often fairly coarse-grained) used with external clients from the purpose of the transaction used within the trust domain.  How a given deployment represents the authorization model within the trust domain is out of scope for this specification. 5.2.2. </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-
Code change:
Added a section to clarify the intent of the claim and how it is different from scope values addressing issue .
From Yaron's : need a lot more discussion of this claim, also it may be OPTIONAL too. Also, why not call it "scope" if that's what it is?
From NAME In an external to internal flow, the scopes tend to be broad. The TraT can be set to a more specific to narrow the use of the TraT. We could call it scope, but it could be confused with the OAuth scope One could set the value to the actual API that was called to be very specific We should add a sub-section to describe the above in the draft.

Related discussion:
text: that have requested Txn-Tokens as part of the transaction processing. <del> 5.2.1.1. </del> <ins> 5.2.2.1. </ins> It is useful to be able to track the set of workloads that have requested a Txn-Token.  The "req_wl" claim allows for tracking this
Code change:
Added a section to clarify the intent of the claim and how it is different from scope values addressing issue .
From Yaron's : need a lot more discussion of this claim, also it may be OPTIONAL too. Also, why not call it "scope" if that's what it is?
From NAME In an external to internal flow, the scopes tend to be broad. The TraT can be set to a more specific to narrow the use of the TraT. We could call it scope, but it could be confused with the OAuth scope One could set the value to the actual API that was called to be very specific We should add a sub-section to describe the above in the draft.

Related discussion:
text: single value, then "req_wl" will be prepresented by an array of StringOrURIs. <del> 5.2.2. </del> <ins> 5.2.3. </ins> The figure below figleaftxtokenbody shows a non-normative example of the JWT body of a Txn-Token:
Code change:
We currently use the URI: "urn:ietf:params:oauth:token-type:txn-token" to denote a Txn-Token in requests or in the token itself. However, if I look at other entries in the OAuth URI Subregistry here (URL), they use the "token" style for the token types. We also use that style when the subject-token-type is "selfsigned". So I'd like to propose that we use the URI: "urn:ietf:params:oauth:token-type:txn_token" for the transaction token URI.
Agreed with aligning to the common practices elsewhere.

Related discussion:
text: 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 <del> defines a new token type URN "urn:ietf: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. </del> <ins> defines a new token type URN "urn:ietf: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. </ins> To request a Txn-Token the workload invokes the OAuth 2.0 RFC6749 token endpoint with the following parameters:
Code change:
We currently use the URI: "urn:ietf:params:oauth:token-type:txn-token" to denote a Txn-Token in requests or in the token itself. However, if I look at other entries in the OAuth URI Subregistry here (URL), they use the "token" style for the token types. We also use that style when the subject-token-type is "selfsigned". So I'd like to propose that we use the URI: "urn:ietf:params:oauth:token-type:txn_token" for the transaction token URI.
Agreed with aligning to the common practices elsewhere.

Related discussion:
text: intent of the transaction. "requested_token_type" REQUIRED.  The value MUST be <del> "urn:ietf:params:oauth:token-type:txn-token" </del> <ins> "urn:ietf:params:oauth:token-type:txn_token" </ins> "subject_token" REQUIRED.  The value MUST represent the subject of the transaction.  This could be an inbound token received by an
Code change:
We currently use the URI: "urn:ietf:params:oauth:token-type:txn-token" to denote a Txn-Token in requests or in the token itself. However, if I look at other entries in the OAuth URI Subregistry here (URL), they use the "token" style for the token types. We also use that style when the subject-token-type is "selfsigned". So I'd like to propose that we use the URI: "urn:ietf:params:oauth:token-type:txn_token" for the transaction token URI.
Agreed with aligning to the common practices elsewhere.

Related discussion:
text: The "access_token" value MUST be the Txn-Token JWT The "issued_token_type" value MUST bet set to <del> "urn:ietf:params:oauth:token-type:txn-token" </del> <ins> "urn:ietf:params:oauth:token-type:txn_token" </ins> The response MUST NOT include the values "expires_in", "refresh_token" and "scope"
Code change:
We currently use the URI: "urn:ietf:params:oauth:token-type:txn-token" to denote a Txn-Token in requests or in the token itself. However, if I look at other entries in the OAuth URI Subregistry here (URL), they use the "token" style for the token types. We also use that style when the subject-token-type is "selfsigned". So I'd like to propose that we use the URI: "urn:ietf:params:oauth:token-type:txn_token" for the transaction token URI.
Agreed with aligning to the common practices elsewhere.

Related discussion:
text: 11.1. <del> URN: urn:ietf:params:oauth:token-type:txn-token </del> <ins> URN: urn:ietf:params:oauth:token-type:txn_token </ins> Common Name: Transaction Token
Code change:
The notes copy-pasted from the WG notes do say "when", but based on our recollection of the events during that session, the real ask was to clarify that one could use unsigned JSON objects. That is indicated in the action item (i.e. the last line in that issue description)
the following came up in the IETF 120 session about TraTs: "Add an outline on when self-signed may be useful Yaron thought self-signed wil be a footgun Suggest a simple JSON object as replacement." The description of in section 7.1 is too rigid as it only allows an inbound token or a self-signed token. It should make it clear that an implementation may choose to have any different format for the subjecttoken.
Just a few very minor comments

Related discussion:
text: "urn:ietf:params:oauth:token-type:txn_token" "subject_token" REQUIRED.  The value MUST represent the subject of <del> the transaction.  This could be an inbound token received by an API Gateway, or a self-signed JWT constructed by a workload initiating a transaction, the type of which is identified by </del> <ins> the transaction.  This MAY be: An inbound token received by an API Gateway A self-signed JWT constructed by a workload initiating a transaction An unsigned JSON object constructed by a workload initiating a transaction Any other format that is understood by the Txn-Token Service The type of the "subject_token" field is identified by </ins> "subject_token_type". "subject_token_type" REQUIRED.  The value MUST indicate the type
Code change:
The notes copy-pasted from the WG notes do say "when", but based on our recollection of the events during that session, the real ask was to clarify that one could use unsigned JSON objects. That is indicated in the action item (i.e. the last line in that issue description)
the following came up in the IETF 120 session about TraTs: "Add an outline on when self-signed may be useful Yaron thought self-signed wil be a footgun Suggest a simple JSON object as replacement." The description of in section 7.1 is too rigid as it only allows an inbound token or a self-signed token. It should make it clear that an implementation may choose to have any different format for the subjecttoken.
Just a few very minor comments

Related discussion:
text: 7.2. The "subject_token_type" parameter value MUST be a URI RFC3986.  It <del> MAY be any one of the subject token types described in Section 3 of OAuth 2.0 Token Exchange RFC8693 except the Refresh Token type (i.e., "urn:ietf:params:oauth:token-type:refresh_token"), or it MAY be a self-signed JWT, as described below, or it MAY be a custom URI agreed to between requesters and the Txn-Token Service. </del> <ins> MAY be: </ins> <del> The Txn-Token Service MAY support other token formats, which MAY be specified in the "subject_token_type" parameter.  Any value used in this parameter MUST be a URI as specified in RFC 8693 RFC8693. </del> <ins> Any one of the subject token types described in Section 3 of OAuth 2.0 Token Exchange RFC8693 except the Refresh Token type (i.e., "urn:ietf:params:oauth:token-type:refresh_token"). A URN type name when the subject token is a self-signed JWT, as described below. A URN type name when the subject token is an unsigned JSON object, as described below. A custom URN agreed to between requesters and the Txn-Token Service.  The Txn-Token Service MAY support other token formats, which MAY be specified in the "subject_token_type" parameter. </ins> 7.2.1.
Code change:
The notes copy-pasted from the WG notes do say "when", but based on our recollection of the events during that session, the real ask was to clarify that one could use unsigned JSON objects. That is indicated in the action item (i.e. the last line in that issue description)
the following came up in the IETF 120 session about TraTs: "Add an outline on when self-signed may be useful Yaron thought self-signed wil be a footgun Suggest a simple JSON object as replacement." The description of in section 7.1 is too rigid as it only allows an inbound token or a self-signed token. It should make it clear that an implementation may choose to have any different format for the subjecttoken.
Just a few very minor comments

Related discussion:
text: The self-signed JWT MAY contain other claims. <ins> 7.2.2. A requester MAY use an unsigned JSON object as a "subject_token" value.  In that case, the requester MUST set the "subject_token_type" value to: "urn:ietf:params:oauth:token-type:unsigned_json".  The value of the "subject_token" field MUST be the BASE64URL encoded value of the JSON object as described in Section 5 of RFC6848.  The JSON object in the subject token MUST contain the following fields: "sub": The subject for whom the Txn-Token is being requested.  The Txn-Token Service SHALL use this value in determining the "sub" value in the Txn-Token issued in the response to this request. "exp": The expiration time of the unsigned JSON object, which the TTS MAY use as input to determining the lifetime of the Txn-token. The unsigned JSON object MAY contain other fields, and the Txn-Token Service MAY consider them when generating the Txn-Token. </ins> 7.3. When the Transaction Token Service receives a Txn-Token Request it
Code change:
The notes copy-pasted from the WG notes do say "when", but based on our recollection of the events during that session, the real ask was to clarify that one could use unsigned JSON objects. That is indicated in the action item (i.e. the last line in that issue description)
the following came up in the IETF 120 session about TraTs: "Add an outline on when self-signed may be useful Yaron thought self-signed wil be a footgun Suggest a simple JSON object as replacement." The description of in section 7.1 is too rigid as it only allows an inbound token or a self-signed token. It should make it clear that an implementation may choose to have any different format for the subjecttoken.
Just a few very minor comments

Related discussion:
text: within the trust domain defined by the "aud" claim. The Transaction Token Service MUST set the "iat" claim to the time of <del> issuance of the Txn-Token.  The Transaction Token Service MUST set the "aud" claim to an identifier representing the 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. </del> <ins> issuance of the Txn-Token. The Transaction Token Service MUST set the "aud" claim to an identifier representing the 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 Txn-Token Service MAY consider any "exp" value present in the "subject_token" parameter of the Txn-Token Request in determining the "exp" value of the resulting Txn-Token. The Transaction Token Service MUST set the "txn" claim to a unique ID specific to this transaction. </ins> 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 <del> claim MUST be ommitted if not set. </del> <ins> claim MUST be omitted if not set. </ins> The Transaction Token Service MUST evaluate the value specified in the "scope" parameter of the request to determine the "purp" claim of
Code change:
The notes copy-pasted from the WG notes do say "when", but based on our recollection of the events during that session, the real ask was to clarify that one could use unsigned JSON objects. That is indicated in the action item (i.e. the last line in that issue description)
the following came up in the IETF 120 session about TraTs: "Add an outline on when self-signed may be useful Yaron thought self-signed wil be a footgun Suggest a simple JSON object as replacement." The description of in section 7.1 is too rigid as it only allows an inbound token or a self-signed token. It should make it clear that an implementation may choose to have any different format for the subjecttoken.
Just a few very minor comments

Related discussion:
text: 9.3. <ins> A service requesting a Txn-Token SHOULD provide an incoming token if it has one that it used itself to authorize a caller, and if it directly correlates with the downstream call chain it needs the Txn- Token for.  In the absence of an appropriate incoming token, the requesting service MAY use a self-signed JWT, an unsigned JSON object or any other format to represent the details of the requester to the Txn-Token service. 9.4. </ins> How requesting clients authenticate to the Transaction Token Service is out of scope for this specification.  However, if using the "actor_token" and "actor_token_type" parameters of the OAuth 2.0
Code change:
The notes copy-pasted from the WG notes do say "when", but based on our recollection of the events during that session, the real ask was to clarify that one could use unsigned JSON objects. That is indicated in the action item (i.e. the last line in that issue description)
the following came up in the IETF 120 session about TraTs: "Add an outline on when self-signed may be useful Yaron thought self-signed wil be a footgun Suggest a simple JSON object as replacement." The description of in section 7.1 is too rigid as it only allows an inbound token or a self-signed token. It should make it clear that an implementation may choose to have any different format for the subjecttoken.
Just a few very minor comments

Related discussion:
text: request.  The "actor_token" MUST authenticate the identity of the requesting workload. <del> 9.4. </del> <ins> 9.5. </ins> Validation of a replacement Txn-Token, as well as any Txn-Token, is critical to the security of the entire transaction invocation
Code change:
The notes copy-pasted from the WG notes do say "when", but based on our recollection of the events during that session, the real ask was to clarify that one could use unsigned JSON objects. That is indicated in the action item (i.e. the last line in that issue description)
the following came up in the IETF 120 session about TraTs: "Add an outline on when self-signed may be useful Yaron thought self-signed wil be a footgun Suggest a simple JSON object as replacement." The description of in section 7.1 is too rigid as it only allows an inbound token or a self-signed token. It should make it clear that an implementation may choose to have any different format for the subjecttoken.
Just a few very minor comments

Related discussion:
text: signature be verified but also the workload identity of the workload requesting the replacement Txn-Token. <del> 9.5. </del> <ins> 9.6. </ins> The authorization model within a trust domain boundary is most often quite different from the authorization model (e.g.  OAuth scopes)