Hi Mitchell, Thanks for raising this concern. My read is that your three points are real and that they land at the composition layer above DTR rather than in DTR itself. DTR is designed as a transport substrate; the delegation-authority questions layer on top rather than modify it.
DTR's job is the async transport: request, defer, poll, redeem, with sender-constraining and cancellation. It deliberately does not define what authority the deferral code represents, how that authority is expressed, or how it's verified beyond the DPoP key binding. That's a design choice IMHO: keeping the transport grant-agnostic lets it carry approval flows whose credential shapes and verification models differ, without the substrate needing to know about them. Your three concerns are all credential-shape and verification-model concerns: (1) resolves to "make the delegation a signed artifact," (2) to "make authority verifiable independently of AS state," and (3) partly to "make revocation an artifact-holder operation." None require DTR to change; they require the substrate to leave room for compositional profiles to define signed delegation artifacts, principal-controlled key material, and independent revocation surfaces. That's the pattern the substrate is designed for. *Existence proof: the Actor Profile family* I've been publishing an actor-side delegation family that layers this kind of authority chain on top of OAuth token issuance (not specifically DTR, but structurally compatible): - draft-mcguinness-oauth-actor-profile <https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-profile/> defines a visible act chain for delegation hops. - draft-mcguinness-oauth-actor-receipts <https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-receipts/> adds AS-signed per-hop provenance. - draft-mcguinness-oauth-actor-proofs <https://datatracker.ietf.org/doc/draft-mcguinness-oauth-actor-proofs/> adds actor-signed per-hop authority. Mapped to your requirements: the principal signs an Actor Proof carrying the target binding ("scopes") and JWT exp ("expiry"). At redemption, the client polls with the deferral_code and a DPoP proof (per DTR ยง5.6); the resource server independently validates the token signature (issuer trust), the DPoP proof (current-hop possession), and the actor-signature chain (delegation authority) against distinct trust roots. Proofs travel alongside the OAuth request and are preserved into the issued token, or are returned via introspection for opaque tokens. Delegation authority is verified as a signature chain, not by consulting AS memory. Your "revocation handle" is the gap I flagged: the current Proofs draft explicitly places per-proof online revocation outside its scope and delegates freshness to AS introspection. A companion status mechanism would close it, but that's follow-on work. Other compositional shapes are equally viable: OpenID Federation entity statements offer a different lens on the same problem, and verifiable credential approaches offer another. On the AuthZEN interop point you raised, AROP (openid/authzen#531 <https://github.com/openid/authzen/pull/531>) is a published composition of DTR + RAR + ARAP for AuthZEN-driven access requests, a concrete working example of the same composability. The specific choice of profile matters less than the substrate being composable enough for multiple viable answers to exist. For DTR itself, the *interesting question is whether the composition hooks are open, not which profile is picked*. *Why DTR already accommodates this* DTR doesn't restrict originating-request parameters (those are the underlying grant type's rules) and doesn't shape the token issued in the polling response (that's the issuing profile's job). A profile carrying a signed delegation via RAR (RFC 9396 <https://datatracker.ietf.org/doc/html/rfc9396>) authorization_details or a dedicated parameter fits on the request today, and the AS can embed the delegation as a claim in the issued token, or expose it via introspection for opaque tokens. No DTR changes required. The substrate posture that makes DTR grant-agnostic is what makes it composable at both ends. Happy to dig into this as a follow-up conversation. If you have other delegation-artifact work you think is useful for your concerns, I'd welcome the reference so I can compare. -Karl
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
