jiebi/TextFlow huggingface dataset:
Original text:
this attack since the Access Token may remain valid even after the Txn-Token has expired. <del> 9.4. </del>  How requesting clients authenticate to the Transaction Token Service is out of scope for this specification.  However, if using the

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:
this attack since the Access Token may remain valid even after the Txn-Token has expired.  <ins> 9.3. </ins> How requesting clients authenticate to the Transaction Token Service is out of scope for this specification.  However, if using the
Original text:
more workloads.  The workloads within an Trust Domain may be invoked only through published interfaces.  A Trust Domain must have an identifier that is used as the "aud" (audience) value in <del> Txn-Tokens.  The format of this identifier is a universal resource identifier.  Each Trust Domain has exactly one Txn-Token Service. </del>  A published interface to an Trust Domain that results in the invocation of a workload within the Trust Domain.

Reviewer comments:
In the Terminology section, the Trust Domain value is being defined and referenced in the aud claim as universal resource identifier. It should be spelled Universal Resource Identifier and a reference to RFC3986 should be added. However, later in the document, the aud claim value is specified as defined in RFC7519. This RFC defines the aud claim as "StringOrURI". The different passages should be aligned. Furthermore, the examples for the aud claim values should be aligned accordingly. In section Txn-Token Request the POST request example to the token service uses: If an URI is used, I suggest to use 'https' instead of 'http'. Later the JWT body example of the Txn-Token just uses a string:

Revised text:
more workloads.  The workloads within an Trust Domain may be invoked only through published interfaces.  A Trust Domain must have an identifier that is used as the "aud" (audience) value in  <ins> Txn-Tokens.  The format of this identifier is as defined in the JWT specification RFC7519. </ins> A published interface to an Trust Domain that results in the invocation of a workload within the Trust Domain.
Original text:
"aud" trust domain.  Unlike OpenID Connect, the "sub" claim is NOT associated with the "iss" claim. <del> REQUIRED A string defining the purpose or intent of this </del>  transaction. OPTIONAL A JSON object that conatains values that remain immutable

Reviewer comments:
I updated the text to require the claim remain unchanged when requesting a replacement transaction token. I also added a mechanism to allow for tracking the workloads that have requested replacement transaction tokens. This was necessary as the current text required the to remain unchanged in the replacement transaction token and the object contains the requesting workload identifier. I used a mechanisms similar to x-forwarded-for. This needs lots of review.
It would be good to show how, in a replacement txn-token, the identity of the previous subid is preserved. The replacement token may have a new subid that represent the workload that requested the replacement token. Originally posted by NAME in URL
Can we close this since it was addressed in PR ?

Revised text:
"aud" trust domain.  Unlike OpenID Connect, the "sub" claim is NOT associated with the "iss" claim.  <ins> REQUIRED A String defining the purpose or intent of this </ins> transaction. OPTIONAL A JSON object that conatains values that remain immutable
Original text:
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- <del> Token. </del>  The JSON value of the "rctx" claim MAY include any values the Txn- Token Service determines are interesting to downstream services that

Reviewer comments:
I updated the text to require the claim remain unchanged when requesting a replacement transaction token. I also added a mechanism to allow for tracking the workloads that have requested replacement transaction tokens. This was necessary as the current text required the to remain unchanged in the replacement transaction token and the object contains the requesting workload identifier. I used a mechanisms similar to x-forwarded-for. This needs lots of review.
It would be good to show how, in a replacement txn-token, the identity of the previous subid is preserved. The replacement token may have a new subid that represent the workload that requested the replacement token. Originally posted by NAME in URL
Can we close this since it was addressed in PR ?

Revised text:
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-  <ins> Token and contextual attributes of the originating request itself. </ins> The JSON value of the "rctx" claim MAY include any values the Txn- Token Service determines are interesting to downstream services that
Original text:
user or a robotic process that requested the Transaction "authn" The authentication method used to idenitfy the requester. <del> 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. </del>  5.2.2.

Reviewer comments:
I updated the text to require the claim remain unchanged when requesting a replacement transaction token. I also added a mechanism to allow for tracking the workloads that have requested replacement transaction tokens. This was necessary as the current text required the to remain unchanged in the replacement transaction token and the object contains the requesting workload identifier. I used a mechanisms similar to x-forwarded-for. This needs lots of review.
It would be good to show how, in a replacement txn-token, the identity of the previous subid is preserved. The replacement token may have a new subid that represent the workload that requested the replacement token. Originally posted by NAME in URL
Can we close this since it was addressed in PR ?

