Hi Karl,
Thanks. I accept this reframing. Keeping the substrate grant agnostic and
locating delegation authority in compositional profiles is the right
architecture; my points are better read as requirements on the composition
hooks than as changes to DTR, and on that reading DTR already leaves the room.
The Actor Profile family is close to what I was hoping existed, actor signed
per hop authority in Proofs especially. I'll study all three drafts properly.
One observation on the remaining delta, which you flagged first: the
composition currently routes exactly one question back through AS memory,
freshness. The authority chain verifies against independent trust roots, but
its currency delegates to introspection. So (1) and (2) from my original mail
are addressed by composition, while (3) survives it: the principal still holds
no first class revocation object, and withdrawal of intent routes through the
issuer's surface.
A companion status mechanism could take the same shape as the delegation
itself: a principal signed status object published to a queryable status
source, verified against the same trust root as the proof chain, with no issuer
in the path. The tradeoff doesn't disappear, currency becomes cache bounded
against the status source, essentially the status list tradeoff, but revocation
becomes a principal operation, which is what closes point (3). The status
source could be any of the shapes already in this thread: a status list, a
federation endpoint, or another queryable transport. The property that matters
is that publication is permissionless for the principal.
On your request for a reference: SignedByMe (where I work) has built a system
for AI agent delegation that implements one instantiation of this pattern, a
principal signed delegation artifact, a principal published revocation object,
and verifier side checking of both. I'm preparing a technical writeup with a
JOSE serialization and will share it with the list shortly so there's something
concrete to compare against Proofs. We're also evaluating DTR's deferral
semantics for our own async approval flow and would report implementation
experience back to the list if that materializes.
I'd welcome a follow up conversation on whether a principal published status
mechanism is the right follow on to Proofs, and where that work would live.
Best,
Mitchell Ross
On Wednesday, July 22nd, 2026 at 12:56 AM, Karl McGuinness
<[email protected]> wrote:
> 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 visibleactchain 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 JWTexp("expiry"). At redemption, the client
> polls with thedeferral_codeand 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_detailsor
> 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]
