



Web Authorization Protocol                                     T. Looker
Internet-Draft                                                     MATTR
Intended status: Standards Track                              P. Bastian
Expires: 27 November 2026                                Bundesdruckerei
                                                              C. Bormann
                                                                  SPRIND
                                                             26 May 2026


           OAuth 2.0 Attestation-Based Client Authentication
           draft-ietf-oauth-attestation-based-client-auth-09

Abstract

   This specification defines an extension to the OAuth 2.0 protocol
   [RFC6749] that enables a client instance to include a key-bound
   attestation when interacting with an Authorization Server or Resource
   Server.  This mechanism allows a client instance to prove its
   authenticity verified by a client attester without revealing its
   target audience to that attester.  It may also serve as a mechanism
   for client authentication as per OAuth 2.0.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at https://oauth-
   wg.github.io/draft-ietf-oauth-attestation-based-client-auth/draft-
   ietf-oauth-attestation-based-client-auth.html.  Status information
   for this document may be found at https://datatracker.ietf.org/doc/
   draft-ietf-oauth-attestation-based-client-auth/.

   Discussion of this document takes place on the Web Authorization
   Protocol Working Group mailing list (mailto:oauth@ietf.org), which is
   archived at https://mailarchive.ietf.org/arch/browse/oauth/.
   Subscribe at https://www.ietf.org/mailman/listinfo/oauth/.

   Source for this draft and an issue tracker can be found at
   https://github.com/oauth-wg/draft-ietf-oauth-attestation-based-
   client-auth.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.






Looker, et al.          Expires 27 November 2026                [Page 1]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 27 November 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   6
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Client Attestation JWT  . . . . . . . . . . . . . . . . . . .   7
   5.  Proof of Possession . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  Client Attestation PoP JWT  . . . . . . . . . . . . . . .   9
     5.2.  Using DPoP as the Proof of Possession . . . . . . . . . .  11
   6.  Challenges  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     6.1.  Providing Challenges through the Challenge Endpoint . . .  12
     6.2.  Providing Challenges on Previous Responses  . . . . . . .  13
   7.  Verification and Processing . . . . . . . . . . . . . . . . .  14
     7.1.  Client Attestation JWT  . . . . . . . . . . . . . . . . .  14
     7.2.  Client Attestation PoP JWT  . . . . . . . . . . . . . . .  14
     7.3.  DPoP Combined Mode  . . . . . . . . . . . . . . . . . . .  15
     7.4.  Errors  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     7.5.  Client Attestation as an OAuth Client Authentication  . .  17
     7.6.  Client Attestation as an additional security signal . . .  17
   8.  Authorization Server Metadata . . . . . . . . . . . . . . . .  19
   9.  Implementation Considerations . . . . . . . . . . . . . . . .  20
     9.1.  DPoP Combined Mode Considerations . . . . . . . . . . . .  20



Looker, et al.          Expires 27 November 2026                [Page 2]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


     9.2.  Reuse of a Client Attestation JWT . . . . . . . . . . . .  20
     9.3.  Refresh token binding . . . . . . . . . . . . . . . . . .  20
     9.4.  Web Server Default Maximum HTTP Header Sizes  . . . . . .  21
     9.5.  Rotation of Client Instance Key . . . . . . . . . . . . .  21
     9.6.  Replay Attack Detection . . . . . . . . . . . . . . . . .  21
     9.7.  Trust Management and Key Resolution . . . . . . . . . . .  22
   10. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  23
     10.1.  Client Instance Tracking Across Authorization Servers or
            Resource Servers . . . . . . . . . . . . . . . . . . . .  23
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  23
     11.1.  Replay Attacks . . . . . . . . . . . . . . . . . . . . .  23
     11.2.  Client Attestation Protection  . . . . . . . . . . . . .  25
   12. Relation to RATS  . . . . . . . . . . . . . . . . . . . . . .  25
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  25
     13.1.  OAuth Parameters Registration  . . . . . . . . . . . . .  26
     13.2.  OAuth Extensions Error Registration  . . . . . . . . . .  26
     13.3.  OAuth Authorization Server Metadata Registration . . . .  27
     13.4.  Registration of attest_jwt_client_auth Token Endpoint
            Authentication Method  . . . . . . . . . . . . . . . . .  27
     13.5.  Registration of attest_jwt_client_auth_dpop Token Endpoint
            Authentication Method  . . . . . . . . . . . . . . . . .  28
     13.6.  HTTP Field Name Registration . . . . . . . . . . . . . .  28
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  29
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  29
     14.2.  Informative References . . . . . . . . . . . . . . . . .  31
   Appendix A.  Document History . . . . . . . . . . . . . . . . . .  31
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  35
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  35

1.  Introduction

   Traditional OAuth client authentication methods, such as
   private_key_jwt defined in [RFC7523], typically rely on a direct
   connection between the client's backend and the Authorization Server.
   In ecosystems such as the Issuer-Holder-Verifier model used in
   [RFC9901], this direct communication raises privacy concerns, as it
   would enable the client's backend (i.e. client attester) to correlate
   which Holder (i.e. client) interacts with which Issuer (i.e.
   Authorization Server) and potentially observe the credentials or
   metadata being issued.  This specification establishes a mechanism
   for a backend-attested client authentication through a front-channel
   to address these issues.

   Additionally, this approach acknowledges the evolving landscape of
   OAuth 2 deployments, where the ability for mobile native apps to
   authenticate securely and reliably has become increasingly important.
   Leveraging platform mechanisms to validate a client instance, such as
   mobile native apps, enables secure authentication that would



Looker, et al.          Expires 27 November 2026                [Page 3]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   otherwise be difficult with traditional OAuth client authentication
   methods.  Transforming these platform-specific mechanisms into a
   common format as described in this specification abstracts this
   complexity to minimize the efforts for the Authorization Server.

   This primary purpose of this specification is the authentication of a
   client instance enabled through the client backend attesting to it.
   The client backend may also attest further technical properties about
   the hardware and software of the client instance.

   The client is considered a confidential OAuth 2 client type according
   to section 2.1 of [RFC6749].  The mechanism described in this
   document may either serve as a standalone OAuth 2 client
   authentication mechanism or as an additional, supportive security
   mechanism beside an existing OAuth 2 client authentication mechanism.

   This specification introduces the concept of client attestations to
   the OAuth 2 protocol, using two artifacts:

   *  a Client Attestation, a signed statement by the Client Attester
      that authenticates the Client Instance

   *  a Proof of Possession (PoP), a signed statement by the Client
      Instance that authenticates the Client Attestation

   The following diagram depicts the overall architecture and protocol
   flow towards an Authorization Server.
























