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

[Mohamad Khalil Yossif <[e-mail]>]

Meiling,


Thank you for the updates on #7, #8 and #9. The rewrite of 3.1.1 is
the right cut. Temporal decoupling and context collapse describe the
problem better than intent parsing did, and separating the detection
gap from the binding gap in Use Case 3 is worth the extra section.

One item still open from my side: issue #15, Intent Confirmation for
Critical Actions. I posted the three Next Actions there on 29 July -
the mapping to existing use cases, the requirements the scenario
adds, and the gap analysis. No comment on it since.

I do not need it adopted as written. What would help is knowing
whether you want it as a new use case, as an extension to an existing
one, or as a requirements class. Tell me which and I will open a PR
with the text in that shape, the same way Morgan is doing.

One substantive point from that issue, since it may bear on the
restructure you are doing anyway.

The scenario is an agent with a valid, unexpired, unrevoked grant
booking a non-refundable ticket. Nothing in the grant is violated.
That is not a detection gap and it is not a confused deputy either -
there is no second principal. It is the case where authorization was
correctly held and the specific action was never approved by anyone.

If Use Case 3 is being split into detection and binding, this is a
third shape and it may deserve its own place rather than being folded
into either.

Mohamad Khalil-Yossif


> On 11 Aug 2026, at 5:41, [e-mail] wrote:
> 
> Hi Jeff, Dick and Yossif,
> Returning to this thread is to remind you that I have already solved four out of the five problems.
> Issue #8: Clarify the architectural boundary between OAuth and Agent Frameworks (LLM/Intent) <https://github.com/Maisy-ML/Agent-Authorization-Use-Cases/issues/8>
> The core issue isn't that OAuth should parse user intent, but rather that the traditional OAuth flow struggles with the temporal decoupling and context collapse inherent in agentic workflows. The user's original intent, which provides the context for an authorization request, is often lost by the time the agent seeks consent hours or days later.
> 
> Based on this, I've completely rewritten Section 3.1.1 (Use Case 1: Personal Digital Assistant) to reflect this more precise problem statement. The updated version now focuses on the gap in carrying authorization context through the flow and the need for more dynamic, interactive consent mechanisms, rather than implying OAuth needs to handle intent parsing.
> 
> Issue #9: Acknowledge and analyze existing OAuth extensions (RAR, DPoP, etc.) in the Gap Analysis
> Added a new section: Analysis of Existing OAuth Extensions, include RAR, DPoP, CIMD, Transaction Token
> https://github.com/Maisy-ML/Agent-Authorization-Use-Cases/blob/main/draft-chen-oauth-agent-authz-use-cases-00.md 
> 
> Issue #11: Define strict requirements for "Execution-Time Evidence" in high-risk Agent actions
> Added in the summury of major gaps as gap 6.
> Verifiable Proof of Action for High-Risk Operations**: The framework provides robust mechanisms to verify the validity of an authorization grant (the permission to act), but lacks a standard for creating a durable, non-repudiable, and independently verifiable proof of the user's consent to the specific parameters of a high-risk action at the moment of execution.
> 
> Issue #12:Refine Use Case descriptions to explicitly highlight the need for Execution Evidence
> [1 ] -Updated Use Case: Personal Digital Assistant
> No Execution-Layer Evidence: At the moment of financial commitment (the final "Book" step), a simple access token is insufficient. The core requirement is for non-repudiable, execution-time evidence that binds the user's explicit consent to the specific, critical parameters of the transaction (e.g., "Book picnic spot at 'Sunnyvale Park', cost $25"). This evidence serves as proof of the human's decision at the moment of execution, not just proof that the agent possessed a scoped token. It must be durable and verifiable for dispute resolution, proving what the user agreed to, not just that the agent had permission to book something.
> [ 2] -Updated Use Case : Automated Security Incident Response
> Absence of a Standard for Verifiable Action Records: The OAuth framework focuses on granting and validating the authority to perform an action (i.e., possessing a valid token). It does not, however, define a standard mechanism for creating a durable, cryptographically verifiable record of the action itself at the moment of execution. In a security context, a simple log entry stating "action performed" is insufficient for high-stakes forensic analysis. What is missing is a formal, non-repudiable piece of evidence that binds the agent's identity, the specific action taken (e.g., "isolate host laptop-789"), the policy justification, and the timestamp into a single, verifiable artifact. This gap makes it difficult to construct an undeniable audit trail for automated, high-risk security operations.
> 
> [ 3] -Updated Use Case: Complex BusinessProcess Automation
> Execution Evidence for Final Action: The final payment action by Agent D must not only be authorized by the delegation chain (grant-layer authority) but must also generate verifiable execution evidence. This evidence should bind the specific payment details (amount, recipient) to the full, verifiable delegation chain and the original claim_id, creating an undeniable record of the transaction's legitimacy.
> 
> [4 ] -Updated Summary of Major Gaps
> Added a new Gap:
>         Verifiable Proof of Action for High-Risk Operations: The framework provides robust mechanisms to verify an agent's authority to act (the grant-layer), but lacks a standard for creating evidence of the action itself (the execution-layer). This gap is critical for high-risk operations, where a durable, non-repudiable proof of consent to specific parameters at the moment of execution is required for auditability and dispute resolution.
> 
> Best,
> Meiling
> [e-mail] <mailto:[e-mail]>
>  
> From: [e-mail] <mailto:[e-mail]>
> Date: 2026-07-15 19:57
> To: Mohamad Khalil Yossif <mailto:[e-mail]>; jeffsec <mailto:[e-mail]>
> CC: oauth <mailto:[e-mail]>
> Subject: [OAUTH-WG] Re: New Version Notification for draft-chen-oauth-agent-authz-use-cases-01.txt
> Hi Yossif, Jeff
> First of all, thank you both for taking the time to review the draft and for providing constructive feedback. 
> @Jeff, your point about ensuring we properly evaluate existing OAuth extensions (RAR, DPoP, Transaction Tokens, etc.) is well taken. We agree that the gap analysis must explicitly address these mechanisms to be robust. To build on that, we want to be very precise about the functional gaps of RAR, DPoP, and Transaction Tokens when they are actually executed within our specific agent use cases. As a side note, we previously authored a document that comprehensively surveyed existing OAuth RFCs and ongoing WG efforts(https://datatracker.ietf.org/doc/draft-chen-oauth-roadmap/), feel free to provide any additional information regarding the possible omissions. Our fundamental goal aligns perfectly with yours: we want to clearly identify which existing OAuth "building blocks" can be reused directly out-of-the-box. Inventing a brand new protocol is absolutely not our objective; we only want to standardize what is genuinely missing.
> @Yossif, your framing of the distinction between "Grant Layer Authority" and "Execution Layer Evidence" perfectly captures the core architectural gap we were trying to articulate. This paradigm shift is exactly what the draft needs to clarify why existing grant-layer tools, while necessary, are not sufficient for high-risk autonomous agent actions.
> To ensure we address your concerns systematically in the upcoming -02 version, we have translated your feedback into actionable GitHub issues. We want to make sure we haven't missed anything critical.
> Could you please take a quick look at the following issues and let us know if they accurately capture your concerns?
> Issue #8: Clarify the architectural boundary between OAuth and Agent Frameworks (LLM/Intent) <https://github.com/Maisy-ML/Agent-Authorization-Use-Cases/issues/8>
> Issue #9: Acknowledge and analyze existing OAuth extensions (RAR, DPoP, etc.) in the Gap Analysis
> Issue #10: Introduce the architectural distinction between "Grant Layer Authority" and "Execution Layer Evidence"
> Issue #11: Define strict requirements for "Execution-Time Evidence" in high-risk Agent actions
> Issue #12:Refine Use Case descriptions to explicitly highlight the need for Execution Evidence
> https://github.com/Maisy-ML/Agent-Authorization-Use-Cases/issues
> @Co-authors: Please review the action items detailed within these issues on GitHub. Let me know if you agree with the proposed direction and the specific next steps for updating the draft.
> Best,
> Meiling
> [e-mail]
>  
> From: Mohamad Khalil Yossif <mailto:[e-mail]>
> Date: 2026-07-13 22:37
> To: chenmeiling <mailto:[e-mail]>
> CC: jeffsec <mailto:[e-mail]>; oauth <mailto:[e-mail]>
> Subject: Re: [OAUTH-WG] New Version Notification for draft-chen-oauth-agent-authz-use-cases-01.txt
> Jeff,
> 
> Thanks for taking the time to lay this out — the reference set
> here is genuinely useful, and worth engaging with before -02.
> 
> One observation on the common structure: every mechanism you cite
> operates at the authorization grant layer. RAR structures the
> scope inside the grant. DPoP binds the grant to a client key.
> Transaction Tokens narrow lifetime and bind to a task. CIMD
> establishes client identity. ID-JAG chains grants across
> identity domains. AuthZEN organizes the resource-server side of
> policy enforcement. Each of these describes properties of the
> authority state that exists at the time authorization is
> granted.
> 
> The gap the draft is trying to name sits one layer below that:
> what evidence exists at the moment a specific high-risk action
> executes, that a human authorized this action in particular,
> verifiable after the fact independent of the grant that carried
> it.
> 
> Grant-layer mechanisms cannot express this evidence because they
> describe the authority, not the decision. A short-lived
> Transaction Token proves scope was granted for a task; it does
> not carry a cryptographic record that the human approved the
> specific parameters of the action being executed under it. DPoP
> proves the client that presented the token holds the key; it does
> not prove a human decided.
> 
> At requirements level, execution-time evidence for high-risk
> agent actions needs to satisfy:
> 
> - Produced at the moment of action execution, bound to the exact
>   parameters rendered to the human.
> - Signed by key material the agent runtime cannot reach.
> - Session-independent — verifiable whether the session that
>   carried the action is active, expired, or absent.
> - Offline third-party verifiable, with non-repudiation over time.
> 
> These are the properties a plain grant-layer mechanism, however
> well-scoped, cannot provide on its own. This is the space
> draft-yossif-psea (https://datatracker.ietf.org/doc/draft-yossif-psea/)
> formulates as a profile, and the space the joint survey
> "Authorization Evidence for High-Risk Actions," posted to
> secdispatch on 2026-06-12, surveys across independent projects.
> 
> The draft's use cases point at this layer implicitly. Making the
> requirement explicit — that certain agent actions need
> execution-time evidence, not just authority — clarifies why the
> grant-layer solutions you list are necessary but not sufficient
> for the full problem the draft is trying to describe.
> 
> — Mohamad Khalil Yossif
> Author, draft-yossif-psea
> 
>> On 13 Jul 2026, at 16:57, [e-mail] wrote:
>> 
>> Hi Jeff,
>> 
>> Thank you very much for taking the time to provide such detailed and professional feedback on our draft, draft-chen-oauth-agent-authz-use-cases-01.
>> Your comments are incredibly helpful, and we particularly appreciate you pointing out the various existing RFCs and other ongoing drafts that are relevant to our use cases. This context is crucial for us to accurately position our work and refine our analysis.
>> Given the number of references and the depth of your analysis, we will need some time to carefully review all the documents you've mentioned and digest the information thoroughly. We plan to formulate a more detailed response and discuss our next steps for the draft in the coming days.
>> Thank you again for your valuable contribution.
>> Best,
>> Meiling
>> [e-mail] <mailto:[e-mail]>
>>  
>> From: Lombardo, Jeff <mailto:[e-mail]>
>> Date: 2026-07-13 18:50
>> To: [e-mail] <mailto:[e-mail]>
>> CC: oauth <mailto:[e-mail]>; Lombardo, Jeff <mailto:[e-mail]>
>> Subject: RE: [OAUTH-WG] Re: New Version Notification for draft-chen-oauth-agent-authz-use-cases-01.txt
>> 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 <x-msg://19/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 <x-msg://19/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 (seehttps://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 (seehttps://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: [e-mail] <mailto:[e-mail]><[e-mail] <mailto:[e-mail]>>
>> Sent: July 6, 2026 12:26 AM
>> To: oauth <[e-mail] <mailto:[e-mail]>>
>> 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
>> [e-mail] <mailto:[e-mail]>
>>  
>> From: internet-drafts <mailto:[e-mail]>
>> Date: 2026-07-06 00:20
>> To: Chunchi Peter Liu <mailto:[e-mail]>; Jia Chen <mailto:[e-mail]>; Jiankang Yao <mailto:[e-mail]>; Meiling Chen <mailto:[e-mail]>; Peter Liu <mailto:[e-mail]>; Yuning Jiang <mailto:[e-mail]>
>> 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 -- [e-mail] <mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>