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