Looker, et al.          Expires 27 November 2026                [Page 4]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


                     (3)
                   +-----+
                   |     |
                   |     v
              +-----------------+
              |                 |
              | Client Attester |
              |   (backend)     |
              |                 |
              +-----------------+
                  ^       |
              (2) |       | (4)
                  |       v
              +---------------+           +---------------+
       +----->|               |    (5)    |               |
   (1) |      |    Client     |<--------->| Authorization |
       |      |   Instance    |    (7)    |    Server     |
       +------|               |<--------->|               |
              +---------------+           +---------------+
                  ^       |
                  |       |
                  +-------+
                     (6)

   The following steps describe this OAuth flow:

   (1) The Client Instance generates a key (Client Instance Key) and
   optional further attestations (that are out of scope) to prove its
   authenticity to the Client Attester.

   (2) The Client Instance sends this data to the Client Attester in
   request for a Client Attestation JWT.

   (3) The Client Attester validates the Client Instance Key and
   optional further data.  It generates a signed Client Attestation JWT
   that is cryptographically bound to the Client Instance Key generated
   by the Client.  Therefore, the attestation is bound to this
   particular Client Instance.

   (4) The Client Attester responds to the Client Instance by sending
   the Client Attestation JWT.

   (5) The Client Instance optionally requests a Challenge from the
   Authorization Server's Challenge endpoint or receives a challenge
   from a previous message.

   (6) The Client Instance generates a Proof of Possession (PoP) with
   the Client Instance Key.



Looker, et al.          Expires 27 November 2026                [Page 5]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   (7) The Client Instance sends the Client Attestation JWT along with
   its Proof of Possession to the Authorization Server, e.g. within a
   token request.  The Proof of Possession is either a Client
   Attestation PoP JWT or a DPoP proof.  The Authorization Server
   validates the Client Attestation and thus authenticates the Client
   Instance.

   The same flow applies when authenticating to a Resource Server, where
   step (7) typically occurs when accessing a protected resource.

   Please note that the protocol details for steps (2) and (4),
   particularly how the Client Instance authenticates to the Client
   Attester, are beyond the scope of this specification.  Furthermore,
   this specification is designed to be flexible and can be implemented
   even in scenarios where the client does not have a backend serving as
   a Client Attester.  In such cases, each Client Instance is
   responsible for performing the functions typically handled by the
   Client Attester on its own.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  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 Client Instance for
      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:  A deployed instance of a piece of client software.

   Client Instance Key:  A cryptographic asymmetric key pair that is
      generated by the Client Instance where the public key of the key
      pair is provided to the Client Attester.  This public key is then
      encapsulated within the Client Attestation JWT and is utilized to
      sign a proof of possession.

   Client Attester:  An entity that authenticates a Client Instance and
      attests it by issuing a Client Attestation JWT.



Looker, et al.          Expires 27 November 2026                [Page 6]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   Challenge:  A String that is the input to a cryptographic challenge-
      response pattern.  This is traditionally called a nonce within
      OAuth.

4.  Client Attestation JWT

   The Client Attestation MUST be encoded as a "JSON Web Token (JWT)"
   according to [RFC7519].

   The following content applies to the JWT Header:

   *  typ: REQUIRED.  The typ (JWT type) header MUST be oauth-client-
      attestation+jwt.

   *  alg: REQUIRED.  The alg (algorithm) header MUST specify the
      cryptographic algorithm used to sign the Client Attestation.

   The following content applies to the JWT Claims Set:

   *  sub: REQUIRED.  The sub (subject) claim MUST specify client_id
      value of the OAuth Client.

   *  exp: REQUIRED.  The exp (expiration time) claim MUST specify the
      time at which the Client Attestation is considered expired by its
      issuer.  The Authorization Server or Resource Server MUST reject
      any JWT with an expiration time that has passed, subject to
      allowable clock skew between systems.

   *  cnf: REQUIRED.  The cnf (confirmation) claim MUST specify a key
      conforming to [RFC7800] that is used by the Client Instance to
      generate the Client Attestation PoP JWT for client authentication
      with an Authorization Server or Resource Server.  The key MUST be
      expressed using the "jwk" representation.

   *  iat: OPTIONAL.  The iat (issued at) claim MUST specify the time at
      which the Client Attestation was issued.

   The following additional rules apply:

   1.  The JWT MAY contain other claims.  All claims that are not
       understood by implementations MUST be ignored.

   2.  The JWT MUST be digitally signed or integrity protected with a
       Message Authentication Code (MAC).  The Authorization Server or
       Resource Server MUST reject JWTs if signature or integrity
       protection validation fails.





Looker, et al.          Expires 27 November 2026                [Page 7]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   3.  The Authorization Server or Resource Server MUST reject a JWT
       that is not valid in all other respects per "JSON Web Token
       (JWT)" [RFC7519].

   The following example is the decoded header and payload of a JWT
   meeting the processing rules as defined above.

   {
     "typ": "oauth-client-attestation+jwt",
     "alg": "ES256",
     "kid": "11"
   }
   .
   {
     "sub": "https://client.example.com",
     "iat": 1772487595,
     "exp": 2529866394,
     "cnf": {
       "jwk": {
         "kty": "EC",
         "use": "sig",
         "crv": "P-256",
         "x": "VcKVNBZ4IaBAYW3jxM4w3TJFVA7myeUGQyGt-g_yvpQ",
         "y": "f-E-hYE3TAWKwhVv9pej9NABs9SX9XsNO80x57jFTyU"
       }
     }
   }

   When using headers to transfer the Client Attestation JWT to an
   Authorization Server or Resource Server, it MUST be provided in an
   HTTP request using the a HTTP header named OAuth-Client-Attestation.

   The following is an example of the OAuth-Client-Attestation header.

   OAuth-Client-Attestation: eyJ0eXAiOiJvYXV0aC1jbGllbnQtYXR0ZXN0YXRpb24
   rand0IiwiYWxnIjoiRVMyNTYiLCJraWQiOiIxMSJ9.eyJzdWIiOiJodHRwczovL2NsaWV
   udC5leGFtcGxlLmNvbSIsImlhdCI6MTc3MjQ4NzU5NSwiZXhwIjoyNTI5ODY2Mzk0LCJj
   bmYiOnsiandrIjp7Imt0eSI6IkVDIiwidXNlIjoic2lnIiwiY3J2IjoiUC0yNTYiLCJ4I
   joiVmNLVk5CWjRJYUJBWVczanhNNHczVEpGVkE3bXllVUdReUd0LWdfeXZwUSIsInkiOi
   JmLUUtaFlFM1RBV0t3aFZ2OXBlajlOQUJzOVNYOVhzTk84MHg1N2pGVHlVIn19fQ._TS4
   d-LAnRlwdN97wiVnl4z7C9gvm45IWr-BvGTzeZaHtZtgNZ88gvzroU3LElUPbgF4kWi_D
   FORnKzsx5yu6A

   Note that per [RFC9110] header field names are case-insensitive; so
   OAUTH-CLIENT-ATTESTATION, oauth-client-attestation, etc., are all
   valid and equivalent header field names.  Case is significant in the
   header field value, however.




