[OAUTH-WG] Re: Comments on draft-gerber-oauth-deferred-token-response: delegation verifiability during the pending window

[Frederik Krogsdal Jacobsen <[e-mail]>]

Hi Mitch,

I think this is another case where having a distinction between clients and
client instances would be helpful. But since there is currently no
standardized way to make that distinction, I get why you would need a way
to revoke the specific grant without revoking the entire permission set of
the client.

Good point about returning the delegation as a revokable credential. What's
not clear to me is where the revocation list would be hosted? It sounds
like the initiating entity/end user would need somewhere to host it outside
of the control of the client.
This has the same problem as the Delegate SD-JWT draft regarding
distribution of revocation information. Perhaps it would make sense to try
to define a common solution for this?
I think this is kind of orthogonal to DTR, so it probably fits into either
the Delegate SD-JWT draft or as a separate document.

Cheers,
Frederik

On Tue, 28 Jul 2026 at 13:50, <[e-mail]> wrote:

> 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 <
> [e-mail]> 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, <[e-mail]> 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 <
>> [e-mail]> 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:
>>
>>    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, <mitch=[e-mail]>
>> 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 <
>>> [e-mail]> 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 -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>