jiebi/TextFlow huggingface dataset:
Original text:
microservices, monolithic services and infrastructure services such as managed databases. <del> A virtually or physically separated network, which contains two or more workloads.  The workloads within a Trust Domain may be invoked only through published interfaces. </del>  A published interface to a Trust Domain that results in the invocation of a workload within the Trust Domain.

Reviewer comments:
See issue Question for reviewers. Do we need the final sentence on how a workload is invoked? If the sentence was not there would it change how we think about a trust domain? Do we need the second sentence as an example? Should we add more examples (e.g. trust domains can be defined as all the applications or workloads that recognise a specific issuer).
The definition of a Trust Domain feels very specific to network segmentation. Is there a industry level Trust Domain definition we can use instead? For example, should we use a definition that defines the trust domain in terms of the shared policies that apply? Something like: "A trust domain refers to a collection of systems, applications, or workloads that share a common security policy".
I'm good with this

Revised text:
microservices, monolithic services and infrastructure services such as managed databases.  <ins> A collection of systems, applications, or workloads that share a common security policy.  In practice this may include a virtually or physically separated network, which contains two or more workloads.  The workloads within a Trust Domain may be invoked only through published interfaces. </ins> A published interface to a Trust Domain that results in the invocation of a workload within the Trust Domain.
Original text:
A successful response to a Txn-Token Request by a Transaction Token Service is called a Txn-Token Response.  If the Transaction Token Service responds with an error, the error response is as described in <del> Section 5.2 of RFC6749.  The following describes required values of a Txn-Token Response: </del>  The "token_type" value MUST be set to "N_A" per guidance in OAuth 2.0 Token Exchange

Reviewer comments:
Related to issue
Section 7.2 includes a "access_token", which is part of the token exchange protocol. RFC 8693 makes it clear that it des not need to be an OAuth token, but perhaps we can reference that this parameter is define in RFC 8693? Perhaps something like: "The following describes required values of the token exchange protocol as defined in RFC 8693 which must be included in the Txn-Token Response:" or "A successful response to a Txn-Token Request by a Transaction Token Service is called a Txn-Token Response. The Txn-Token Response is a profile of the token exchange response defined in RFC 8693. If the Transaction Token Service responds with an error, the error response is as described in Section 5.2 of RFC6749. The following describes required values of the token exchange protocol as defined in RFC 8693 which must be included in the Txn-Token Response:"
I'm not seeing access_token mentioned in section 7.2 other than implicitly when referencing the token types defined by 8693. Did you mean section 7.4? I'm fine with the first suggestion.
Yes, section 7.4.
I'm good with this

Revised text:
A successful response to a Txn-Token Request by a Transaction Token Service is called a Txn-Token Response.  If the Transaction Token Service responds with an error, the error response is as described in  <ins> Section 5.2 of RFC6749.  The following values defined in RFC8693 MUST be included in the Txn-Token Response: </ins> The "token_type" value MUST be set to "N_A" per guidance in OAuth 2.0 Token Exchange
Original text:
The "issued_token_type" value MUST bet set to "urn:ietf:params:oauth:token-type:txn_token" <del> The response MUST NOT include the values "expires_in", "refresh_token" and "scope" </del>  figtxtokenresponse shows a non-normative example of a Txn-Token Response.

Reviewer comments:
Related to issue
Section 7.2 includes a "access_token", which is part of the token exchange protocol. RFC 8693 makes it clear that it des not need to be an OAuth token, but perhaps we can reference that this parameter is define in RFC 8693? Perhaps something like: "The following describes required values of the token exchange protocol as defined in RFC 8693 which must be included in the Txn-Token Response:" or "A successful response to a Txn-Token Request by a Transaction Token Service is called a Txn-Token Response. The Txn-Token Response is a profile of the token exchange response defined in RFC 8693. If the Transaction Token Service responds with an error, the error response is as described in Section 5.2 of RFC6749. The following describes required values of the token exchange protocol as defined in RFC 8693 which must be included in the Txn-Token Response:"
I'm not seeing access_token mentioned in section 7.2 other than implicitly when referencing the token types defined by 8693. Did you mean section 7.4? I'm fine with the first suggestion.
Yes, section 7.4.
I'm good with this

Revised text:
The "issued_token_type" value MUST bet set to "urn:ietf:params:oauth:token-type:txn_token"  <ins> The Txn-Token Response MUST NOT include the values "expires_in", "refresh_token" and "scope" </ins> figtxtokenresponse shows a non-normative example of a Txn-Token Response.
Original text:
an OAuth 2.0 Token Exchange RFC8693 to obtain a Txn-Token.  To do this, it invokes a special Token Service (the Txn-Token Service) and provides context that is sufficient for it to generate a Txn-Token. <del> This context MAY include: </del>  The external authorization token (e.g., the OAuth access token)

