DPoP Optimisation #146

tplooker · 2025-09-05T04:36:11Z

Initial draft at this proposal, things to discuss include

Whether we should consider instead of a _supported metadata flag defining another method for client authentication because otherwise an AS cannot force the optimisation in the event it would like to.
Unrelated but I noticed nbf is defined for the Client Attestation PoP when I dont think its required, suggest we remove this.
How should we handle challenge vs nonce in the DPoP proof, technically we could support both.

Fixes #69

tplooker · 2025-09-05T04:37:17Z

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

+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.


Note im definitely not convinced of the changes here, it implies the combined mode isn't really optional

tplooker · 2025-09-09T06:15:17Z

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

+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.


Should we be more specific around how this matching should occur, e.g if both JWK use thumbprint etc?

tplooker · 2025-09-09T06:26:44Z

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

+
+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


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.

We could also define a new token_endpoint_auth_method beside the existing one and solve it without introducing a new flag

applying same arguments as for fully-specified algorithms

paulbastian · 2025-09-12T20:45:01Z

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

 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.


It feels a little odd to spread requirements and verification rules across multiple chapters/sections.

paulbastian · 2025-09-12T20:58:27Z

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

+
+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


We could also define a new token_endpoint_auth_method beside the existing one and solve it without introducing a new flag

paulbastian · 2025-09-12T21:25:08Z

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

+
+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


I would favor merging this with the other HTTP request section, so it's easier to compare both modes

paulbastian · 2025-09-12T21:28:01Z

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

+
+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.


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

clarify: remove iss entirely for the PoP, even in "normal" mode

paulbastian · 2025-09-12T21:30:37Z

we're also missing the considerations for challenge/DPoP nonce

panva · 2025-09-30T06:55:57Z

This should either

be required by AS to support when it supports both dpop and attest; or
be required when dpop and attestation is used together; or
not exist.

Anything towards the end of not having any AS support optionality.

I am supportive of this in theory but if its not MTI for the AS I would not bother implementing the client side for it.

paulbastian · 2025-10-10T07:13:26Z

This should either
* be required by AS to support when it supports both dpop and attest; or

* be required when dpop and attestation is used together; or

* not exist.
Anything towards the end of not having any AS support optionality.

I am supportive of this in theory but if its not MTI for the AS I would not bother implementing the client side for it.

favorite direction would be to create two distinct token_endpoint_auth_methods, which could be independtly signaled using token_endpoint_auth_methods_supported, therefore leaving the AS the clear option to support either or both. What do you think about this option? @panva

panva · 2025-10-10T07:58:48Z

@paulbastian yes that's acceptable (I think?).

Add intial draft

8c4349c

tplooker requested review from c2bo and paulbastian as code owners September 5, 2025 04:36

tplooker commented Sep 5, 2025

View reviewed changes

tplooker commented Sep 9, 2025

View reviewed changes

paulbastian requested changes Sep 12, 2025

View reviewed changes

remove iss from pop

f4fb47b

tplooker mentioned this pull request Oct 24, 2025

PoP attestation binding #47

Open


		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


		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

DPoP Optimisation #146

Are you sure you want to change the base?

DPoP Optimisation #146

Uh oh!

Conversation

tplooker commented Sep 5, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

paulbastian Sep 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

paulbastian commented Sep 12, 2025

Uh oh!

panva commented Sep 30, 2025

Uh oh!

paulbastian commented Oct 10, 2025

Uh oh!

panva commented Oct 10, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

paulbastian Sep 30, 2025 •

edited

Loading