Hi Meiling, Thank you for capturing both points in the tracker so quickly. I will post substantive comments in issues #5 and #6 within the next day or two, including the link to the "Authorization Evidence for High-Risk Actions" survey and the per-action vs. point-in-time distinction you asked about.
Best, Mohamad > On 10 Jul 2026, at 13:35, [email protected] wrote: > > Hi Mohamad, > > Thank you for the sharp and detailed follow-up. I have noticed both points > you raised, and I wanted to let you know we’ve already captured them in > GitHub issues. > > 1. Consent channels that the agent itself cannot operate > Your framing – that the proof of human decision must be generated at > execution time, bound to the specific action, and signed by key material the > agent runtime cannot reach – is exactly the sort of requirement we believe > should apply to any consent mechanism the group standardizes. This is > recorded in issue #5. > > https://github.com/Maisy-ML/Agent-Authorization-Use-Cases/issues/5 > > 2. Durable record of the authorization event > I also fully agree that this is the necessary complement to the > non-repudiation requirement in Section 5. Token introspection and claims > describe the live grant, but they are not a durable event record. We captured > this in issue #6, > > https://github.com/Maisy-ML/Agent-Authorization-Use-Cases/issues/6 > <https://github.com/Maisy-ML/Agent-Authorization-Use-Cases/issues/5> > > explicitly noting the need for a record that captures who authorized, which > scopes, when, and under which policy version. Your mention of the > “Authorization Evidence for High-Risk Actions” survey and the separation > between per-action evidence and point-in-time signals about the grant is > directly relevant. It would be great if you could link or expand on that in > the issue. > > These security considerations are critical to getting the design right, and > I’m glad we are already aligned in the issue tracker. > > Best, > Meiling > [email protected] <mailto:[email protected]> > > From: Mohamad Khalil Yossif <mailto:[email protected]> > Date: 2026-07-09 02:01 > To: Christopher Emerson <mailto:[email protected]> > CC: [email protected] <mailto:[email protected]>; oauth > <mailto:[email protected]> > Subject: Re: [OAUTH-WG] New Version Notification for > draft-chen-oauth-agent-authz-use-cases-01.txt > Hi Christopher, Meiling, > > Two of the points in this exchange coincide with problems I have been > working through, and I think they sharpen the problem definition the > group is assembling. I will keep to those two. > > On Christopher's point 3 (consent channels the agent can operate). > This is the crux. Once an agent has browser-automation or > computer-use capabilities, any confirmation surface reachable from > its execution context can be completed by the agent itself, so a > plain approval click carries no evidence of a human decision. The > requirement that follows is that the proof of the human decision be > generated at the moment of the action, bound to the specific action > payload, by key material the agent runtime cannot reach. This is the > execution-time, session-independent framing in draft-yossif-psea > (https://datatracker.ietf.org/doc/draft-yossif-psea/): assurance > that holds whether a session is active, expired, or absent, because > it does not inherit from session state. > > Christopher notes that binding the approval to what the user was > actually shown remains open. One workable direction: the issuer > forms a commitment over the parameters rendered to the user; the > user's authenticator signs a response over that commitment at > execution time; the server verifies the signed selection against > the commitment before the action proceeds. The authenticator is > provisioned before the task begins, and its key is outside the > agent's execution context. WebAuthn with user verification supplies > the human-presence signal; the commitment supplies the > what-you-approved binding. A confirmation dialog on a device where > the agent controls input does not meet this bar, which is also why > Use Case 4's privilege escalation needs the same treatment. This > belongs in Section 5 as a security consideration for whatever > interactive channel the group standardizes. > > On the durable record of the authorization event (Christopher's > first gap-analysis addition). This is the complement to Section 5's > non-repudiation requirement, and I agree it is missing. > Introspection responses and token claims describe the live grant > while it exists. They are not a durable record of the event that > created it: who authorized, which scopes, when, under which policy > version. When an agent's later actions are disputed, that record is > the first thing needed and the first thing absent. This granularity > question is the subject of a survey recently submitted to > secdispatch, "Authorization Evidence for High-Risk Actions," which > separates per-action authorization evidence from point-in-time > signals about the grant. It may warrant either a gap of its own or > an explicit sub-point under Section 5. > > I am happy to propose text for both, in coordination with > Christopher's offer, for the next revision. > > Best regards, > Mohamad Khalil Yossif > Author, draft-yossif-psea > > > On 8 Jul 2026, at 19:40, Christopher Emerson <[email protected]> > > wrote: > > > > 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: > > • 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? > > • 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]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