Reviewer comments:
See issue
In section 2.2.1 the context that may be included in a transaction token includes "The external authorization token (e.g., the OAuth access token)". To ensure this is not interpreted to mean that an access token is included in a transaction token, I would suggest the following additions, in line with section 9.3 in Security Considerations: "A reference to the external authorization token (e.g., the OAuth access token), including scopes or claims included in the authorization token, but not the unmodified authorization token (see Security Considerations, Section 9.3)"
Pieter, in that section of the spec we are describing what needs to be sent to the Transaction token service, I think in that case the full access token should be passed. However, when generating the request context, we want to ensure that the full access token is not included. Did I get my spec sections wrong?
Maybe instead we shouldn't say "This context MAY include:" but rather ... "The information provided to the Txn-Token Service MAY include" to not confuse readers who might think this data should be included in the request context.
Agreed - I missed that this was for initial token creation. I did create a PR with your suggested text.
PR approved
Looks good.

Revised text:
an OAuth 2.0 Token Exchange RFC8693 to obtain a Txn-Token.  To do this, it invokes a special Token Service (the Txn-Token Service) and provides context that is sufficient for it to generate a Txn-Token.  <ins> The context information provided to the Txn-Token Service MAY include: </ins> The external authorization token (e.g., the OAuth access token)
Original 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>  REQUIRED Expiry time of the Txn-Token as defined in

Reviewer comments:
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

Revised text:
REQUIRED This claim, defined in RFC7519, identifies the trust domain in which the Txn-Token is valid.  This identifier MUST  <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
Original 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>  <del> "audience" REQUIRED.  The value MUST be set to the Trust Domain name </del>  "scope" REQUIRED.  A space-delimited list of case-sensitive strings where the value(s) MUST represent the specific purpose or

Reviewer comments:
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

Revised text:
token endpoint with the following parameters: "grant_type" REQUIRED.  The value MUST be set to  <ins> "urn:ietf:params:oauth:grant-type:token-exchange". </ins>  <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
Original 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>  7.5.3.

Reviewer comments:
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.

Revised 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  <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.
Original text:
Common Name: Transaction Token <del> Change Controller: IESG </del>  Specification Document Section txn-token-request of this specification

Reviewer comments:
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

Revised text:
Common Name: Transaction Token  <ins> Change Controller: IETF </ins> Specification Document Section txn-token-request of this specification
Original text:
Common Name: Token type for Self-signed JWT <del> Change Controller: IESG </del>  Specification Document: Section self-signed-subject-token-type of this specification

Reviewer comments:
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

Revised text:
Common Name: Token type for Self-signed JWT  <ins> Change Controller: IETF </ins> Specification Document: Section self-signed-subject-token-type of this specification
Original text:
Common Name: Token type for Unsigned JSON Object <del> Change Controller: IESG </del>  Specification Document: Section unsigned-json-subject-token- type of this specification

Reviewer comments:
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

Revised text:
Common Name: Token type for Unsigned JSON Object  <ins> Change Controller: IETF </ins> Specification Document: Section unsigned-json-subject-token- type of this specification
Original text:
Claim Description: The authorization context details <del> Change Controller: IESG </del>  Specification Document: Section txn-token-claims of this specification

Reviewer comments:
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

Revised text:
Claim Description: The authorization context details  <ins> Change Controller: IETF </ins> Specification Document: Section txn-token-claims of this specification
Original text:
Claim Description: The requester context <del> Change Controller: IESG </del>  Specification Document: Section requester-context of this specification

Reviewer comments:
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

Revised text:
Claim Description: The requester context  <ins> Change Controller: IETF </ins> Specification Document: Section requester-context of this specification
Original text:
Claim Description: The purpose of the transaction <del> Change Controller: IESG </del>  Specification Document: Section txn-token-claims of this specification

Reviewer comments:
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

Revised text:
Claim Description: The purpose of the transaction  <ins> Change Controller: IETF </ins> Specification Document: Section txn-token-claims of this specification
Original text:
The following entry will be proposed using the IANA Media Type registration IANA.MediaTypes form. <del> Applicant Name: Atul Tulshibagwale </del>  <del> Applicant Email: atul@sgnl.ai </del>  <del> Type Name: "application (RFC 2046)" </del>  <del> Subtype Name: "txntoken+jwt" </del>  <del> Required Parameters: "N/A." Optional Parameters: "N/A." </del>  Encoding Considerations: 7-bit text

Reviewer comments:
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

Revised text:
The following entry will be proposed using the IANA Media Type registration IANA.MediaTypes form.  <ins> Type Name: application </ins>  <ins> Subtype Name: txntoken+jwt </ins>  <ins> Change Controller: IETF </ins>  <ins> Required Parameters: N/A. </ins>  <ins> Optional Parameters: N/A. </ins> Encoding Considerations: 7-bit text
Original text:
7.5. A workload within a call chain may request the Transaction Token <del> Server to replace a Txn-Token. </del>  Workloads MAY request replacement Txn-Tokens in order to change (add to, remove or modify) the asserted values within a Txn-Token.

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

Revised text:
7.5. A workload within a call chain may request the Transaction Token  <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.