Revised text:
user or a robotic process that requested the Transaction "authn" The authentication method used to idenitfy the requester.  <ins> Its value is a StringOrURI that uniquely identifies the method used. "req_wl" The requesting workload.  A StringOrURI that uniquely identifies the computational entity that requested the Txn-Token. This entity MUST be within the Trust Domain of the Txn-Token.  If a replacement Txn-Token has been requested, then this claim will be an array of StringOrURIs representing the different workloads that have requested Txn-Tokens as part of the transaction processing. 5.2.1.1. 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 information even through requests for a replacement Txn-Token.  By default the "req_wl" is a StringOrURI representing the original workload entity that requested the Txn-Token.  However, if a workload within the path of servicing the transaction requests a replacement Txn-Token, then the Transaction Token Service will append the new requesting workload as a subsequent array element in the "req_wl" claim.  This provides a "pathing" mechanism to track which services have requested replacement Txn-Tokens.  If there is only a single value the "req_wl" will be a StringOrURI.  If there is more than a single value, then "req_wl" will be prepresented by an array of StringOrURIs. </ins> 5.2.2.
Original text:
case-sensitive strings where the value(s) MUST represent the specific purpose or intent of the transaction.  * "requested_token_type" REQUIRED.  The value MUST be "urn:ietf:params:oauth:token-type:txn- <del> token" * "subject_token" REQUIRED.  The value MUST be a token representing the subject of the transaction.  This could be an OAuth access_token received by an API Gateway or a JWT assertion constructed by a workload initiating a transaction or another form of token as identified by "subject_token_type".  * "subject_token_type" REQUIRED.  The value MUST indicate the type of the token present in the "subject_token" parameter </del>  The following additional parameters MAY be present in a Txn-Token Request:

Reviewer comments:
I updated the text to require the claim remain unchanged when requesting a replacement transaction token. I also added a mechanism to allow for tracking the workloads that have requested replacement transaction tokens. This was necessary as the current text required the to remain unchanged in the replacement transaction token and the object contains the requesting workload identifier. I used a mechanisms similar to x-forwarded-for. This needs lots of review.
It would be good to show how, in a replacement txn-token, the identity of the previous subid is preserved. The replacement token may have a new subid that represent the workload that requested the replacement token. Originally posted by NAME in URL
Can we close this since it was addressed in PR ?

Revised text:
case-sensitive strings where the value(s) MUST represent the specific purpose or intent of the transaction.  * "requested_token_type" REQUIRED.  The value MUST be "urn:ietf:params:oauth:token-type:txn-  <ins> token" * "subject_token" REQUIRED.  The value MUST represent the subject of the transaction.  This could be an OAuth access_token received by an API Gateway, a JWT assertion constructed by a workload initiating a transaction or a simple string value all identified by "subject_token_type".  * "subject_token_type" REQUIRED.  The value MUST indicate the type of the token or value present in the "subject_token" parameter </ins> The following additional parameters MAY be present in a Txn-Token Request:
Original text:
Workloads MAY request replacement Txn-Tokens in order to change (add to, remove or modify) the asserted values within a Txn-Token. <del> The value of the "aud" claim MUST remain unchanged in a replacement Txn-Token.  If the claim "rctx" is present in the original Txn-Token, then it MUST be present unchanged in the replacement Txn-Token. </del>  7.4.1.

Reviewer comments:
I updated the text to require the claim remain unchanged when requesting a replacement transaction token. I also added a mechanism to allow for tracking the workloads that have requested replacement transaction tokens. This was necessary as the current text required the to remain unchanged in the replacement transaction token and the object contains the requesting workload identifier. I used a mechanisms similar to x-forwarded-for. This needs lots of review.
It would be good to show how, in a replacement txn-token, the identity of the previous subid is preserved. The replacement token may have a new subid that represent the workload that requested the replacement token. Originally posted by NAME in URL
Can we close this since it was addressed in PR ?

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 values of the "sub" and "aud" claims MUST remain unchanged in a replacement Txn-Token.  If the claim "rctx" is present in the original Txn-Token, then it MUST be present and unchanged in the replacement Txn-Token except for the "req_wl" claim which MUST be updated to include the requesting workload identifier. </ins> 7.4.1.
Original text:
immutable context of a call chain. A special service within the Trust Domain, which issues Txn-Tokens <del> to requesting workloads.  Each Trust Domain has exactly one Txn- Token Service. </del>  5.