Looker, et al.          Expires 27 November 2026                [Page 8]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   The OAuth-Client-Attestation HTTP header field values uses the
   token68 syntax defined in Section 11.2 of [RFC9110] (repeated below
   for ease of reference).

   OAuth-Client-Attestation       = token68
   token68                        = 1*( ALPHA / DIGIT / "-" / "." /
                                        "_" / "~" / "+" / "/" ) *"="

5.  Proof of Possession

   This specification enables two options for the proof of possession:

   *  A Client Attestation PoP JWT, introduced by this specification

   *  Utilizing DPoP as defined in [RFC9449]

5.1.  Client Attestation PoP JWT

   The Client Attestation PoP MUST be encoded as a "JSON Web Token
   (JWT)" according to [RFC7519].

   The following content applies to the JWT Header:

   *  typ: REQUIRED.  The typ (JWT type) header MUST be oauth-client-
      attestation-pop+jwt.

   *  alg: REQUIRED.  The alg (algorithm) header MUST specify the
      cryptographic algorithm used to sign the Client Attestation PoP

   The following content applies to the JWT Claims Set:

   *  aud: REQUIRED.  The aud (audience) claim MUST specify a value that
      identifies the intended audience of the JWT.  When the JWT is
      presented to an Authorization Server, the [RFC8414] issuer
      identifier URL of the Authorization Server MUST be used.  When the
      JWT is presented to a Resource Server, the [RFC9728] resource
      identifier URL of the Resource Server MUST be used.  A Client
      Attestation PoP JWT is intended for a single audience, Clients
      MUST generate JWTs for each target.

   *  jti: REQUIRED.  The jti (JWT identifier) claim MUST specify a
      unique identifier for the Client Attestation PoP.  The
      Authorization Server or Resource Server can utilize the jti value
      for replay attack detection, see Section 11.1.







Looker, et al.          Expires 27 November 2026                [Page 9]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   *  iat: REQUIRED.  The iat (issued at) claim MUST specify the time at
      which the Client Attestation PoP was issued.  Note that the
      Authorization Server or Resource Server may reject JWTs with an
      "iat" claim value that is unreasonably far in the past.

   *  challenge: OPTIONAL.  The challenge (challenge) claim MUST specify
      a String value that is provided by the Authorization Server or
      Resource Server for the client to include in the Client
      Attestation PoP JWT.

   The following additional rules apply:

   1.  The JWT MAY contain other claims.  All claims that are not
       understood by implementations MUST be ignored.

   2.  The JWT MUST be digitally signed using an asymmetric
       cryptographic algorithm.  The Authorization Server or Resource
       Server MUST reject JWTs with an invalid signature.

   3.  The public key used to verify the JWT MUST be the key located in
       the "cnf" claim of the corresponding Client Attestation JWT.

   4.  The Authorization Server or Resource Server MUST reject a JWT
       that is not valid in all other respects per "JSON Web Token
       (JWT)" [RFC7519].

   The following example is the decoded header and payload of a JWT
   meeting the processing rules as defined above.

   {
     "typ": "oauth-client-attestation-pop+jwt",
     "alg": "ES256"
   }
   .
   {
     "aud": "https://as.example.com",
     "jti": "d25d00ab-552b-46fc-ae19-98f440f25064",
     "challenge": "5c1a9e10-29ff-4c2b-ae73-57c0957c09c4"
   }

   When using headers to transfer the Client Attestation PoP JWT to an
   Authorization Server or Resource Server, it MUST be provided in an
   HTTP request using the a HTTP header named OAuth-Client-Attestation-
   PoP.

   The following is an example of the OAuth-Client-Attestation-PoP
   header.




Looker, et al.          Expires 27 November 2026               [Page 10]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   OAuth-Client-Attestation-PoP: eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hdXRoLWN
   saWVudC1hdHRlc3RhdGlvbi1wb3Arand0In0.eyJhdWQiOiJodHRwczovL2FzLmV4YW1w
   bGUuY29tIiwianRpIjoiZDI1ZDAwYWItNTUyYi00NmZjLWFlMTktOThmNDQwZjI1MDY0I
   iwibm9uY2UiOiI1YzFhOWUxMC0yOWZmLTRjMmItYWU3My01N2MwOTU3YzA5YzQifQ.U0u
   AUL60MXSf2qB3uWoo1tQanBMLa7OJ-pk_GsA_o1rfJfRkUOyWpqeSbNH90ykVad-m6x5M
   crEnFgCqdkNfUA

   Note that per [RFC9110] header field names are case-insensitive; so
   OAUTH-CLIENT-ATTESTATION-POP, oauth-client-attestation-pop, etc., are
   all valid and equivalent header field names.  Case is significant in
   the header field value, however.

   The OAuth-Client-Attestation-PoP HTTP header field values uses the
   token68 syntax defined in Section 11.2 of [RFC9110] (repeated below
   for ease of reference).

   OAuth-Client-Attestation-PoP   = token68
   token68                        = 1*( ALPHA / DIGIT / "-" / "." /
                                        "_" / "~" / "+" / "/" ) *"="

5.2.  Using DPoP as the Proof of Possession

   This section defines an optimization that allows a single Proof of
   Possession (PoP) JWT to satisfy the role of both (a) the Client
   Attestation PoP defined in this specification and (b) the DPoP proof
   defined in [RFC9449] for sender-contrained access tokens.  In this
   "combined mode" the Client Instance Key and the DPoP Key are the same
   asymmetric key pair, and a request using the mechanism carries only
   one PoP, the DPoP proof, instead of two separate PoP JWTs (the DPoP
   proof and Client Attestation PoP JWT).

   The following rules apply to the DPoP proof as defined in [RFC9449]:

   1.  The DPoP proof MUST adhere to [RFC9449]

   2.  The public key located in the DPoP proof MUST match the public
       key located in the cnf claim of the Client Attestation JWT.

   The following non-normative example shows a token request using
   combined mode (line breaks for display only):

   POST /token HTTP/1.1
   Host: as.example.com
   Content-Type: application/x-www-form-urlencoded
   OAuth-Client-Attestation: <Client-Attestation-JWT>
   DPoP: <Combined-DPoP-And-Attestation-PoP-JWT>

   grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA



Looker, et al.          Expires 27 November 2026               [Page 11]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   Decoded (non-normative) DPoP (combined) proof:

   Header: { "typ": "dpop+jwt", "alg": "ES256", "jwk": { "kty": "EC",
   "crv": "P-256", "x": "18wHLeIgW9wVN6VD1Txgpqy2LszYkMf6J8njVAibvhM",
   "y": "-V4dS4UaLMgP_4fY4j8ir7cl1TXlFdAgcx55o7TkcSA" } }

   Payload: { "htm": "POST", "htu": "https://as.example.com/token",
   "iat": 1700000000, "jti": "7c20c3e2-0f52-4f74-81a5-5c7b83a7a1f9" }

   Note that additional claims may be present in the DPoP proof
   depending on the context, as required by [RFC9449].

6.  Challenges

   This section defines optional mechanisms that allows a Client to
   receive a fresh Challenge from the Authorization Server or Resource
   Server and to include the Challenge in the proof of possession.  This
   construct may be similar or equivalent to a nonce, see Section 3.
   The value of the challenge is opaque to the client.

