[OAUTH-WG] Re: New Version Notification for draft-chen-oauth-agent-authz-use-cases-01.txt

[Christopher Emerson <[e-mail]>]

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 [e-mail] <
[e-mail]> 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
> ------------------------------
> [e-mail]
>
>
> *From:* Christopher Emerson <[e-mail]>
> *Date:* 2026-07-09 00:40
> *To:* [e-mail]
> *CC:* oauth <[e-mail]>
> *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 [e-mail] <
> [e-mail]> 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
>> ------------------------------
>> [e-mail]
>>
>>
>> *From:* Christopher Emerson <[e-mail]>
>> *Date:* 2026-07-07 11:23
>> *To:* [e-mail]
>> *CC:* oauth <[e-mail]>
>> *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
>>>
>>