jiebi/TextFlow huggingface dataset:
Original text:
To request a replacement Txn-Token, the requester makes a Txn-Token Request as described in txn-token-request but includes the Txn-Token <del> to be replaced as the value of the "subject_token" parameter. </del>  7.5.3.

Reviewer comments:
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.

Revised text:
To request a replacement Txn-Token, the requester makes a Txn-Token Request as described in txn-token-request but includes the Txn-Token  <ins> to be replaced as the value of the "subject_token" parameter.  The "scope" value in the replacement request, if different from that in the original Txn-Token, MUST NOT increase the authorization surface beyond that of the original Txn-Token. </ins> 7.5.3.
Original 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>  9.2.

Reviewer comments:
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.

Revised 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  <ins> omitted from the response in favor of the "purp" claim in the Txn- Token. </ins> 9.2.
Original text:
request.  The "actor_token" MUST authenticate the identity of the requesting workload.  10. 10.1.

Reviewer comments:
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.

Revised 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.
Original 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>  REQUIRED A unique identifier for the subject within the context of the "aud" trust domain.  Unlike OpenID Connect, the "sub" claim is

Reviewer comments:
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

Revised text:
REQUIRED A unique transaction identifier as defined in Section 2.2 of RFC8417.  When used in the transaction token, it identifies the  <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
Original text:
5.2.1.  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-

Reviewer comments:
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.

Revised 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-
Original text:
that have requested Txn-Tokens as part of the transaction processing. <del> 5.2.1.1. </del>  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

Reviewer comments:
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.

Revised text:
that have requested Txn-Tokens as part of the transaction processing.  <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
Original text:
single value, then "req_wl" will be prepresented by an array of StringOrURIs. <del> 5.2.2. </del>  The figure below figleaftxtokenbody shows a non-normative example of the JWT body of a Txn-Token:

Reviewer comments:
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.

Revised text:
single value, then "req_wl" will be prepresented by an array of StringOrURIs.  <ins> 5.2.3. </ins> The figure below figleaftxtokenbody shows a non-normative example of the JWT body of a Txn-Token:
Original 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>  To request a Txn-Token the workload invokes the OAuth 2.0 RFC6749 token endpoint with the following parameters:

Reviewer comments:
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.

Revised 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  <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:
Original text:
intent of the transaction. "requested_token_type" REQUIRED.  The value MUST be <del> "urn:ietf:params:oauth:token-type:txn-token" </del>  "subject_token" REQUIRED.  The value MUST represent the subject of the transaction.  This could be an inbound token received by an

Reviewer comments:
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.

Revised text:
intent of the transaction. "requested_token_type" REQUIRED.  The value MUST be  <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
Original 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>  The response MUST NOT include the values "expires_in", "refresh_token" and "scope"

Reviewer comments:
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.

Revised text:
The "access_token" value MUST be the Txn-Token JWT The "issued_token_type" value MUST bet set to  <ins> "urn:ietf:params:oauth:token-type:txn_token" </ins> The response MUST NOT include the values "expires_in", "refresh_token" and "scope"
Original text:
11.1. <del> URN: urn:ietf:params:oauth:token-type:txn-token </del>  Common Name: Transaction Token

Reviewer comments:
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.

Revised text:
11.1.  <ins> URN: urn:ietf:params:oauth:token-type:txn_token </ins> Common Name: Transaction Token
Original 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>  "subject_token_type". "subject_token_type" REQUIRED.  The value MUST indicate the type

Reviewer comments:
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

Revised text:
"urn:ietf:params:oauth:token-type:txn_token" "subject_token" REQUIRED.  The value MUST represent the subject of  <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
Original 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>  <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>  7.2.1.

Reviewer comments:
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

Revised text:
7.2. The "subject_token_type" parameter value MUST be a URI RFC3986.  It  <ins> MAY be: </ins>  <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.
Original text:
The self-signed JWT MAY contain other claims.  7.3. When the Transaction Token Service receives a Txn-Token Request it

Reviewer comments:
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

Revised 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
Original 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>  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>  The Transaction Token Service MUST evaluate the value specified in the "scope" parameter of the request to determine the "purp" claim of

Reviewer comments:
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

Revised text:
within the trust domain defined by the "aud" claim. The Transaction Token Service MUST set the "iat" claim to the time of  <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  <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