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 <[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./
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
