jiebi/TextFlow huggingface dataset:
Original text:
ultimately controls how long a client instance can re-use a single Client Attestation JWT.  5. TODO

Reviewer comments:
As discussed over email, this PR drafts some text to capture the requirement around refresh token binding to the client instance not just the client. The PR also addresses some broken links. Personally I'm still not convinced that the best way to do this binding is through the client attestation key, instead I think we could add a claim that identifies the client instance in the client key attestation
few suggestions

Revised text:
ultimately controls how long a client instance can re-use a single Client Attestation JWT. <ins> 4.2. Authorization servers issuing a refresh token in response to a token request using the "urn:ietf:params:oauth:client-assertion-type:jwt- 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. </ins> 5. TODO
Original text:
<del> OAuth 2.0 Attestation Based Client Authentication </del>  draft-looker-oauth-attestation-based-client-authentication-latest Abstract

Reviewer comments:
In the Terminology section, the term names and term definitions are run together with no punctuation between them. For example: I suggest emulating the formatting in URL

Revised text:
 <ins> OAuth 2.0 Attestation-Based Client Authentication </ins> draft-looker-oauth-attestation-based-client-authentication-latest Abstract
Original text:
Note that the protocol for steps 2 and 4 and how the client instance authenticates with the client backend is out of scope of this <del> specification. </del>  This specification defines the format of the Client Attestation that a client instance uses to authenticate in its interactions with an authorization server, which is comprised of two key parts: <del> A Client Attestation JWT- produced by the client backend. </del>  A Client Attestation Proof of Possession (PoP) - produced by the client instance.

Reviewer comments:
In the Terminology section, the term names and term definitions are run together with no punctuation between them. For example: I suggest emulating the formatting in URL

Revised text:
Note that the protocol for steps 2 and 4 and how the client instance authenticates with the client backend is out of scope of this  <ins> specification.  Note also that this specification can be utilized without the client having a backend server at all; in this case, each client instance will perform the functions described as being done by the backend for itself. </ins> This specification defines the format of the Client Attestation that a client instance uses to authenticate in its interactions with an authorization server, which is comprised of two key parts:  <ins> A Client Attestation JWT - typically produced by the client backend. </ins> A Client Attestation Proof of Possession (PoP) - produced by the client instance.
Original text:
3. <del> Client Attestation JWT A JSON Web Token (JWT) generated by the client backend which is bound to a key managed by a client instance which can then be used by the instance for client authentication. Client Attestation Proof of Possession (PoP) JWT A Proof of Possession generated by the client instance using the key that the Client Attestation JWT is bound to. Client Instance Key A cryptographic, asymmetric key generated by the client instance and proven to the client backend.  The public key is contained in the Client Attestation JWT and is used to sign the Client Attestation Proof of Possession. </del> 4. To perform client authentication using this scheme, the client

Reviewer comments:
In the Terminology section, the term names and term definitions are run together with no punctuation between them. For example: I suggest emulating the formatting in URL

Revised text:
3.  4. To perform client authentication using this scheme, the client
Original text:
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-client- attestation o Common Name: OAuth2 Attested Key Based Client Authentication Authentication o Change Controller: IESG o Specification Document: TBC </del>  8.2.

Reviewer comments:
In the Terminology section, the term names and term definitions are run together with no punctuation between them. For example: I suggest emulating the formatting in URL

Revised text:
attestation" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" RFC6755.  <ins> URN: urn:ietf:params:oauth:client-assertion-type:jwt-client- attestation Common Name: OAuth 2.0 Attested Key-Based Client Authentication Change Controller: IESG Specification Document: TBC </ins> 8.2.
Original text:
"OAuth Token Endpoint Authentication Methods" registry established by OAuth 2.0 Dynamic Client Registration Protocol RFC7591. <del> o Token Endpoint Authentication Method Name: "attest_jwt_client_auth" o Change Controller: IESG o Specification Document(s): TBC </del> 

Reviewer comments:
In the Terminology section, the term names and term definitions are run together with no punctuation between them. For example: I suggest emulating the formatting in URL

Revised text:
"OAuth Token Endpoint Authentication Methods" registry established by OAuth 2.0 Dynamic Client Registration Protocol RFC7591.  <ins> Token Endpoint Authentication Method Name: "attest_jwt_client_auth" Change Controller: IESG Specification Document(s): TBC </ins>
Original text:
time at which the JWT was issued. The JWT MAY contain a "jti" (JWT ID) claim that provides a unique <del> 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.

