jiebi/TextFlow huggingface dataset:
Original text:
Abstract This specification defines a new method of client authentication for <del> OAuth2 RFC6749 by extending the approach defined in RFC7523.  This </del>  new method enables client deployments that are traditionally viewed as public clients to be able to authenticate with the authorization server through an attested key based authentication scheme. 1. <del> RFC7523 defines a way for a client to include an assertion in a token </del>  request to an authorization server for the purposes of client authentication.  This specification extends this mechanism to provide a way for a client instance to authenticate it self with the

Reviewer comments:
The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.

Revised text:
Abstract This specification defines a new method of client authentication for  <ins> OAuth2 RFC6749 by extending the approach defined in RFC7521.  This </ins> new method enables client deployments that are traditionally viewed as public clients to be able to authenticate with the authorization server through an attested key based authentication scheme. 1.  <ins> RFC7521 defines a way for a client to include an assertion in a token </ins> request to an authorization server for the purposes of client authentication.  This specification extends this mechanism to provide a way for a client instance to authenticate it self with the
Original text:
authorization server MUST validate BOTH the JWTs present in the "client_assertion" parameter according to the criteria below.  3.1.1. The following rules apply to validating the client key attestation

Reviewer comments:
The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.

Revised text:
authorization server MUST validate BOTH the JWTs present in the "client_assertion" parameter according to the criteria below. <ins> It is RECOMMENDED that the authorization server validate the Client Key Attestation prior to validating the Client Key Attestation PoP. </ins> 3.1.1. The following rules apply to validating the client key attestation
Original text:
the time window during which the JWT can be used.  The authorization server MUST reject any JWT with an expiration time that has passed, subject to allowable clock skew between systems. <del> Note that the authorization server may reject JWTs with an "exp" claim value that is unreasonably far in the future. </del> The JWT MUST contain an "cnf" claim conforming RFC7800 that conveys the key to be used for sender constraining tokens issued

Reviewer comments:
The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.

Revised text:
the time window during which the JWT can be used.  The authorization server MUST reject any JWT with an expiration time that has passed, subject to allowable clock skew between systems.  The JWT MUST contain an "cnf" claim conforming RFC7800 that conveys the key to be used for sender constraining tokens issued
Original text:
processing. The JWT MAY contain an "iat" (issued at) claim that identifies the <del> time at which the JWT was issued.  Note that the authorization server may reject JWTs with an "iat" claim value that is unreasonably far in the past. </del>  The JWT MAY contain a "jti" (JWT ID) claim that provides a unique identifier for the token.  The authorization server MAY ensure

Reviewer comments:
The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.

Revised text:
processing. The JWT MAY contain an "iat" (issued at) claim that identifies the  <ins> time at which the JWT was issued. </ins> The JWT MAY contain a "jti" (JWT ID) claim that provides a unique identifier for the token.  The authorization server MAY ensure
Original text:
The JWT MAY contain other claims. <del> The JWT MUST be digitally signed or have a Message Authentication Code (MAC) applied by the issuer.  The authorization server MUST reject JWTs with an invalid signature or MAC. </del>  The authorization server MUST reject a JWT that is not valid in <del> all other respects per "JSON Web Token (JWT)". </del>  The following example is the decoded header and payload of a JWT meeting the processing rules as defined above.

Reviewer comments:
The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.

Revised text:
The JWT MAY contain other claims.  <ins> The JWT MUST be digitally signed using an asymmetric cryptographic algorithm.  The authorization server MUST reject the JWT if it is using a Message Authentication Code (MAC) based algorithm.  The authorization server MUST reject JWTs with an invalid signature. </ins> The authorization server MUST reject a JWT that is not valid in  <ins> all other respects per "JSON Web Token (JWT)" RFC7519. </ins> The following example is the decoded header and payload of a JWT meeting the processing rules as defined above.
Original text:
Note that the authorization server may reject JWTs with an "exp" claim value that is unreasonably far in the future.  The JWT MAY contain an "nbf" (not before) claim that identifies the time before which the token MUST NOT be accepted for processing.

Reviewer comments:
The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.

