jiebi/TextFlow huggingface dataset:
Original text:
identifiers from the "req_wl" field in the "rctx" claim of the Txn-Token  7.5.2. To request a replacement Txn-Token, the requester makes a Txn-Token

Reviewer comments:
Update Transaction Token Service responsibility when creating replacement tokens. Also contains minor changes for consistent language. Related URL

Revised text:
identifiers from the "req_wl" field in the "rctx" claim of the Txn-Token <ins> MUST NOT issue replacement Txn-token with lifetime exceeding the lifetime of the originally presented token </ins> 7.5.2. To request a replacement Txn-Token, the requester makes a Txn-Token
Original text:
The following additional parameter MUST be present in a Txn-Token Request: <del> A parameter named "azc" , whose value is a JSON object.  This object contains any information the Transaction Token Service needs to understand the context of the incoming request. </del>  figtxtokenrequest shows a non-normative example of a Txn-Token Request.

Reviewer comments:
The current draft had a request parameter named "azc" and also the claim within the TraT is called "azc", which leads to confusion whether the request parameter content is directly embedded into the token. So I am renaming the request parameter to "rctx".
Ahh... I think this parameter is for cases where the requestor wants to add some specific authorization data into the overall TxTkn. I would prefer to rename the parameter 'authz_details' which would be a JSON object and then add it as a sub-object in the of the TxTkn.
From Dr. Kelley W. Burgin Section 6.2: What does the AS do with the values in “azc”? Are they included in the transaction token? Can I put anything I want in “azc”?

Revised text:
The following additional parameter MUST be present in a Txn-Token Request:  <ins> 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. </ins> figtxtokenrequest shows a non-normative example of a Txn-Token Request.
Original text:
The following claims MUST be present in the JWT body of a Leaf Txn- Token: <del> A "tid" claim, whose value is the unique identifier of entire call </del>  chain. A "sub_id" claim, whose value is the unique identifier of the user

Reviewer comments:
is already registered (URL). Do we need to register it again? I'm not sure what the guidance here is.
I believe we should add an IANA consideration to propose the registration of azc claim. A list of registered claims can be found here: URL
I believe we should add an IANA consideration and propose to register .
Thanks for this email and adding the issues to GitHub. I will update the spec shortly.
Implementation feedback. The "tid" claim clashes with a claim commonly used in AAD for the tenant ID. Perhaps we can use an alternative like idt, txi, txnid, txn_id or tti?
Discussed in the identity chaining call. Recommendation is to use the 'txn' claim name as defined in RFC 8417.
Add reference to SET add RFC 8417
Looks good to me

Revised text:
The following claims MUST be present in the JWT body of a Leaf Txn- Token:  <ins> A "txn" claim, whose value is the unique identifier of entire call </ins> chain. A "sub_id" claim, whose value is the unique identifier of the user
Original text:
9. <del> This memo includes no request to IANA. </del>  10.

Reviewer comments:
is already registered (URL). Do we need to register it again? I'm not sure what the guidance here is.
I believe we should add an IANA consideration to propose the registration of azc claim. A list of registered claims can be found here: URL
I believe we should add an IANA consideration and propose to register .
Thanks for this email and adding the issues to GitHub. I will update the spec shortly.
Implementation feedback. The "tid" claim clashes with a claim commonly used in AAD for the tenant ID. Perhaps we can use an alternative like idt, txi, txnid, txn_id or tti?
Discussed in the identity chaining call. Recommendation is to use the 'txn' claim name as defined in RFC 8417.
Add reference to SET add RFC 8417
Looks good to me

Revised text:
9.  <ins> This specification registers the following claims defined in Section txn-token-header to the OAuth Access Token Types Registry defined in RFC6749, and the following claims defined in Section txn-token-claims in the IANA JSON Web Token Claims Registry defined in 9.1. Name: "txn_token" Description: JWT of type Transaction Token Additional Token Endpoint Response Parameters: none HTTP Authentication Schemes: TLS Change Controller: IESG Specification Document: Section txn-token-header of this specificaiton 9.2. Claim Name: "azc" Claim Description: The authorization context Change Controller: IESG Specification Document: Section txn-token-claims of this specification </ins> 10.
Original text:
An "exp" claim, whose value is the time at which the Txn-Token expires. <del> A "txn" claim, whose value is the unique identifier of entire call chain. </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