6.1.  Providing Challenges through the Challenge Endpoint

   The Authorization Server or Resource 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] or the Resource Server supports metadata as
   defined in [RFC9728], 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 Client
   Attestation PoP JWT or DPoP Proof as defined in Section 5.

   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:

   POST /as/challenge HTTP/1.1
   Host: as.example.com
   Accept: application/json

   The Authorization Server or Resource 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:





Looker, et al.          Expires 27 November 2026               [Page 12]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   *  attestation_challenge: REQUIRED if the Authorization Server or
      Resource Server supports Client Attestations and server-provided
      challenges as described in this document.  String containing a
      Challenge to be used in the Client Attestation PoP JWT or DPoP
      Proof as defined in Section 5.  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 or Resource Server MUST make the response
   uncacheable by adding a Cache-Control header field including the
   value no-store.  The Authorization Server or Resource 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
   Content-Type: application/json
   Cache-Control: no-store

   {
     "attestation_challenge": "AYjcyMzY3ZDhiNmJkNTZ"
   }

6.2.  Providing Challenges on Previous Responses

   The Authorization Server or Resource 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 200 OK
   Content-Type: application/json
   Cache-Control: no-store
   OAuth-Client-Attestation-Challenge: AYjcyMzY3ZDhiNmJkNTZ

   {
     "access_token": "2YotnFZFEjr1zCsicMWpAA",
     "token_type": "Bearer",
     "expires_in": 3600
   }




Looker, et al.          Expires 27 November 2026               [Page 13]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


7.  Verification and Processing

7.1.  Client Attestation JWT

   To validate a Client Attestation, the receiving server MUST ensure
   the following conditions and rules are met:

   1.  There is precisely one OAuth-Client-Attestation HTTP request
       header field containing a Client Attestation JWT.

   2.  The Client Attestation JWT contains all required claims and
       header parameters as per Section 4.

   3.  The alg JOSE Header Parameter contains a registered algorithm
       [IANA.JOSE.ALGS], is not none, is supported by the application,
       and is acceptable per local policy.

   4.  The signature of the Client Attestation JWT verifies with the
       public key of a known and trusted Client Attester.

   5.  The key contained in the cnf claim of the Client Attestation JWT
       is not a private key.

   6.  The Client Attestation JWT is fresh enough per local policy of
       the Authorization Server or Resource Server by checking the iat
       or exp claims.

   7.  If a client_id is provided in the request containing the Client
       Attestation, then this client_id matches the sub claim of the
       Client Attestation JWT.

7.2.  Client Attestation PoP JWT

   This section applies when the Client Attestation PoP JWT is used as
   the Proof of Possession.  When operating in DPoP combined mode as
   defined in Section 5.2, this section does not apply; instead, see
   Section 7.3.

   To validate a Client Attestation PoP, the receiving server MUST
   ensure the following conditions and rules are met:

   1.  There is precisely one OAuth-Client-Attestation-PoP HTTP request
       header field containing a Client Attestation PoP JWT.

   2.  The Client Attestation PoP JWT contains all required claims and
       header parameters as per Section 5.1.





Looker, et al.          Expires 27 November 2026               [Page 14]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   3.  The alg JOSE Header Parameter contains a registered algorithm
       [IANA.JOSE.ALGS], is not none, is supported by the application,
       and is acceptable per local policy.

   4.  The signature of the Client Attestation PoP JWT verifies with the
       public key contained in the cnf claim of the Client Attestation
       JWT.

   5.  If the server provided a challenge value to the client, the
       challenge claim is present in the Client Attestation PoP JWT and
       matches the server-provided challenge value.

   6.  The creation time of the Client Attestation PoP JWT as determined
       by either the iat claim or a server managed timestamp via the
       challenge claim, is within an acceptable window per local policy
       of the Authorization Server or Resource Server.

   7.  The audience claim in the Client Attestation PoP JWT identifies
       the receiving server: when validated by an Authorization Server,
       it MUST be the issuer identifier URL of the Authorization Server
       as described in [RFC8414]; when validated by a Resource Server,
       it MUST be the resource identifier URL of the Resource Server as
       described in [RFC9728].

   8.  If the Client received a challenge through the Authorization
       Server's challenge endpoint or within previous responses as
       described in Section 6, it MUST match the challenge claim of the
       Client Attestation PoP JWT.

   9.  Depending on the security requirements of the deployment,
       additional checks to guarantee replay protection for the Client
       Attestation PoP JWT might need to be applied (see Section 11.1
       for more details).

7.3.  DPoP Combined Mode

   This section applies when the DPoP combined mode is used as defined
   in Section 5.2.  When the Client Attestation PoP JWT is used as the
   Proof of Possession instead, this section does not apply; see
   Section 7.2.

   To validate a request using DPoP combined mode, the receiving server
   MUST perform the following steps:

   1.  There is no OAuth-Client-Attestation-PoP HTTP request header
       field present in the request.





Looker, et al.          Expires 27 November 2026               [Page 15]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   2.  There is precisely one DPoP HTTP request header field present in
       the request.

   3.  Validate the DPoP proof in accordance with [RFC9449].

   4.  The public key in the jwk header parameter of the DPoP proof MUST
       be identical to the public key in the cnf claim of the Client
       Attestation JWT.

   5.  If the Client received a challenge through the Authorization
       Server's challenge endpoint or within previous responses as
       described in Section 6, it MUST match the nonce payload claim of
       the DPoP proof.

7.4.  Errors

   When validation errors specifically related to the use of client
   attestations are encountered the following additional error codes are
   defined for use in either Authorization Server authenticated endpoint
   error responses (as defined in Section 5.2 of [RFC6749]) or Resource
   Server error responses (as defined in Section 3 of [RFC6750]).

   *  use_attestation_challenge MUST be used when the Client Attestation
      PoP JWT is not using an expected server-provided challenge.  When
      used this error code MUST be accompanied by the OAuth-Client-
      Attestation-Challenge HTTP header field parameter (as described in
      Section 6.2).

   *  use_fresh_attestation MUST be used when the Client Attestation JWT
      is deemed to be not fresh enough to be acceptable by the server.

   *  invalid_client_attestation MAY be used in addition to the more
      general invalid_client error code as defined in [RFC6749] if the
      attestation or its proof of possession could not be successfully
      verified.

   In the event of errors due to situations not described above,
   Authorization and Resource Servers MUST follow the guidance of
   [RFC6749] and [RFC6750] or their respective extensions of when to
   return suitable Error Responses.











Looker, et al.          Expires 27 November 2026               [Page 16]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


