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

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

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]
>>
>