Revised text:
Note that the authorization server may reject JWTs with an "exp" claim value that is unreasonably far in the future. <ins> The JWT MUST contain a "jti" (JWT ID) claim that provides a unique identifier for the token.  The authorization server MAY ensure that JWTs are not replayed by maintaining the set of used "jti" values for the length of time for which the JWT would be considered valid based on the applicable "exp" instant. The JWT MUST contain an "aud" (audience) claim containing a value that identifies the authorization server as an intended audience. The RFC8414 issuer identifier URL of the authorization server MUST be used as a value for an "aud" element to identify the authorization server as the intended audience of the JWT. </ins> The JWT MAY contain an "nbf" (not before) claim that identifies the time before which the token MUST NOT be accepted for processing.
Original text:
server may reject JWTs with an "iat" claim value that is unreasonably far in the past. <del> The JWT MAY contain a "jti" (JWT ID) claim that provides a unique identifier for the token.  The authorization server MAY ensure that JWTs are not replayed by maintaining the set of used "jti" values for the length of time for which the JWT would be considered valid based on the applicable "exp" instant. </del> The JWT MAY contain other claims. The JWT MUST be digitally signed using an asymmetric cryptographic

Reviewer comments:
The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.

Revised text:
server may reject JWTs with an "iat" claim value that is unreasonably far in the past.  The JWT MAY contain other claims. The JWT MUST be digitally signed using an asymmetric cryptographic
Original text:
the "cnf" claim of the corresponding client key attestation JWT. The authorization server MUST reject a JWT that is not valid in <del> all other respects per "JSON Web Token (JWT)". </del>  The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. 4. <del> TODO Security </del>  5. <del> This document has no IANA actions. </del> 

Reviewer comments:
The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.

Revised text:
the "cnf" claim of the corresponding client key attestation JWT. The authorization server MUST reject a JWT that is not valid in  <ins> all other respects per "JSON Web Token (JWT)" RFC7519. </ins> The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. 4.  <ins> 4.1. Implementers should be aware that the design of this authentication mechanism deliberately allows for a client instance to re-use a single Client Attestation JWT in multiple interactions/requests with an authorization server, whilst producing a fresh Client Attestation PoP JWT.  Client deployments should consider this when determining the validity period for issued Client Attestation JWTs as this ultimately controls how long a client instance can re-use a single Client Attestation JWT. </ins> 5.  <ins> TODO 6. 6.1. This section registers the value "client-assertion-type:jwt-key- attestation" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" RFC6755. o URN: urn:ietf:params:oauth:client-assertion-type:jwt-key- attestation o Common Name: OAuth2 Attested Key Based Client Authentication Authentication o Change Controller: IESG o Specification Document: TBC 6.2. This section registers the value "attest_key_client_auth" in the IANA "OAuth Token Endpoint Authentication Methods" registry established by OAuth 2.0 Dynamic Client Registration Protocol RFC7591. o Token Endpoint Authentication Method Name: "attest_key_client_auth" o Change Controller: IESG o Specification Document(s): TBC </ins>
Original text:
The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. <del> 3.1.2. </del>  <del> The following rules apply to validating the client key attestation PoP JWT.  Application of additional restrictions and policy are at the discretion of the authorization server. </del>  The JWT MUST contain an "iss" (issuer) claim with a value corresponding to the "client_id" of the OAuth client.

Reviewer comments:
Please change file/draft name and title, too.
Opened as a separate issue.
NAME please check my latest suggestion
I would like to see the description under the sequence diagram improved, but if you want to address that in another PR, that is fine too.

Revised text:
The following example is the decoded header and payload of a JWT meeting the processing rules as defined above.  <ins> 4.1.2. </ins>  <ins> The following rules apply to validating the client attestation PoP JWT.  Application of additional restrictions and policy are at the discretion of the authorization server. </ins> The JWT MUST contain an "iss" (issuer) claim with a value corresponding to the "client_id" of the OAuth client.
Original text:
authorization server MUST reject JWTs with an invalid signature. The public key used to verify the JWT MUST be the key located in <del> the "cnf" claim of the corresponding client key attestation JWT. </del>  The authorization server MUST reject a JWT that is not valid in all other respects per "JSON Web Token (JWT)" RFC7519.

Reviewer comments:
Please change file/draft name and title, too.
Opened as a separate issue.
NAME please check my latest suggestion
I would like to see the description under the sequence diagram improved, but if you want to address that in another PR, that is fine too.

Revised text:
authorization server MUST reject JWTs with an invalid signature. The public key used to verify the JWT MUST be the key located in  <ins> the "cnf" claim of the corresponding client attestation JWT. </ins> The authorization server MUST reject a JWT that is not valid in all other respects per "JSON Web Token (JWT)" RFC7519.
Original text:
The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. <del> 4. </del>  <del> 4.1. </del>  Implementers should be aware that the design of this authentication mechanism deliberately allows for a client instance to re-use a

