Hi Yaron, only answering to “[awareness] of any existing work explicitly addressing this delegation path”, there are two:
* the problem raising now expired TMB draft: https://datatracker.ietf.org/doc/draft-richer-oauth-tmb-claim/01/ * Justin presented at Vienna PoP with HTTP Message Sig for OAuth: https://datatracker.ietf.org/doc/draft-richer-oauth-httpsig/03/ * I fully recognize that this is a full different PoP mechanism, still the problem you raise is one of the use case as discussed on mic Jeff Jean-François “Jeff” Lombardo | Amazon Web Services Architecte Principal de Solutions, Stratégie de Sécurité Principal Solution Architect, Security Strategy Montréal, Canada From: Yaron ZEHAVI <[email protected]> Sent: September 3, 2026 3:18 AM To: oauth <[email protected]> Subject: [EXT] [OAUTH-WG] Proposal for Delegation Authorization with DPoP Tokens Using RFC 8707 Resource Indicators and may_act claim 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. Dear OAuth Working Group, I would like to discuss a potential extension to OAuth token exchange and DPoP usage that addresses delegation scenarios where a resource server (RS) calls downstream resource servers on behalf of a client. Currently, exchanging a DPoP token by a party not controlling the DPoP private key risks unauthorized use. To mitigate this, I suggest leveraging RFC 8707 resource indicators as delegation-authorization input to DPoP token request, combined with the `may_act` claim in the DPoP token. In this model: - The DPoP token includes the delegated resource in the `may_act` claim. - An RS requesting a token exchange of a DPoP token it received, authenticates to the authorization server (AS) using applicable client authentication. - The authorization server validates the requesting client matches the pre-approved `may_act` resource, for example using client metadata’s `client_uri` to match the `may_act` resource. - This allows the RS to exchange the DPoP token for a downstream bearer token (e.g., a transaction token), while preventing such exchanges by unauthorized parties. I believe this approach could enhance secure delegation in OAuth flows involving DPoP tokens. I am not aware of any existing work explicitly addressing this delegation path. Could the WG consider this as a potential extension or profile of token exchange or DPoP usage? I would appreciate guidance on where such work might best be incorporated — whether as an extension to RFC 8693, RFC 8707, RFC 9449, or a new draft. Thank you for your consideration. Regards, Yaron ZEHAVI This message and any attachment ("the Message") are confidential. If you have received the Message in error, please notify the sender immediately and delete the Message from your system, any use of the Message is forbidden. Correspondence via e-mail is primarily for information purposes. RBI neither makes nor accepts legally binding statements via e-mail unless explicitly agreed otherwise. Information pursuant to § 14 Austrian Companies Code: Raiffeisen Bank International AG; Registered Office: Am Stadtpark 9, 1030 Vienna, Austria; Company Register Number: FN 122119m at the Commercial Court of Vienna (Handelsgericht Wien). Classification: GENERAL
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