Reviewer comments:
See issue
Implementation feedback. The "tid" claim clashes with a claim commonly used in AAD for the tenant ID. Perhaps we can use an alternative like idt, txi, txnid, txn_id or tti?
Discussed in the identity chaining call. Recommendation is to use the 'txn' claim name as defined in RFC 8417.
Add reference to SET add RFC 8417

Revised text:
An "exp" claim, whose value is the time at which the Txn-Token expires.  <ins> 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. </ins> 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
Original text:
Txn-Tokens are expected to be short-lived (order of minutes, e.g., 5 minutes), and as a result MAY be used only for the expected duration <del> of an external invocation.  If a long-running process such as an batch or offline task is involved, it can use a separate mechanism to perform the external invocation, but the resulting Txn-Token is still short-lived. </del>  2.4.

Reviewer comments:
Constrain Txn-Token to be shorter than the Access Token Lifetime (upper bound on lifetime) Editorial update to security considerations

Revised text:
Txn-Tokens are expected to be short-lived (order of minutes, e.g., 5 minutes), and as a result MAY be used only for the expected duration  <ins> of an external invocation.  If the token or other credential presented to the Txn-Token service when requesting a Txn-Token has an expiration time, then the Txn-Token MUST NOT exceed the lifetime of the originally presented token or credential.  If a long-running process such as an batch or offline task is involved, it can use a separate mechanism to perform the external invocation, but the resulting Txn-Token is still short-lived. </ins> 2.4.
Original text:
Because Txn-Tokens are short-lived, the Txn-Token response from the Txn-Token service does not contain the "refresh_token" field.  A Txn- <del> Token is also cannot be issued by presenting a "refresh_token". </del>  The "expires_in" and "scope" fields of the OAuth 2.0 Token Exchange specification RFC8693 are also not used in Txn-Token responses.  The

Reviewer comments:
Constrain Txn-Token to be shorter than the Access Token Lifetime (upper bound on lifetime) Editorial update to security considerations

Revised text:
Because Txn-Tokens are short-lived, the Txn-Token response from the Txn-Token service does not contain the "refresh_token" field.  A Txn-  <ins> Token cannot be issued by presenting a "refresh_token". </ins> The "expires_in" and "scope" fields of the OAuth 2.0 Token Exchange specification RFC8693 are also not used in Txn-Token responses.  The
Original text:
An "iat" claim, whose value is the time at which the Txn-Token was created.  An "exp" claim, whose value is the time at which the Txn-Token expires.

Reviewer comments:
Looks good to me. Left a comment, but nothing major.
Left a comment, but looks good to me.

Revised text:
An "iat" claim, whose value is the time at which the Txn-Token was created. <ins> 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. </ins> An "exp" claim, whose value is the time at which the Txn-Token expires.
Original text:
format of this claim MAY be a Subject Identifier as specified in SubjectIdentifiers. <del> An "azc" claim, whose value is a JSON object that contains values </del>  that remain constant in the call chain. <del> figleaftxtokenbody shows a non-normative example of the JWT body of a Txn-Token: </del>  6.

Reviewer comments:
Looks good to me. Left a comment, but nothing major.
Left a comment, but looks good to me.

Revised text:
format of this claim MAY be a Subject Identifier as specified in SubjectIdentifiers.  <ins> An "azd" claim, whose value is a JSON object that contains values </ins> that remain constant in the call chain.  <ins> 5.2.2. The JWT body MAY have the following claims: 5.2.2.1. 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. The JSON value of the "req_ctx" claim MAY include any values the Txn- 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: * "req_ip" The IP address of the requester.  This MAY be the end-user or a robotic process that requested the Transaction * "authn" The authentication method used to idenitfy the requester.  Its value is a URN that uniquely identifies the method used.  * "req_wl" The requesting workload.  A URN that uniquely identifies the computational entity that requested the Txn-Token.  This entity MUST be within the Trust Domain of the Txn-Token. 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. The figure below figleaftxtokenbody shows a non-normative example of the JWT body of a Txn-Token: </ins> 6.
Original text:
Workloads MAY request replacement Txn-Tokens in order to change (add to, remove or modify) the asserted values within a Txn-Token.  7.3.1. A Txn-Token Service replacing a Txn-Token must consider that

