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 <[email protected]> > *Date:* 2026-07-09 00:40 > *To:* [email protected] > *CC:* oauth <[email protected]> > *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 <[email protected]> >> *Date:* 2026-07-07 11:23 >> *To:* [email protected] >> *CC:* oauth <[email protected]> >> *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]