7.5.  Client Attestation as an OAuth Client Authentication

   A Client Attestation may be used as an OAuth 2 Client Authentication
   mechanism as described in Section 2.3 of [RFC6749] towards an
   Authorization Server.  If the token request contains a client_id
   parameter as per [RFC6749] the Authorization Server MUST verify that
   the value of this parameter is the same as the client_id value in the
   sub claim of the Client Attestation.

   The following example demonstrates usage of the client attestation
   mechanism in an access token request (with extra line breaks for
   display purposes only):

   POST /token HTTP/1.1
   Host: as.example.com
   Content-Type: application/x-www-form-urlencoded
   OAuth-Client-Attestation: eyJ0eXAiOiJvYXV0aC1jbGllbnQtYXR0ZXN0YXRpb24
   rand0IiwiYWxnIjoiRVMyNTYiLCJraWQiOiIxMSJ9.eyJzdWIiOiJodHRwczovL2NsaWV
   udC5leGFtcGxlLmNvbSIsImlhdCI6MTc3MjQ4NzU5NSwiZXhwIjoyNTI5ODY2Mzk0LCJj
   bmYiOnsiandrIjp7Imt0eSI6IkVDIiwidXNlIjoic2lnIiwiY3J2IjoiUC0yNTYiLCJ4I
   joiVmNLVk5CWjRJYUJBWVczanhNNHczVEpGVkE3bXllVUdReUd0LWdfeXZwUSIsInkiOi
   JmLUUtaFlFM1RBV0t3aFZ2OXBlajlOQUJzOVNYOVhzTk84MHg1N2pGVHlVIn19fQ._TS4
   d-LAnRlwdN97wiVnl4z7C9gvm45IWr-BvGTzeZaHtZtgNZ88gvzroU3LElUPbgF4kWi_D
   FORnKzsx5yu6A
   OAuth-Client-Attestation-PoP: eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hdXRoLWN
   saWVudC1hdHRlc3RhdGlvbi1wb3Arand0In0.eyJhdWQiOiJodHRwczovL2FzLmV4YW1w
   bGUuY29tIiwianRpIjoiZDI1ZDAwYWItNTUyYi00NmZjLWFlMTktOThmNDQwZjI1MDY0I
   iwibm9uY2UiOiI1YzFhOWUxMC0yOWZmLTRjMmItYWU3My01N2MwOTU3YzA5YzQifQ.U0u
   AUL60MXSf2qB3uWoo1tQanBMLa7OJ-pk_GsA_o1rfJfRkUOyWpqeSbNH90ykVad-m6x5M
   crEnFgCqdkNfUA

   grant_type=authorization_code&
   code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4

7.6.  Client Attestation as an additional security signal

   A Client Attestation may be used as a (additional) security signal
   towards an Authorization Server or Resource Server.  This may provide
   additional assurance about the client's authenticity, integrity,
   state or other information contained in the Client Attestation.  When
   used at the Authorization Server, the Client Attestation may appear
   along existing OAuth 2 Client Authentication mechanisms.

   The following example demonstrates usage of the client attestation
   mechanism in a PAR request as defined in [RFC9126] along side
   client_secret (with extra line breaks for display purposes only):





Looker, et al.          Expires 27 November 2026               [Page 17]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   POST /as/par HTTP/1.1
   Host: as.example.com
   Content-Type: application/x-www-form-urlencoded
   OAuth-Client-Attestation: eyJ0eXAiOiJvYXV0aC1jbGllbnQtYXR0ZXN0YXRpb24
   rand0IiwiYWxnIjoiRVMyNTYiLCJraWQiOiIxMSJ9.eyJzdWIiOiJodHRwczovL2NsaWV
   udC5leGFtcGxlLmNvbSIsImlhdCI6MTc3MjQ4NzU5NSwiZXhwIjoyNTI5ODY2Mzk0LCJj
   bmYiOnsiandrIjp7Imt0eSI6IkVDIiwidXNlIjoic2lnIiwiY3J2IjoiUC0yNTYiLCJ4I
   joiVmNLVk5CWjRJYUJBWVczanhNNHczVEpGVkE3bXllVUdReUd0LWdfeXZwUSIsInkiOi
   JmLUUtaFlFM1RBV0t3aFZ2OXBlajlOQUJzOVNYOVhzTk84MHg1N2pGVHlVIn19fQ._TS4
   d-LAnRlwdN97wiVnl4z7C9gvm45IWr-BvGTzeZaHtZtgNZ88gvzroU3LElUPbgF4kWi_D
   FORnKzsx5yu6A
   OAuth-Client-Attestation-PoP: eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hdXRoLWN
   saWVudC1hdHRlc3RhdGlvbi1wb3Arand0In0.eyJhdWQiOiJodHRwczovL2FzLmV4YW1w
   bGUuY29tIiwianRpIjoiZDI1ZDAwYWItNTUyYi00NmZjLWFlMTktOThmNDQwZjI1MDY0I
   iwibm9uY2UiOiI1YzFhOWUxMC0yOWZmLTRjMmItYWU3My01N2MwOTU3YzA5YzQifQ.U0u
   AUL60MXSf2qB3uWoo1tQanBMLa7OJ-pk_GsA_o1rfJfRkUOyWpqeSbNH90ykVad-m6x5M
   crEnFgCqdkNfUA

   response_type=code
   &state=af0ifjsldkj
   &client_id=s6BhdRkqt3
   &client_secret=7Fjfp0ZBr1KtDRbnfVdmIw
   &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
   &code_challenge=K2-ltc83acc4h0c9w6ESC_rEMTJ3bww-uCHaoeK1t8U
   &code_challenge_method=S256&scope=account-information

   The following example demonstrates usage of the client attestation
   mechanism at the Resource Server (with extra line breaks for display
   purposes only):






















Looker, et al.          Expires 27 November 2026               [Page 18]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   POST /api/users/list HTTP/1.1
   Host: rs.example.com
   Content-Type: application/x-www-form-urlencoded
   Authorization: Bearer mF_9.B5f-4.1JqM
   Accept: application/json
   OAuth-Client-Attestation: eyJ0eXAiOiJvYXV0aC1jbGllbnQtYXR0ZXN0YXRpb24
   rand0IiwiYWxnIjoiRVMyNTYiLCJraWQiOiIxMSJ9.eyJzdWIiOiJodHRwczovL2NsaWV
   udC5leGFtcGxlLmNvbSIsImlhdCI6MTc3MjQ4NzU5NSwiZXhwIjoyNTI5ODY2Mzk0LCJj
   bmYiOnsiandrIjp7Imt0eSI6IkVDIiwidXNlIjoic2lnIiwiY3J2IjoiUC0yNTYiLCJ4I
   joiVmNLVk5CWjRJYUJBWVczanhNNHczVEpGVkE3bXllVUdReUd0LWdfeXZwUSIsInkiOi
   JmLUUtaFlFM1RBV0t3aFZ2OXBlajlOQUJzOVNYOVhzTk84MHg1N2pGVHlVIn19fQ._TS4
   d-LAnRlwdN97wiVnl4z7C9gvm45IWr-BvGTzeZaHtZtgNZ88gvzroU3LElUPbgF4kWi_D
   FORnKzsx5yu6A
   OAuth-Client-Attestation-PoP: eyJhbGciOiJFUzI1NiIsInR5cCI6Im9hdXRoLWN
   saWVudC1hdHRlc3RhdGlvbi1wb3Arand0In0.eyJhdWQiOiJodHRwczovL3JzLmV4YW1w
   bGUuY29tIiwianRpIjoiZDI1ZDAwYWItNTUyYi00NmZjLWFlMTktOThmNDQwZjI1MDY0I
   iwibm9uY2UiOiI1YzFhOWUxMC0yOWZmLTRjMmItYWU3My01N2MwOTU3YzA5YzQifQ.gzk
   0WkWsjNNx92gVMSp6jVpPDUvR0toYxLMyGmJMJOfm8mG2Otg0Nfm4PefOUpwBMNQtIXSd
   dW-cqJopljQaCQ

