I suspect a general recommendation for dealing with DPoP in token exchange
("T-eX"!) scenarios is unattainable due to the wide variance in how T-eX
gets used. It's not exhaustive but this comment on an issue about sender
constraining in the chaining repo
<https://github.com/oauth-wg/oauth-identity-chaining/issues/168#issuecomment-3146485550>
points to the difficulties that some of us have had in even just talking
about the concepts. I share that not necessarily with the expectation that
people look through it all but similarly that there'll be something about
it in the list archives for me to be able to reference it when I need it :)On Wed, Oct 22, 2025 at 5:18 AM Vladimir Dzhuvinov | Connect2id < [email protected]> wrote: > Thanks everyone for responding here. > > I reread the entire RFC 9449 to make sure we have nothing that was written > down to forestall the use of a DPoP RS structured proof (+ath claim) at the > token endpoint. So, it looks like that's okay. > > So far in our PoC we realised three things: 1) the client minting a single > DPoP proof for the entire token exchange request makes good sense in terms > of efficiency - nice! ; 2) when the client rotates its DPoP key it has an > extended context of tokens to consider, but that's okay; 2) in our > particular server implementation we had to make sure the DPoP proof is only > once checked for single use - that's because it was once "seen" as the > proof that comes with the subject token, plus a second time to bind the > newly minted token. If the server is exercising the nonce option there > might be similar considerations. > > To repeat, I was aiming for a general, perhaps let's say universal, > recommendation how to deal with DPoP in token exchange scenarios. I was not > thinking of a specific OAuth / OIDC profile. Even if the WG never publishes > a proper document for DPoP in "T-eX" , it's nice to have an informal > agreement here, for me to be able to reference it when I have to :) > > Vladimir Dzhuvinov > > On 22/10/2025 01:31, Brian Campbell wrote: > > I think that when Filip wrote "TX-issued token" in his message below, he > meant it as shorthand for "Token eXchange-issued token" meaning the thing > returned from the token exchange call in general. Rather than the similar > looking "Txn-Token" which is the shortened version of Transaction Token in > https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/ > > Key bound Transaction Tokens don't make a lot of sense, for the reasons > you've hinted at and more. > > But a single DPoP key being used through an ID Assertion Authorization > Grant > <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-identity-assertion-authz-grant> > flow, > as Karl described, does make some sense to me and I think the single > existing proof works fine for that case. > > > > > On Mon, Oct 13, 2025 at 10:40 AM Lombardo, Jeff <jeffsec= > [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] >> > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* > > -- _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you._
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