Reviewer comments:
Looks good to me. Left a comment, but nothing major.
Left a comment, but looks good to me.

Revised text:
Workloads MAY request replacement Txn-Tokens in order to change (add to, remove or modify) the asserted values within a Txn-Token. <ins> The value of the "aud" claim MUST remain unchanged in a replacement Txn-Token.  If the claim "req_ctx" is present in the original Txn- Token, then it MUST be present unchanged in the replacement Txn- Token. </ins> 7.3.1. A Txn-Token Service replacing a Txn-Token must consider that
Original text:
8.2. <del> Claim Name: "azc" </del>  <del> Claim Description: The authorization context </del>  Change Controller: IESG Specification Document: Section txn-token-claims of this specification  9. 9.1.

Reviewer comments:
Looks good to me. Left a comment, but nothing major.
Left a comment, but looks good to me.

Revised text:
8.2.  <ins> Claim Name: "azd" </ins>  <ins> Claim Description: The authorization context details </ins> Change Controller: IESG Specification Document: Section txn-token-claims of this specification <ins> Claim Name: "req_ctx" Claim Description: The requester context Change Controller: IESG Specification Document: Section requester-context of this specification Claim Name: "purp" Claim Description: The purpose of the transaction Change Controller: IESG Specification Document: Section purpose of this specification </ins> 9. 9.1.
Original text:
8.  This specification registers the following claims defined in Section txn-token-header to the OAuth Access Token Types Registry defined in RFC6749, and the following claims defined in Section txn-token-claims in the IANA JSON Web Token Claims Registry defined in <del> 8.1. </del>  Name: "txn_token"

Reviewer comments:
I moved the Security Considerations section before the IANA registry text and added a Privacy Considerations section as raised in the IETF 118 meeting.

Revised text:
8. <ins> 8.1. A Txn-Token is not resistant to replay attacks.  A long-lived Txn- Token therefore represents a risk if it is stored in a file, discovered by an attacker, and then replayed.  For this reason, a Txn-Token lifetime must be kept short, not exceeding the lifetime of a call-chain.  Even for long-running "batch" jobs, a longer lived access token should be used to initiate the request to the batch endpoint.  It then obtains short-lived Txn-Tokens that may be used to authorize the call to downstream services in the call-chain. Because Txn-Tokens are short-lived, the Txn-Token response from the Txn-Token service does not contain the "refresh_token" field.  A Txn- Token cannot be issued by presenting a "refresh_token". The "expires_in" and "scope" fields of the OAuth 2.0 Token Exchange 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 omitted from the request and therefore omitted in the response. 8.2. Although Txn-Tokens are short-lived, they MAY be sender constrained as an additional layer of defence to prevent them from being re-used by a compromised or malicious workload under the control of a hostile actor. 8.3. When creating Txn-Tokens, the Txn-Token MUST NOT contain the Access Token presented to the external endpoint.  If an Access Token is included in a Txn-Token, an attacker may extract the Access Token from the Txn-Token, and replay it to any Resource Server that can accept that Access Token.  Txn-Token expiry does not protect against this attack since the Access Token may remain valid even after the Txn-Token has expired. 9. 9.1. Some "req_ctx" claims may be considered personal information in some jurisdictions and if so their values need to be obsfucated.  For example, originating IP address ("req_ip") is often considerd personal information and in that case must be protected through some obsfucation method (e.g.  SHA256). 10. </ins> This specification registers the following claims defined in Section txn-token-header to the OAuth Access Token Types Registry defined in RFC6749, and the following claims defined in Section txn-token-claims in the IANA JSON Web Token Claims Registry defined in  <ins> 10.1. </ins> Name: "txn_token"
Original text:
Specification Document: Section txn-token-header of this specificaiton <del> 8.2. </del>  Claim Name: "azd"

