DPoP Optimisation #146
DPoP Optimisation #146
Conversation
| 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. |
There was a problem hiding this comment.
Note im definitely not convinced of the changes here, it implies the combined mode isn't really optional
| 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. |
There was a problem hiding this comment.
Should we be more specific around how this matching should occur, e.g if both JWK use thumbprint etc?
|
|
||
| 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_dpop_combined_mode_supported |
There was a problem hiding this comment.
The alternative model here is to define a new method of client authentication so that the AS can effectively require the method for a specific client.
There was a problem hiding this comment.
We could also define a new token_endpoint_auth_method beside the existing one and solve it without introducing a new flag
| @@ -325,6 +325,8 @@ To validate an HTTP request which contains the client attestation headers, the r | |||
| 2. There is precisely one OAuth-Client-Attestation-PoP HTTP request header field, where its value is a single well-formed JWT conforming to the syntax outlined in [](#client-attestation-pop-jwt). | |||
| 3. The signature of the Client Attestation PoP JWT obtained from the OAuth-Client-Attestation-PoP HTTP header verifies with the Client Instance Key contained in the `cnf` claim of the Client Attestation JWT obtained from the OAuth-Client-Attestation HTTP header. | |||
|
|
|||
| 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. | |||
There was a problem hiding this comment.
It feels a little odd to spread requirements and verification rules across multiple chapters/sections.
|
|
||
| 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_dpop_combined_mode_supported |
There was a problem hiding this comment.
We could also define a new token_endpoint_auth_method beside the existing one and solve it without introducing a new flag
|
|
||
| This section defines an OPTIONAL 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 |
There was a problem hiding this comment.
I would favor merging this with the other HTTP request section, so it's easier to compare both modes
|
|
||
| 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. Beyond what is defined in {{RFC9449}} the following additional claims in the DPoP proof apply. |
There was a problem hiding this comment.
I wonder if the iss value in the PoP really serves an important function, or whether to remove it, to avoid this additional claim for DPoP Proof
|
we're also missing the considerations for challenge/DPoP nonce |
Initial draft at this proposal, things to discuss include
Fixes #69