Legitimate needs for Token Exchange are few and far between to begin with, most uses of TX are proprietary (not interoperable) profiles tailed for and by specific solutions. In the case of Identity Assertion Authorization Grant mentioned on this thread, the way the grant is drafted, there's no need for multiple proofs because the party that obtained the ID-JAG and the one exchanging it for RS ATs is one and the same, I think at least?
I merely wanted to point out that not every profile of TX requires more standardization wrt DPoP. It probably won't hurt, but might, at least in the scenarios where a single existing proof works because the party that's doing a token's exchange is the same one that obtained said token. S pozdravem, *Filip Skokan* On Mon, 13 Oct 2025 at 18:40, Lombardo, Jeff <[email protected]> wrote: > Are you pointing at TX-Tokens cause then multiple parties of the > transaction could generate a DPoP header when they are using the TX-Token? > > > > This would establish the requirement that all the parties of the > transaction then share the key material. It can see being the case like not > , which now triggers a new question: would a multi-party DPoP bound > TX-token would have a sense? > > > > *Jean-François “Jeff” Lombardo* | Amazon Web Services > > > > Architecte Principal de Solutions, Spécialiste de Sécurité > Principal Solution Architect, Security Specialist > Montréal, Canada > > *Commentaires à propos de notre échange? **Exprimez-vous **ici* > <https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$> > *.* > > > > *Thoughts on our interaction? Provide feedback **here* > <https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$> > *.* > > > > *From:* Filip Skokan <[email protected]> > *Sent:* October 13, 2025 9:24 AM > *To:* Vladimir Dzhuvinov | Connect2id <[email protected]> > *Cc:* OAuth WG <[email protected]> > *Subject:* [EXT] [OAUTH-WG] Re: DPoP for the OAuth token exchange grant? > > > > *CAUTION*: This email originated from outside of the organization. Do not > click links or open attachments unless you can confirm the sender and know > the content is safe. > > > > *AVERTISSEMENT*: Ce courrier électronique provient d’un expéditeur > externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous > ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas > certain que le contenu ne présente aucun risque. > > > > 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]