Reviewer comments:
I moved the Security Considerations section before the IANA registry text and added a Privacy Considerations section as raised in the IETF 118 meeting.

Revised text:
Specification Document: Section txn-token-header of this specificaiton  <ins> 10.2. </ins> Claim Name: "azd"
Original text:
Change Controller: IESG Specification Document: Section purpose of this specification <del> 9. 9.1. A Txn-Token is not resistant to replay attacks.  A long-lived Txn- Token therefore represents a risk if it is stored in a file, discovered by an attacker, and then replayed.  For this reason, a Txn-Token lifetime must be kept short, not exceeding the lifetime of a call-chain.  Even for long-running "batch" jobs, a longer lived access token should be used to initiate the request to the batch endpoint.  It then obtains short-lived Txn-Tokens that may be used to authorize the call to downstream services in the call-chain. Because Txn-Tokens are short-lived, the Txn-Token response from the Txn-Token service does not contain the "refresh_token" field.  A Txn- Token cannot be issued by presenting a "refresh_token". The "expires_in" and "scope" fields of the OAuth 2.0 Token Exchange 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 omitted from the request and therefore omitted in the response. 9.2. Although Txn-Tokens are short-lived, they MAY be sender constrained as an additional layer of defence to prevent them from being re-used by a compromised or malicious workload under the control of a hostile actor. 9.3. When creating Txn-Tokens, the Txn-Token MUST NOT contain the Access Token presented to the external endpoint.  If an Access Token is included in a Txn-Token, an attacker may extract the Access Token from the Txn-Token, and replay it to any Resource Server that can accept that Access Token.  Txn-Token expiry does not protect against this attack since the Access Token may remain valid even after the Txn-Token has expired. </del>

Reviewer comments:
I moved the Security Considerations section before the IANA registry text and added a Privacy Considerations section as raised in the IETF 118 meeting.

Revised text:
Change Controller: IESG Specification Document: Section purpose of this specification
Original text:
8.  8.1.  A Txn-Token is not resistant to replay attacks.  A long-lived Txn- Token therefore represents a risk if it is stored in a file, discovered by an attacker, and then replayed.  For this reason, a

