From e556191469a8ce6c4bb84c25f856bcf2ca810530 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 9 May 2025 16:24:59 +0200 Subject: [PATCH 01/20] initial draft for challenge endpoint --- ...etf-oauth-attestation-based-client-auth.md | 75 ++++++++++++------- 1 file changed, 47 insertions(+), 28 deletions(-) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index 96b172f..5085d73 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -125,7 +125,7 @@ Please note that the protocol details for steps (2) and (4), particularly how th {::boilerplate bcp14-tagged} -# Terminology +# Terminology {#terminology} Client Attestation JWT: : A JSON Web Token (JWT) generated by the Client Attester which is bound to a key managed by a Client Instance which can then be used by the instance for client authentication. @@ -142,6 +142,9 @@ Client Instance Key: Client Attester: : An entity that authenticates a Client Instance and attests it by issuing a Client Attestation JWT. +Challenge: +: A String that is the input to a cryptographic challenge-response pattern. This is traditionally called nonce within OAuth. + # Relation to RATS The Remote Attestation Procedures (RATS) architecture defined by {{RFC9334}} has some commonalities to this document. The flow specified in this specification relates to the "Passport Model" in RATS. However, while the RATS ecosystem gives explicit methods and values how the RATS Attester proves itself to the Verifier, this is deliberately out of scope for Attestation-Based Client Authentication. Additionally, the terminology between RATS and OAuth is different: @@ -221,7 +224,7 @@ The following content applies to the JWT Claims Set: * `exp`: REQUIRED. The `exp` (expiration time) claim MUST specify the time at which the Client Attestation PoP is considered expired. The authorization server MUST reject any JWT with an expiration time that has passed, subject to allowable clock skew between systems. Note that the authorization server may reject JWTs with an "exp" claim value that is unreasonably far in the future. * `aud`: REQUIRED. The `aud` (audience) claim MUST specify 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. * `jti`: REQUIRED. The `jti` (JWT identifier) claim MUST specify a unique identifier for the Client Attestation PoP. 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. -* `nonce`: OPTIONAL. The `nonce` (nonce) claim MUST specify 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. +* `challenge`: OPTIONAL. The `challenge` (challenge) claim MUST specify 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. * `iat`: OPTIONAL. The `iat` (issued at) claim MUST specify the time at which the Client Attestation PoP was issued. Note that the authorization server may reject JWTs with an "iat" claim value that is unreasonably far in the past. * `nbf`: OPTIONAL. The `nbf` (not before) claim MUST specify the time before which the Client Attestation PoP MUST NOT be accepted for processing. @@ -249,7 +252,7 @@ The following example is the decoded header and payload of a JWT meeting the pro "nbf":1300815780, "exp":1300819380, "jti": "d25d00ab-552b-46fc-ae19-98f440f25064", - "nonce" : "5c1a9e10-29ff-4c2b-ae73-57c0957c09c4" + "challenge" : "5c1a9e10-29ff-4c2b-ae73-57c0957c09c4" } ~~~ @@ -424,32 +427,49 @@ To validate a client attestation using the concatenated serialization form, the 2. After the '~' character, there exists precisely a single well-formed JWT conforming to the syntax outlined in [](client-attestation-pop-jwt). 3. The signature of the Client Attestation PoP JWT obtained after the '~' character verifies with the Client Instance Key contained in the `cnf` claim of the Client Attestation JWT obtained before the '~' character. -# Nonce Retrieval {#nonce-retrieval} - -This specification defines header fields that allow a Client to request a fresh nonce value to be used in the OAuth-Client-Attestation-PoP. The nonce is opaque to the client. - -An Authorization Server compliant with this specification SHOULD signal via the metadata entry `client_attestation_pop_nonce_required` which endpoints support and expect a server-provided nonce. The client MUST retrieve a nonce before other calls to this endpoint and MUST use this nonce for the Client Attestation PoP. +# Challenge Retrieval {#challenge-retrieval} -A Request to an endpoint supporting the server-provided nonce MUST include the `attestation-nonce-request` field name with the value `true` and use the HTTP method of type OPTIONS (without payload) to actively request a nonce. The server answers with an HTTP Response with status code 200 without body, but sets the header field `attestation-nonce` to the nonce. +This section defines an optional mechanism that allows a Client to request a fresh Challenge from the Authorization Server to be used for the OAuth-Client-Attestation-PoP. This construct may be similar or equivalent to a nonce, see [](terminology). The challenge is opaque to the client. + +An Authorization Server MAY offer a challenge endpoint, that it MUST signal via the metadata entry `challenge_endpoint`. If the Authorization Server offers a challenge endpoint, the Client MUST retrieve a challenge and MUST use this challenge in the OAuth-Attestation-PoP as defined in (#client-attestation-pop-jwt). -The client MUST use this nonce in the OAuth-Attestation-PoP as defined in (#client-attestation-pop-jwt). +A request for a Challenge is made by sending an HTTP POST request to the URL provided in the challenge_endpoint parameter of the Authorization Server metadata. The following is a non-normative example of a request: ~~~ -OPTIONS /as/par HTTP/1.1 +POST /as/challenge HTTP/1.1 Host: as.example.com -attestation-nonce-request: true +Accept: application/json ~~~ -the following is a non-normative example of a response: +The Authorization Server provides a Challenge in the HTTP response with a 200 status code and the following parameters included in the message body of the HTTP response using the application/json media type: +* attestation-challenge: REQUIRED. String containing a Challenge to be used in the OAuth-Attestation-PoP as defined in (#client-attestation-pop-jwt). + +The Authorization Server MUST make the response uncacheable by adding a `Cache-Control` header field including the value `no-store`. The Authorization Server MAY add additional challenges or data. + +The following is a non-normative example of a response: ~~~ HTTP/1.1 200 OK Host: as.example.com -attestation-nonce: AYjcyMzY3ZDhiNmJkNTZ +attestation-challenge: AYjcyMzY3ZDhiNmJkNTZ +~~~ + +## Providing Challenges on Previous Successful Responses + +The Authorization Server MAY provide a fresh Challenge on any previous successful response using a HTTP header-based syntax. The HTTP header field parameter MUST be named "attestation-challenge" and contain the value of the Challenge. The Client MUST use this new Challenge for the next OAuth-Client-Attestation-PoP. + +The following is a non-normative example of an Authorization Response containing a fresh Challenge: + +~~~ +HTTP/1.1 302 Found +attestation-challenge: AYjcyMzY3ZDhiNmJkNTZ +Location: https://Wallet.example.org/cb? + code=SplxlOBeZQQYbYS6WxSbIA ~~~ + # Implementation Considerations ## Reuse of a Client Attestation JWT @@ -482,10 +502,10 @@ The guidance provided by {{RFC7519}} and {{RFC8725}} applies. The following mechanisms exist within this client authentication method in order to allow an authorization server to detect replay attacks for presented client attestation PoPs: - The client uses "jti" (JWT ID) claims for the Client Attestation PoP JWT and the authorization server maintains a list of used (seen) "jti" values for the time of which the JWT would be considered valid based on the applicable "exp" claim. If any Client Attestation PoP JWT would be replayed, the authorization server would recognize the "jti" and respond with an authentication error. -- The authorization server provides a nonce for the particular transaction and the client uses it for the "nonce" claim in the Client Attestation PoP JWT. The authorization server validates that the nonce matches for the transaction. This approach may require an additional roundtrip in the protocol. The authorization server MUST ensure that the nonce provides sufficient entropy. -- The authorization server may expect the usage of a nonce in the Client Attestation PoP JWT, but instead of providing the nonce explicitly, the client may implicitly reuse an existing artefact, e.g. the authorization code. The authorization server MUST ensure that the nonce provides sufficient entropy. +- The authorization server provides a challenge for the particular transaction and the client uses it for the "challenge" claim in the Client Attestation PoP JWT. The authorization server validates that the challenge matches for the transaction. This approach may require an additional roundtrip in the protocol. The authorization server MUST ensure that the challenge provides sufficient entropy. +- The authorization server may expect the usage of a challenge in the Client Attestation PoP JWT, but instead of providing the challenge explicitly, the client may implicitly reuse an existing artefact, e.g. the authorization code. The authorization server MUST ensure that the challenge provides sufficient entropy. -The approach using a nonce explicitly provided by the authorization server gives stronger replay attack detection guarantees, however support by the authorization server is OPTIONAL to simplify mandatory implementation requirements. The "jti" method is mandatory and hence acts as a default fallback. +The approach using a challenge explicitly provided by the authorization server gives stronger replay attack detection guarantees, however support by the authorization server is OPTIONAL to simplify mandatory implementation requirements. The "jti" method is mandatory and hence acts as a default fallback. # Appendix A IANA Considerations @@ -493,10 +513,10 @@ The approach using a nonce explicitly provided by the authorization server gives This specification requests registration of the following values in the IANA "OAuth Authorization Server Metadata" registry {{IANA.OAuth.Params}} established by {{RFC8414}}. -* Metadata Name: client_attestation_pop_nonce_required -* Metadata Description: An array of URLs that specify the endpoints supporting the nonce retrieval and expecting a Client Attestation bound to a server-provided nonce. +* Metadata Name: client_attestation_pop_challenge_required +* Metadata Description: An array of URLs that specify the endpoints supporting the challenge retrieval and expecting a Client Attestation bound to a server-provided challenge. * Change Controller: IETF -* Reference: [](#nonce-retrieval) of this specification +* Reference: [](#challenge-retrieval) of this specification ## Registration of attest_jwt_client_auth Token Endpoint Authentication Method @@ -521,19 +541,18 @@ This section requests registration of the following scheme in the "Hypertext Tra
-* Field Name: attestation-nonce-request +* Field Name: attestation-challenge * Status: permanent -* Reference: [](#nonce-retrieval) of this specification - -
- -* Field Name: attestation-nonce -* Status: permanent -* Reference: [](#nonce-retrieval) of this specification +* Reference: [](#challenge-retrieval) of this specification --- back # Document History +-06 + +* revert the HTTP OPTIONS mechanism to fetch nonces and add a dedicated challenge endpoint +* rename nonce to challenge + -05 * add nonce endpoint From 6cbc2ae36e5a8c2f77b04e518b6b91785f893247 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Fri, 9 May 2025 16:28:07 +0200 Subject: [PATCH 02/20] fix linting --- draft-ietf-oauth-attestation-based-client-auth.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index 5085d73..8b9c1b9 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -430,7 +430,7 @@ To validate a client attestation using the concatenated serialization form, the # Challenge Retrieval {#challenge-retrieval} This section defines an optional mechanism that allows a Client to request a fresh Challenge from the Authorization Server to be used for the OAuth-Client-Attestation-PoP. This construct may be similar or equivalent to a nonce, see [](terminology). The challenge is opaque to the client. - + An Authorization Server MAY offer a challenge endpoint, that it MUST signal via the metadata entry `challenge_endpoint`. If the Authorization Server offers a challenge endpoint, the Client MUST retrieve a challenge and MUST use this challenge in the OAuth-Attestation-PoP as defined in (#client-attestation-pop-jwt). A request for a Challenge is made by sending an HTTP POST request to the URL provided in the challenge_endpoint parameter of the Authorization Server metadata. From b0678359141d1ce26b3544416e8cb005962b3d35 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Tue, 20 May 2025 18:14:19 +0200 Subject: [PATCH 03/20] Apply suggestions from code review Co-authored-by: Tobias Looker Co-authored-by: Timo Glastra --- draft-ietf-oauth-attestation-based-client-auth.md | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index 8b9c1b9..6dfb79f 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -143,7 +143,7 @@ Client Attester: : An entity that authenticates a Client Instance and attests it by issuing a Client Attestation JWT. Challenge: -: A String that is the input to a cryptographic challenge-response pattern. This is traditionally called nonce within OAuth. +: A String that is the input to a cryptographic challenge-response pattern. This is traditionally called a nonce within OAuth. # Relation to RATS @@ -224,7 +224,7 @@ The following content applies to the JWT Claims Set: * `exp`: REQUIRED. The `exp` (expiration time) claim MUST specify the time at which the Client Attestation PoP is considered expired. The authorization server MUST reject any JWT with an expiration time that has passed, subject to allowable clock skew between systems. Note that the authorization server may reject JWTs with an "exp" claim value that is unreasonably far in the future. * `aud`: REQUIRED. The `aud` (audience) claim MUST specify 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. * `jti`: REQUIRED. The `jti` (JWT identifier) claim MUST specify a unique identifier for the Client Attestation PoP. 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. -* `challenge`: OPTIONAL. The `challenge` (challenge) claim MUST specify 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. +* `challenge`: OPTIONAL. The `challenge` (challenge) claim MUST specify a String value that is provided by the authorization server for the client to include in the Client Attestation PoP JWT. * `iat`: OPTIONAL. The `iat` (issued at) claim MUST specify the time at which the Client Attestation PoP was issued. Note that the authorization server may reject JWTs with an "iat" claim value that is unreasonably far in the past. * `nbf`: OPTIONAL. The `nbf` (not before) claim MUST specify the time before which the Client Attestation PoP MUST NOT be accepted for processing. @@ -429,7 +429,7 @@ To validate a client attestation using the concatenated serialization form, the # Challenge Retrieval {#challenge-retrieval} -This section defines an optional mechanism that allows a Client to request a fresh Challenge from the Authorization Server to be used for the OAuth-Client-Attestation-PoP. This construct may be similar or equivalent to a nonce, see [](terminology). The challenge is opaque to the client. +This section defines an optional mechanism that allows a Client to request a fresh Challenge from the Authorization Server to be included in the Client Attestation PoP JWT. This construct may be similar or equivalent to a nonce, see [](terminology). The value of the challenge is opaque to the client. An Authorization Server MAY offer a challenge endpoint, that it MUST signal via the metadata entry `challenge_endpoint`. If the Authorization Server offers a challenge endpoint, the Client MUST retrieve a challenge and MUST use this challenge in the OAuth-Attestation-PoP as defined in (#client-attestation-pop-jwt). @@ -444,7 +444,7 @@ Accept: application/json ~~~ The Authorization Server provides a Challenge in the HTTP response with a 200 status code and the following parameters included in the message body of the HTTP response using the application/json media type: -* attestation-challenge: REQUIRED. String containing a Challenge to be used in the OAuth-Attestation-PoP as defined in (#client-attestation-pop-jwt). +* attestation_challenge: REQUIRED. String containing a Challenge to be used in the OAuth-Attestation-PoP as defined in (#client-attestation-pop-jwt). The Authorization Server MUST make the response uncacheable by adding a `Cache-Control` header field including the value `no-store`. The Authorization Server MAY add additional challenges or data. @@ -453,7 +453,11 @@ The following is a non-normative example of a response: ~~~ HTTP/1.1 200 OK Host: as.example.com -attestation-challenge: AYjcyMzY3ZDhiNmJkNTZ +Content-Type: application/json + +{ + "attestation_challenge": "AYjcyMzY3ZDhiNmJkNTZ" +} ~~~ ## Providing Challenges on Previous Successful Responses From ce8fc80c92326c2005b613998ccaaaba256e9f9f Mon Sep 17 00:00:00 2001 From: Tobias Looker Date: Tue, 27 May 2025 18:23:03 +1200 Subject: [PATCH 04/20] Update draft-ietf-oauth-attestation-based-client-auth.md Co-authored-by: Paul Bastian --- draft-ietf-oauth-attestation-based-client-auth.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index 6dfb79f..1affe25 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -431,7 +431,7 @@ To validate a client attestation using the concatenated serialization form, the This section defines an optional mechanism that allows a Client to request a fresh Challenge from the Authorization Server to be included in the Client Attestation PoP JWT. This construct may be similar or equivalent to a nonce, see [](terminology). The value of the challenge is opaque to the client. -An Authorization Server MAY offer a challenge endpoint, that it MUST signal via the metadata entry `challenge_endpoint`. If the Authorization Server offers a challenge endpoint, the Client MUST retrieve a challenge and MUST use this challenge in the OAuth-Attestation-PoP as defined in (#client-attestation-pop-jwt). +An Authorization Server MAY offer a challenge endpoint for Clients to fetch Challenges in the context of this specification. If the Authorization Server supports metadata as defined in {{RFC8414}}, it MUST signal support for the challenge endpoint by including the metadata entry `challenge_endpoint` containing the URL of the endpoint as its value. If the Authorization Server offers a challenge endpoint, the Client MUST retrieve a challenge and MUST use this challenge in the OAuth-Attestation-PoP as defined in (#client-attestation-pop-jwt). A request for a Challenge is made by sending an HTTP POST request to the URL provided in the challenge_endpoint parameter of the Authorization Server metadata. From d5b7b4d2509ba2b042e91d7f2f35bc1608696169 Mon Sep 17 00:00:00 2001 From: Christian Bormann Date: Mon, 2 Jun 2025 22:45:42 +0200 Subject: [PATCH 05/20] allow error responses to contain a nonce --- draft-ietf-oauth-attestation-based-client-auth.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index 1affe25..64008b8 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -460,9 +460,9 @@ Content-Type: application/json } ~~~ -## Providing Challenges on Previous Successful Responses +## Providing Challenges on Previous Responses -The Authorization Server MAY provide a fresh Challenge on any previous successful response using a HTTP header-based syntax. The HTTP header field parameter MUST be named "attestation-challenge" and contain the value of the Challenge. The Client MUST use this new Challenge for the next OAuth-Client-Attestation-PoP. +The Authorization Server MAY provide a fresh Challenge on any previous successful response using a HTTP header-based syntax. The HTTP header field parameter MUST be named "attestation-challenge" and contain the value of the Challenge. The Client MUST use this new Challenge for the next OAuth-Client-Attestation-PoP. Note that this also includes error responses. The following is a non-normative example of an Authorization Response containing a fresh Challenge: From 2ca090dc0f9e8d17d640f5657aa7fbf332322ffa Mon Sep 17 00:00:00 2001 From: Christian Bormann Date: Mon, 2 Jun 2025 23:04:56 +0200 Subject: [PATCH 06/20] add error response values --- ...ietf-oauth-attestation-based-client-auth.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index 64008b8..cda52a8 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -317,6 +317,8 @@ To validate an HTTP request which contains the client attestation headers, the r 2. There is precisely one OAuth-Client-Attestation-PoP HTTP request header field, where its value is a single well-formed JWT conforming to the syntax outlined in [](client-attestation-pop-jwt). 3. The signature of the Client Attestation PoP JWT obtained from the OAuth-Client-Attestation-PoP HTTP header verifies with the Client Instance Key contained in the `cnf` claim of the Client Attestation JWT obtained from the OAuth-Client-Attestation HTTP header. +An error parameter according to Section 3 of {{RFC6750}} SHOULD be included to indicate why a request was declined. If the client attestation is absent or not using an expected server-provided challenge, the value `use_attestation_challenge` can be used to indicate that an attestation with a server-provided challenge was expected. If the attestation was present but could not be successfully verified, the value `invalid_client_attestation` is used. + ## Client Attestation at the Token Endpoint {#token-endpoint} While usage of the the client attestation mechanism defined by this draft can be used in a variety of different HTTP requests to different endpoints, usage within the token request as defined by {{RFC6749}} has particular additional considerations outlined below. @@ -522,6 +524,22 @@ This specification requests registration of the following values in the IANA "OA * Change Controller: IETF * Reference: [](#challenge-retrieval) of this specification +## OAuth Extensions Error Registration + +This specification requests registration of the following values in the IANA "OAuth Extensions Error Registry" registry of {{IANA.OAuth.Params}} established by {{RFC6749}}. + +* Name: use_attestation_challenge +* Usage Location: token error response, resource access error response +* Protocol Extension: OAuth 2.0 Attestation-Based Client Authentication +* Change Controller: IETF +* Reference: this specification + +* Name: invalid_client_attestation +* Usage Location: token error response, resource access error response +* Protocol Extension: OAuth 2.0 Attestation-Based Client Authentication +* Change Controller: IETF +* Reference: this specification + ## Registration of attest_jwt_client_auth Token Endpoint Authentication Method This section registers the value "attest_jwt_client_auth" in the IANA "OAuth Token Endpoint Authentication Methods" registry established by OAuth 2.0 Dynamic Client Registration Protocol {{RFC7591}}. From bc574abf7786258721b8dad5a60569cc26da49e1 Mon Sep 17 00:00:00 2001 From: Christian Bormann Date: Mon, 2 Jun 2025 23:06:38 +0200 Subject: [PATCH 07/20] document history and reference --- draft-ietf-oauth-attestation-based-client-auth.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index cda52a8..c3ee380 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -36,6 +36,7 @@ author: normative: RFC3986: RFC3986 + RFC6750: RFC6750 RFC7591: RFC7591 RFC7519: RFC7519 RFC7800: RFC7800 @@ -572,6 +573,7 @@ This section requests registration of the following scheme in the "Hypertext Tra -06 +* add oauth error response values `invalid_client_attestation` and `use_attestation_challenge` * revert the HTTP OPTIONS mechanism to fetch nonces and add a dedicated challenge endpoint * rename nonce to challenge From 43261f9e6a2447d1e8801302fc61a3abd31d4445 Mon Sep 17 00:00:00 2001 From: Christian Bormann <8774236+c2bo@users.noreply.github.com> Date: Mon, 2 Jun 2025 23:13:16 +0200 Subject: [PATCH 08/20] change to upper case name for header field Co-authored-by: Paul Bastian --- draft-ietf-oauth-attestation-based-client-auth.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index c3ee380..2768474 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -465,13 +465,13 @@ Content-Type: application/json ## Providing Challenges on Previous Responses -The Authorization Server MAY provide a fresh Challenge on any previous successful response using a HTTP header-based syntax. The HTTP header field parameter MUST be named "attestation-challenge" and contain the value of the Challenge. The Client MUST use this new Challenge for the next OAuth-Client-Attestation-PoP. Note that this also includes error responses. +The Authorization Server MAY provide a fresh Challenge on any previous successful response using a HTTP header-based syntax. The HTTP header field parameter MUST be named "Attestation-Challenge" and contain the value of the Challenge. The Client MUST use this new Challenge for the next OAuth-Client-Attestation-PoP. Note that this also includes error responses. The following is a non-normative example of an Authorization Response containing a fresh Challenge: ~~~ HTTP/1.1 302 Found -attestation-challenge: AYjcyMzY3ZDhiNmJkNTZ +Attestation-Challenge: AYjcyMzY3ZDhiNmJkNTZ Location: https://Wallet.example.org/cb? code=SplxlOBeZQQYbYS6WxSbIA ~~~ @@ -564,7 +564,7 @@ This section requests registration of the following scheme in the "Hypertext Tra
-* Field Name: attestation-challenge +* Field Name: Attestation-Challenge * Status: permanent * Reference: [](#challenge-retrieval) of this specification --- back From f1fef28c224fee753ea2c436463123cee76a96b9 Mon Sep 17 00:00:00 2001 From: Tobias Looker Date: Wed, 4 Jun 2025 11:54:03 +1200 Subject: [PATCH 09/20] update iana entry for challenge endpoint --- draft-ietf-oauth-attestation-based-client-auth.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index 2768474..22b4214 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -520,8 +520,8 @@ The approach using a challenge explicitly provided by the authorization server g This specification requests registration of the following values in the IANA "OAuth Authorization Server Metadata" registry {{IANA.OAuth.Params}} established by {{RFC8414}}. -* Metadata Name: client_attestation_pop_challenge_required -* Metadata Description: An array of URLs that specify the endpoints supporting the challenge retrieval and expecting a Client Attestation bound to a server-provided challenge. +* Metadata Name: challenge_endpoint +* Metadata Description: URL of the authorization servers challenge endpoint which is used to obtain a fresh challenge for usage in client authentication methods such as client attestation. * Change Controller: IETF * Reference: [](#challenge-retrieval) of this specification From 803ea079375a6e1fd3a3aae1254ec540d7fef7d0 Mon Sep 17 00:00:00 2001 From: Tobias Looker Date: Wed, 4 Jun 2025 11:58:04 +1200 Subject: [PATCH 10/20] namespace the challenge --- draft-ietf-oauth-attestation-based-client-auth.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index 22b4214..3202317 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -465,13 +465,13 @@ Content-Type: application/json ## Providing Challenges on Previous Responses -The Authorization Server MAY provide a fresh Challenge on any previous successful response using a HTTP header-based syntax. The HTTP header field parameter MUST be named "Attestation-Challenge" and contain the value of the Challenge. The Client MUST use this new Challenge for the next OAuth-Client-Attestation-PoP. Note that this also includes error responses. +The Authorization Server MAY provide a fresh Challenge on any previous successful response using a HTTP header-based syntax. The HTTP header field parameter MUST be named "OAuth-Client-Attestation-Challenge" and contain the value of the Challenge. The Client MUST use this new Challenge for the next OAuth-Client-Attestation-PoP. Note that this also includes error responses. The following is a non-normative example of an Authorization Response containing a fresh Challenge: ~~~ HTTP/1.1 302 Found -Attestation-Challenge: AYjcyMzY3ZDhiNmJkNTZ +OAuth-Client-Attestation-Challenge: AYjcyMzY3ZDhiNmJkNTZ Location: https://Wallet.example.org/cb? code=SplxlOBeZQQYbYS6WxSbIA ~~~ @@ -564,7 +564,7 @@ This section requests registration of the following scheme in the "Hypertext Tra
-* Field Name: Attestation-Challenge +* Field Name: OAuth-Client-Attestation-Challenge * Status: permanent * Reference: [](#challenge-retrieval) of this specification --- back From 42b73d6e384db9260719e48284658094d9f449af Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Sat, 7 Jun 2025 22:37:15 +0200 Subject: [PATCH 11/20] implementation consideration for replay detection --- ...t-ietf-oauth-attestation-based-client-auth.md | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index 3202317..72f9924 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -494,6 +494,16 @@ Because the Client Attestation and Client Attestation PoP are communicated using This specification does not provide a mechanism to rotate the Client Instance Key in the Client Attestation JWT's "cnf" claim. If the Client Instance needs to use a new Client Instance Key for any reason, then it MUST request a new Client Attestation JWT from its Client Attester. +## Replay Attack Detection + +Authorization Servers implementing measures to detect replay attacks as described in [](security-consideration-replay) require efficient data structures to manage large amounts of challenges for use cases with high volumes of transactions. To limit the size of the data structure, the Authorization Server should use a sliding window, allowing Client Attestation PoPs within a certain time window, in which the seen `challenge` or `jti` values are stored, but discard them afterwards. To ensure security, Client Attestation PoPs outside this time window MUST be rejected by the Authorization Server. The allowed window is determined by the `iat` of the Client Attestation PoP and the sliding window time duration chosen by the Authorization Server. These data structures need to: + +- search the data structure to validate whether a challenge form a Client Attestation PoP has been previously seen +- insert the new challenges from the Client Attestation PoP if the search returned no result +- delete the challenges after the Client Attestation PoP has passed the sliding time window + +A trie (also called prefix tree), or a patricia trie (also called radix tree) is a RECOMMENDED data structures to implement such a mechanism. + # Privacy Considerations ## Client Instance Tracking Across Authorization Servers @@ -504,7 +514,11 @@ Implementers should be aware that using the same client attestation across multi The guidance provided by {{RFC7519}} and {{RFC8725}} applies. -## Replay Attack Detection +## Freshness {#security-consideration-freshness} + +todo + +## Replay Attack Detection {#security-consideration-replay} The following mechanisms exist within this client authentication method in order to allow an authorization server to detect replay attacks for presented client attestation PoPs: From a43db1b87ec460c81676469527f13a7621c40410 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Mon, 9 Jun 2025 23:54:11 +0200 Subject: [PATCH 12/20] rewrite security consideration on replay attacks --- ...etf-oauth-attestation-based-client-auth.md | 26 +++++++++++-------- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index 72f9924..4fe739b 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -494,9 +494,9 @@ Because the Client Attestation and Client Attestation PoP are communicated using This specification does not provide a mechanism to rotate the Client Instance Key in the Client Attestation JWT's "cnf" claim. If the Client Instance needs to use a new Client Instance Key for any reason, then it MUST request a new Client Attestation JWT from its Client Attester. -## Replay Attack Detection +## Replay Attack Detection {#implementation-consideration-replay} -Authorization Servers implementing measures to detect replay attacks as described in [](security-consideration-replay) require efficient data structures to manage large amounts of challenges for use cases with high volumes of transactions. To limit the size of the data structure, the Authorization Server should use a sliding window, allowing Client Attestation PoPs within a certain time window, in which the seen `challenge` or `jti` values are stored, but discard them afterwards. To ensure security, Client Attestation PoPs outside this time window MUST be rejected by the Authorization Server. The allowed window is determined by the `iat` of the Client Attestation PoP and the sliding window time duration chosen by the Authorization Server. These data structures need to: +Authorization Servers implementing measures to detect replay attacks as described in [](#security-consideration-replay) require efficient data structures to manage large amounts of challenges for use cases with high volumes of transactions. To limit the size of the data structure, the Authorization Server should use a sliding window, allowing Client Attestation PoPs within a certain time window, in which the seen `challenge` or `jti` values are stored, but discard them afterwards. To ensure security, Client Attestation PoPs outside this time window MUST be rejected by the Authorization Server. The allowed window is determined by the `iat` of the Client Attestation PoP and the sliding window time duration chosen by the Authorization Server. These data structures need to: - search the data structure to validate whether a challenge form a Client Attestation PoP has been previously seen - insert the new challenges from the Client Attestation PoP if the search returned no result @@ -514,19 +514,21 @@ Implementers should be aware that using the same client attestation across multi The guidance provided by {{RFC7519}} and {{RFC8725}} applies. -## Freshness {#security-consideration-freshness} +## Replay Attacks {#security-consideration-replay} -todo +An Authorization Server MUST implement measures to detect replay attacks by the Client Instance. In the context of this specification, this means to detect that an attacker is resending any Client Attestation PoP JWT an Authorization Server. The following options are RECOMMENDED for this client authentication method: -## Replay Attack Detection {#security-consideration-replay} +- The Authorization Server manages a list of witnessed `jti` values of the Client Attestation PoP JWT for the time window of which the JWT would be considered valid. This sliding time window is based on the `iat` of the Client Attestation PoP and and the duration chosen by the Authorization Server. If any Client Attestation PoP JWT would be replayed, the Authorization Server would recognize the `jti` value in the list and respond with an authentication error. Details how to implement such a data structure to maintain `jti` values is given in [](#implementation-consideration-replay). +- The Authorization Server provides a challenge as an `OAuth-Client-Attestation-Challenge` in the challenge endpoint to the Client Instance and the Client uses it as a `challenge` value in the Client Attestation PoP JWT. The Authorization Server may chose to: + - manage a list of witnissed `challenge` values, similar to the previously described `jti` approach. Details how to implement such a data structure to maintain `challenge` values is given in [](#implementation-consideration-replay). This guarantees stronger replay protection with a challenge chosen by the Authorization Server itself, at the potential cost of an additional round-trip. + - use self-contained challenges while not storing the seen challenges. This approach scales well, while only guaranteeing freshness, but no replay protection within the limited time-window chosen by the Authorization Server. +- The Authorization Server generates a challenge that is bound to the Client Instance's session, such that a specific `challenge` in the Client Attestation PoP JWT is expected and validated. The Authorization Server may either: +- send the challenge as part of another previous response to the Client Instance of providing the challenge explicitly +- reuse an existing artefact of the Client Instance's session, e.g. the authorization code. This MUST be communicated out-of-band between Authorization Server and Client. -The following mechanisms exist within this client authentication method in order to allow an authorization server to detect replay attacks for presented client attestation PoPs: +It is important for successful replay attack detection to have considerable time synchronization between Authorization Server and the Client. Furthermore, the Authorization Server MUST reject Client Attestation PoP JWTs that have `iat` values too far in the future or past beyond an agreeable time difference. -- The client uses "jti" (JWT ID) claims for the Client Attestation PoP JWT and the authorization server maintains a list of used (seen) "jti" values for the time of which the JWT would be considered valid based on the applicable "exp" claim. If any Client Attestation PoP JWT would be replayed, the authorization server would recognize the "jti" and respond with an authentication error. -- The authorization server provides a challenge for the particular transaction and the client uses it for the "challenge" claim in the Client Attestation PoP JWT. The authorization server validates that the challenge matches for the transaction. This approach may require an additional roundtrip in the protocol. The authorization server MUST ensure that the challenge provides sufficient entropy. -- The authorization server may expect the usage of a challenge in the Client Attestation PoP JWT, but instead of providing the challenge explicitly, the client may implicitly reuse an existing artefact, e.g. the authorization code. The authorization server MUST ensure that the challenge provides sufficient entropy. - -The approach using a challenge explicitly provided by the authorization server gives stronger replay attack detection guarantees, however support by the authorization server is OPTIONAL to simplify mandatory implementation requirements. The "jti" method is mandatory and hence acts as a default fallback. +The approach using a challenge explicitly provided by the Authorization Server gives stronger replay attack detection guarantees, however support by the Authorization Server is OPTIONAL to simplify mandatory implementation requirements. The `jti` value is mandatory and hence acts as a default fallback. # Appendix A IANA Considerations @@ -590,6 +592,8 @@ This section requests registration of the following scheme in the "Hypertext Tra * add oauth error response values `invalid_client_attestation` and `use_attestation_challenge` * revert the HTTP OPTIONS mechanism to fetch nonces and add a dedicated challenge endpoint * rename nonce to challenge +* rewrite security consideration on replay attacks +* add implementation consideration on replay attacks -05 From e4b289e37706e30f71436f6339c191153f31a9c4 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Tue, 10 Jun 2025 10:52:08 +0200 Subject: [PATCH 13/20] Update draft-ietf-oauth-attestation-based-client-auth.md --- draft-ietf-oauth-attestation-based-client-auth.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index 4fe739b..990cfd2 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -523,8 +523,8 @@ An Authorization Server MUST implement measures to detect replay attacks by the - manage a list of witnissed `challenge` values, similar to the previously described `jti` approach. Details how to implement such a data structure to maintain `challenge` values is given in [](#implementation-consideration-replay). This guarantees stronger replay protection with a challenge chosen by the Authorization Server itself, at the potential cost of an additional round-trip. - use self-contained challenges while not storing the seen challenges. This approach scales well, while only guaranteeing freshness, but no replay protection within the limited time-window chosen by the Authorization Server. - The Authorization Server generates a challenge that is bound to the Client Instance's session, such that a specific `challenge` in the Client Attestation PoP JWT is expected and validated. The Authorization Server may either: -- send the challenge as part of another previous response to the Client Instance of providing the challenge explicitly -- reuse an existing artefact of the Client Instance's session, e.g. the authorization code. This MUST be communicated out-of-band between Authorization Server and Client. + - send the challenge as part of another previous response to the Client Instance of providing the challenge explicitly + - reuse an existing artefact of the Client Instance's session, e.g. the authorization code. This MUST be communicated out-of-band between Authorization Server and Client. It is important for successful replay attack detection to have considerable time synchronization between Authorization Server and the Client. Furthermore, the Authorization Server MUST reject Client Attestation PoP JWTs that have `iat` values too far in the future or past beyond an agreeable time difference. From b0a46d2ab1267717a34bc0ec0e8dcc60a61e0aa3 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Sat, 14 Jun 2025 08:38:28 +0200 Subject: [PATCH 14/20] Update draft-ietf-oauth-attestation-based-client-auth.md --- draft-ietf-oauth-attestation-based-client-auth.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index 990cfd2..29871ce 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -318,7 +318,7 @@ To validate an HTTP request which contains the client attestation headers, the r 2. There is precisely one OAuth-Client-Attestation-PoP HTTP request header field, where its value is a single well-formed JWT conforming to the syntax outlined in [](client-attestation-pop-jwt). 3. The signature of the Client Attestation PoP JWT obtained from the OAuth-Client-Attestation-PoP HTTP header verifies with the Client Instance Key contained in the `cnf` claim of the Client Attestation JWT obtained from the OAuth-Client-Attestation HTTP header. -An error parameter according to Section 3 of {{RFC6750}} SHOULD be included to indicate why a request was declined. If the client attestation is absent or not using an expected server-provided challenge, the value `use_attestation_challenge` can be used to indicate that an attestation with a server-provided challenge was expected. If the attestation was present but could not be successfully verified, the value `invalid_client_attestation` is used. +An error parameter according to Section 3 of {{RFC6750}} SHOULD be included to indicate why a request was declined. If the Client Attestation is absent or not using an expected server-provided challenge, the value `use_attestation_challenge` can be used to indicate that an attestation with a server-provided challenge was expected. If the attestation was present but could not be successfully verified, the value `invalid_client_attestation` is used. ## Client Attestation at the Token Endpoint {#token-endpoint} From 32254ad440d38074713421f549463d5c928f3a37 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Sat, 14 Jun 2025 08:41:14 +0200 Subject: [PATCH 15/20] Update draft-ietf-oauth-attestation-based-client-auth.md Co-authored-by: Christian Bormann <8774236+c2bo@users.noreply.github.com> --- draft-ietf-oauth-attestation-based-client-auth.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index 29871ce..16c279c 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -496,7 +496,7 @@ This specification does not provide a mechanism to rotate the Client Instance Ke ## Replay Attack Detection {#implementation-consideration-replay} -Authorization Servers implementing measures to detect replay attacks as described in [](#security-consideration-replay) require efficient data structures to manage large amounts of challenges for use cases with high volumes of transactions. To limit the size of the data structure, the Authorization Server should use a sliding window, allowing Client Attestation PoPs within a certain time window, in which the seen `challenge` or `jti` values are stored, but discard them afterwards. To ensure security, Client Attestation PoPs outside this time window MUST be rejected by the Authorization Server. The allowed window is determined by the `iat` of the Client Attestation PoP and the sliding window time duration chosen by the Authorization Server. These data structures need to: +Authorization Servers implementing measures to detect replay attacks as described in [](#security-consideration-replay) require efficient data structures to manage large amounts of challenges for use cases with high volumes of transactions. To limit the size of the data structure, the Authorization Server should use a sliding window, allowing Client Attestation PoPs within a certain time window, in which the seen `challenge` or `jti` values are stored, but discarded afterwards. To ensure security, Client Attestation PoPs outside this time window MUST be rejected by the Authorization Server. The allowed window is determined by the `iat` of the Client Attestation PoP and the sliding window time duration chosen by the Authorization Server. These data structures need to: - search the data structure to validate whether a challenge form a Client Attestation PoP has been previously seen - insert the new challenges from the Client Attestation PoP if the search returned no result From 962e5d102077c6c5602c295ba7c7378ae5941b71 Mon Sep 17 00:00:00 2001 From: Tobias Looker Date: Thu, 3 Jul 2025 07:55:50 +1200 Subject: [PATCH 16/20] Update draft-ietf-oauth-attestation-based-client-auth.md --- draft-ietf-oauth-attestation-based-client-auth.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index 16c279c..ef1b78c 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -520,7 +520,7 @@ An Authorization Server MUST implement measures to detect replay attacks by the - The Authorization Server manages a list of witnessed `jti` values of the Client Attestation PoP JWT for the time window of which the JWT would be considered valid. This sliding time window is based on the `iat` of the Client Attestation PoP and and the duration chosen by the Authorization Server. If any Client Attestation PoP JWT would be replayed, the Authorization Server would recognize the `jti` value in the list and respond with an authentication error. Details how to implement such a data structure to maintain `jti` values is given in [](#implementation-consideration-replay). - The Authorization Server provides a challenge as an `OAuth-Client-Attestation-Challenge` in the challenge endpoint to the Client Instance and the Client uses it as a `challenge` value in the Client Attestation PoP JWT. The Authorization Server may chose to: - - manage a list of witnissed `challenge` values, similar to the previously described `jti` approach. Details how to implement such a data structure to maintain `challenge` values is given in [](#implementation-consideration-replay). This guarantees stronger replay protection with a challenge chosen by the Authorization Server itself, at the potential cost of an additional round-trip. + - manage a list of witnessed `challenge` values, similar to the previously described `jti` approach. Details how to implement such a data structure to maintain `challenge` values is given in [](#implementation-consideration-replay). This guarantees stronger replay protection with a challenge chosen by the Authorization Server itself, at the potential cost of an additional round-trip. - use self-contained challenges while not storing the seen challenges. This approach scales well, while only guaranteeing freshness, but no replay protection within the limited time-window chosen by the Authorization Server. - The Authorization Server generates a challenge that is bound to the Client Instance's session, such that a specific `challenge` in the Client Attestation PoP JWT is expected and validated. The Authorization Server may either: - send the challenge as part of another previous response to the Client Instance of providing the challenge explicitly From 66fc8bac38ab2d7cd94f3c371765571d481d07b9 Mon Sep 17 00:00:00 2001 From: Christian Bormann <8774236+c2bo@users.noreply.github.com> Date: Sat, 5 Jul 2025 19:28:27 +0200 Subject: [PATCH 17/20] Apply suggestions from filip's review Co-authored-by: Filip Skokan --- ...ietf-oauth-attestation-based-client-auth.md | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index ef1b78c..4835b87 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -253,7 +253,7 @@ The following example is the decoded header and payload of a JWT meeting the pro "nbf":1300815780, "exp":1300819380, "jti": "d25d00ab-552b-46fc-ae19-98f440f25064", - "challenge" : "5c1a9e10-29ff-4c2b-ae73-57c0957c09c4" + "challenge": "5c1a9e10-29ff-4c2b-ae73-57c0957c09c4" } ~~~ @@ -318,7 +318,7 @@ To validate an HTTP request which contains the client attestation headers, the r 2. There is precisely one OAuth-Client-Attestation-PoP HTTP request header field, where its value is a single well-formed JWT conforming to the syntax outlined in [](client-attestation-pop-jwt). 3. The signature of the Client Attestation PoP JWT obtained from the OAuth-Client-Attestation-PoP HTTP header verifies with the Client Instance Key contained in the `cnf` claim of the Client Attestation JWT obtained from the OAuth-Client-Attestation HTTP header. -An error parameter according to Section 3 of {{RFC6750}} SHOULD be included to indicate why a request was declined. If the Client Attestation is absent or not using an expected server-provided challenge, the value `use_attestation_challenge` can be used to indicate that an attestation with a server-provided challenge was expected. If the attestation was present but could not be successfully verified, the value `invalid_client_attestation` is used. +An error parameter according to Section 3 of {{RFC6750}} SHOULD be included to indicate why a request was declined. If the Client Attestation is absent or not using an expected server-provided challenge, the value `use_attestation_challenge` can be used to indicate that an attestation with a server-provided challenge was expected. If the attestation and proof of possession was present but could not be successfully verified, the value `invalid_client_attestation` is used. ## Client Attestation at the Token Endpoint {#token-endpoint} @@ -465,15 +465,21 @@ Content-Type: application/json ## Providing Challenges on Previous Responses -The Authorization Server MAY provide a fresh Challenge on any previous successful response using a HTTP header-based syntax. The HTTP header field parameter MUST be named "OAuth-Client-Attestation-Challenge" and contain the value of the Challenge. The Client MUST use this new Challenge for the next OAuth-Client-Attestation-PoP. Note that this also includes error responses. +The Authorization Server MAY provide a fresh Challenge with any HTTP response using a HTTP header-based syntax. The HTTP header field parameter MUST be named "OAuth-Client-Attestation-Challenge" and contain the value of the Challenge. The Client MUST use this new Challenge for the next OAuth-Client-Attestation-PoP. The following is a non-normative example of an Authorization Response containing a fresh Challenge: ~~~ -HTTP/1.1 302 Found +HTTP/1.1 200 OK +Content-Type: application/json +Cache-Control: no-store OAuth-Client-Attestation-Challenge: AYjcyMzY3ZDhiNmJkNTZ -Location: https://Wallet.example.org/cb? - code=SplxlOBeZQQYbYS6WxSbIA + +{ + "access_token": "2YotnFZFEjr1zCsicMWpAA", + "token_type": "Bearer", + "expires_in": 3600 +} ~~~ From 1b3e83d9caf1b598884cea12dc4d587c6438c91a Mon Sep 17 00:00:00 2001 From: Tobias Looker Date: Mon, 7 Jul 2025 18:30:22 +1200 Subject: [PATCH 18/20] Update draft-ietf-oauth-attestation-based-client-auth.md --- draft-ietf-oauth-attestation-based-client-auth.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index 4835b87..3348bbc 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -447,7 +447,7 @@ Accept: application/json ~~~ The Authorization Server provides a Challenge in the HTTP response with a 200 status code and the following parameters included in the message body of the HTTP response using the application/json media type: -* attestation_challenge: REQUIRED. String containing a Challenge to be used in the OAuth-Attestation-PoP as defined in (#client-attestation-pop-jwt). +* attestation_challenge: REQUIRED if the authorization server supports Client Attestations and server provided challenges as described in this document. String containing a Challenge to be used in the OAuth-Attestation-PoP as defined in (#client-attestation-pop-jwt). The intention of this element not being required in other circumstances is to preserve the ability for the challenge endpoint to be used in other applications unrelated to client attestations. The Authorization Server MUST make the response uncacheable by adding a `Cache-Control` header field including the value `no-store`. The Authorization Server MAY add additional challenges or data. From b442da872e98b7b447d712a985fc35435cbe61b5 Mon Sep 17 00:00:00 2001 From: Tobias Looker Date: Mon, 7 Jul 2025 18:32:20 +1200 Subject: [PATCH 19/20] Update draft-ietf-oauth-attestation-based-client-auth.md --- draft-ietf-oauth-attestation-based-client-auth.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index 3348bbc..00f32cf 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -522,7 +522,7 @@ The guidance provided by {{RFC7519}} and {{RFC8725}} applies. ## Replay Attacks {#security-consideration-replay} -An Authorization Server MUST implement measures to detect replay attacks by the Client Instance. In the context of this specification, this means to detect that an attacker is resending any Client Attestation PoP JWT an Authorization Server. The following options are RECOMMENDED for this client authentication method: +An Authorization Server SHOULD implement measures to detect replay attacks by the Client Instance. In the context of this specification, this means to detect that an attacker is resending the same Client Attestation PoP JWT in multiple requests. The following options are RECOMMENDED for this client authentication method: - The Authorization Server manages a list of witnessed `jti` values of the Client Attestation PoP JWT for the time window of which the JWT would be considered valid. This sliding time window is based on the `iat` of the Client Attestation PoP and and the duration chosen by the Authorization Server. If any Client Attestation PoP JWT would be replayed, the Authorization Server would recognize the `jti` value in the list and respond with an authentication error. Details how to implement such a data structure to maintain `jti` values is given in [](#implementation-consideration-replay). - The Authorization Server provides a challenge as an `OAuth-Client-Attestation-Challenge` in the challenge endpoint to the Client Instance and the Client uses it as a `challenge` value in the Client Attestation PoP JWT. The Authorization Server may chose to: From abf6874c47e7f89961de693c45f58aac84277867 Mon Sep 17 00:00:00 2001 From: Tobias Looker Date: Mon, 7 Jul 2025 18:41:32 +1200 Subject: [PATCH 20/20] Update draft-ietf-oauth-attestation-based-client-auth.md --- draft-ietf-oauth-attestation-based-client-auth.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/draft-ietf-oauth-attestation-based-client-auth.md b/draft-ietf-oauth-attestation-based-client-auth.md index 00f32cf..f76843f 100644 --- a/draft-ietf-oauth-attestation-based-client-auth.md +++ b/draft-ietf-oauth-attestation-based-client-auth.md @@ -532,7 +532,9 @@ An Authorization Server SHOULD implement measures to detect replay attacks by th - send the challenge as part of another previous response to the Client Instance of providing the challenge explicitly - reuse an existing artefact of the Client Instance's session, e.g. the authorization code. This MUST be communicated out-of-band between Authorization Server and Client. -It is important for successful replay attack detection to have considerable time synchronization between Authorization Server and the Client. Furthermore, the Authorization Server MUST reject Client Attestation PoP JWTs that have `iat` values too far in the future or past beyond an agreeable time difference. +Because clock skews between servers and clients may be large, Authorization Servers MAY limit Client Attestation PoP lifetimes by using server-provided challenge values containing the time at the server rather than comparing the client-supplied iat time to the time at the server. Challenges created in this way yield the same result even in the face of arbitrarily large clock skews. + +In any case the Authorization Server SHOULD ensure the freshness of the Client Attestation PoP by checking either the iat claim or if present the server provided challenge, is within an acceptable time window. The approach using a challenge explicitly provided by the Authorization Server gives stronger replay attack detection guarantees, however support by the Authorization Server is OPTIONAL to simplify mandatory implementation requirements. The `jti` value is mandatory and hence acts as a default fallback.