[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 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
>>
>