Reviewer comments:
Changed MUST to MAY. Cardinality of the txn-token service is 0..1, not exactly one. MAY not be the appropriate framing, I'm open to alternative text here to describe this more correctly.
I've updated the PR with the language provided by NAME in two places where the previous language was found in the draft.

Revised text:
immutable context of a call chain. A special service within the Trust Domain, which issues Txn-Tokens  <ins> to requesting workloads.  Each Trust Domain that uses Txn-Tokens MUST have exactly one logical Txn-Token Service. </ins> 5.
Original text:
features, but that is not a requirement for it to be a Txn-Token Service. <del> Each Trust Domain MUST have exactly one logical Txn-Token Service. </del>  7.

Reviewer comments:
Changed MUST to MAY. Cardinality of the txn-token service is 0..1, not exactly one. MAY not be the appropriate framing, I'm open to alternative text here to describe this more correctly.
I've updated the PR with the language provided by NAME in two places where the previous language was found in the draft.

Revised text:
features, but that is not a requirement for it to be a Txn-Token Service.  <ins> Each Trust Domain that uses Txn-Tokens MUST have exactly one logical Txn-Token Service. </ins> 7.
Original text:
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 <del> obsfucation method (e.g.  SHA256). </del>  11.

Reviewer comments:
I'll create a new issue to track that logging concern
From Yaron's : : salted SHA256. : also, in most cases txn tokens MUST NOT be logged because they contain PII (e.g. a subject that's an email address).
I'm ok with these changes. I think we could give some more advise around logging that could be useful to the industry.

Revised text:
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  <ins> obsfucation method (e.g. salted SHA256). 10.2. 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. </ins> 11.
Original text:
7.5.1. <del> A Txn-Token Service replacing a Txn-Token must consider that modifying previously asserted values from existing Txn-Tokens can completely negate the benefits of Txn-Tokens.  When issuing replacement Txn-Tokens, a Transaction Token Server therefore: </del>  MAY enable modifications to asserted values that reduce the scope of permitted actions

Reviewer comments:
a replacement request. Removed vague language
There was a point in Yaron's about specifying in 7.4.1 that sub must be unchanged, and although this is mentioned in 7.4, perhaps we should add bullet points in 7.4.1 (Txn-Token Service Responsibilities) that specify that MUST NOT be modified and MUST NOT be modified.
LGTM

Revised text:
7.5.1.  <ins> When issuing replacement Txn-Tokens, a Txn-Token Service: </ins> MAY enable modifications to asserted values that reduce the scope of permitted actions
Original text:
SHOULD NOT enable modification to asserted values that expand the scope of permitted actions  7.5.2. To request a replacement Txn-Token, the requester makes a Txn-Token

Reviewer comments:
a replacement request. Removed vague language
There was a point in Yaron's about specifying in 7.4.1 that sub must be unchanged, and although this is mentioned in 7.4, perhaps we should add bullet points in 7.4.1 (Txn-Token Service Responsibilities) that specify that MUST NOT be modified and MUST NOT be modified.
LGTM

Revised text:
SHOULD NOT enable modification to asserted values that expand the scope of permitted actions <ins> MUST NOT modify "sub" and "aud" values of the Txn-Token in the request MUST NOT remove any of the existing requesting workload identifiers from the "req_wl" field in the "rctx" claim of the Txn-Token </ins> 7.5.2. To request a replacement Txn-Token, the requester makes a Txn-Token
Original text:
7.5.3. <del> A successful response by the Transaction Token Server to a Replacement Txn-Token Request is a Txn-Token Response as described in </del>  7.6.

Reviewer comments:
a replacement request. Removed vague language
There was a point in Yaron's about specifying in 7.4.1 that sub must be unchanged, and although this is mentioned in 7.4, perhaps we should add bullet points in 7.4.1 (Txn-Token Service Responsibilities) that specify that MUST NOT be modified and MUST NOT be modified.
LGTM

Revised text:
7.5.3.  <ins> A successful response by the Txn-Token Service to a Replacement Txn- Token Request is a Txn-Token Response as described in </ins> 7.6.
Original text:
to authorize its calls to subsequent workloads.  Subsequent workloads may obtain Txn-Tokens of their own.  2.2.2. A service within a call chain may choose to replace the Txn-Token.

