feat: initial proposal to use http headers

draft-ietf-oauth-attestation-based-client-auth.md

@@ -24,28 +24,26 @@ author:
 normative:
   RFC3986: RFC3986
   RFC7800: RFC7800
-  RFC6755: RFC6755
   RFC7591: RFC7591
   RFC7519: RFC7519
   RFC8414: RFC8414
   RFC8725: RFC8725
+  RFC9110: RFC9110
+  RFC9112: RFC9112
 informative:
   RFC6749: RFC6749
-  RFC7521: RFC7521
   ARF:
   	title: "The European Digital Identity Wallet Architecture and Reference Framework"
 
 
 --- abstract
 
-This specification defines a new method of client authentication for OAuth 2.0 {{RFC6749}} by extending the approach defined in {{RFC7521}}. This new method enables client deployments that are traditionally viewed as public clients to be able to authenticate with the authorization server through an attestation based authentication scheme.
+This specification defines an extension to the OAuth 2 protocol as defined in {{RFC6749}} which enables a Client Instance to include an attestation in interactions with an Authorization Server or a Resource Server. This new method enables Client Instances involved in a client deployment that is traditionally viewed as a public client, to be able to provide an attestation in order to authenticate.
 
 --- middle
 
 # Introduction
 
-{{RFC7521}} defines a way for a client to include an assertion in a token request to an authorization server for the purposes of client authentication. This specification uses this framework to define a new assertion type that provides a way for a client instance to authenticate itself with the authorization server through an assertion that is bound to a public key (for proof of possession). This assertion is designated with the name of Client Attestation in this draft.
-
 The following diagram depicts the overall architecture and protocol flow.
 
 ~~~ ascii-art
@@ -89,12 +87,9 @@ The following steps describe this OAuth flow:
 
 (6) The Client Instance sends both the Client Attestation JWT and the Client Attestation PoP JWT to the authorization server, e.g. within a token request. The authorization server validates the Client Attestation and thus authenticates the Client Instance.
 
-Note that the protocol for steps (2) and (4) and how the Client Instance authenticates to the Client Backend is out of scope of this specification.  Note also that this specification can be utilized without the client having a backend server at all; in this case, each client instance will perform the functions described as being done by the backend for itself.
-
-This specification defines the format of the Client Attestation that a Client Instance uses to authenticate in its interactions with an authorization server, which is comprised of two key parts:
+Please note that the protocol details for steps (2) and (4), particularly how the Client Instance authenticates to the client Backend, 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 server. In such cases, each Client Instance is responsible for performing the functions typically handled by the backend on its own.
 
-1. A Client Attestation JWT - typically produced by the client backend.
-2. A Client Attestation Proof of Possession (PoP) - produced by the client instance.
+This approach acknowledges the evolving landscape of OAuth 2.0 deployments, where the ability for public clients to authenticate securely and reliably has become increasingly important.
 
 # Conventions and Definitions
 
@@ -103,49 +98,69 @@ This specification defines the format of the Client Attestation that a Client In
 # Terminology
 
 Client Attestation JWT:
-:  A JSON Web Token (JWT) generated by the client backend which is bound to a key managed by a client instance which can then be used by the instance for client authentication.
+:  A JSON Web Token (JWT) generated by the client backend which is bound to a key managed by a Client Instance which can then be used by the instance for client authentication.
 
 Client Attestation Proof of Possession (PoP) JWT:
-:  A Proof of Possession generated by the client instance using the key that the Client Attestation JWT is bound to.
+:  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 generated by the client instance and proven to the client backend. The public key is contained in the Client Attestation JWT and is used to sign the Client Attestation Proof of Possession.
+:  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 backend. This public key is then encapsulated within the Client Attestation JWT and is utilized to sign the Client Attestation Proof of Possession.
+
+# Client Attestation
+
+This draft introduces the concept of client attestations to the OAuth 2 protocol, using two JWTs: a Client Attestation and a Client Attestation Proof of Possession (PoP). These JWTs are transmitted via HTTP headers in an HTTP request from a Client Instance to an Authorization Server or Resource Server. The primary purpose of these headers is to authenticate the Client Instance.
 
-# Client Authentication
+## Client Attestation HTTP Headers
 
-To perform client authentication using this scheme, the client instance uses the following parameter values and encodings.
+A Client Attestation JWT and Client Attestation PoP JWT is included in an HTTP request using the following request header fields.
 