8.  Authorization Server Metadata

   The Authorization Server SHOULD communicate support for
   authentication with Attestation-Based Client Authentication using a
   Client Attestation PoP JWT as the PoP by using the value
   attest_jwt_client_auth in the token_endpoint_auth_methods_supported
   within its published metadata.  The Authorization Server SHOULD
   communicate support for authentication with Attestation-Based Client
   Authentication using a DPoP proof as the PoP by using the value
   attest_jwt_client_auth_dpop in the
   token_endpoint_auth_methods_supported within its published metadata.
   The client SHOULD fetch and parse the Authorization Server metadata
   and recognize Attestation-Based Client Authentication as a client
   authentication mechanism if either of the given
   token_endpoint_auth_methods_supported values are present.

   The Authorization Server SHOULD communicate supported algorithms for
   client attestations by using
   client_attestation_signing_alg_values_supported and
   client_attestation_pop_signing_alg_values_supported within its
   published metadata.  This enables the client to validate that its
   client attestation is understood by the Authorization Server prior to
   authentication.  The client MAY try to get a new client attestation
   with different algorithms.  The Authorization Server MUST include
   client_attestation_signing_alg_values_supported and
   client_attestation_pop_signing_alg_values_supported in its published
   metadata if the token_endpoint_auth_methods_supported includes
   attest_jwt_client_auth.  When token_endpoint_auth_methods_supported



Looker, et al.          Expires 27 November 2026               [Page 19]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   includes attest_jwt_client_auth_dpop, the Authorization Server SHOULD
   advertise supported DPoP signing algorithms using
   dpop_signing_alg_values_supported as defined in [RFC9449], rather
   than client_attestation_pop_signing_alg_values_supported, as the
   Proof of Possession in combined mode is a DPoP proof.

9.  Implementation Considerations

9.1.  DPoP Combined Mode Considerations

   When using DPoP combined mode, the key used for client authentication
   and token binding is shared.  This may be undesirable depending on
   the deployment considerations of the Client.  Conversely, the
   benefits of this approach are as follows:

   *  It authenticates (attests) the DPoP key used for sender-
      constraining tokens against the Client deployment.

   *  It reduces implementation complexity for the Client by minimizing
      the number of JWTs that need to be constructed or validated in a
      request.

   *  It reduces run-time costs for the Client by minimizing the number
      of cryptographic operations that need to be constructed in a
      request, especially if the keys are in a remote and/or hardware-
      backed key storage.

9.2.  Reuse of a Client Attestation JWT

   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 or Resource 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.

9.3.  Refresh token binding

   Authorization servers issuing a refresh token in response to a token
   request using the client attestation mechanism as defined by this
   draft MUST bind the refresh token to the Client Instance and its
   associated public key, and NOT just the client as specified in
   section 6 [RFC6749].  To prove this binding, the Client Instance MUST
   use the client attestation mechanism when refreshing an access token.
   The client MUST also use the same key that was present in the "cnf"
   claim of the client attestation that was used when the refresh token



Looker, et al.          Expires 27 November 2026               [Page 20]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   was issued.

9.4.  Web Server Default Maximum HTTP Header Sizes

   Because the Client Attestation and Client Attestation PoP are
   communicated using HTTP headers, implementers should consider that
   web servers may have a default maximum HTTP header size configured
   which could be too low to allow conveying a Client Attestation and or
   Client Attestation PoP in an HTTP request.  It should be noted, that
   this limit is not given by the HTTP [RFC9112], but instead web server
   implementations commonly set a default maximum size for HTTP headers.
   As of 2024, typical limits for modern web servers configure maximum
   HTTP headers as 8 kB or more as a default.

9.5.  Rotation of Client Instance Key

   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.

9.6.  Replay Attack Detection

   Authorization Server or Resource Servers implementing measures to
   detect replay attacks as described in Section 11.1 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 or Resource 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 or Resource 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 or Resource 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





Looker, et al.          Expires 27 November 2026               [Page 21]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   A trie (also called prefix tree), or a patricia trie (also called
   radix tree) is a RECOMMENDED data structures to implement such a
   mechanism.

9.7.  Trust Management and Key Resolution

   The mechanisms by which the Authorization Server establishes trust in
   the Client Attester, and by which it obtains the public keys used to
   verify Client Attestation JWTs, are out of scope of this
   specification.

   Attestation-Based Client Authentication protects the integrity of
   Client Attestations using either Message Authentication Codes (MACs)
   or digital signatures.  When digital signatures are used, the
   Authorization Server needs to be able to obtain the corresponding
   public key, either through pre-configuration or through dynamic
   discovery.

   Examples of trust management approaches include:

   *  Public Key Infrastructure (PKI) and trust lists.

   *  Pre-shared or out-of-band negotiated configuration (e.g., keys,
      URLs).

   Specifications, profiles, and ecosystems built on top of Attestation-
   Based Client Authentication SHOULD adopt one of the following
   mechanisms to resolve the public key used to verify a Client
   Attestation JWT:

   *  The x5c header parameter, as defined in Section 4.1.6 of
      [RFC7515], conveys an X.509 certificate chain in the JOSE header
      of each Client Attestation.  Trust is established by validating
      the chain against a configured trust anchor.

   *  The kid header parameter combined with the jku header parameter,
      as defined in Section 4.1.2 of [RFC7515] and Section 4.1.3 of
      [RFC7515].  The Authorization Server retrieves a JWK Set from the
      URL indicated by jku and selects the key identified by kid.  This
      approach is self-contained but requires an additional HTTP
      request, and trust must be established in the jku URL.

   *  The kid header parameter combined with Client Metadata or other
      pre-shared information.  Client Metadata, as defined in [RFC7591],
      includes a jwks_uri parameter which, together with kid, enables
      resolution of the verification key.





Looker, et al.          Expires 27 November 2026               [Page 22]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


10.  Privacy Considerations

10.1.  Client Instance Tracking Across Authorization Servers or Resource
       Servers

   Implementers should be aware that using the same client attestation
   across multiple Authorization Servers or Resource Servers could
   result in correlation of the end user using the Client Instance
   through claim values (including the Client Instance Key in the cnf
   claim).  Client deployments are therefore RECOMMENDED to use
   different Client Attestation JWTs with different Client Instance Keys
   across different Authorization Servers or Resource Servers.

