Frederik,
Agreed on both counts. There is no initiating entity in the cron job case, and
anything requiring a third party to contact the AS directly belongs in a
profile rather than in DTR itself. I am not proposing a change to the draft.
Where I would push back is on the binary between a client that behaves
correctly and one that is compromised, because the agent deployments I am
looking at do not sit at either pole.
Two cases:
1. The initiating entity generally cannot revoke the client. When a user
delegates a task to a hosted agent platform, the OAuth client is the platform's
registration, not the user's. The user has no ability to revoke it, and should
not, since revoking it would break every other tenant on that platform. The
only authority the user can withdraw is their own grant. So "just revoke the
client's permissions" is not available to the party who actually wants to stop
the transaction.
2. Clients are not so much compromised as steered. A prompt injected agent
misbehaves on one task while continuing to run others correctly. Revocation at
client granularity is the wrong blast radius for that failure mode.
Both point at the same thing. For a client serving many principals at once, the
unit of authority is not the client, it is the individual delegation. And DTR
is where that matters most, because deferral opens a window between request and
issuance during which delegation state can change and the AS has no way to
notice.
On the objection that this requires a direct channel to the AS, I do not think
it does. If the delegation is a signed credential with a published revocation
status, the AS can check that status at issuance, in the same shape as a status
list or OCSP. The initiating entity revokes its own credential, the AS checks
again at issuance, and no new endpoint or new relationship between the
initiating entity and the AS is needed.
That is a profile, and I would be glad to write it up as one if there is
interest, or to be told it is out of scope here.
Mitch
Sent from [Proton Mail](https://proton.me/mail/home) for iOS.
-------- Original Message --------
On Tuesday, 07/28/26 at 05:21 Frederik Krogsdal Jacobsen
<[email protected]> wrote:
> Hi Mitchell,
>
> Thanks for the additional explanation and use cases!
>
> The use cases you mention all have in common that they start with what I will
> call an "initiating entity" that wants to do something, then later changes
> its mind and is no longer in control of the client.
> Crucially, the initiating entity is not the same entity as the one that is
> deferred to (otherwise it could just deny the request in the deferral
> itself), and it is not the client (otherwise it could just use the
> cancellation endpoint already in DTR).
>
> In general there is no separate initiating entity though, as we also consider
> e.g. automated workflows (it might just be a cron job or something similar
> that does not have any kind of agency to change its mind).
> I think this would need to be defined in a higher-level profile, since it
> requires some way for the initiating entity to contact the AS directly, i.e.
> without involving the client.
>
> I'm also not sure it really makes sense to distinguish the client and the
> initiating entity using it. If your client is compromised, there's generally
> not a lot you can do to prevent it from misbehaving other than revoking its
> permissions.
> If we assume that the client is well-behaved, I think a lot of these could be
> solved by the client just giving the initiating entity the ability to cancel
> in its application code, which will then make the client cancel the flow.
> If the assumption is that the client is malicious, are there any cases where
> the initiating entity would cancel just the one transaction and not revoke
> the permissions of the client?
> I don't think I quite understand which threat model would lead to this
> outcome.
>
> Cheers,
> Frederik
>
> On Thu, 23 Jul 2026 at 17:42, <[email protected]> wrote:
>
>> 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]
