Hi,
Thanks for your Draft.
Here are some comments on the elements listed as Gaps:
* Section 3.1.1:
* You identify that OAuth is not capable of understand an intent. True
but is it the purpose of OAuth? The Agent will rely on the LLM to understand
how the task need to be decomposed based on the tools and other agents
available. At the end, this is for the Tools and Agents allowing to fulfill the
task that the Agent will need to acquire consented delegation of Authorization.
MCP Servers and Agent Card can contain information about the AS to contact and
the scopes and potentially RAR authorization details
(RFC9396<datatracker.ietf.org/doc/rfc9396/>) required to call them thanks to
OAuth2.0 Protected Resource Metadata
(RFC9728<https://datatracker.ietf.org/doc/rfc9728/>)
* You indicate that there is no No Standardized Interactive Flow. But
again is this even an OAuth problem? If the Agent needs more information from
the User / Resource Owner, Agentic AI Development Frameworks like CrewAI,
LangChain, LangGraph, Strands and other have all the capabilities to do such
things through their converse API. Additional Information provided by the User
/ Resource Owner will allow, thanks again to the LLM, to the selection of a new
set of Tools and Agents to fulfill the updated Taks and new consented
Delegation of Authorization will be acquired as explained in the previous point.
* Impractical Revocation. There are two points here: 1/ Tokens are
stateless and lifetime is a perfect dimension to also control the permissions
accumulation; 2/ You completely omits that write operations could be perform
through the usage of Transaction Tokens (see
https://datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/ and
https://datatracker.ietf.org/doc/html/draft-oauth-transaction-tokens-for-agents
)bound to a specific task / intent (in this case a picnic event)
* Section 3.1.2 is frivolous. It does not include any mention of usage of
AI. This is the old Smart Home Automation use case we know for years and has
very successful deployment at the Enterprise and Open Source level: see Apple,
Google, Home Assistant, Ring, etc.
* "Scope Explosion" and Usability : Again you forgot about the ability
to use RAR authorization details (RFC9396<datatracker.ietf.org/doc/rfc9396/>)
as a way to express Token Boundaries in Token but more importantly when in
single Trust Domain, most of those scoping are stored in backend Policy
Decision Point’s policy stores and only referenced in Tokens.
* No Standardized Policy Enforcement: Again this is a big misconception.
OAuth is perfectly capable of handling claims that are JSON Structure that
could host such information as “At 7 AM” or “in between 6AM and 8 AM”. But at
the end of the the policy enforcement is done by the Resource Server after
receiving all the information from the token, retrieving other information from
other Policy Information Point and submitting the Authorization Request to the
Policy Decision Point. None of those actions are in the scope of OAuth which
always set those as explicitly ‘out of scope” in any OAuth RFC. If you are
looking for standards, you should look at OpenID Foundation AuthZEN (see
https://openid.net/wg/authzen/)
* No Standardized Bulk Revocation: I agree that there is no standardized
Global Sign Out.
* Section 3.1.3 does not encompass the latest and greatest of OAuth
* If tokens are cryptographically bound to a client key, they cannot be
shared and reused by AI Agent as they don’t have access to the key. See DPoP
(RFC9449<https://datatracker.ietf.org/doc/html/rfc9449>)
* Therefore the AI Agent needs to possess their own Client identifier
and that is where Draft like CIMD are useful as the document they exposes can
establish the Agentic nature of the client (see
https://datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/)
* Also we start to see a movement for Agent Registration ahead of time.
That is what WebBotAuth WG came to -
https://datatracker.ietf.org/wg/webbotauth/about/
* Finally we a lot of Workload Identity Federation support among
OpenAI<https://developers.openai.com/api/docs/guides/workload-identity-federation>,
Anthropic<https://platform.claude.com/docs/en/manage-claude/workload-identity-federation>,
and
Snowflake<https://docs.snowflake.com/en/user-guide/workload-identity-federation>
* Section 3.1.4 is a real problem but globally even MCP decide to
standardize around STDIO and not RPC JSON for local access. All Operating
Systems are still locked on ACLs access control and not open for supporting a
Web Authorization Framework like OAuth
* Side note on the Policy enforcement point, there solutions like
https://github.com/trusted-remote-execution/trusted-remote-execution
* Section 3.2.1: You are right but there is progress in the right direction
with ID JAG (see
https://datatracker.ietf.org/doc/draft-ietf-oauth-identity-assertion-authz-grant/)
and Transaction Token Authorization Grant Profile for OAuth Identity and
Authorization
Chaining<https://datatracker.ietf.org/doc/draft-fletcher-transaction-token-chaining-profile/>.
* Section 3.2.2: I might not sure how you are making it different from
3.2.1. You forget that each agent from the group can work unitarily from the
coordinator scoped Token they are called with from which they can Token
Exchange, ID-JAG and cross domain accordingly. What can they exchange to? that
is a policy enforcement at the AS and outside of the scope of OAuth.
* Section 3.2.3: you make it sound like it should its own peculiar beast…
And that is what causes the problem. by doing so you are calling out for custom
solutions. This use case is not different from 3.2.1 and 3.2.2 IMO.
* Section 3.2.4: As noted you miss Transaction Token Authorization Grant
Profile for OAuth Identity and Authorization
Chaining<https://datatracker.ietf.org/doc/draft-fletcher-transaction-token-chaining-profile/>.
* Section 3.3.1: Security Agents are not existing out of vacuum. They are
configured by SecOps therefore they have owners they can act on behalf of. Also
they are rarely one agent but a chain of agents to have of custody and clear
bounding in the actions authorized to be taken. At AWS we do since at least
2010 through RPA and AI did not change the authorization model. In a nutshell
this is not different again from 3.2.1 and 3.2.2
My Canadian 2 cents
Jeff
Jean-François “Jeff” Lombardo | Amazon Web Services
Architecte Principal de Solutions, Stratégie de Sécurité
Principal Solution Architect, Security Strategy
Montréal, Canada
Commentaires à propos de notre échange? Exprimez-vous
ici<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>.
Thoughts on our interaction? Provide feedback
here<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>.
From: [email protected] <[email protected]>
Sent: July 6, 2026 12:26 AM
To: oauth <[email protected]>
Subject: [EXT] [OAUTH-WG] Re: New Version Notification for
draft-chen-oauth-agent-authz-use-cases-01.txt
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you can confirm the sender and know the
content is safe.
AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne
cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas
confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le
contenu ne présente aucun risque.
Hi all,
We are writing to introduce a new Internet-Draft, "Agent Authorization Use
Cases and Gap Analysis," which we believe is highly relevant to the future work
of Oauth.
HTMLized:
https://datatracker.ietf.org/doc/html/draft-chen-oauth-agent-authz-use-cases
https://github.com/Maisy-ML/Agent-Authorization-Use-Cases
This draft's primary goal is not to propose a solution, but rather to clearly
define the problem space. It provides a systematic analysis of emerging
agent-based use cases, categorizing them into distinct scenarios (from simple
assistants to complex agent swarms).
For each use case, the draft details the specific authorization requirements
and then performs a comprehensive gap analysis against the existing OAuth 2.0
framework and its common extensions. It aims to answer the question: "Where do
current standards fall short when faced with the demands of AI agents?"
Key gaps identified include challenges related to:
* Handling long-lived, offline, and autonomous tasks.
* Representing and securing complex, multi-step delegation chains.
* Enabling contextual and interactive user consent during a task.
* Providing fine-grained, task-level authorization and revocation.
* Managing authorization for groups or "swarms" of agents.
We hope this document can serve as a foundational piece to spark a focused
discussion within the working group.
Feedback, comments, critiques, and suggestions are invaluable. We believe this
is a crucial conversation for the future of authorization, and we look forward
to discussing it with you on this mailing list.
Best,
Meiling
________________________________
[email protected]<mailto:[email protected]>
From: internet-drafts<mailto:[email protected]>
Date: 2026-07-06 00:20
To: Chunchi Peter Liu<mailto:[email protected]>; Jia
Chen<mailto:[email protected]>; Jiankang Yao<mailto:[email protected]>;
Meiling Chen<mailto:[email protected]>; Peter
Liu<mailto:[email protected]>; Yuning
Jiang<mailto:[email protected]>
Subject: New Version Notification for
draft-chen-oauth-agent-authz-use-cases-01.txt
A new version of Internet-Draft draft-chen-oauth-agent-authz-use-cases-01.txt
has been successfully submitted by Meiling Chen and posted to the
IETF repository.
Name: draft-chen-oauth-agent-authz-use-cases
Revision: 01
Title: Agent Authorization use cases and gap analysis
Date: 2026-07-05
Group: Individual Submission
Pages: 20
URL:
https://www.ietf.org/archive/id/draft-chen-oauth-agent-authz-use-cases-01.txt
Status:
https://datatracker.ietf.org/doc/draft-chen-oauth-agent-authz-use-cases/
HTML:
https://www.ietf.org/archive/id/draft-chen-oauth-agent-authz-use-cases-01.html
HTMLized:
https://datatracker.ietf.org/doc/html/draft-chen-oauth-agent-authz-use-cases
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-chen-oauth-agent-authz-use-cases-01
Abstract:
This document provides a systematic analysis of these emerging agent-
based use cases. It categorizes them into distinct scenarios,
details their specific authorization requirements, and performs a
comprehensive gap analysis against the existing OAuth 2.0 framework
[RFC6749] and its common extensions. The analysis identifies
fundamental mismatches, the goal of this document is to articulate
these gaps clearly, providing a foundation for future work on new
extensions within the OAuth Working Group to address the
authorization needs of the next generation of ai agents.
The IETF Secretariat
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
