Dear Kieran,
Thanks, this helps clarify the model.
I agree that binding may_act to the resource URI alone provides no validated
match to the party performing token exchange.
Instead, the binding should be either to keys the resource server controls or
to the RS's client_id at the exchanging AS.
That points to the RFC 9728 protected resource metadata URI as the right anchor.
The issuing AS would not need to know every AS-local client_id the RS uses.
It only needs to include the protected resource metadata URI in may_act as
party identifier:
"may_act": {
"protected_resource_metadata":
https://api.example.com/.well-known/oauth-protected-resource
}
The protected resource metadata could then carry the RS's token-exchange client
identifiers, scoped by authorization server namespace or denote a CIMD
client_id:
"token_exchange_clients": [
{
"client_namespace": https://as-a.example,
"client_id": "rs-client-at-as-a"
},
{
"client_namespace": https://as-b.example,
"client_id": "rs-client-at-as-b"
},
{
"client_namespace": "cimd",
"client_id": https://api.example.com/oauth-client
}
]
At exchange time, the AS would dereference the protected resource metadata,
verify that its resource value corresponds to the subject token's aud/resource,
select the token_exchange_clients entry for its own issuer or use CIMD if
provided,
and compare that client_id with the authenticated client making the token
exchange request.
So the authorization decision remains based on authenticated client identity,
while may_act only provides a trusted indirection point to discover the correct
binding.
Yaron
Classification: GENERAL
From: Kieran Sweeney <[email protected]>
Sent: Thursday, September 3, 2026 5:02 PM
To: [email protected]
Cc: Yaron ZEHAVI <[email protected]>
Subject: Re: [OAUTH-WG] Proposal for Delegation Authorization with DPoP Tokens
Using RFC 8707 Resource Indicators and may_act claim
You don't often get email from [email protected]<mailto:[email protected]>.
Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
This message is from an external sender - be cautious, particularly with links
and attachments.
Yaron,
The gap is real. RFC 8693 leaves the question of who may exchange a DPoP-bound
token entirely to unstated AS policy, and a standard way to pre-approve the
exchanging party closes an actual hole in RS-to-RS delegation.
Two corrections before this becomes a draft.
First, may_act is the wrong container for a resource. RFC 8693 Section 4.4
defines may_act as a statement about a party authorized to become the actor,
identified the way subjects are identified. Putting a resource URI inside it
changes the registered semantics of the claim. Keep the downstream resource in
the resource parameter and the aud of the exchanged token, where RFC 8707
already puts it, and put the RS that is authorized to perform the exchange in
may_act as a party identifier. That expresses exactly your policy with no
semantic overload.
Second, client_uri cannot carry the match. RFC 7591 Section 2 defines it as a
URL for a human-readable page about the client. It is informational,
self-asserted, and unvalidated. Matching it against anything in an
authorization decision imports an unvetted value into policy. The AS should
match the authenticated client_id of the party presenting the exchange request
against the party named in may_act, which it already verified through client
authentication.
With those two changes this is a clean profile of RFC 8693 plus RFC 9449, needs
no new claims, and any authorization server or middleware can implement it
without coordination beyond the token itself. That last property is worth
preserving deliberately.
Kieran Sweeney
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).
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
