Date: Thu, 16 Jul 2026 05:14:49 +0000
To: oauth <oauth@ietf.org>
From: Blake <blake@truealter.com>
Message-ID: 
 <qKxC6Uj-5GJVJdb76e3zWpzPzN7pq4fE3Bm7SVyar8oU20vLNdf9UQ2eK9MtPCjZnc3_VP2C9Cjs3qZzienzFJCC1dRZzSHBdnDHtUC-kKc=@truealter.com>
In-Reply-To: <202607152116331707952@chinamobile.com>
References: 
 <178326844691.267540.6806897697824010077@dt-datatracker-57b5d8f849-zrqfx>
 <202607061225540639426@chinamobile.com>
 <CO1PR18MB46849517689A4D7EB14AAA7CD9FA2@CO1PR18MB4684.namprd18.prod.outlook.com>
 <202607132157242002541@chinamobile.com>
 <49E4C072-13E0-4A56-B6BA-2D1DF70F0C0C@yuthent.com>
 <202607151957484157299@chinamobile.com>
 <56ADA8DA-10DA-4899-A4B4-3907B5682808@yuthent.com>
 <202607152116331707952@chinamobile.com>
Feedback-ID: 187617253:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: 3A547FOFLIROOGBJWVQNK5PKG3G7HDK4
CC: "chenmeiling@chinamobile.com" <chenmeiling@chinamobile.com>,
 Mohamad Khalil Yossif <mohamad@yuthent.com>
Precedence: list
Subject: =?utf-8?q?=5BOAUTH-WG=5D_Re=3A_New_Version_Notification_for_draft-chen-oauth?=
	=?utf-8?q?-agent-authz-use-cases-01=2Etxt?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/oauth/uyQtBLjuatxxRLxmfzSifqbVp8c>

Meiling,

Before Yossif drafts #10, one thing to settle. The boundary is titled
grant versus execution, and both index on the party who acts. The Data
Subject I raised on the 12th and 14th is neither. Their authority is issued
ahead of the session, by someone who never acts in it, so there's no grant
of theirs to describe and no execution moment to bind to. A two-layer split
writes them out.

The fix is one line. Make the axis when the evidence is produced relative t=
o
the action, not which layer of the acting party's authority it describes.
That keeps a data-subject record and an execution-time proof on the one
axis, and it's cheaper to set before #10 than after. If Yossif would rather
take it in the text, I'll post the class there.

Best,
Blake


On Wednesday, 15 July 2026 at 11:17 PM, chenmeiling@chinamobile.com <chenme=
iling@chinamobile.com> wrote:

> Yossif,
>=20
> Thank you for the quick reply and for your willingness to contribute dire=
ctly to the draft.
>=20
> We really appreciate you taking the lead on issues #10, #11, and #12. Hav=
ing your expertise to flesh out the substantive text for the grant-layer vs=
. execution-layer boundary, and ensuring the requirements and use cases ali=
gn cleanly with it, will be incredibly valuable for the next revision.
>=20
> While you are working on those, our author team will focus our efforts on=
 issues #8 and #9.
