Hi Frederik,
Both takeaways sound right to me, and a subject linked cancellation path in
particular would close the gap I was pointing at. Since you asked about uses,
here are three concrete scenarios from the agent deployment side, all the same
shape: the principal's intent changes during the pending window, and today the
principal has no path of their own.
1. Agent trading. A human authorizes an AI agent to execute a position on a
regulated prediction market. Approval lands at hour 2, the token redeems at
hour 12. At hour 7 conditions change and the human wants out. The cancellation
token doesn't help them, the client holds it, and a compromised or simply
autonomous agent has no reason to use it. CAEP doesn't fire either, the account
is fine, only the intent changed. The human's only path today is whatever
support surface the AS offers.
2. Enterprise delegation. An employee authorizes an agent to act in a
procurement negotiation, then is reassigned mid window. Account termination
would surface via SSF/CAEP, but voluntary reassignment or withdrawal is not an
account state event. The subject needs a first class way to say this specific
grant no longer stands.
3. Consumer purchases. A user approves an agent purchase flow, sleeps on it,
and changes their mind before the merchant's approval workflow completes.
Chargeback style remediation after redemption is expensive for everyone.
Cancellation by the subject before redemption is cheap.
The common requirements these imply: the cancellation path must be exercisable
by the subject rather than the client, must not depend on the client
cooperating, and must be distinguishable from account level signals, withdrawal
of one grant, not a change in account state.
On where it lives: I think you're right that the endpoint itself may be profile
territory, OIDC or otherwise, while DTR's job is to guarantee the extension
point exists, a defined way for the AS to check subject cancellation state
before releasing the token at redemption. That keeps the substrate grant
agnostic and lets profiles define how subject intent is expressed. For what
it's worth, the layered work Karl and I have been discussing treats the
subject's grant and its withdrawal as signed artifacts verified alongside
redemption, which would compose naturally with a subject linked cancellation
check in DTR: the endpoint handles the in band case, the artifact handles
verifiability across trust boundaries. Happy to write up the use cases in more
detail if that's useful for the draft.
Mitchell Ross
SignedByMe
-------- Original Message --------
On Thursday, 07/23/26 at 10:12 Frederik Krogsdal Jacobsen
<[email protected]> wrote:
> 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:
>
> - Make sure there are adequate extension points for SSF/CAEP profiles.
> - 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 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]_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
