Meiling, Mohamad, Mohamad, thanks, that answers it. Session-independence is a property of the acting party so the two classes need different artefacts.
Meiling, issues #3 to #6 carry Christopher's and Mohamad's additions. Could you please open one for this class too, and I'll post text there in the document's structure as Christopher has. The class is already in the draft, unremarked. In Use Case 5, Agent B is authorised to access external databases to verify the details of the incident, and those records describe people who aren't the customer - the other driver, a treating doctor. The gap analysis doesn't reach them, and Section 2 is why. It defines only User (Resource Owner), per RFC 6749, so the only human it names is the one who delegates, never the one the data describes, which leaves no actor to hang a requirement on. I'd rather the subsection was written to the requirements than around my draft. Best, Blake On Saturday, 11 July 2026 at 05:48, Christopher Emerson <[email protected]> wrote: > Hi Meiling, > > > > Thank you for capturing these in the tracker so quickly, and for the > invitation. I have posted proposed text for all three: > > > > - Issue #3 > (https://github.com/Maisy-ML/Agent-Authorization-Use-Cases/issues/3): > proposed text for the new use case (first connection to a service with no > authorization front channel), following the document's existing use-case > structure. > > > > - Issue #4 > (https://github.com/Maisy-ML/Agent-Authorization-Use-Cases/issues/4): > proposed extension text for Use Case 3 covering caller-class consent, per > your suggestion to extend it rather than add a separate use case. > > > > - Issue #5 > (https://github.com/Maisy-ML/Agent-Authorization-Use-Cases/issues/5): > proposed Security Considerations text stating the agent-operable consent > surface property. > > > > Happy to iterate on any of them in the issues. > > > > > > Best regards, > Christopher Emerson > > > On Fri, Jul 10, 2026 at 2:58 AM [email protected] > <[email protected]> wrote: > > > Hi Christopher, > > > > > > Thank you for your detailed and insightful analysis and I want to respond > > specifically to each point, share some thoughts, and invite you to > > contribute these use cases directly to our GitHub repository. > > > > 1. Credential bootstrapping when neither side has a front channel > > We fully agree that RFC 8628 (Device Authorization Grant) goes part of the > > way – it handles browserless clients – but it does not solve the case where > > no browser-facing verification page exists at all because the service is a > > plain API with no authorization server relationship. This is a genuine gap. > > We think this is worth capturing as a new use case in the document. Your > > description of the first‑connection problem where the user needs a way to > > grant scoped, revocable access and the agent needs a way to obtain the > > resulting credential, all without any front channel on either side, is very > > clear. We’d be happy to include it, and we encourage you to submit it as a > > use-case proposal on GitHub. > > > > https://github.com/Maisy-ML/Agent-Authorization-Use-Cases/issues/3 > > > > 2. Caller-class consent within a single API surface > > You are right that this is related to Use Case 3 but also distinct. The > > idea that a user might grant consent independently for interactive > > sessions, the application’s own built-in AI, and external agent access is > > an important dimension. We agree this can be addressed by extending the > > existing Use Case 3 rather than creating a completely separate one. > > > > https://github.com/Maisy-ML/Agent-Authorization-Use-Cases/issues/4 > > > > 3. Consent channels that the agent itself cannot operate > > Your premise here is absolutely crucial: the same agent must not be able to > > approve its own authorization requests. That is a fundamental security > > property, and you are right to call it out as a cross-cutting concern. As > > you noted, any consent surface reachable from the agent’s execution context > > can be subverted. This applies generally, beyond any single use case. We > > think this should be captured as a security consideration or a shared > > requirement in the document, and it is definitely a common problem for all > > consent‑seeking mechanisms in agent environments. > > > > https://github.com/Maisy-ML/Agent-Authorization-Use-Cases/issues/5 > > > > These are valuable additions that can inform both the use cases and the > > security discussion. > > > > We would love to have these contributions directly in the repository, this > > way we can iterate on them with the broader community. > > > > Looking forward to your contributions. > > > > Best, > > > > Meiling > > > > [email protected] > > > > > From: Christopher Emerson > > > Date: 2026-07-09 00:40 > > > To: [email protected] > > > CC: oauth > > > Subject: Re: Re: [OAUTH-WG] Re: New Version Notification for > > > draft-chen-oauth-agent-authz-use-cases-01.txt > > > Hi Meiling, > > > > > > Thank you for the kind words and for both questions. Taking them in > > > turn. > > > > > > On the use cases: Section 3 covers most of what I encounter in > > > practice; Use Case 1 in particular matches my experience closely. > > > Three scenarios I have had to solve for are not yet represented, and > > > may be worth considering: > > > > > > 1. Credential bootstrapping for services with no OAuth front channel. > > > > > > A long tail of agent-facing services (plain APIs, including many MCP > > > servers that predate or do not implement the MCP authorization > > > framework) has not adopted an authorization server relationship, its > > > own or a delegated one, and exposes no browser-facing authorization > > > endpoint. The agent side is often headless or remote, with no > > > co-located browser. In practice these connections are commonly worked > > > around with static API keys passed through environment variables: > > > long-lived, broad, and invisible to the user after setup. The Device > > > Authorization Grant [RFC8628] covers browserless clients, but it > > > still assumes an authorization server with a browser-facing > > > verification page, and the client initiates the request and proposes > > > the scopes. What I have not seen represented is the first-connection > > > case where no front channel exists on either side: the user needs a > > > way to grant scoped, revocable access, and the agent needs a way to > > > obtain the resulting credential. This precedes the scenarios in > > > Section 3; Use Case 1's gap analysis, for example, notes that the > > > Authorization Code flow can obtain the initial permissions, which > > > assumes that front channel is available. > > > > > > 2. Caller-class consent within a single API surface. > > > > > > Use Case 3 distinguishes an agent from its user for rate and policy > > > purposes. A related but distinct situation: the same API serves three > > > classes of caller (interactive human sessions, the application's own > > > internal AI features, and external user-delegated agents), and the > > > user's consent decision for each class is independent. A user may > > > permit the application's built-in AI to process their data while > > > denying external agents, or the reverse. Today the internal-AI class > > > typically never traverses the authorization layer at all, so there is > > > nothing to attach that consent decision to. There is no standard > > > representation of a caller class beyond the human-versus-agent > > > distinction in Use Case 3, and no standard way to express consent > > > that is evaluated per class without inheritance between classes. > > > This could be an extension of Use Case 3 or a separate use case; it > > > becomes acute as applications add native AI features alongside > > > external agent access. > > > > > > 3. Consent channels that the agent itself can operate. > > > > > > Gap 2 calls for a standardized way for an agent to pause and securely > > > ask the user. Implementation experience suggests a requirement worth > > > stating explicitly: as agents gain browser-automation and computer-use > > > capabilities, any consent interface reachable from the agent's > > > execution context can be completed by the agent itself. An injected > > > or compromised agent can click its own "Approve" button. This > > > applies to any consent surface reachable from the agent's machine, > > > including the connection interface in my own draft. A pause-and-ask > > > mechanism therefore needs a ceremony the agent cannot complete from > > > where it runs: an approval on a device outside the > > > agent's control, or a user-verified assertion (for example WebAuthn > > > with user verification) from an authenticator registered before the > > > task began. A plain confirmation click is not evidence of a human > > > decision. Even then, binding the approval to what the user was > > > actually shown remains an open problem. The same consideration > > > applies to the secure privilege escalation requirement in Use Case 4: > > > on a device where the agent controls the input, an ordinary approval > > > dialog proves nothing. This may belong in Section 5 as a security > > > consideration for whatever interactive channel the group > > > standardizes. > > > > > > On the gap analysis: Gaps 1, 2, and 4 are precisely the problems I > > > faced; they are why my draft exists. Two subtler challenges from > > > implementation are not yet on the list: > > > > > > First, evidence of the authorization event itself. Section 5 calls > > > for agent actions to be auditable and non-repudiable. Implementation > > > surfaced the complementary need: a durable record of the grant, > > > capturing who authorized it, which scopes, when, and under which > > > policy version. When an agent's later actions are disputed, the first > > > question is what the human actually authorized. There is no standard > > > shape for that record (consent-receipt work exists outside OAuth); > > > introspection responses and access token claims describe the live > > > grant while it exists, not a durable record of the event that > > > created it. > > > > > > Second, redemption semantics for one-time credentials under > > > adversarial concurrency. Any design in this space mints some > > > single-use artifact: an authorization code, a user code, or the > > > connection credential in my draft. Whether a failed redemption > > > attempt consumes the artifact, and which attempt wins when two > > > redemptions race, is implementation-defined today. I ended up burning > > > the credential on any redemption attempt that presents it, successful > > > or not, to close the case where a failed attempt leaves a still-live > > > credential behind. Small surface, but it decides whether an > > > intercepted credential is recoverable by an attacker. > > > > > > On Gap 4 specifically: since my earlier note, I have implemented > > > bulk (per-user) and label-scoped (task-handle) revocation on top of > > > the per-connection model described in my draft > > > (draft-emerson-oauth-user-mediated-delivery). Both are a single > > > server-side operation. As with the per-connection case, tokens are > > > validated online on every call, so revocation takes effect on the > > > agent's next request. I mention this only as evidence that the > > > revocation gap you identify is closable; my draft does not > > > standardize a revocation API surface. For standardization, Global > > > Token Revocation (draft-parecki-oauth-global-token-revocation) > > > already defines the per-user bulk case at the authorization server, > > > and the OpenID Grant Management API's grant_id is the closest > > > handle-scoped mechanism I know of, though a task handle spanning > > > multiple grants is not quite the same thing. > > > > > > Happy to propose text for any of these if useful for the next > > > revision. > > > > > > Best regards, > > > Christopher Emerson > > > > > > On Wed, Jul 8, 2026 at 2:38 AM [email protected] > > > <[email protected]> wrote: > > > > > > > Hi Christopher, > > > > > > > > Thank you for your email and for sharing your draft, > > > > `draft-emerson-oauth-user-mediated-delivery-00`. We are very pleased to > > > > hear that our `use case and gap analysis` was helpful in > > > > contextualizing your work. > > > > > > > > The primary goal of our draft is to help the community clarify the > > > > problem space for agent authorization. Your hands-on experience in > > > > building a real-world solution is precisely the kind of input that can > > > > help us make our document more accurate and comprehensive. Your > > > > insights would be invaluable in ensuring we are mapping the territory > > > > correctly. > > > > > > > > To that end, we have two key questions for you, based on your practical > > > > experience: > > > > > > > > 1. Regarding the Use Cases: Do the scenarios currently described in > > > > Section 3 of our draft (`draft-chen-oauth-agent-authz-use-cases-01`) > > > > adequately cover the situations you have encountered in practice? Or > > > > are there significant agent authorization scenarios you've had to solve > > > > for that are not yet represented? > > > > 2. Regarding the Gap Analysis: Does our gap analysis fully capture the > > > > fundamental problems you've faced? Your draft provides a brilliant > > > > solution pattern that addresses several of the gaps we identified. We > > > > are curious if, during your development process, you encountered other, > > > > perhaps more subtle, gaps or challenges that are not yet on our list. > > > > > > > > Your feedback on these points would be extremely valuable as we prepare > > > > the next revision. A more robust problem definition will benefit the > > > > entire working group as we move towards developing solutions. > > > > > > > > Thank you again for initiating this important conversation. > > > > > > > > Best regards, > > > > > > > > Meiling > > > > > > > > [email protected] > > > > > > > > > From: Christopher Emerson > > > > > Date: 2026-07-07 11:23 > > > > > To: [email protected] > > > > > CC: oauth > > > > > Subject: Re: [OAUTH-WG] Re: New Version Notification for > > > > > draft-chen-oauth-agent-authz-use-cases-01.txt > > > > > > > > > > > > > > > > > Hi Meiling, > > > > > > > > > > > > Thank you for this draft. The gap analysis is a useful catalogue, > > > > > > and it > > > > > > matches what we see building agent access against real applications. > > > > > > > > > > > > Gap 2 in your summary ("the framework has no built-in mechanism for > > > > > > an > > > > > > agent to 'pause' and securely ask the user for an intermediate > > > > > > decision") > > > > > > is the problem I tried to address in > > > > > > draft-emerson-oauth-user-mediated-delivery-00, posted last week: > > > > > > > > > > > > https://datatracker.ietf.org/doc/draft-emerson-oauth-user-mediated-delivery/ > > > > > > > > > > > > It proposes user-mediated credential delivery as a complementary > > > > > > primitive: the credential is delivered to the user through > > > > > > human-controlled channels, and the user hands it to the agent, so > > > > > > the > > > > > > authorization decision happens outside the agent's execution > > > > > > context. > > > > > > There is no redirect, callback, or other agent-addressable path for > > > > > > an > > > > > > injected instruction to exploit. > > > > > > > > > > > > The same primitive gives a concrete shape to two of your other gaps: > > > > > > > > > > > > - Gap 1 (just-in-time authorization): when an agent attempts an > > > > > > operation outside its granted scope, the system returns an error > > > > > > identifying the specific missing scope, and the escalation runs > > > > > > through the user as a renewed user-mediated grant (Section 4.2 of > > > > > > the draft). Scope changes always terminate at a human decision. > > > > > > > > > > > > - Gap 4 (revocation): grants are per-connection and validated by > > > > > > introspection on each request, so revoking one agent's access is > > > > > > immediate and does not affect other connections. > > > > > > > > > > > > I would welcome the group's thoughts on whether user-mediated > > > > > > delivery > > > > > > is a useful primitive for the requirements you catalogue, > > > > > > particularly > > > > > > the personal and consumer scenarios in section 3.1, where the end > > > > > > user > > > > > > rather than an enterprise administrator is the authority. > > > > > > > > > > > > Best regards, > > > > > > Christopher Emerson _______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
