Dear Jeff,
Thanks for your response.
Regarding TMB, I think it handles a slightly different challenge. The DPoP
issuer in my example doesn't know at which AS the token will be exchanged.
Maybe the resource server is a client of several authorization servers, so
deferred key binding requires a decision on which key to bind which depends on
the target AS.
Regarding HTTPSig, good call out.
I agree it's a mechanism that allows "beyond direct line of sight" delegation
chains.
It could allow a receiving RS1 to obtain implicit delegation powers to extend a
signed hash chain, referencing the previous node and extendind the PoP so RS2
can validate it's being called by RS1 which has been delegated by the token's
holder using httpsig.
In the attached email from July, Justin wrote this delegation use-case could be
supported by HTTPSig over a signed hash chain.
I'm honestly not sure what is the better approach for this challenge.
It's worth a discussion in the WG.
Regards,
Yaron
Classification: GENERAL
From: Lombardo, Jeff <[email protected]>
Sent: Thursday, September 3, 2026 6:07 PM
To: Yaron ZEHAVI <[email protected]>; oauth <[email protected]>
Cc: Lombardo, Jeff <[email protected]>
Subject: RE: [OAUTH-WG] Proposal for Delegation Authorization with DPoP Tokens
Using RFC 8707 Resource Indicators and may_act claim
This message is from an external sender - be cautious, particularly with links
and attachments.
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]<mailto:[email protected]>>
Sent: September 3, 2026 3:18 AM
To: oauth <[email protected]<mailto:[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
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).
--- Begin Message ---
This message is from an external sender - be cautious, particularly with links
and attachments.
I don’t think you’d need to extend much at all for this to work, tbh. You can
already add multiple signatures, and the real fix here is, as with DPoP and
MTLS, having multiple confirmation keys for each sender (Client and RS1), and
possibly multiple contexts for each verifier (RS1 and RS2). So if RS2 has the
ability and need to verify the original signature, it can do that as well as
the presentation from RS1 to RS2. This is largely the same for any PoP method
(you could have one token tied to the certs for Client and RS1 for example).
The core protocol isn’t meant to deal with the in-trust-domain boundary though
so you either solve it silently (so the spec doesn’t mention it, it’s an
internal detail) or you do some additional step, in which case you’re looking
at token exchange at the boundary or something.
Even with all that, within a trust domain, I still think you’d rather haven a
transaction token for use cases like this.
— Justin
On Jul 5, 2026, at 4:54 PM, Yaron ZEHAVI <[email protected]>
wrote:
Dears,
Thanks for sharing this draft.
I think it makes sense and adds interoperability.
I’d like to ask if it can be extended for cases when (please count to 3
before telling me it’s wrong) resource server wishes to forward the received
access token to another resource server in the same trust domain.
In my company, the internal API architecture uses mainly bearer tokens and
calls within API layers (head office and subsidiaries) by forwarding the same
token downstream.
When adding calls to external facing APIs (for example from native mobile
apps) we’re adding DPoP as a countermeasure.
PoP only protects the first resource server called, so whoever is called
needs to token exchange to a bearer token such as a transaction token.
This is the reference architecture but sometimes these token exchanges are
unnecessary overhead and safely forwarding the original token would have made
more sense.
With your draft a caller (client) names the intended recipient (resource
server1) and based on that it can also delegate it the right to forward the
same token downstream.
RS1 which is verifiably named by the client, when calling RS2 with the same
token can add a node to a signed hash chain, referencing the previous node and
using its “delegation powers” to extend the PoP so RS2 can validate it’s being
called by RS1 which has been delegated by the token’s holder using httpsig.
Please share your thoughts on feasibility and value of this proposal.
I prepared some examples with the help of an LLM which I can share.
Regards,
Yaron
Classification: GENERAL
From: Justin Richer <[email protected]<mailto:[email protected]>>
Sent: Thursday, July 2, 2026 4:51 PM
To: oauth <[email protected]<mailto:[email protected]>>
Subject: [OAUTH-WG] HTTP Signatures for OAuth
This message is from an external sender - be cautious, particularly with
links and attachments.
Starting a new thread on this one:
As you may have seen, I’ve updated the draft for applying HTTP Message
Signatures to OAuth Access Tokens, and Aaron has joined as co-author. A pull
for this work has come from a few different places lately and we’d like to see
this move forward in the WG.
https://www.ietf.org/archive/id/draft-richer-oauth-httpsig-02.html<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-richer-oauth-httpsig-02.html&data=05%7C02%7Cyaron.zehavi%40rbinternational.com%7C7965df9ea22f47535d9408dedb739edc%7C9b511fdaf0b143a5b06e1e720f64520a%7C0%7C0%7C639189486807892385%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=yWUefrmLxwZflzeN51i9puscsXv28UxhmlOMcXR6LXY%3D&reserved=0>
Please read the draft, it’s not that long and I’ve left a bunch of editor’s
notes in places that I think we’d want to address more directly or would need
WG debate to come to a satisfying answer.
— Justin
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).
--- End Message ---
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
