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]<mailto:[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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