Reviewer comments:
Please change file/draft name and title, too.
Opened as a separate issue.
NAME please check my latest suggestion
I would like to see the description under the sequence diagram improved, but if you want to address that in another PR, that is fine too.

Revised text:
The following example is the decoded header and payload of a JWT meeting the processing rules as defined above.  <ins> 5. </ins>  <ins> 5.1. </ins> Implementers should be aware that the design of this authentication mechanism deliberately allows for a client instance to re-use a
Original text:
ultimately controls how long a client instance can re-use a single Client Attestation JWT. <del> 4.2. </del>  Authorization servers issuing a refresh token in response to a token request using the "urn:ietf:params:oauth:client-assertion-type:jwt- <del> key-attestation" client authentication method MUST bind the refresh token to the client instance, and NOT just the client as specified in section 6 [@!RFC6749].  To prove this binding, the client instance MUST authenticate itself to the authorization server when refreshing an access token using the "urn:ietf:params:oauth:client-assertion- type:jwt-key-attestation" authentication method.  The client MUST also use the same client attestation key that was used for authentication when the refresh token was issued. </del>  <del> 5. </del>  <del> 5.1. </del>  Implementers should be aware that using the same client attestation across multiple authorization servers could result in correlation of

Reviewer comments:
Please change file/draft name and title, too.
Opened as a separate issue.
NAME please check my latest suggestion
I would like to see the description under the sequence diagram improved, but if you want to address that in another PR, that is fine too.

Revised text:
ultimately controls how long a client instance can re-use a single Client Attestation JWT.  <ins> 5.2. </ins> Authorization servers issuing a refresh token in response to a token request using the "urn:ietf:params:oauth:client-assertion-type:jwt-  <ins> client-attestation" client authentication method MUST bind the refresh token to the client instance, and NOT just the client as specified in section 6 [@!RFC6749].  To prove this binding, the client instance MUST authenticate itself to the authorization server when refreshing an access token using the "urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation" authentication method.  The client MUST also use the same Client Attestation that was used for authentication when the refresh token was issued. </ins>  <ins> 6. </ins>  <ins> 6.1. </ins> Implementers should be aware that using the same client attestation across multiple authorization servers could result in correlation of
Original text:
are therefore RECOMMENDED to use different client attestations across different authorization servers. <del> 6. </del>  TODO <del> 7. </del>  <del> 7.1. </del>  <del> This section registers the value "client-assertion-type:jwt-key- </del>  attestation" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" RFC6755. <del> o URN: urn:ietf:params:oauth:client-assertion-type:jwt-key- </del>  attestation o Common Name: OAuth2 Attested Key Based Client Authentication Authentication o Change Controller: IESG o Specification Document: TBC <del> 7.2. </del>  <del> This section registers the value "attest_key_client_auth" in the IANA </del>  "OAuth Token Endpoint Authentication Methods" registry established by OAuth 2.0 Dynamic Client Registration Protocol RFC7591. <del> o Token Endpoint Authentication Method Name: "attest_key_client_auth" </del>  o Change Controller: IESG o Specification Document(s): TBC

Reviewer comments:
Please change file/draft name and title, too.
Opened as a separate issue.
NAME please check my latest suggestion
I would like to see the description under the sequence diagram improved, but if you want to address that in another PR, that is fine too.

Revised text:
are therefore RECOMMENDED to use different client attestations across different authorization servers.  <ins> 7. </ins> TODO  <ins> 8. </ins>  <ins> 8.1. </ins>  <ins> This section registers the value "client-assertion-type:jwt-client- </ins> attestation" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" RFC6755.  <ins> o URN: urn:ietf:params:oauth:client-assertion-type:jwt-client- </ins> attestation o Common Name: OAuth2 Attested Key Based Client Authentication Authentication o Change Controller: IESG o Specification Document: TBC  <ins> 8.2. </ins>  <ins> This section registers the value "attest_jwt_client_auth" in the IANA </ins> "OAuth Token Endpoint Authentication Methods" registry established by OAuth 2.0 Dynamic Client Registration Protocol RFC7591.  <ins> o Token Endpoint Authentication Method Name: "attest_jwt_client_auth" </ins> o Change Controller: IESG o Specification Document(s): TBC