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, <[email protected]> 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 < > [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: >> >> 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]