-The value of the "client_assertion_type" parameter (as defined in {{RFC7521}}) set to "urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation".
+OAuth-Client-Attestation:
+: A JWT that conforms to the structure and syntax as defined in [](#client-attestation-jwt)
 
-The value of the "client_assertion" parameter (as defined in {{RFC7521}}) set to a value containing two JWTs, separated by a '~' character. It MUST NOT contain more or less than precisely two JWTs separated by the '~' character. The first JWT MUST be the client attestation JWT defined in [](#client-attestation-jwt), the second JWT MUST be the client attestation PoP defined in [](#client-attestation-pop-jwt).
+OAuth-Client-Attestation-PoP:
+: A JWT that adheres to the structure and syntax as defined in [](#client-attestation-pop-jwt)
 
-The following example demonstrates client authentication using this scheme during the presentation of an authorization code grant in an access token request (with extra line breaks for display purposes only):
+The following is an example of the OAuth-Client-Attestation header.
 
 ~~~
-POST /token HTTP/1.1
-Host: as.example.com
-Content-Type: application/x-www-form-urlencoded
+OAuth-Client-Attestation: eyJhbGciOiAiRVMyNTYiLCJraWQiOiAiMTEifQ.eyJ\
+pc3MiOiJodHRwczovL2NsaWVudC5leGFtcGxlLmNvbSIsInN1YiI6Imh0dHBzOi8vY2x\
+pZW50LmV4YW1wbGUuY29tIiwibmJmIjoxMzAwODE1NzgwLCJleHAiOjEzMDA4MTkzODA\
+sImNuZiI6eyJqd2siOnsia3R5IjoiRUMiLCJ1c2UiOiJzaWciLCJjcnYiOiJQLTI1NiI\
+sIngiOiIxOHdITGVJZ1c5d1ZONlZEMVR4Z3BxeTJMc3pZa01mNko4bmpWQWlidmhNIiw\
+ieSI6Ii1WNGRTNFVhTE1nUF80Zlk0ajhpcjdjbDFUWGxGZEFnY3g1NW83VGtjU0EifX1\
+9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
+~~~
 
-grant_type=authorization_code&
-code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4&
-client_assertion_type=urn%3Aietf%3Aparams%3Aoauth%3A
-client-assertion-type%3Ajwt-client-attestation&
-client_assertion=eyJhbGciOiJSUzI1NiIsImtpZCI6IjIyIn0.
-eyJpc3Mi[...omitted for brevity...].
-cC4hiUPo[...omitted for brevity...]~eyJzI1NiIsImtphbGciOimtpZCI6IjIyIn0.
-IjIyIn0[...omitted for brevity...].
-iOiJSUzI1[...omitted for brevity...]
+The following is an example of the OAuth-Client-Attestation-PoP header.
+
+~~~
+OAuth-Client-Attestation-PoP: eyJhbGciOiJFUzI1NiJ9.eyJpc3MiOiJodHRwc\
+zovL2NsaWVudC5leGFtcGxlLmNvbSIsImF1ZCI6Imh0dHBzOi8vYXMuZXhhbXBsZS5jb\
+20iLCJuYmYiOjEzMDA4MTU3ODAsImV4cCI6MTMwMDgxOTM4MH0.coB_mtdXwvi9RxSMz\
+bIey8GVVQLv9qQrBUqmc1qj9Bs
 ~~~
 
-## JWT Format and Processing Requirements {#jwt-format-and-processing-requirements}
+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.
+
+The OAuth-Client-Attestation and 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).
 
-In order to authenticate the client using this scheme, the authorization server MUST validate BOTH the JWTs present in the "client_assertion" parameter according to the criteria below.
+~~~
+OAuth-Client-Attestation       = token68
+OAuth-Client-Attestation-PoP   = token68
+token68                        = 1*( ALPHA / DIGIT / "-" / "." /
+                                     "_" / "~" / "+" / "/" ) *"="
+~~~
 
 It is RECOMMENDED that the authorization server validate the Client Attestation JWT prior to validating the Client Attestation PoP.
 
-### Client Attestation JWT {#client-attestation-jwt}
+## Client Attestation JWT {#client-attestation-jwt}
 
-The following rules apply to validating the client attestation JWT. Application of additional restrictions and policy are at the discretion of the authorization server.
+The following rules apply to validating the Client Attestation JWT. Application of additional restrictions and policy are at the discretion of the Authorization Server.
 
 1. The JWT MUST contain an "iss" (issuer) claim that contains a unique identifier for the entity that issued the JWT. In the absence of an application profile specifying otherwise, compliant applications MUST compare issuer values using the Simple String Comparison method defined in Section 6.2.1 of {{RFC3986}}.
 
@@ -190,9 +205,9 @@ The following example is the decoded header and payload of a JWT meeting the pro
 }
 ~~~
 
-### Client Attestation PoP JWT {#client-attestation-pop-jwt}
+## Client Attestation PoP JWT {#client-attestation-pop-jwt}
 
-The following rules apply to validating the Client Attestation JWT. Application of additional restrictions and policy are at the discretion of the Authorization Server.
+The following rules apply to validating the Client Attestation PoP JWT. Application of additional restrictions and policy are at the discretion of the Authorization Server.
 
 1. The JWT MUST contain an "iss" (issuer) claim with a value corresponding to the "client_id" of the OAuth client.
 
@@ -212,9 +227,9 @@ The following rules apply to validating the Client Attestation JWT. Application
 
 9. The JWT MUST be digitally signed using an asymmetric cryptographic algorithm. The authorization server MUST reject the JWT if it is using a Message Authentication Code (MAC) based algorithm. The authorization server MUST reject JWTs with an invalid signature.
 
-10. The public key used to verify the JWT MUST be the key located in the "cnf" claim of the corresponding client attestation JWT.
+10. The public key used to verify the JWT MUST be the key located in the "cnf" claim of the corresponding Client Attestation JWT.
 
-11. The authorization server MUST reject a JWT that is not valid in all other respects per "JSON Web Token (JWT)" {{RFC7519}}.
+11. The Authorization 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.
 
@@ -232,16 +247,55 @@ The following example is the decoded header and payload of a JWT meeting the pro
 }
 ~~~
 