Reviewer comments:
Addresses issues with language about the jti claim in the client attestation and pop jwt.
The spec states: "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." However the is not shown in the example in the same section.
The text says jti is required URL but the example doesn't have jti URL
Duplicate of
The Client Attestation JWT seems like a long(er) lived credential that should be reusable so the client instance doesn't have to go get a new one each time (right?). But this text for the Client Attestation JWT has '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' that suggests the AS might limit them to single use. I think that sentence can just be removed. \ right: URL
Agreed, need to remove this sentence from step 7 of 4.1.1.

Revised text:
time at which the JWT was issued. The JWT MAY contain a "jti" (JWT ID) claim that provides a unique  <ins> identifier for the token. </ins> The JWT MAY contain other claims.
Original text:
To perform client authentication using this scheme, the client instance uses the following parameter values and encodings. <del> The value of the "client_assertion_type" is "urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation". The value of the "client_assertion" parameter contains two JWTs, separated by a '~' character.  It MUST NOT contain more or less than precisely two JWTs seperated by the '~' character.  The first JWT MUST be the client attestation JWT defined in client-attestation-jwt, the second JWT MUST the client attestation PoP defined in client- attestation-pop-jwt. </del>  The following example demonstrates client authentication using this scheme during the presentation of an authorization code grant in an

Reviewer comments:
Minor language tweaks aligning more to RFC 7521 in how the client authentication mechanism is defined as to not limit its application to only being used at the token endpoint.
There is an idea to send the Client attestation already in Authorization Request or PAR instead of with the Token Request. I see the following advantages: the client attestation could act as some kind of mobile capability descriptor, thus allowing the Authorization Server(Issuer) to check these before the user performs user authentication, otherwise this could result in poor UX as the user authenticates and the AS realizes only afterwards in Token Request that the level of client attestation is not enough (e.g. wallet can only handle key type xyz or LoA low) I see the following disadvantage: some flows do not require Authorization Request the user usually does not give consent before sending Authorization Request
The client attestation can for sure be used to authenticate with PAR. The HAIP already requires that.
The draft just needs to be clarified that this is a general purpose client authentication method that can be used with any interaction with an AS that is requiring or making use of client authentication.

Revised text:
To perform client authentication using this scheme, the client instance uses the following parameter values and encodings.  <ins> The value of the "client_assertion_type" parameter (as defined in RFC7521) set to "urn:ietf:params:oauth:client-assertion-type:jwt- client-attestation". The value of the "client_assertion" parameter (as defined in RFC7521) set to a value containing two JWTs, separated by a '~' character.  It MUST NOT contain more or less than precisely two JWTs separated by the '~' character.  The first JWT MUST be the client attestation JWT defined in client-attestation-jwt, the second JWT MUST be the client attestation PoP defined in client-attestation-pop-jwt. </ins> The following example demonstrates client authentication using this scheme during the presentation of an authorization code grant in an
Original text:
5. <del> TODO </del>  6. <del> 6.1. </del>  This section registers the value "client-assertion-type:jwt-key- attestation" in the IANA "OAuth URI" registry established by "An IETF

Reviewer comments:
As highlighted in the title this PR adds a privacy consideration around potential client instance tracking along with a recommendation for client deployments to mitigate such risk.

Revised text:
5.  <ins> 5.1. Implementers should be aware that using the same client attestation across multiple authorization servers could result in correlation of the end user using the client instance through claim values (including the public key in the "cnf" claim).  Client deployments are therefore RECOMMENDED to use different client attestations across different authorization servers. </ins> 6.  <ins> TODO 7. 7.1. </ins> This section registers the value "client-assertion-type:jwt-key- attestation" in the IANA "OAuth URI" registry established by "An IETF
Original text:
Authentication Authentication o Change Controller: IESG o Specification Document: TBC <del> 6.2. </del>  This section registers the value "attest_key_client_auth" in the IANA "OAuth Token Endpoint Authentication Methods" registry established by

Reviewer comments:
As highlighted in the title this PR adds a privacy consideration around potential client instance tracking along with a recommendation for client deployments to mitigate such risk.

