jiebi/CodeConvo huggingface dataset:
Code change:
Looks good to me. Left a comment, but nothing major.
Left a comment, but looks good to me.

Related discussion:
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
Code change:
Looks good to me. Left a comment, but nothing major.
Left a comment, but looks good to me.

Related discussion:
text: 8.2. <del> Claim Name: "azc" </del> <ins> Claim Name: "azd" </ins> <del> Claim Description: The authorization context </del> <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.
Code change:
I moved the Security Considerations section before the IANA registry text and added a Privacy Considerations section as raised in the IETF 118 meeting.

Related discussion:
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 <del> 8.1. </del> <ins> 10.1. </ins> Name: "txn_token"
Code change:
I moved the Security Considerations section before the IANA registry text and added a Privacy Considerations section as raised in the IETF 118 meeting.

Related discussion:
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>
Code change:
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"

Related discussion:
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
Code change:
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"

Related discussion:
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> <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. <del> 8.3. </del> <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
Code change:
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"

Related discussion:
text: this attack since the Access Token may remain valid even after the Txn-Token has expired. <del> 9. </del> <ins> 10. </ins> <del> 9.1. </del> <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
Code change:
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"

Related discussion:
text: personal information and in that case must be protected through some obsfucation method (e.g.  SHA256). <del> 10. </del> <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 <del> 10.1. </del> <ins> 11.1. </ins> Name: "txn_token"
Code change:
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"

Related discussion:
text: Specification Document: Section txn-token-header of this specificaiton <del> 10.2. </del> <ins> 11.2. </ins> Claim Name: "azd"
Code change:
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

Related discussion:
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
Code change:
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

Related discussion:
text: this attack since the Access Token may remain valid even after the Txn-Token has expired. <del> 9.4. </del> <ins> 9.3. </ins> How requesting clients authenticate to the Transaction Token Service is out of scope for this specification.  However, if using the
Code change:
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:

Related discussion:
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> <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.
Code change:
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 ?

Related discussion:
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> <ins> REQUIRED A String defining the purpose or intent of this </ins> transaction. OPTIONAL A JSON object that conatains values that remain immutable
Code change:
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 ?

Related discussion:
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> <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
Code change:
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 ?

Related discussion:
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> <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.
Code change:
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 ?

Related discussion:
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> <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:
Code change:
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 ?

Related discussion:
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> <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.
Code change:
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.

Related discussion:
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> <ins> to requesting workloads.  Each Trust Domain that uses Txn-Tokens MUST have exactly one logical Txn-Token Service. </ins> 5.
Code change:
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.

Related discussion:
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> <ins> Each Trust Domain that uses Txn-Tokens MUST have exactly one logical Txn-Token Service. </ins> 7.
Code change:
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.

Related discussion:
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> <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.
Code change:
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

Related discussion:
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> <ins> When issuing replacement Txn-Tokens, a Txn-Token Service: </ins> MAY enable modifications to asserted values that reduce the scope of permitted actions