+## Checking HTTP requests feature client attestations {#checking-http-requests-with-client-attestations}
+
+To validate an HTTP request which contains the client attestation headers, the receiving server MUST ensure the following with regard to a received HTTP request:
+
+1. There is precisely one OAuth-Client-Attestation HTTP request header field, where its value is a single well-formed JWT conforming to the syntax outlined in []{client-attestation-jwt}.
+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 public key contained in the `cnf` claim of the Client Attestation JWT obtained from the OAuth-Client-Attestation HTTP header.
+
+# Client Attestation Access Token Request
+
+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 with token endpoint as defined by {{RFC6749}} has particular additional considerations outlined below.
+
+The Authorization Server MUST perform all of the checks outlined in [](#checking-http-requests-with-client-attestations) for a received access token request which is making use of the client attestation mechanism as defined by this draft.
+
+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: eyJhbGciOiAiRVMyNTYiLCJraWQiOiAiMTEifQ.eyJ\
+pc3MiOiJodHRwczovL2NsaWVudC5leGFtcGxlLmNvbSIsInN1YiI6Imh0dHBzOi8vY2x\
+pZW50LmV4YW1wbGUuY29tIiwibmJmIjoxMzAwODE1NzgwLCJleHAiOjEzMDA4MTkzODA\
+sImNuZiI6eyJqd2siOnsia3R5IjoiRUMiLCJ1c2UiOiJzaWciLCJjcnYiOiJQLTI1NiI\
+sIngiOiIxOHdITGVJZ1c5d1ZONlZEMVR4Z3BxeTJMc3pZa01mNko4bmpWQWlidmhNIiw\
+ieSI6Ii1WNGRTNFVhTE1nUF80Zlk0ajhpcjdjbDFUWGxGZEFnY3g1NW83VGtjU0EifX1\
+9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
+OAuth-Client-Attestation-PoP: eyJhbGciOiJFUzI1NiJ9.eyJpc3MiOiJodHRwc\
+zovL2NsaWVudC5leGFtcGxlLmNvbSIsImF1ZCI6Imh0dHBzOi8vYXMuZXhhbXBsZS5jb\
+20iLCJuYmYiOjEzMDA4MTU3ODAsImV4cCI6MTMwMDgxOTM4MH0.coB_mtdXwvi9RxSMz\
+bIey8GVVQLv9qQrBUqmc1qj9Bs
+
+grant_type=authorization_code&
+code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4
+~~~
+
 # Implementation Considerations
 
 ## 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, 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.
+Implementers should be aware that the design of this authentication mechanism deliberately allows for a Client Instance to re-use a single Client Attestation JWT in multiple interactions/requests with an Authorization Server, whilst producing a fresh Client Attestation PoP JWT. Client deployments should consider this when determining the validity period for issued Client Attestation JWTs as this ultimately controls how long a Client Instance can re-use a single Client Attestation JWT.
 
 ## Refresh token binding
 
-Authorization servers issuing a refresh token in response to a token request using the "urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation" client authentication method MUST bind the refresh token to the client instance, and NOT just the client as specified in section 6 {{RFC6749}}. To prove this binding, the client instance MUST authenticate itself to the authorization server when refreshing an access token using the "urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation" authentication method. The client MUST also use the same key that was present in the "cnf" claim of the client attestation that was used for client authentication when the refresh token was issued.
+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 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 was issued.
+
+### 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.
 ## 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 Backend.
@@ -250,7 +304,7 @@ This specification does not provide a mechanism to rotate the Client Instance Ke
 
 ## Client Instance Tracking Across Authorization Servers
 
-Implementers should be aware that using the same client attestation across multiple authorization servers could result in correlation of the end user using the client instance through claim values (including the public key in the `cnf` claim). Client deployments are therefore RECOMMENDED to use different client attestations across different authorization servers.
+Implementers should be aware that using the same client attestation across multiple authorization servers could result in correlation of the end user using the Client Instance through claim values (including the public key in the `cnf` claim). Client deployments are therefore RECOMMENDED to use different client attestations across different authorization servers.
 
 # Security Considerations
 
@@ -268,15 +322,6 @@ The approach using a nonce explicitly provided by the authorization server gives
 
 # Appendix A IANA Considerations
 
-## Sub-Namespace Registration of urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation
-
-This section registers the value "client-assertion-type:jwt-client-attestation" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" {{RFC6755}}.
-
-* URN: urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation
-* Common Name: OAuth 2.0 Attested Key-Based Client Authentication
-* Change Controller: IESG
-* Specification Document: TBC
-
 ## 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}}.
@@ -327,7 +372,7 @@ This non-normative example shows a client attestations used as an wallet instanc
 * 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
+* 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