Reviewer comments:
Addresses Issue
We need to add in the section, information on how services may use Txn-Tokens securely, by possibly using them in conjunction with SPIFFE or other service-to-service security mechanisms. (based on feedback by Kai Lehmann (NAME
talks about the same issue, but this is a broader statement.
We will use a new header named "Txn-Token"

Revised text:
8. <ins> Txn-Tokens need to be communicated between workloads that depend upon them to authorize the request.  Such workloads will often present HTTP RFC2616 interfaces for being invoked by other workloads.  This section specifies the HTTP header the invoking workload MUST use to communicate the Txn-Token to the invoked workload, when the invoked workload presents an HTTP interface.  Note that the standard HTTP "Authorization" header MUST NOT be used because that may be used by the workloads to communicate channel authorization. </ins> 8.1. <ins> A workload that invokes another workload using HTTP and needs to present a Txn-Token to the invoked workload MUST use the HTTP Header "Txn-Token" to communicate the Txn-Token.  The value of this header MUST be the JWT that represents the Txn-Token. 9. 9.1. </ins> A Txn-Token is not resistant to replay attacks.  A long-lived Txn- Token therefore represents a risk if it is stored in a file, discovered by an attacker, and then replayed.  For this reason, a
Original text:
field, which indicates the token lifetime.  The "scope" field is omitted from the request and therefore omitted in the response. <del> 8.2. </del>  Although Txn-Tokens are short-lived, they MAY be sender constrained as an additional layer of defence to prevent them from being re-used by a compromised or malicious workload under the control of a hostile actor. <del> 8.3. </del>  When creating Txn-Tokens, the Txn-Token MUST NOT contain the Access Token presented to the external endpoint.  If an Access Token is

Reviewer comments:
Addresses Issue
We need to add in the section, information on how services may use Txn-Tokens securely, by possibly using them in conjunction with SPIFFE or other service-to-service security mechanisms. (based on feedback by Kai Lehmann (NAME
talks about the same issue, but this is a broader statement.
We will use a new header named "Txn-Token"

Revised text:
field, which indicates the token lifetime.  The "scope" field is omitted from the request and therefore omitted in the response.  <ins> 9.2. </ins> Although Txn-Tokens are short-lived, they MAY be sender constrained as an additional layer of defence to prevent them from being re-used by a compromised or malicious workload under the control of a hostile actor.  <ins> 9.3. </ins> When creating Txn-Tokens, the Txn-Token MUST NOT contain the Access Token presented to the external endpoint.  If an Access Token is
Original text:
this attack since the Access Token may remain valid even after the Txn-Token has expired. <del> 9. </del>  <del> 9.1. </del>  Some "req_ctx" claims may be considered personal information in some jurisdictions and if so their values need to be obsfucated.  For

Reviewer comments:
Addresses Issue
We need to add in the section, information on how services may use Txn-Tokens securely, by possibly using them in conjunction with SPIFFE or other service-to-service security mechanisms. (based on feedback by Kai Lehmann (NAME
talks about the same issue, but this is a broader statement.
We will use a new header named "Txn-Token"

Revised text:
this attack since the Access Token may remain valid even after the Txn-Token has expired.  <ins> 10. </ins>  <ins> 10.1. </ins> Some "req_ctx" claims may be considered personal information in some jurisdictions and if so their values need to be obsfucated.  For
Original text:
personal information and in that case must be protected through some obsfucation method (e.g.  SHA256). <del> 10. </del>  This specification registers the following claims defined in Section txn-token-header to the OAuth Access Token Types Registry defined in RFC6749, and the following claims defined in Section txn-token-claims in the IANA JSON Web Token Claims Registry defined in <del> 10.1. </del>  Name: "txn_token"

Reviewer comments:
Addresses Issue
We need to add in the section, information on how services may use Txn-Tokens securely, by possibly using them in conjunction with SPIFFE or other service-to-service security mechanisms. (based on feedback by Kai Lehmann (NAME
talks about the same issue, but this is a broader statement.
We will use a new header named "Txn-Token"

Revised text:
personal information and in that case must be protected through some obsfucation method (e.g.  SHA256).  <ins> 11. </ins> This specification registers the following claims defined in Section txn-token-header to the OAuth Access Token Types Registry defined in RFC6749, and the following claims defined in Section txn-token-claims in the IANA JSON Web Token Claims Registry defined in  <ins> 11.1. </ins> Name: "txn_token"
Original text:
Specification Document: Section txn-token-header of this specificaiton <del> 10.2. </del>  Claim Name: "azd"

Reviewer comments:
Addresses Issue
We need to add in the section, information on how services may use Txn-Tokens securely, by possibly using them in conjunction with SPIFFE or other service-to-service security mechanisms. (based on feedback by Kai Lehmann (NAME
talks about the same issue, but this is a broader statement.
We will use a new header named "Txn-Token"

Revised text:
Specification Document: Section txn-token-header of this specificaiton  <ins> 11.2. </ins> Claim Name: "azd"
Original text:
9.2. <del> Although Txn-Tokens are short-lived, they MAY be sender constrained as an additional layer of defence to prevent them from being re-used by a compromised or malicious workload under the control of a hostile actor. 9.3. </del> When creating Txn-Tokens, the Txn-Token MUST NOT contain the Access Token presented to the external endpoint.  If an Access Token is included in a Txn-Token, an attacker may extract the Access Token

Reviewer comments:
See meeting notes here where we agreed to remove this: URL
The language in section needs to refer to the RFC and specify how to use them with Txn-Tokens

Revised text:
9.2.  When creating Txn-Tokens, the Txn-Token MUST NOT contain the Access Token presented to the external endpoint.  If an Access Token is included in a Txn-Token, an attacker may extract the Access Token