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.
S pozdravem, *Filip Skokan* 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]
