jiebi/CodeConvo huggingface dataset:
Code change:
See issue
Good practice is to explain why something is a MUST. Suggestion: From: The value of the aud claim MUST remain unchanged in a replacement Txn-Token. To: The value of the aud claim MUST remain unchanged in a replacement Txn-Token to prevent the Txn-Token from being accepted outside it's current Trust Domain. Alternatively, we cann add security considerations for the draft as well.
I'm good with that text.
I think the current PR is making the change in the wrong place (unless I'm horribly mistaken)
Looks good

Related discussion:
text: REQUIRED This claim, defined in RFC7519, identifies the trust domain in which the Txn-Token is valid.  This identifier MUST <del> uniquely identify the trust domain. </del> <ins> uniquely identify the trust domain to prevent the Txn-Token from being accepted outside it's current trust domain. </ins> REQUIRED Expiry time of the Txn-Token as defined in
Code change:
See issue
Good practice is to explain why something is a MUST. Suggestion: From: The value of the aud claim MUST remain unchanged in a replacement Txn-Token. To: The value of the aud claim MUST remain unchanged in a replacement Txn-Token to prevent the Txn-Token from being accepted outside it's current Trust Domain. Alternatively, we cann add security considerations for the draft as well.
I'm good with that text.
I think the current PR is making the change in the wrong place (unless I'm horribly mistaken)
Looks good

Related discussion:
text: token endpoint with the following parameters: "grant_type" REQUIRED.  The value MUST be set to <del> "urn:ietf:params:oauth:grant-type:token-exchange" </del> <ins> "urn:ietf:params:oauth:grant-type:token-exchange". </ins> <del> "audience" REQUIRED.  The value MUST be set to the Trust Domain name </del> <ins> "audience" REQUIRED.  The value MUST be set to the trust domain name. </ins> "scope" REQUIRED.  A space-delimited list of case-sensitive strings where the value(s) MUST represent the specific purpose or
Code change:
Addresses issue - clarifying the value for when requesting a replacement Txn-Token
In : Does this assume that should be ? Should we call it out explicitly?
Yes, I think that makes sense.

Related discussion:
text: To request a replacement Txn-Token, the requester makes a Txn-Token Request as described in txn-token-request but includes the Txn-Token <del> to be replaced as the value of the "subject_token" parameter.  The "scope" value in the replacement request, if different from that in the original Txn-Token, MUST NOT increase the authorization surface beyond that of the original Txn-Token. </del> <ins> to be replaced as the value of the "subject_token" parameter and sets the "subject_token_type" parameter to the value "urn:ietf:params:oauth:token-type:txn_token".  The "scope" value in the replacement request, if different from that in the original Txn- Token, MUST NOT increase the authorization surface beyond that of the original Txn-Token. </ins> 7.5.3.
Code change:
We received the following email from IANA: Before the IETF meeting, we check working group agendas for documents with IANA-related issues. We have notes about the current version of this document: URL 1) We haven’t been asked to update the change controller field for existing registrations, but the IESG prefers that the IETF be listed as the change controller for new registrations. 2) A few minor editorial notes about the media type registration: The applicant name and email field should be omitted. Where those fields appear on the IANA website, they’re an artifact of the web form, and not officially part of the template. We’re gradually removing those fields from existing registrations.The media type registrations don’t appear to include a change controller field.The quotation marks around type, subtype, and required and optional parameters can be removed, as should the “(RFC 2046)” after “application.” Finally, please note that RFC 6838 recommends asking the mailing list for an informal review. If you have any questions, just let us know. If you'd like to talk in person, you can find us next to the RFC Editor's table from Monday through Thursday. You can also request another review at any time by contacting us at . For more information about IANA Considerations section requirements, please see URL Best regards, Amanda Baber IANA Operations Manager

