jiebi/TextFlow huggingface dataset:
Original text:
figtxtokenresponse shows a non-normative example of a Txn-Token Response. <del> 7.4. </del>  A workload within a call chain may request the Transaction Token Server to replace a 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:
figtxtokenresponse shows a non-normative example of a Txn-Token Response.  <ins> 7.5. </ins> A workload within a call chain may request the Transaction Token Server to replace a Txn-Token.
Original text:
replacement Txn-Token except for the "req_wl" claim which MUST be updated to include the requesting workload identifier. <del> 7.4.1. </del>  A Txn-Token Service replacing a Txn-Token must consider that modifying previously asserted values from existing Txn-Tokens can

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:
replacement Txn-Token except for the "req_wl" claim which MUST be updated to include the requesting workload identifier.  <ins> 7.5.1. </ins> A Txn-Token Service replacing a Txn-Token must consider that modifying previously asserted values from existing Txn-Tokens can
Original text:
This specification registers the following claims defined in Section txn-token-header to the OAuth Access Token Types Registry defined in <del> RFC6749, and the following claims defined in Section txn-token-claims in the IANA JSON Web Token Claims Registry defined in </del>  11.1.

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:
This specification registers the following claims defined in Section txn-token-header to the OAuth Access Token Types Registry defined in  <ins> RFC6749, the following claim in Section subject-token-types to the "OAuth URI" subregistry of the "OAuth Parameters" IANA.OAuth.Parameters registry, and the following claims defined in Section txn-token-claims in the IANA JSON Web Token Claims Registry defined in </ins> 11.1.
Original text:
11.2.  Claim Name: "azd" Claim Description: The authorization context details

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:
11.2. <ins> URN: urn:ietf:params:oauth:token-type:self_signed Common Name: Token type for Self-signed JWT Change Controller: IESG Specification Document: Section subject-token-types of this specification 11.3. </ins> Claim Name: "azd" Claim Description: The authorization context details
Original text:
that have requested Txn-Tokens as part of the transaction processing. <del> 5.2.1.1. </del>  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

Reviewer comments:
To address issue
From Yaron's : how is "azd" different from "rctx"? There's a whole section about "rctx" and nothing about "azd".
Discussed in meeting on 06/14/2024: Add a subsection for azd, like we agreed to add a section for purp.
Looks good

Revised text:
that have requested Txn-Tokens as part of the transaction processing.  <ins> 5.2.2. The Txn-Token SHOULD contain an "azd" claim.  The value of this claim is a JSON object that contains name/value pairs (wherein the value could itself be an object), which together assert the details that remain immutable through the call-chain where this Txn-Token is used. Txn-Tokens are primarily used to assure identity and context for a transaction, and the content of this field is a critical part of that context. Whereas the "rctx" field contains environmental values related to the request, the "azd" field contains the actual authorizaiton details that are determined by the TTS.  These values are used by services using the Txn-Token to reliably obtain specific parameters needed to perform their work.  The content of the "azd" field is determined by the Txn-Token Service and they may be computed internally or from parameters it receives from the service that requests the Txn-Token. The following is a non-normative example of an "azd" claim: 5.2.2.1. </ins> 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
Original text:
single value, then "req_wl" will be prepresented by an array of StringOrURIs. <del> 5.2.2. </del>  The figure below figleaftxtokenbody shows a non-normative example of the JWT body of a Txn-Token:

Reviewer comments:
To address issue
From Yaron's : how is "azd" different from "rctx"? There's a whole section about "rctx" and nothing about "azd".
Discussed in meeting on 06/14/2024: Add a subsection for azd, like we agreed to add a section for purp.
Looks good

Revised text:
single value, then "req_wl" will be prepresented by an array of StringOrURIs.  <ins> 5.2.3. </ins> The figure below figleaftxtokenbody shows a non-normative example of the JWT body of a Txn-Token:
Original text:
string of URIs as per Section 4.3.2 of Refresh tokens for public clients must either be sender- <del> constrained or one-time use as per Section 4.12.2 of </del>  10.1.

Reviewer comments:
An invalid link to the OpenID core spec has been fixed, as well as a section number referencing the draft.

Revised text:
string of URIs as per Section 4.3.2 of Refresh tokens for public clients must either be sender-  <ins> constrained or one-time use as per Section 4.13.2 of </ins> 10.1.
Original text:
1.3.3. The client credentials or other forms of client authentication (e.g. <del> a "client_secret" or a private key used to sign a JWT) can be used as an authorization grant when the authorization scope is limited to the protected resources under the control of the client, or to protected resources previously arranged with the authorization server.  Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner) or is requesting access to protected resources based on an authorization previously arranged with the authorization server. </del>  1.4.

Reviewer comments:
OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.