>=20
> We will keep an eye on the GitHub tracker for your updates over the next =
day or so.
>=20
> Best,
>=20
> Meiling
>=20
> chenmeiling@chinamobile.com
>=20
> > > From:=C2=A0Mohamad Khalil Yossif
> > > Date:=C2=A02026-07-15=C2=A020:21
> > > To:=C2=A0chenmeiling
> > > CC:=C2=A0jeffsec; oauth
> > > Subject:=C2=A0Re: [OAUTH-WG] New Version Notification for draft-chen-=
oauth-agent-authz-use-cases-01.txt
> > > Meiling, Jeff,
> > >=20
> > > Thanks for opening the five issues so quickly. The split between
> > > the OAuth-extensions evaluation (#8, #9) and the execution-layer
> > > framing (#10=E2=80=93#12) looks right, and matches where the review l=
ens
> > > sits differently in each area.
> > >=20
> > > I'll take issues #10, #11, and #12 in the tracker =E2=80=94 the
> > > distinction, the requirements, and the alignment to specific use
> > > cases =E2=80=94 and post substantive text in each within the next day=
. The
> > > grant-layer / execution-layer framing you captured in #10 reads
> > > correct as an architectural boundary; I want to make sure the
> > > requirement list under #11 and the use-case pointers under #12
> > > line up cleanly with it.
> > >=20
> > > Best,
> > > Mohamad Khalil Yossif
> > > Author, draft-yossif-psea
> > >=20
> > >=20
> > > > On 15 Jul 2026, at 14:57, chenmeiling@chinamobile.com wrote:
> > > >=20
> > > >=20
> > > > Hi Yossif, Jeff
> > > >=20
> > > > First of all, thank you both for taking the time to review the draf=
t and for providing constructive feedback.
> > > >=20
> > > > @Jeff, your point about ensuring we properly evaluate existing OAut=
h 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 o=
ur specific agent use cases. As a side note, we previously authored a docum=
ent that comprehensively surveyed existing OAuth RFCs and ongoing WG effort=
s(https://datatracker.ietf.org/doc/draft-chen-oauth-roadmap/), feel free to=
 provide any additional information regarding the possible omissions. Our f=
undamental goal aligns perfectly with yours: we want to clearly identify wh=
ich existing OAuth "building blocks" can be reused directly out-of-the-box.=
 Inventing a brand new protocol is absolutely not our objective; we only wa=
nt to standardize what is genuinely missing.
> > > >=20
> > > > @Yossif, your framing of the distinction between "Grant Layer Autho=
rity" and "Execution Layer Evidence" perfectly captures the core architectu=
ral gap we were trying to articulate. This paradigm shift is exactly what t=
he draft needs to clarify why existing grant-layer tools, while necessary, =
are not sufficient for high-risk autonomous agent actions.
> > > >=20
> > > > To ensure we address your concerns systematically in the upcoming `=
-02` version, we have translated your feedback into actionable GitHub issue=
s. We want to make sure we haven't missed anything critical.
> > > >=20
> > > > Could you please take a quick look at the following issues and let =
us know if they accurately capture your concerns?
> > > >=20
> > > > -   Issue=C2=A0#8:=C2=A0Clarify the architectural boundary between =
OAuth and Agent Frameworks (LLM/Intent)
> > > > -   Issue #9:=C2=A0Acknowledge and analyze existing OAuth extension=
s (RAR, DPoP, etc.) in the Gap Analysis
> > > > -   Issue #10:=C2=A0Introduce the architectural distinction between=
 "Grant Layer Authority" and "Execution Layer Evidence"
> > > > -   Issue #11:=C2=A0Define 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
> > > >=20
> > > > https://github.com/Maisy-ML/Agent-Authorization-Use-Cases/issues
> > > >=20
> > > > @Co-authors: Please review the action items detailed within these i=
ssues on GitHub. Let me know if you agree with the proposed direction and t=
he specific next steps for updating the draft.
> > > >=20
> > > > Best,
> > > > Meiling
> > > >=20
> > > > chenmeiling@chinamobile.com
> > > >=20
> > > > > From:=C2=A0Mohamad Khalil Yossif
> > > > > Date:=C2=A02026-07-13=C2=A022:37
> > > > > To:=C2=A0chenmeiling
> > > > > CC:=C2=A0jeffsec;=C2=A0oauth
> > > > > Subject:=C2=A0Re: [OAUTH-WG] New Version Notification for draft-c=
hen-oauth-agent-authz-use-cases-01.txt
> > > > > Jeff,
> > > > >=20
> > > > > Thanks for taking the time to lay this out =E2=80=94 the referenc=
e set
> > > > > here is genuinely useful, and worth engaging with before -02.
> > > > >=20
> > > > > 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.
> > > > >=20
> > > > > 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.
> > > > >=20
> > > > > 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.
> > > > >=20
> > > > > At requirements level, execution-time evidence for high-risk
> > > > > agent actions needs to satisfy:
> > > > >=20
> > > > > - Produced at the moment of action execution, bound to the exact
> > > > > =C2=A0 parameters rendered to the human.
> > > > > - Signed by key material the agent runtime cannot reach.
> > > > > - Session-independent =E2=80=94 verifiable whether the session th=
at
> > > > > =C2=A0 carried the action is active, expired, or absent.
> > > > > - Offline third-party verifiable, with non-repudiation over time.
> > > > >=20
> > > > > 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.
> > > > >=20
> > > > > The draft's use cases point at this layer implicitly. Making the
> > > > > requirement explicit =E2=80=94 that certain agent actions need
> > > > > execution-time evidence, not just authority =E2=80=94 clarifies w=
hy the
> > > > > grant-layer solutions you list are necessary but not sufficient
> > > > > for the full problem the draft is trying to describe.
> > > > >=20
> > > > > =E2=80=94 Mohamad Khalil Yossif
> > > > > Author, draft-yossif-psea
> > > > >=20
> > > > >=20
> > > > > > On 13 Jul 2026, at 16:57, chenmeiling@chinamobile.com wrote:
> > > > > >=20
> > > > > > Hi Jeff,
> > > > > >=20
> > > > > >=20
> > > > > > Thank you very much for taking the time to provide such detaile=
d and professional feedback on our draft, `draft-chen-oauth-agent-authz-use=
-cases-01`.
> > > > > >=20
> > > > > > Your comments are incredibly helpful, and we particularly appre=
ciate you pointing out the various existing RFCs and other ongoing drafts t=
hat are relevant to our use cases. This context is crucial for us to accura=
tely position our work and refine our analysis.
> > > > > >=20
> > > > > > Given the number of references and the depth of your analysis, =
we will need some time to carefully review all the documents you've mention=
ed and digest the information thoroughly. We plan to formulate a more detai=
led response and discuss our next steps for the draft in the coming days.
> > > > > >=20
> > > > > > Thank you again for your valuable contribution.
> > > > > >=20
> > > > > > Best,
> > > > > > Meiling
> > > > > >=20
> > > > > > chenmeiling@chinamobile.com
> > > > > >=20
> > > > > > > From:=C2=A0Lombardo, Jeff
> > > > > > > Date:=C2=A02026-07-13=C2=A018:50
> > > > > > > To:=C2=A0chenmeiling@chinamobile.com
> > > > > > > CC:=C2=A0oauth;=C2=A0Lombardo, Jeff
> > > > > > > Subject:=C2=A0RE: [OAUTH-WG] Re: New Version Notification for=
 draft-chen-oauth-agent-authz-use-cases-01.txt
> > > > > > > Hi,
> > > > > > >=20
> > > > > > > Thanks for your Draft.
> > > > > > >=20
> > > > > > > Here are some comments on the elements listed as Gaps:
> > > > > > >=20
> > > > > > > -   Section 3.1.1:
> > > > > > >=20
> > > > > > > -   You identify that OAuth is not capable of understand an i=
ntent. True but is it the purpose of OAuth? The Agent will rely on the LLM =
=C2=A0to understand how the task need to be decomposed based on the tools a=
nd other agents available. At the end, this is for the Tools and Agents all=
owing to fulfill the task that the Agent will need to acquire consented del=
egation of Authorization. MCP Servers and Agent Card can contain informatio=
n about the AS to contact and the scopes and potentially RAR authorization =
details (RFC9396) required to call them thanks to OAuth2.0 Protected Resour=
ce Metadata (RFC9728)
> > > > > > > -   You indicate that there is no=C2=A0No Standardized Intera=
ctive Flow.=C2=A0=C2=A0But again is this even an OAuth problem? If the Agen=
t needs more information from the User / Resource Owner, Agentic AI Develop=
ment Frameworks like CrewAI, LangChain, LangGraph, Strands and other have a=
ll the capabilities to do such things through their converse API. Additiona=
l Information provided by the User / Resource Owner will allow, thanks agai=
n 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 acqu=
ired as explained in the previous point.
> > > > > > > -   Impractical Revocation.=C2=A0There 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=C2=A0https:/=
/datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/=C2=A0=C2=
=A0and=C2=A0https://datatracker.ietf.org/doc/html/draft-oauth-transaction-t=
okens-for-agents=C2=A0)bound to a specific task / intent =C2=A0(in this cas=
e a picnic event)
> > > > > > >=20
> > > > > > > -   Section 3.1.2 is frivolous. It does not include any menti=
on of usage of AI. This is the old Smart Home Automation use case we know f=
or years and has very successful deployment at the Enterprise and Open Sour=
ce level: see Apple, Google, Home Assistant, Ring, etc.
> > > > > > >=20
> > > > > > > -   "Scope Explosion" and Usability=C2=A0:=C2=A0Again you for=
got about the ability to use RAR authorization details (RFC9396) as a way t=
o express Token Boundaries in Token but more importantly when in single Tru=
st Domain, most of those scoping are stored in backend Policy Decision Poin=
t=E2=80=99s policy stores and only referenced in Tokens.
> > > > > > > -   No Standardized Policy Enforcement:Again this is a big mi=
sconception. OAuth is perfectly capable of handling claims that are JSON St=
ructure that could host such information as =E2=80=9CAt 7 AM=E2=80=9D or =
=E2=80=9Cin between 6AM and 8 AM=E2=80=9D. But at the end of the the policy=
 enforcement is done by the Resource Server after receiving all the informa=
tion from the token, retrieving other information from other Policy Informa=
tion Point and submitting the Authorization Request to the Policy Decision =
Point. None of those actions are in the scope of OAuth which always set tho=
se as explicitly =E2=80=98out of scope=E2=80=9D in any OAuth RFC. If you ar=
e looking for standards, you should look at OpenID Foundation AuthZEN (seeh=
ttps://openid.net/wg/authzen/)
> > > > > > > -   No Standardized Bulk Revocation:=C2=A0I agree that there =
is no standardized Global Sign Out.
> > > > > > >=20
> > > > > > > -   Section 3.1.3 does not encompass the latest and greatest =
of OAuth
> > > > > > >=20
> > > > > > > -   If tokens are cryptographically bound to a client key, th=
ey cannot be shared and reused by AI Agent as they don=E2=80=99t have acces=
s to the key. See DPoP (RFC9449)
> > > > > > > -   Therefore the AI Agent needs to possess their own Client =
identifier and that is where Draft like CIMD are useful as the document the=
y exposes can establish the Agentic nature of the client (see=C2=A0https://=
datatracker.ietf.org/doc/draft-ietf-oauth-client-id-metadata-document/)
> > > > > > > -   Also we start to see a movement for Agent Registration ah=
ead of time. That is what WebBotAuth WG came to -https://datatracker.ietf.o=
rg/wg/webbotauth/about/
> > > > > > > -   Finally we a lot of Workload Identity Federation support =
among=C2=A0OpenAI,=C2=A0Anthropic, and=C2=A0Snowflake
> > > > > > >=20
> > > > > > > -   Section 3.1.4 is a real problem but globally =C2=A0even M=
CP decide to standardize around STDIO and not RPC JSON for local access. Al=
l Operating Systems are still locked on ACLs access control and not open fo=
r supporting a Web Authorization Framework like OAuth
> > > > > > >=20
> > > > > > > -   Side note on the Policy enforcement point, there solution=
s like=C2=A0https://github.com/trusted-remote-execution/trusted-remote-exec=
ution
> > > > > > >=20
> > > > > > > -   Section 3.2.1: You are right but there is progress in the=
 right direction with ID JAG (seehttps://datatracker.ietf.org/doc/draft-iet=
f-oauth-identity-assertion-authz-grant/) and=C2=A0Transaction Token Authori=
zation Grant Profile for OAuth Identity and Authorization Chaining.
> > > > > > > -   Section 3.2.2: I might not sure how you are making it dif=
ferent from 3.2.1. You forget that each agent from the group can work unita=
rily from the coordinator scoped Token they are called with from which they=
 can Token Exchange, ID-JAG and cross domain accordingly. What can they exc=
hange to? that is a policy enforcement at the AS and outside of the scope o=
f OAuth.
> > > > > > > -   Section 3.2.3: you make it sound like it should its own p=
eculiar beast=E2=80=A6 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=C2=A0Transaction Token A=
uthorization Grant Profile for OAuth Identity and Authorization Chaining.
> > > > > > > -   Section 3.3.1: Security Agents are not existing out of va=
cuum. 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 AW=
S we do since at least 2010 through RPA and AI did not change the authoriza=
tion model. In a nutshell this is not different again from 3.2.1 and 3.2.2
> > > > > > >    =20
> > > > > > >=20
> > > > > > > My Canadian 2 cents
> > > > > > >=20
> > > > > > > Jeff
> > > > > > >=20
> > > > > > > Jean-Fran=C3=A7ois =E2=80=9CJeff=E2=80=9D Lombardo=C2=A0|=
=C2=A0Amazon Web Services
> > > > > > >=20
> > > > > > > Architecte Principal de Solutions, Strat=C3=A9gie de S=C3=
=A9curit=C3=A9
> > > > > > > Principal Solution Architect, Security Strategy
> > > > > > > Montr=C3=A9al, Canada
> > > > > > >=20
> > > > > > > Commentaires =C3=A0 propos de notre =C3=A9change?=C2=A0Exprim=
ez-vous=C2=A0ici.
> > > > > > >=20
> > > > > > > Thoughts on our interaction? Provide feedback=C2=A0here.
> > > > > > >=20
> > > > > > > From:=C2=A0chenmeiling@chinamobile.com<chenmeiling@chinamobil=
e.com>
> > > > > > > Sent:=C2=A0July 6, 2026 12:26 AM
> > > > > > > To:=C2=A0oauth <oauth@ietf.org>
> > > > > > > Subject:=C2=A0[EXT] [OAUTH-WG] Re: New Version Notification f=
or draft-chen-oauth-agent-authz-use-cases-01.txt
> > > > > > >=20
> > > > > > > CAUTION: This email originated from outside of the organizati=
on. Do not click links or open attachments unless you can confirm the sende=
r and know the content is safe.
> > > > > > >=20
> > > > > > > AVERTISSEMENT: Ce courrier =C3=A9lectronique provient d=
=E2=80=99un exp=C3=A9diteur externe. Ne cliquez sur aucun lien et n=
=E2=80=99ouvrez aucune pi=C3=A8ce jointe si vous ne pouvez pas confirmer l=
=E2=80=99identit=C3=A9 de l=E2=80=99exp=C3=A9diteur et si vous n=E2=80=
=99=C3=AAtes pas certain que le contenu ne pr=C3=A9sente aucun risque.
> > > > > > >=20
> > > > > > > Hi all,
> > > > > > >=20
> > > > > > > We are writing to introduce a new Internet-Draft, "Agent Auth=
orization Use Cases and Gap Analysis," which we believe is highly relevant =
to the future work of Oauth.
> > > > > > >=20
> > > > > > > HTMLized: https://datatracker.ietf.org/doc/html/draft-chen-oa=
uth-agent-authz-use-cases=C2=A0
> > > > > > >=20
> > > > > > > https://github.com/Maisy-ML/Agent-Authorization-Use-Cases=
=C2=A0
> > > > > > >=20
> > > > > > > This draft's primary goal is not to propose a solution, but r=
ather to clearly define the problem space. It provides a systematic analysi=
s of emerging agent-based use cases, categorizing them into distinct scenar=
ios (from simple assistants to complex agent swarms).
> > > > > > >=20
> > > > > > > For each use case, the draft details the specific authorizati=
on requirements and then performs a comprehensive gap analysis against the =
existing OAuth 2.0 framework and its common extensions. It aims to answer t=
he question: "Where do current standards fall short when faced with the dem=
ands of AI agents?"
> > > > > > >=20
> > > > > > > Key gaps identified include challenges related to:
> > > > > > >=20
> > > > > > > -   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 revo=
cation.
> > > > > > > -   Managing authorization for groups or "swarms" of agents.
> > > > > > >=20
> > > > > > > We hope this document can serve as a foundational piece to sp=
ark a focused discussion within the working group.
> > > > > > >=20
> > > > > > > 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.
> > > > > > >=20
> > > > > > > Best,
> > > > > > >=20
> > > > > > > Meiling
> > > > > > >=20
> > > > > > > chenmeiling@chinamobile.com
> > > > > > >=20
> > > > > > > > From:=C2=A0internet-drafts
> > > > > > > > Date:=C2=A02026-07-06=C2=A000:20
> > > > > > > > To:=C2=A0Chunchi Peter Liu;=C2=A0Jia Chen;=C2=A0Jiankang Ya=
o;=C2=A0Meiling Chen;=C2=A0Peter Liu;=C2=A0Yuning Jiang
> > > > > > > > Subject:=C2=A0New Version Notification for draft-chen-oauth=
-agent-authz-use-cases-01.txt
> > > > > > > > A new version of Internet-Draft draft-chen-oauth-agent-auth=
z-use-cases-01.txt
> > > > > > > > has been successfully submitted by Meiling Chen and posted =
to the
> > > > > > > > IETF repository.
> > > > > > > >=20
> > > > > > > > Name:=C2=A0=C2=A0=C2=A0=C2=A0 draft-chen-oauth-agent-authz-=
use-cases
> > > > > > > > Revision: 01
> > > > > > > > Title:=C2=A0=C2=A0=C2=A0 Agent Authorization use cases and =
gap analysis
> > > > > > > > Date:=C2=A0=C2=A0=C2=A0=C2=A0 2026-07-05
> > > > > > > > Group:=C2=A0=C2=A0=C2=A0 Individual Submission
> > > > > > > > Pages:=C2=A0=C2=A0=C2=A0 20
> > > > > > > > URL:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.or=
g/archive/id/draft-chen-oauth-agent-authz-use-cases-01.txt
> > > > > > > > Status:=C2=A0=C2=A0=C2=A0https://datatracker.ietf.org/doc/d=
raft-chen-oauth-agent-authz-use-cases/
> > > > > > > > HTML:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/arc=
hive/id/draft-chen-oauth-agent-authz-use-cases-01.html
> > > > > > > > HTMLized:=C2=A0https://datatracker.ietf.org/doc/html/draft-=
chen-oauth-agent-authz-use-cases
> > > > > > > > Diff:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://author-tools.iet=
f.org/iddiff?url2=3Ddraft-chen-oauth-agent-authz-use-cases-01
> > > > > > > >=20
> > > > > > > > Abstract:
> > > > > > > >=20
> > > > > > > > =C2=A0=C2=A0 This document provides a systematic analysis o=
f these emerging agent-
> > > > > > > > =C2=A0=C2=A0 based use cases.=C2=A0 It categorizes them int=
o distinct scenarios,
> > > > > > > > =C2=A0=C2=A0 details their specific authorization requireme=
nts, and performs a
> > > > > > > > =C2=A0=C2=A0 comprehensive gap analysis against the existin=
g OAuth 2.0 framework
> > > > > > > > =C2=A0=C2=A0 [RFC6749] and its common extensions.=C2=A0 The=
 analysis identifies
> > > > > > > > =C2=A0=C2=A0 fundamental mismatches, the goal of this docum=
ent is to articulate
> > > > > > > > =C2=A0=C2=A0 these gaps clearly, providing a foundation for=
 future work on new
> > > > > > > > =C2=A0=C2=A0 extensions within the OAuth Working Group to a=
ddress the
> > > > > > > > =C2=A0=C2=A0 authorization needs of the next generation of =
ai agents.
> > > > > > > >=20
> > > > > > > > The IETF Secretariat
> > > > > >=20
> > > > > > _______________________________________________
> > > > > > OAuth mailing list --=C2=A0oauth@ietf.org
> > > > > > To unsubscribe send an email to=C2=A0oauth-leave@ietf.org