DPoP Optimisation

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

@@ -325,6 +325,10 @@ To validate an HTTP request which contains the client attestation headers, the r
 2. There is precisely one OAuth-Client-Attestation-PoP HTTP request header field, where its value is a single well-formed JWT conforming to the syntax outlined in [](#client-attestation-pop-jwt).
 3. The signature of the Client Attestation PoP JWT obtained from the OAuth-Client-Attestation-PoP HTTP header verifies with the Client Instance Key contained in the `cnf` claim of the Client Attestation JWT obtained from the OAuth-Client-Attestation HTTP header.
 
+If the Authorization Server supports DPoP as per {{RFC9449}}, a client MAY instead use the combined client attestation and DPoP mode described in [](#combined-dpop).
+
+Alternatively if client attestations are being used in conjunction with DPoP in the combined mode as specified in [](#combined-dpop) the processing rules as specified in that section apply. 
+
 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 [](#challenge-header)).
@@ -338,6 +342,8 @@ While usage of the the client attestation mechanism defined by this draft can be
 
 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.
 
+If the Authorization Server supports DPoP as per {{RFC9449}} as well as Client Attestation via the mechanism specified in this draft for Client Authentication purposes, the Authorization Server MUST also support the combined mode described in [](#combined-dpop).
+
 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 and `iss` claim of the Client Attestation PoP.
 
 The following example demonstrates usage of the client attestation mechanism in an access token request (with extra line breaks for display purposes only):
@@ -370,6 +376,8 @@ code=n0esc3NRze7LTCu7iYzS6a5acc3f0ogp4
 
 A Client Attestation can be used at the PAR endpoint instead of alternative client authentication mechanisms like JWT client assertion-based authentication (as defined in Section 2.2 of [RFC7523]).
 
+If the Authorization Server supports DPoP as per {{RFC9449}} as well as Client Attestation via the mechanism specified in this draft for Client Authentication purposes, the Authorization Server MUST also support the combined mode described in [](#combined-dpop).
+
 The Authorization Server MUST perform all of the checks outlined in [](#checking-http-requests-with-client-attestations) for a received PAR 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 a PAR request (with extra line breaks for display purposes only):
@@ -400,6 +408,63 @@ response_type=code&state=af0ifjsldkj&client_id=s6BhdRkqt3
 &code_challenge_method=S256&scope=account-information
 ~~~
 
+## Usage of Client Instance Key as DPoP Key {#combined-dpop}
+
+This section defines an optimization that allows a single Proof of Possession (PoP) JWT to satisfy both (a) the Client Attestation PoP defined in this specification and (b) the DPoP proof defined in {{RFC9449}}. 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).
+
+### Validating HTTP requests
+
+In order to detect whether this combined mode is being used, the following conditions MUST be met:
+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 DPoP HTTP request header field, its value is conforming to the syntax outlined in {{RFC9449}}.
+3. There is no OAuth-Client-Attestation-PoP HTTP request header field present.
+
+Provided the above conditions are meet the following additional rules apply:
+1. The public key located in the DPoP proof MUST match the public key located in the `cnf` claim of the Client Attestation JWT.
+2. As per {{RFC9449}} the DPoP proof `typ` header value MUST be `dpop+jwt`.
+
+// TODO error handling
+
+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
+~~~
+
+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"
+}
+
+Client implementations should be aware of the trade offs of using this mechanism, namely the benefits are as follows:
+* It authenticates (attests) the DPoP key used for sender-constraining tokens against the Client deployment.
+* It can reduce implementation complexity for the Client by reducing the number of JWTs that need to be constructed and or validated in a request.
+
+Conversely using this mechanism means the key used for client authentication and token binding is shared, which maybe undesirable depending on the various deployment considerations the Client may have.
+
 # Concatenated Serialization for Client Attestations {#alternative-representation}
 
 A Client Attestation according to this specification MAY be presented using an alternative representation for cases where the header-based mechanism (as introduced in introduced in [](#headers) does not fit the underlying protocols, e.g., for direct calls to Browser APIs.
@@ -502,10 +567,10 @@ OAuth-Client-Attestation-Challenge: AYjcyMzY3ZDhiNmJkNTZ
 
 Upon receiving a Client Attestation, the receiving server MUST ensure the following conditions and rules:
 
-1. If the Client Attestation was received via Header based Syntax (as described in [](#header-based)):
+1. If the Client Attestation was received via Header based Syntax (as described in [](#header-based)) the HTTP request MUST conform to exactly one of the following:
 
-    * The HTTP request contains exactly one field `OAuth-Client-Attestation` and one field `OAuth-Client-Attestation-PoP`.
-    * Both fields contain exactly one well-formed JWT.
+  * Separate proofs pattern: exactly one field `OAuth-Client-Attestation` and exactly one field `OAuth-Client-Attestation-PoP`, each containing exactly one well-formed JWT; OR
+  * Combined DPoP pattern: exactly one field `OAuth-Client-Attestation` and exactly one field `DPoP` meeting the requirements of [](#combined-dpop), and no `OAuth-Client-Attestation-PoP` field present.
 
 2. The Client Attestation JWT contains all claims and header parameters as per [](#client-attestation-jwt).
 3. The Client Attestation PoP JWT contains all claims and header parameters as per [](#client-attestation-pop-jwt).