Revised text:
1.3.3. The client credentials or other forms of client authentication (e.g.  <ins> a private key used to sign a JWT, as described in RFC7523) can be used as an authorization grant when the authorization scope is limited to the protected resources under the control of the client, or to protected resources previously arranged with the authorization server.  Client credentials are used as an authorization grant typically when the client is acting on its own behalf (the client is also the resource owner) or is requesting access to protected resources based on an authorization previously arranged with the authorization server. </ins> 1.4.
Original text:
the process of issuance/registration and distribution of the underlying credentials ensures their confidentiality. <del> If the client is confidential or credentialed, the authorization server MAY accept any form of client authentication meeting its security requirements (e.g., password, public/private key pair). </del>  It is RECOMMENDED to use asymmetric (public-key based) methods for client authentication such as mTLS RFC8705 or "private_key_jwt"

Reviewer comments:
OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.

Revised text:
the process of issuance/registration and distribution of the underlying credentials ensures their confidentiality.  <ins> If the client is confidential, the authorization server MAY accept any form of client authentication meeting its security requirements (e.g., password, public/private key pair). </ins> It is RECOMMENDED to use asymmetric (public-key based) methods for client authentication such as mTLS RFC8705 or "private_key_jwt"
Original text:
credentials to a counterfeit client after obtaining resource owner authorization. <del> The authorization server MAY establish a client authentication method with public clients, which converts them to credentialed clients. However, the authorization server MUST NOT rely on credentialed client authentication for the purpose of identifying the client. </del> The client MUST NOT use more than one authentication method in each request to prevent a conflict of which authentication mechanism is authoritative for the request.

Reviewer comments:
OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.

Revised text:
credentials to a counterfeit client after obtaining resource owner authorization.  The client MUST NOT use more than one authentication method in each request to prevent a conflict of which authentication mechanism is authoritative for the request.
Original text:
3.2.1. <del> Confidential or credentialed clients MUST authenticate with the authorization server as described in client-authentication when making requests to the token endpoint. </del>  Client authentication is used for:

Reviewer comments:
OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.

Revised text:
3.2.1.  <ins> Confidential clients MUST authenticate with the authorization server as described in client-authentication when making requests to the token endpoint. </ins> Client authentication is used for:
Original text:
supported by the token request.  The details of those grant types are defined below. <del> Confidential or credentialed clients MUST authenticate with the authorization server as described in token-endpoint-client- authentication. </del>  For example, the client makes the following HTTP request (with extra line breaks for display purposes only): The authorization server MUST: <del> require client authentication for confidential and credentialed clients (or clients with other authentication requirements), </del>  authenticate the client if client authentication is included

Reviewer comments:
OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.

Revised text:
supported by the token request.  The details of those grant types are defined below.  <ins> Confidential clients MUST authenticate with the authorization server as described in token-endpoint-client-authentication. </ins> For example, the client makes the following HTTP request (with extra line breaks for display purposes only): The authorization server MUST:  <ins> require client authentication for confidential clients (or clients with other authentication requirements), </ins> authenticate the client if client authentication is included
Original text:
authorization server MUST: ensure that the authorization code was issued to the authenticated <del> confidential or credentialed client, or if the client is public, ensure that the code was issued to "client_id" in the request, </del>  verify that the authorization code is valid,

Reviewer comments:
OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.

Revised text:
authorization server MUST: ensure that the authorization code was issued to the authenticated  <ins> confidential client, or if the client is public, ensure that the code was issued to "client_id" in the request, </ins> verify that the authorization code is valid,
Original text:
the scope of this specification). The client credentials grant type MUST only be used by confidential <del> or credentialed clients. </del>  The use of the client credentials grant illustrated in fig-client- credentials-grant includes the following steps:

Reviewer comments:
OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.

Revised text:
the scope of this specification). The client credentials grant type MUST only be used by confidential  <ins> clients. </ins> The use of the client credentials grant illustrated in fig-client- credentials-grant includes the following steps:
Original text:
Because refresh tokens are typically long-lasting credentials used to request additional access tokens, the refresh token is bound to the <del> client to which it was issued.  Confidential or credentialed clients MUST authenticate with the authorization server as described in token-endpoint-client-authentication. </del>  For example, the client makes the following HTTP request using transport-layer security (with extra line breaks for display purposes

Reviewer comments:
OAuth 2 gives a clear definition of public clients, which is where OAuth 2.1 says isn't one of the forms / attributes that could be referred to as credentials? Public clients do have them, they didn't go away, right? ... while they don't have clientsecret of course.
A is not a credential, it is an identifier, and it is always public.

Revised text:
Because refresh tokens are typically long-lasting credentials used to request additional access tokens, the refresh token is bound to the  <ins> client to which it was issued.  Confidential clients MUST authenticate with the authorization server as described in token- endpoint-client-authentication. </ins> For example, the client makes the following HTTP request using transport-layer security (with extra line breaks for display purposes