11.  Security Considerations

   The guidance provided by [RFC7519] and [RFC8725] applies.

11.1.  Replay Attacks

   An Authorization/Resource 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/Resource 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/Resource Server.  If any
      Client Attestation PoP JWT would be replayed, the Authorization/
      Resource 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
      Section 9.6.

   *  The Authorization/Resource 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/Resource Server
      may chose to:

      -  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
         Section 9.6.  This guarantees stronger replay protection with a
         challenge chosen by the Authorization/Resource Server itself,
         at the potential cost of an additional round-trip.



Looker, et al.          Expires 27 November 2026               [Page 23]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


      -  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/Resource Server.

   *  The Authorization/Resource 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/Resource 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/Resource Server and Client.

   Note that protocols that provide a challenge as part of a previous
   response should provide a clear indicator for clients when this
   feature is used.  This makes it easier for client implementations to
   deal with proper state handling.  This can be implicit by always
   mandating support for this feature or via some metadata that allows
   the client to detect support for this feature for a specific server.

   Because clock skews between servers and clients may be large,
   Authorization/Resource 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/Resource 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/Resource Server gives stronger replay attack detection
   guarantees, however support by the Authorization/Resource Server is
   OPTIONAL to simplify mandatory implementation requirements.  The jti
   value is mandatory and hence acts as a default fallback.










Looker, et al.          Expires 27 November 2026               [Page 24]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


11.2.  Client Attestation Protection

   This specification allows both, digital signatures using asymmetric
   cryptography, and Message Authentication Codes (MAC) to be used to
   protect Client Attestation JWTs.  Implementers should only use MACs
   to secure the integrity of Client Attestations JWTs if they fully
   understand the risks of MACs when compared to digital signatures and
   especially the requirements of their use-case scenarios.  These use-
   cases typically represent deployments where the Client Attester and
   Authorization Server have a trust relationship and the possibility to
   securely exchange keys out of band or are the same entity and no
   other entity needs to verify the Client Attestations.  We expect most
   deployments to use digital signatures for the protection of Client
   Attestations, and implementers SHOULD default to digital signatures
   if they are unsure.

12.  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:

   *  a RATS "Attester" relates to an OAuth "Client"

   *  a RATS "Relying Party" relates to an OAuth "Authorization Server
      or Resource Server"

   *  a RATS "Verifier" relates to the "Client Attester" defined in this
      specification

   *  a RATS "Attestion Result" relates to the "Client Attestation JWT"
      defined by this specification

   *  a RATS "Endorser", "Reference Value Provider", "Endorsement",
      "Evidence" and "Policies and Reference Values" are out of scope
      for this specification

13.  IANA Considerations








Looker, et al.          Expires 27 November 2026               [Page 25]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


13.1.  OAuth Parameters Registration

   This specification requests registration of the following values in
   the IANA "OAuth Authorization Server Metadata" registry
   [IANA.OAuth.Params] established by [RFC8414].

   *  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: Section 6.1 of this specification

13.2.  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: Section 7.4 of this specification



   *  Name: use_fresh_attestation

   *  Usage Location: token error response, resource access error
      response

   *  Protocol Extension: OAuth 2.0 Attestation-Based Client
      Authentication

   *  Change Controller: IETF

   *  Reference: Section 7.4 of this specification




Looker, et al.          Expires 27 November 2026               [Page 26]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   *  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: Section 7.4 of this specification

13.3.  OAuth Authorization Server Metadata Registration

   This specification requests registration of the following values in
   the IANA "OAuth Authorization Server Metadata" registry of
   [IANA.OAuth.Params] established by [RFC8414].

   *  Metadata Name: client_attestation_signing_alg_values_supported

   *  Metadata Description: JSON array containing a list of the JWS
      signing algorithms supported by the authorization server for the
      signature on the Client Attestation JWT.

   *  Change Controller: IETF

   *  Reference: Section 8 of this specification



   *  Metadata Name: client_attestation_pop_signing_alg_values_supported

   *  Metadata Description: JSON array containing a list of the JWS
      signing algorithms supported by the authorization server for the
      signature on the Client Attestation PoP JWT.

   *  Change Controller: IETF

   *  Reference: this specification

13.4.  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].





Looker, et al.          Expires 27 November 2026               [Page 27]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   *  Token Endpoint Authentication Method Name:
      "attest_jwt_client_auth"

   *  Change Controller: IESG

   *  Specification Document(s): TBC

13.5.  Registration of attest_jwt_client_auth_dpop Token Endpoint
       Authentication Method

   This section registers the value "attest_jwt_client_auth_dpop" in the
   IANA "OAuth Token Endpoint Authentication Methods" registry
   established by OAuth 2.0 Dynamic Client Registration Protocol
   [RFC7591].

   *  Token Endpoint Authentication Method Name:
      "attest_jwt_client_auth_dpop"

   *  Change Controller: IESG

   *  Specification Document(s): Section 5.2 of this specification

13.6.  HTTP Field Name Registration

   This section requests registration of the following scheme in the
   "Hypertext Transfer Protocol (HTTP) Field Name Registry"
   [IANA.HTTP.Fields] described in [RFC9110]:

   *  Field Name: OAuth-Client-Attestation

   *  Status: permanent

   *  Structured Type: Item

   *  Reference: Section 4 of this specification



   *  Field Name: OAuth-Client-Attestation-PoP

   *  Status: permanent

   *  Structured Type: Item

   *  Reference: Section 5.1 of this specification






Looker, et al.          Expires 27 November 2026               [Page 28]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   *  Field Name: OAuth-Client-Attestation-Challenge

   *  Status: permanent

   *  Structured Type: Item

   *  Reference: Section 6 of this specification

14.  References

