Theoretically there could be multiple keys in the client registered jwks_uri with different private keys being used for SSO and ID-JAG token exchange in my use case. There isn’t enough real world deployments yet to see if single key constraint holds true.
Sent via thumbs on glass I think we should ask whether there's a need for the TX-issued token to use a different DPoP Private Key than the tokens being exchanged? That's as far as I can tell the only scenario when the existing single header wouldn't cut it.
On Mon, 13 Oct 2025 at 09:40, Vladimir Dzhuvinov | Connect2id < [email protected]> wrote:
The new document clarifying the use of DPoP with device grants is
giving me hope that we'll agree on a similar DPoP spec for the
token exchange. Have there been thoughts on this in the WG?
The token exchange specs a subject_token and an optional
actor_token. If any of these are DPoP bound, say the subject_token
is a DPoP access token, the client has to include the DPoP + ath
proof in the request. The DPoP header in token requests (according
to RFC 9449) is reserved to enable a DPoP binding for the issued
token. This means a DPoP header will not work for the subject
/
actor_token. My preference has been to use a dedicated
form parameter - subject_token_dpop and actor_token_dpop for
this purpose.
Thoughts / comments on this?
https://datatracker.ietf.org/doc/html/draft-parecki-oauth-dpop-device-flow
--
Vladimir Dzhuvinov
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
|
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