Revised text:
Authentication Authentication o Change Controller: IESG o Specification Document: TBC  <ins> 7.2. </ins> This section registers the value "attest_key_client_auth" in the IANA "OAuth Token Endpoint Authentication Methods" registry established by
Original text:
be used as a value for an "aud" element to identify the authorization server as the intended audience of the JWT.  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:
Add security consideration for replay attack prevention and add nonce as optional value for PoP JWT URL
Currently the specification does not define a mechanism for an AS contributed nonce to feature in the client attestation PoP meaning replay attack detection by authorisation servers requires tracking the JTI within the time window set by the PoP's iat claim. We should elaborate on an AS contributed nonce for the specification.
What about using the authorization code or pre auth code as suggested in our demo?
I think this is an option, however the nonce for client authentication becomes dependent on the grant type which creates a bit of an awkward coupling when an application wants to say use this mode of client authentication for grant type other than pre auth code or authorisation code.
How many implemantations out there actually use different grant types than auth-code? Given that this serves our purposes and imo everybody is using auth-code, I think that we should RECOMMEND that scenario but I#m ok with showing up alternatives as you suggested. NAME What's your opinion on this?
I think the flow can be used with and without nonce. If it is used without nonce, jti and short expiration must be used to limit the risk. If a nonce is used, I think using the codes is a pragmatic option. Alternatively, the AS could provide a dedicated nonce with the credential offer or authorization response. It could also provide the nonce with a token error response.
discussion on 23.05 is leaning towards DpoP-style error providing nonce
can we please bring this issue forward, it is very important? I see some advantages in that approach as it would allow the AS to request nonce use for all endpoints (including PAR).
on that topic, I would suggest such an AS provided nonce should be good up until the AS says otherwise. That would allow a client to use the same nonce for PAR and token endpoint.
Update provided in
PR
PR

Revised text:
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 "nonce" claim containing a String value that is provided by the authorization server to associate the Client Attestation PoP JWT with a particular transaction and prevent replay attacks. </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:
7.2.  TLS certificate checking MUST be performed by the client, as described in TLSRequirements, when making a protected resource metadata request.  Checking that the server certificate is valid for

Reviewer comments:
"The parameter is not meant to indicate that a client should request all scopes in the list. The client should still follow best practices and request tokens with as limited scope as possible for the given operation."

Revised text:
7.2. <ins> The "scopes_supported" parameter is the list of scopes the resource server is willing to disclose that it supports.  It is not meant to indicate that an OAuth client should request all scopes in the list. The client SHOULD still follow OAuth best practices and request tokens with as limited scope as possible for the given operation, as described in Section 2.3 of OAuth 2.0 Security Best Current Practice draft-ietf-oauth-security-topics. 7.3. </ins> TLS certificate checking MUST be performed by the client, as described in TLSRequirements, when making a protected resource metadata request.  Checking that the server certificate is valid for
Original text:
value in the protected resource metadata document received by the client. <del> 7.3. </del>  Publishing information about the protected resource in a standard format makes it easier for both legitimate clients and attackers to

Reviewer comments:
"The parameter is not meant to indicate that a client should request all scopes in the list. The client should still follow best practices and request tokens with as limited scope as possible for the given operation."

Revised text:
value in the protected resource metadata document received by the client.  <ins> 7.4. </ins> Publishing information about the protected resource in a standard format makes it easier for both legitimate clients and attackers to
Original text:
this specification, the same defenses against attacks that might be mounted that use this information should be applied. <del> 7.4. </del>  Secure determination of appropriate authorization servers to use with a protected resource for all use cases is out of scope of this

Reviewer comments:
"The parameter is not meant to indicate that a client should request all scopes in the list. The client should still follow best practices and request tokens with as limited scope as possible for the given operation."

Revised text:
this specification, the same defenses against attacks that might be mounted that use this information should be applied.  <ins> 7.5. </ins> Secure determination of appropriate authorization servers to use with a protected resource for all use cases is out of scope of this
Original text:
against one another for consistency when these lists are used by the application profile. <del> 7.5. </del>  The OAuth client is expected to fetch the authorization server metadata based on the value of the issuer in the resource server

Reviewer comments:
"The parameter is not meant to indicate that a client should request all scopes in the list. The client should still follow best practices and request tokens with as limited scope as possible for the given operation."