Reviewer comments:
Yup. Thanks. I realized I forgot to add the IANA section after I sent out the PR. I'll update it soon.
NAME Regarding your comment about wrong approach: I mentioned something along those lines as well. I personally don't think that a new token type is actually necessary. A JWT is a good fit as it can carry the necessary data, but whether it should be signed by the workload (or what additional claims and associated checks should be incorporated) could be a decision by the individual TTS/trust domain.
NAME My point is that even the JWT structure/encoding is not needed. No need to sign anything, no need to encode stuff in base64 (and either of them adds potential security issues). All the semantics we need can be carried in a simple JSON object.
I tend to agree with Yaron, that perhaps self-signed JWTs aren't the best way to express this. We can discuss this on the call tomorrow.
Given the requirement that the TTS/AS always has to authenticate the identity of the requesting workload, conveying this info in an unsigned thing (the subject token could even contain just plain JSON) would probably be okay. Though it seems like the kind of thing that might lead to mistakes in deployment and resultant security issues.
Letting the input be any kind of JSON structure feels problematic - not least because of interop. Using a JWT as the container and then putting constraints on it (i.e. a minimal set of supported claims) will help transaction token services in parsing and making some basic determinations about security. Self-signing has pros and cons - we can make it optional for those deployments that have a risk profile that would get additional assurances from it, but as Brian notes, signing is easy to get wrong.
Well, you'd put some constraints on the JSON content too. I don't see how that'd be any more problematic from an interop perspective.
As long as there are some constraints on the format and contents that everyone would expect. Why not just use a JWT at that point though (there are libraries that support it etc)?
NAME On we discussed this topic, and while there are valid opinions on both approaches, for now I am keeping the request as a self-signed JWT unless we think this approach is problematic.
Let's go ahead and merge and then file issues if there is stuff we want to change.

Revised text:
to authorize its calls to subsequent workloads.  Subsequent workloads may obtain Txn-Tokens of their own. <ins> If the requesting service does not have an inbound token that it can use in its request to the Txn-Token Service, it generates a self- signed JWT and passes that in the request in place of the external authorization token. </ins> 2.2.2. A service within a call chain may choose to replace the Txn-Token.
Original text:
The Transaction Token Service MAY provide additional processing and verification that is outside the scope of this specification. <del> 7.3. </del>  A successful response to a Txn-Token Request by a Transaction Token Service is called a Txn-Token Response.  If the Transaction Token

Reviewer comments:
Yup. Thanks. I realized I forgot to add the IANA section after I sent out the PR. I'll update it soon.
NAME Regarding your comment about wrong approach: I mentioned something along those lines as well. I personally don't think that a new token type is actually necessary. A JWT is a good fit as it can carry the necessary data, but whether it should be signed by the workload (or what additional claims and associated checks should be incorporated) could be a decision by the individual TTS/trust domain.
NAME My point is that even the JWT structure/encoding is not needed. No need to sign anything, no need to encode stuff in base64 (and either of them adds potential security issues). All the semantics we need can be carried in a simple JSON object.
I tend to agree with Yaron, that perhaps self-signed JWTs aren't the best way to express this. We can discuss this on the call tomorrow.
Given the requirement that the TTS/AS always has to authenticate the identity of the requesting workload, conveying this info in an unsigned thing (the subject token could even contain just plain JSON) would probably be okay. Though it seems like the kind of thing that might lead to mistakes in deployment and resultant security issues.
Letting the input be any kind of JSON structure feels problematic - not least because of interop. Using a JWT as the container and then putting constraints on it (i.e. a minimal set of supported claims) will help transaction token services in parsing and making some basic determinations about security. Self-signing has pros and cons - we can make it optional for those deployments that have a risk profile that would get additional assurances from it, but as Brian notes, signing is easy to get wrong.
Well, you'd put some constraints on the JSON content too. I don't see how that'd be any more problematic from an interop perspective.
As long as there are some constraints on the format and contents that everyone would expect. Why not just use a JWT at that point though (there are libraries that support it etc)?
NAME On we discussed this topic, and while there are valid opinions on both approaches, for now I am keeping the request as a self-signed JWT unless we think this approach is problematic.
Let's go ahead and merge and then file issues if there is stuff we want to change.

Revised text:
The Transaction Token Service MAY provide additional processing and verification that is outside the scope of this specification.  <ins> 7.4. </ins> A successful response to a Txn-Token Request by a Transaction Token Service is called a Txn-Token Response.  If the Transaction Token