Related discussion:
text: Common Name: Transaction Token <del> Change Controller: IESG </del> <ins> Change Controller: IETF </ins> Specification Document Section txn-token-request of this specification
Code change:
We received the following email from IANA: Before the IETF meeting, we check working group agendas for documents with IANA-related issues. We have notes about the current version of this document: URL 1) We haven’t been asked to update the change controller field for existing registrations, but the IESG prefers that the IETF be listed as the change controller for new registrations. 2) A few minor editorial notes about the media type registration: The applicant name and email field should be omitted. Where those fields appear on the IANA website, they’re an artifact of the web form, and not officially part of the template. We’re gradually removing those fields from existing registrations.The media type registrations don’t appear to include a change controller field.The quotation marks around type, subtype, and required and optional parameters can be removed, as should the “(RFC 2046)” after “application.” Finally, please note that RFC 6838 recommends asking the mailing list for an informal review. If you have any questions, just let us know. If you'd like to talk in person, you can find us next to the RFC Editor's table from Monday through Thursday. You can also request another review at any time by contacting us at . For more information about IANA Considerations section requirements, please see URL Best regards, Amanda Baber IANA Operations Manager

Related discussion:
text: Common Name: Token type for Self-signed JWT <del> Change Controller: IESG </del> <ins> Change Controller: IETF </ins> Specification Document: Section self-signed-subject-token-type of this specification
Code change:
We received the following email from IANA: Before the IETF meeting, we check working group agendas for documents with IANA-related issues. We have notes about the current version of this document: URL 1) We haven’t been asked to update the change controller field for existing registrations, but the IESG prefers that the IETF be listed as the change controller for new registrations. 2) A few minor editorial notes about the media type registration: The applicant name and email field should be omitted. Where those fields appear on the IANA website, they’re an artifact of the web form, and not officially part of the template. We’re gradually removing those fields from existing registrations.The media type registrations don’t appear to include a change controller field.The quotation marks around type, subtype, and required and optional parameters can be removed, as should the “(RFC 2046)” after “application.” Finally, please note that RFC 6838 recommends asking the mailing list for an informal review. If you have any questions, just let us know. If you'd like to talk in person, you can find us next to the RFC Editor's table from Monday through Thursday. You can also request another review at any time by contacting us at . For more information about IANA Considerations section requirements, please see URL Best regards, Amanda Baber IANA Operations Manager

Related discussion:
text: Common Name: Token type for Unsigned JSON Object <del> Change Controller: IESG </del> <ins> Change Controller: IETF </ins> Specification Document: Section unsigned-json-subject-token- type of this specification
Code change:
We received the following email from IANA: Before the IETF meeting, we check working group agendas for documents with IANA-related issues. We have notes about the current version of this document: URL 1) We haven’t been asked to update the change controller field for existing registrations, but the IESG prefers that the IETF be listed as the change controller for new registrations. 2) A few minor editorial notes about the media type registration: The applicant name and email field should be omitted. Where those fields appear on the IANA website, they’re an artifact of the web form, and not officially part of the template. We’re gradually removing those fields from existing registrations.The media type registrations don’t appear to include a change controller field.The quotation marks around type, subtype, and required and optional parameters can be removed, as should the “(RFC 2046)” after “application.” Finally, please note that RFC 6838 recommends asking the mailing list for an informal review. If you have any questions, just let us know. If you'd like to talk in person, you can find us next to the RFC Editor's table from Monday through Thursday. You can also request another review at any time by contacting us at . For more information about IANA Considerations section requirements, please see URL Best regards, Amanda Baber IANA Operations Manager

Related discussion:
text: Claim Description: The authorization context details <del> Change Controller: IESG </del> <ins> Change Controller: IETF </ins> Specification Document: Section txn-token-claims of this specification
Code change:
We received the following email from IANA: Before the IETF meeting, we check working group agendas for documents with IANA-related issues. We have notes about the current version of this document: URL 1) We haven’t been asked to update the change controller field for existing registrations, but the IESG prefers that the IETF be listed as the change controller for new registrations. 2) A few minor editorial notes about the media type registration: The applicant name and email field should be omitted. Where those fields appear on the IANA website, they’re an artifact of the web form, and not officially part of the template. We’re gradually removing those fields from existing registrations.The media type registrations don’t appear to include a change controller field.The quotation marks around type, subtype, and required and optional parameters can be removed, as should the “(RFC 2046)” after “application.” Finally, please note that RFC 6838 recommends asking the mailing list for an informal review. If you have any questions, just let us know. If you'd like to talk in person, you can find us next to the RFC Editor's table from Monday through Thursday. You can also request another review at any time by contacting us at . For more information about IANA Considerations section requirements, please see URL Best regards, Amanda Baber IANA Operations Manager