14.1.  Normative References

   [IANA.HTTP.Fields]
              IANA, "Hypertext Transfer Protocol (HTTP) Field Name
              Registry", n.d., <https://www.iana.org/assignments/http-
              fields/http-fields.xhtml>.

   [IANA.JOSE.ALGS]
              IANA, "JSON Web Signature and Encryption Algorithms",
              n.d., <https://www.iana.org/assignments/jose/
              jose.xhtml#web-signature-encryption-algorithms>.

   [IANA.OAuth.Params]
              IANA, "OAuth Authorization Server Metadata", n.d.,
              <https://www.iana.org/assignments/oauth-parameters/oauth-
              parameters.xhtml#authorization-server-metadata>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/rfc/rfc3986>.

   [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
              Framework: Bearer Token Usage", RFC 6750,
              DOI 10.17487/RFC6750, October 2012,
              <https://www.rfc-editor.org/rfc/rfc6750>.

   [RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
              Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
              2015, <https://www.rfc-editor.org/rfc/rfc7515>.






Looker, et al.          Expires 27 November 2026               [Page 29]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
              <https://www.rfc-editor.org/rfc/rfc7519>.

   [RFC7591]  Richer, J., Ed., Jones, M., Bradley, J., Machulak, M., and
              P. Hunt, "OAuth 2.0 Dynamic Client Registration Protocol",
              RFC 7591, DOI 10.17487/RFC7591, July 2015,
              <https://www.rfc-editor.org/rfc/rfc7591>.

   [RFC7800]  Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-
              Possession Key Semantics for JSON Web Tokens (JWTs)",
              RFC 7800, DOI 10.17487/RFC7800, April 2016,
              <https://www.rfc-editor.org/rfc/rfc7800>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC8414]  Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
              Authorization Server Metadata", RFC 8414,
              DOI 10.17487/RFC8414, June 2018,
              <https://www.rfc-editor.org/rfc/rfc8414>.

   [RFC8725]  Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
              Current Practices", BCP 225, RFC 8725,
              DOI 10.17487/RFC8725, February 2020,
              <https://www.rfc-editor.org/rfc/rfc8725>.

   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/rfc/rfc9110>.

   [RFC9112]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
              June 2022, <https://www.rfc-editor.org/rfc/rfc9112>.

   [RFC9126]  Lodderstedt, T., Campbell, B., Sakimura, N., Tonge, D.,
              and F. Skokan, "OAuth 2.0 Pushed Authorization Requests",
              RFC 9126, DOI 10.17487/RFC9126, September 2021,
              <https://www.rfc-editor.org/rfc/rfc9126>.

   [RFC9449]  Fett, D., Campbell, B., Bradley, J., Lodderstedt, T.,
              Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of
              Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449,
              September 2023, <https://www.rfc-editor.org/rfc/rfc9449>.





Looker, et al.          Expires 27 November 2026               [Page 30]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   [RFC9728]  Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0
              Protected Resource Metadata", RFC 9728,
              DOI 10.17487/RFC9728, April 2025,
              <https://www.rfc-editor.org/rfc/rfc9728>.

14.2.  Informative References

   [ARF]      "The European Digital Identity Wallet Architecture and
              Reference Framework", n.d..

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/rfc/rfc6749>.

   [RFC7523]  Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
              (JWT) Profile for OAuth 2.0 Client Authentication and
              Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May
              2015, <https://www.rfc-editor.org/rfc/rfc7523>.

   [RFC9334]  Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
              W. Pan, "Remote ATtestation procedureS (RATS)
              Architecture", RFC 9334, DOI 10.17487/RFC9334, January
              2023, <https://www.rfc-editor.org/rfc/rfc9334>.

   [RFC9901]  Fett, D., Yasuda, K., and B. Campbell, "Selective
              Disclosure for JSON Web Tokens", RFC 9901,
              DOI 10.17487/RFC9901, November 2025,
              <https://www.rfc-editor.org/rfc/rfc9901>.

Appendix A.  Document History

   -09

   *  restructure draft

   *  add section how to establish trust and resolve keys

   *  rephrasing of introduction text

   *  adding challenge request/response to graphic

   *  restructure and minor fixes to challenge section

   *  add mentioning or Resource Server, where applicable

   *  clarify that alg is required for Client Attestation JWT and Client
      Attestation PoP JWT




Looker, et al.          Expires 27 November 2026               [Page 31]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   -08

   *  remove concatenated Serialization for Client Attestations

   *  update all examples (removal of iss and nbf)

   *  remove iss from Client Attestation JWT and Client Attestation PoP
      JWT

   *  add small security consideration sub-section for MAC-based
      deployments

   *  remove public clients reference and clarify this draft targets
      confidential clients

   *  clarify this may be a client authentication mechanism but also may
      be not

   *  add examples for RS usage and non client authentication

   *  Add note on protocols providing a challenge on previous responses

   *  add structured-type to iana header field registration requests

   *  moving Authorization Server metadata into it's own top level
      section

   *  editorial fixes

   -07

   *  remove restrictions to not allow MAC-based algorithms

   *  require iat in Client Attestation PoP JWT

   *  clarify use_attestation_challenge and add
      invalid_client_attestation

   *  add client_attestation_signing_alg_values_supported and
      client_attestation_pop_signing_alg_values_supported to IANA
      registration

   *  add implementation consideration for Authorization Server Metadata

   *  clarify refresh token binding

   *  check client_id at PAR endpoint




Looker, et al.          Expires 27 November 2026               [Page 32]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   *  added use_fresh_attestation as an error to signal that the
      attestation was not deemed fresh enough by the server

   *  mandate the defined header fields if the attestation and pop are
      transferred via header fields

   -06

   *  clarify client_id processing in token request with client
      attestation

   *  clarify usage of client attestation outside of oauth2 applications

   *  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

   *  remove exp from Client Attestation PoP JWT

   *  add verification and processing rules

   -05

   *  add nonce endpoint

   *  add metadata entry for nonce

   *  improve introduction

   *  rename client backend to client attester

   *  fix missing typ header in examples

   -04

   *  remove key attestation example

   *  restructured JWT Claims for better readability





Looker, et al.          Expires 27 November 2026               [Page 33]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   *  added JOSE typ values for Client Attestation and Client
      Attestation PoP

   *  add RATS relation

   *  add concatenated representation without headers

   *  add PAR endpoint example

   *  fix PoP examples to include jti and nonce

   *  add iana http field name registration

   -03

   *  remove usage of RFC7521 and the usage of client_assertion

   *  add new header-based syntax introducing Oauth-Client-Attestation
      and OAuth-Client-Attestation-PoP

   *  add Client Instance to the terminology and improve text around
      this concept

   -02

   *  add text on the inability to rotate the Client Instance Key

   -01

   *  Updated eIDAS example in appendix

   *  Removed text around jti claim in client attestation, refined text
      for its usage in the client attestation pop

   *  Refined text around cnf claim in client attestation

   *  Clarified how to bind refresh tokens to a Client Instance using
      this client authentication method

   *  Made it more explicit that the client authentication mechanism is
      general purpose making it compatible with extensions like PAR

   *  Updated acknowledgments

   *  Simplified the diagram in the introduction

   *  Updated references




Looker, et al.          Expires 27 November 2026               [Page 34]

Internet-Draft  OAuth 2.0 Attestation-Based Client Authe        May 2026


   *  Added some guidance around replay attack detection

   -00

   *  Initial draft

Acknowledgments

   We would like to thank Babis Routis, Brian Campbell, Dimitris Zarras,
   Filip Skokan, Francesco Marino, Frederik Krogsdal Jacobsen, Guiseppe
   De Marco, Joseph Heenan, Kristina Yasuda, Micha Kraus, Michael B.
   Jones, Takahiko Kawasaki, Timo Glastra and Torsten Lodderstedt for
   their valuable contributions to this specification.

Authors' Addresses

   Tobias Looker
   MATTR
   Email: tobias.looker@mattr.global


   Paul Bastian
   Bundesdruckerei
   Email: paul.bastian@posteo.de


   Christian Bormann
   SPRIND
   Email: chris.bormann@gmx.de






















Looker, et al.          Expires 27 November 2026               [Page 35]
