jiebi/TextFlow huggingface dataset:
Original text:
9.3.  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

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:
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
Original text:
request.  The "actor_token" MUST authenticate the identity of the requesting workload. <del> 9.4. </del>  Validation of a replacement Txn-Token, as well as any Txn-Token, is critical to the security of the entire transaction invocation

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:
request.  The "actor_token" MUST authenticate the identity of the requesting workload.  <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
Original text:
signature be verified but also the workload identity of the workload requesting the replacement Txn-Token. <del> 9.5. </del>  The authorization model within a trust domain boundary is most often quite different from the authorization model (e.g.  OAuth scopes)

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:
signature be verified but also the workload identity of the workload requesting the replacement Txn-Token.  <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)
Original text:
URN: urn:ietf:params:oauth:token-type:txn_token <del> Common Name: Transaction Token </del>  <del> Change Controller: IESG </del>  <del> Specification Document Section txn-token-request of this specification </del>  URN: urn:ietf:params:oauth:token-type:self_signed <del> Common Name: Token type for Self-signed JWT </del>  <del> Change Controller: IESG </del>  <del> Specification Document: Section subject-token-types of this specification </del>  11.2.

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: urn:ietf:params:oauth:token-type:txn_token  <ins> Common Name: Transaction Token </ins>  <ins> Change Controller: IESG </ins>  <ins> Specification Document Section txn-token-request of this specification </ins> URN: urn:ietf:params:oauth:token-type:self_signed  <ins> Common Name: Token type for Self-signed JWT Change Controller: IESG Specification Document: Section self-signed-subject-token-type of this specification URN: urn:ietf:params:oauth:token-type:unsigned_json </ins>  <ins> Common Name: Token type for Unsigned JSON Object Change Controller: IESG </ins>  <ins> Specification Document: Section unsigned-json-subject-token- type of this specification </ins> 11.2.
Original text:
REQUIRED Expiry time of the Txn-Token as defined in REQUIRED A unique transaction identifier as defined in Section 2.2 <del> of RFC8417.  When used in the transaction token, it identifies the 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. </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:
The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"

Revised text:
REQUIRED Expiry time of the Txn-Token as defined in REQUIRED A unique transaction identifier as defined in Section 2.2  <ins> of RFC8417. </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:
"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 following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"

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 following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"

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 following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"

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 following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"

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
Original text:
9.3.  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

Reviewer comments:
The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"

Revised 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
Original text:
request.  The "actor_token" MUST authenticate the identity of the requesting workload. <del> 9.4. </del>  Validation of a replacement Txn-Token, as well as any Txn-Token, is critical to the security of the entire transaction invocation

Reviewer comments:
The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"

Revised text:
request.  The "actor_token" MUST authenticate the identity of the requesting workload.  <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
Original text:
signature be verified but also the workload identity of the workload requesting the replacement Txn-Token. <del> 9.5. </del>  The authorization model within a trust domain boundary is most often quite different from the authorization model (e.g.  OAuth scopes)

Reviewer comments:
The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"

Revised text:
signature be verified but also the workload identity of the workload requesting the replacement Txn-Token.  <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)
Original text:
replacement Txn-Token.  The TTS MUST ensure there is not unintentional increase in authorization scope.  10. 10.1.

Reviewer comments:
The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"

Revised text:
replacement Txn-Token.  The TTS MUST ensure there is not unintentional increase in authorization scope. <ins> 9.7. A Txn-token typically represents the call-chain of workloads necessary to complete a logical function initiated by an external or internal workload.  The "txn" claim in the Txn-token provides a unique identifier that when logged by the TTS and each subsequent workload can provide both discovery and auditability of successful and failed transactions.  It is therefore strongly RECOMMENDED to use an identifier, unique within the trust domain, for the "txn" value. </ins> 10. 10.1.
Original text:
URN: urn:ietf:params:oauth:token-type:txn_token <del> Common Name: Transaction Token </del>  <del> Change Controller: IESG </del>  <del> Specification Document Section txn-token-request of this specification </del>  URN: urn:ietf:params:oauth:token-type:self_signed <del> Common Name: Token type for Self-signed JWT </del>  <del> Change Controller: IESG </del>  <del> Specification Document: Section subject-token-types of this specification </del>  11.2.

Reviewer comments:
The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"

Revised text:
URN: urn:ietf:params:oauth:token-type:txn_token  <ins> Common Name: Transaction Token </ins>  <ins> Change Controller: IESG </ins>  <ins> Specification Document Section txn-token-request of this specification </ins> URN: urn:ietf:params:oauth:token-type:self_signed  <ins> Common Name: Token type for Self-signed JWT Change Controller: IESG Specification Document: Section self-signed-subject-token-type of this specification URN: urn:ietf:params:oauth:token-type:unsigned_json </ins>  <ins> Common Name: Token type for Unsigned JSON Object Change Controller: IESG </ins>  <ins> Specification Document: Section unsigned-json-subject-token- type of this specification </ins> 11.2.
Original text:
10.2. <del> Txn-Tokens SHOULD NOT be logged if they contain Personally Identifiable Information (PII).  What constitutes PII depends upon the use case, but in some cases even an email address (which could be a "sub" value) can be protected PII, which should not be logged. </del>  11.

Reviewer comments:
Is there a reason why you did not use uppercase terms like MUST NOT or SHOULD? Because it's supposed to be informative?
Yes, the section is non-normative.
Currently logging guidance says "Txn-Tokens SHOULD NOT be logged if they contain Personally Identifiable Information (PII)". I have few questions on this one Risks with logging is that token is still valid for few minutes and if logs are rotated to any other central archival storage with access to broader set of people or someone has access to the server with logs, then they can reuse the token. So why not just say MUST not log token? Also how would a service know if incoming token has PII or not. They will have to validate the token, extract claims and then somehow know infer that a claim is PII or not. On similar lines, for PII , can we mention that TTS SHOULD evaluate encrypting or tokenizing PII claims rather than adding them in plaintext. Adding in plaintext is a risk because TTS isn't aware where the token flows.
Txn-Tokens already contain the subject identifier which is enough to be considered PII in some environments. Our own policy states that PII data can be logged, but the logs must be deleted after a few days (max 7) days. We forbid logging of Txn-Tokens in our integrations for security reasons, not just because they could contain PII.
Our implementation in my company, we do follow the same guidance i.e do not log tokens at all, nothing to do with PII. Tokens are pretty much considered as credentials as validating parties leverage the claims for authorizing the request.

Revised text:
10.2.  <ins> Complete Txn-Tokens must not be logged verbatim.  This is in order to prevent replay of tokens or leakage of PII or other sensitive information via log files.  A hash of the Txn-Token may be logged to allow for correlation with the log files of the Txn-Token Service that records issued tokens.  Alternatively the JWS payload of a Txn- Token may be logged after the signature has been removed.  If the Txn-Token contains PII, then care should be taken in logging the content of the Txn-Token so that the PII does not get logged. </ins> 11.