Thank you Brian, that is correct, at no point in time was i referring to Transaction Token. It didn't occur to me that abbreviating Token eXchange that way could be misunderstood.
S pozdravem, *Filip Skokan* On Wed, 22 Oct 2025 at 00:31, Brian Campbell <[email protected]> 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.*
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