Revised text:
against one another for consistency when these lists are used by the application profile.  <ins> 7.6. </ins> The OAuth client is expected to fetch the authorization server metadata based on the value of the issuer in the resource server
Original text:
recommendations can be found in the OWASP SSRF Prevention Cheat Sheet OWASP.SSRF. <del> 7.6. </del>  This specification may be deployed in a scenario where the desired HTTP resource is identified by a user-selected URL.  If this resource

Reviewer comments:
"The parameter is not meant to indicate that a client should request all scopes in the list. The client should still follow best practices and request tokens with as limited scope as possible for the given operation."

Revised text:
recommendations can be found in the OWASP SSRF Prevention Cheat Sheet OWASP.SSRF.  <ins> 7.7. </ins> This specification may be deployed in a scenario where the desired HTTP resource is identified by a user-selected URL.  If this resource
Original text:
7.4.  Publishing information about the protected resource in a standard format makes it easier for both legitimate clients and attackers to use the protected resource.  Whether a protected resource publishes

Reviewer comments:
The security concern is when there are two separate RSs with different sets of scopes, it shouldn't be possible for RS1 to tell the client to ask for scopes for RS2, and then have RS1 be able to use the access token at RS2. Audience-restricted access tokens and resource indicators are a solution.
Apply my wording suggestion if you like it or don't if you don't. Then merge.

Revised text:
7.4. <ins> If a client expects to interact with multiple resource servers, the client SHOULD request audience-restricted access tokens using RFC8707, and the authorization server SHOULD support audience- restricted access tokens. Without audience-restricted access tokens, a malicious resource server (RS1) may be able to use the "WWW-Authenticate" header to get a client to request an access token with a scope used by a legitimate resource server (RS2), and after the client sends a request to RS1, then RS1 could re-use the access token at RS2. While this attack is not explicitly enabled by this specification, and is possible in a plain OAuth 2.0 deployment, it is made somewhat more likely by the use of dynamically-configured clients.  As such, the use of audience-restricted access tokens and Resource Indicators RFC8707 is RECOMMENDED when using the features in this specification. 7.5. </ins> Publishing information about the protected resource in a standard format makes it easier for both legitimate clients and attackers to use the protected resource.  Whether a protected resource publishes
Original text:
this specification, the same defenses against attacks that might be mounted that use this information should be applied. <del> 7.5. </del>  Secure determination of appropriate authorization servers to use with a protected resource for all use cases is out of scope of this

Reviewer comments:
The security concern is when there are two separate RSs with different sets of scopes, it shouldn't be possible for RS1 to tell the client to ask for scopes for RS2, and then have RS1 be able to use the access token at RS2. Audience-restricted access tokens and resource indicators are a solution.
Apply my wording suggestion if you like it or don't if you don't. Then merge.

Revised text:
this specification, the same defenses against attacks that might be mounted that use this information should be applied.  <ins> 7.6. </ins> Secure determination of appropriate authorization servers to use with a protected resource for all use cases is out of scope of this
Original text:
against one another for consistency when these lists are used by the application profile. <del> 7.6. </del>  The OAuth client is expected to fetch the authorization server metadata based on the value of the issuer in the resource server

Reviewer comments:
The security concern is when there are two separate RSs with different sets of scopes, it shouldn't be possible for RS1 to tell the client to ask for scopes for RS2, and then have RS1 be able to use the access token at RS2. Audience-restricted access tokens and resource indicators are a solution.
Apply my wording suggestion if you like it or don't if you don't. Then merge.

Revised text:
against one another for consistency when these lists are used by the application profile.  <ins> 7.7. </ins> The OAuth client is expected to fetch the authorization server metadata based on the value of the issuer in the resource server
Original text:
recommendations can be found in the OWASP SSRF Prevention Cheat Sheet OWASP.SSRF. <del> 7.7. </del>  This specification may be deployed in a scenario where the desired HTTP resource is identified by a user-selected URL.  If this resource

Reviewer comments:
The security concern is when there are two separate RSs with different sets of scopes, it shouldn't be possible for RS1 to tell the client to ask for scopes for RS2, and then have RS1 be able to use the access token at RS2. Audience-restricted access tokens and resource indicators are a solution.
Apply my wording suggestion if you like it or don't if you don't. Then merge.

Revised text:
recommendations can be found in the OWASP SSRF Prevention Cheat Sheet OWASP.SSRF.  <ins> 7.8. </ins> This specification may be deployed in a scenario where the desired HTTP resource is identified by a user-selected URL.  If this resource