Hi Mitchell and Karl, Thanks for thinking this through.
My takeaway from this is that there are two things we should think about in DTR: 1. Make sure there are adequate extension points for SSF/CAEP profiles. 2. Consider supporting a separate cancellation endpoint, perhaps linked to the subject itself. I think this may possibly be use-case specific and belong in an OpenID Connect profile for DTR, but I'm not 100% sure I understand the uses yet. Cheers, Frederik On Wed, 22 Jul 2026 at 23:44, <[email protected]> wrote: > 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 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] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