Related discussion:
text: Claim Description: The requester context <del> Change Controller: IESG </del> <ins> Change Controller: IETF </ins> Specification Document: Section requester-context of this specification
Code change:
We received the following email from IANA: Before the IETF meeting, we check working group agendas for documents with IANA-related issues. We have notes about the current version of this document: URL 1) We haven’t been asked to update the change controller field for existing registrations, but the IESG prefers that the IETF be listed as the change controller for new registrations. 2) A few minor editorial notes about the media type registration: The applicant name and email field should be omitted. Where those fields appear on the IANA website, they’re an artifact of the web form, and not officially part of the template. We’re gradually removing those fields from existing registrations.The media type registrations don’t appear to include a change controller field.The quotation marks around type, subtype, and required and optional parameters can be removed, as should the “(RFC 2046)” after “application.” Finally, please note that RFC 6838 recommends asking the mailing list for an informal review. If you have any questions, just let us know. If you'd like to talk in person, you can find us next to the RFC Editor's table from Monday through Thursday. You can also request another review at any time by contacting us at . For more information about IANA Considerations section requirements, please see URL Best regards, Amanda Baber IANA Operations Manager

Related discussion:
text: Claim Description: The purpose of the transaction <del> Change Controller: IESG </del> <ins> Change Controller: IETF </ins> Specification Document: Section txn-token-claims of this specification
Code change:
We received the following email from IANA: Before the IETF meeting, we check working group agendas for documents with IANA-related issues. We have notes about the current version of this document: URL 1) We haven’t been asked to update the change controller field for existing registrations, but the IESG prefers that the IETF be listed as the change controller for new registrations. 2) A few minor editorial notes about the media type registration: The applicant name and email field should be omitted. Where those fields appear on the IANA website, they’re an artifact of the web form, and not officially part of the template. We’re gradually removing those fields from existing registrations.The media type registrations don’t appear to include a change controller field.The quotation marks around type, subtype, and required and optional parameters can be removed, as should the “(RFC 2046)” after “application.” Finally, please note that RFC 6838 recommends asking the mailing list for an informal review. If you have any questions, just let us know. If you'd like to talk in person, you can find us next to the RFC Editor's table from Monday through Thursday. You can also request another review at any time by contacting us at . For more information about IANA Considerations section requirements, please see URL Best regards, Amanda Baber IANA Operations Manager

Related discussion:
text: The following entry will be proposed using the IANA Media Type registration IANA.MediaTypes form. <del> Applicant Name: Atul Tulshibagwale </del> <ins> Type Name: application </ins> <del> Applicant Email: atul@sgnl.ai </del> <ins> Subtype Name: txntoken+jwt </ins> <del> Type Name: "application (RFC 2046)" </del> <ins> Change Controller: IETF </ins> <del> Subtype Name: "txntoken+jwt" </del> <ins> Required Parameters: N/A. </ins> <del> Required Parameters: "N/A." Optional Parameters: "N/A." </del> <ins> Optional Parameters: N/A. </ins> Encoding Considerations: 7-bit text
Code change:
Update Transaction Token Service responsibility when creating replacement tokens. Also contains minor changes for consistent language. Related URL

Related discussion:
text: 7.5. A workload within a call chain may request the Transaction Token <del> Server to replace a Txn-Token. </del> <ins> Service to replace a Txn-Token. </ins> Workloads MAY request replacement Txn-Tokens in order to change (add to, remove or modify) the asserted values within a Txn-Token.
Code change:
Update Transaction Token Service responsibility when creating replacement tokens. Also contains minor changes for consistent language. Related URL

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

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

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

Related discussion:
text: 9. <del> This memo includes no request to IANA. </del> <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.
Code change:
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

Related discussion:
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> <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
Code change:
Constrain Txn-Token to be shorter than the Access Token Lifetime (upper bound on lifetime) Editorial update to security considerations

Related discussion:
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> <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.
Code change:
Constrain Txn-Token to be shorter than the Access Token Lifetime (upper bound on lifetime) Editorial update to security considerations

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

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

Related discussion:
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> <ins> An "azd" claim, whose value is a JSON object that contains values </ins> that remain constant in the call chain. <del> figleaftxtokenbody shows a non-normative example of the JWT body of a Txn-Token: </del> <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.