[OAUTH-WG] Re: OAuth Digest, Vol 214, Issue 74

[Sergio Alzate Jiménez <[e-mail]>]

El mar, 11 ago 2026, 9:50 p. m., <[e-mail]> escribió:

> Send OAuth mailing list submissions to
>         [e-mail]
>
> To subscribe or unsubscribe via email, send a message with subject or
> body 'help' to
>         [e-mail]
>
> You can reach the person managing the list at
>         [e-mail]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of OAuth digest..."
>
> Today's Topics:
>
>    1. Re: New Version Notification for
> draft-chen-oauth-agent-authz-use-cases-01.txt
>       (Blake Morrison)
>    2. Fw: New Version Notification for
> draft-chen-oauth-agent-authz-use-cases-02.txt
>       (Meiling Chen)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 12 Aug 2026 01:46:09 +0000
> From: Blake Morrison <[e-mail]>
> Subject: [OAUTH-WG] Re: New Version Notification for
>         draft-chen-oauth-agent-authz-use-cases-01.txt
> To: oauth <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>,
>         Mohamad Khalil Yossif <[e-mail]>, "[e-mail]"
>         <[e-mail]>
> Message-ID: <LtJbldQ4EGXmKab6NkXA2OYOKSZ2aLatKckjW3wDg4mDOaarWVCbyFtBo
>         -2WCGhoHLWKQuuK9nS8P9ebp6o_vvtjHUQ7Q-iUomkOkxVMhzo=@truealter.com>
> Content-Type: text/plain; charset=utf-8
>
> Hi Meiling,
>
> Thanks for landing it, and both edits went in verbatim which is more than I
> expected. The placement is right too - the case I pointed at was Use Case 5
> when I wrote that comment and it's Use Case 6 now.
>
> The gap analysis didn't move with it, so I've opened issue #26 with the
> text, taking the route you offered Morgan yesterday. Your own summary
> section is what pointed me at it. Use-case-specific gaps stay with the
> individual scenarios, and it names data-subject authorization in UC6 as one
> of them. There's a note on my own wording in there too.
>
> Mohamad, the third shape on #15 is the Data Subject case one over. A valid
> grant where the specific action was never approved, and authority issued
> ahead of the session by someone who never acts in it. Neither folds into
> detection or binding.
>
> Last thing. The repo md is well ahead of -01, which is from 5 July and has
> none of issues 7 through 12. If you want the working group to review
> this class rather than the four of us, please put up a -02.
>
> Best,
> Blake
>
>
> On Tuesday, 11 August 2026 at 12:17 PM, [e-mail] <
> [e-mail]> wrote:
>
> > Hi Blake, Mohamad,
> > Returning to this thread, this is just a reminder.
> > Regarding Issue 7, we have now added "Data Subject" in the Section
> Terminology and added requirements in the Complex Business Process
> Automation use case.
> > You can view the detailed information in the latest md file.
> >
> > Best,
> > Meiling
> >
> > [e-mail]
> >
> > > > From: [e-mail]
> > > > Date: 2026-07-13 15:54
> > > > To: Mohamad Khalil Yossif; ~blake
> > > > CC: oauth; Christopher Emerson; [e-mail]
> > > > Subject: [OAUTH-WG] Re: New Version Notification for
> draft-chen-oauth-agent-authz-use-cases-01.txt
> > > > Hi Blake, Mohamad,
> > > > Thank you for this incredibly clear and insightful analysis. This is
> extremely helpful.
> > > > Your breakdown of the divergence in artifact, trigger, and lifecycle
> perfectly captures the core distinction.
> > > > I fully agree that this warrants a separate requirement class in the
> catalogue for a cleaner taxonomy.
> > > > I've captured this in GitHub Issue #7 and will proceed with Blake on
> drafting this as a new, distinct subsection.
> > > > https://github.com/Maisy-ML/Agent-Authorization-Use-Cases/issues/7
> > > >
> > > >
> > > > Thanks again for the strong support and clarification.
> > > >
> > > > Best,
> > > > Meiling
> > > >
> > > > [e-mail]
> > > >
> > > > > From: Mohamad Khalil Yossif
> > > > > Date: 2026-07-09 22:23
> > > > > To: ~blake
> > > > > CC: oauth; Christopher Emerson; [e-mail];
> [e-mail]
> > > > > Subject: Re: [OAUTH-WG] New Version Notification for
> draft-chen-oauth-agent-authz-use-cases-01.txt
> > > > > Hi Blake, Christopher, Meiling,
> > > > >
> > > > > Direct answer to Blake's question. PSEA's session-independence is a
> > > > > property of the acting party. It removes the dependency on prior
> > > > > session state for the human whose action is being executed, so that
> > > > > a proof exists at execution time whether a session is active,
> > > > > expired, or absent. It does not cover a human who is never in the
> > > > > session at all. That case belongs to a different requirement class.
> > > > >
> > > > > On the shape. What carries across the two classes is the invariant
> > > > > that the evidence artifact is bound to specific semantics by key
> > > > > material the invoker cannot reach. The artifact shape, its trigger,
> > > > > and its lifecycle diverge. Execution-time authorization by the
> > > > > acting human is a per-action signed response over a commitment to
> > > > > the parameters rendered at the moment of the action. Authorization
> > > > > by the human the data describes is closer to a subject-signed,
> > > > > scoped, revocable grant that the reader presents. Different
> objects,
> > > > > different verification moments, different revocation semantics.
> > > > >
> > > > > That divergence supports two classes in the catalogue rather than
> > > > > one nested inside the other. Authorization evidence by the acting
> > > > > human at execution time, and authorization evidence by the human
> the
> > > > > data describes, issued ahead of the disclosure. Common invariant,
> > > > > distinct requirements on artifact, trigger, and lifecycle.
> > > > >
> > > > > Meiling, I would support Blake drafting the second class as its own
> > > > > subsection rather than folding it under the execution-time class.
> > > > > The taxonomy is cleaner that way and each class remains open to
> more
> > > > > than one mechanism.
> > > > >
> > > > > Best regards,
> > > > > Mohamad Khalil Yossif
> > > > > Author, draft-yossif-psea
> > > > >
> > > > > > On 9 Jul 2026, at 16:53, ~blake <blake=
> [e-mail]> wrote:
> > > > > >
> > > > > > Mohamad, Christopher, Meiling,
> > > > > >
> > > > > > Mohamad's framing is the right one. The proof has to be made at
> the
> > > > > > moment of the action, bound to the payload, by key material the
> agent
> > > > > > runtime can't reach.
> > > > > >
> > > > > > Every scenario in the exchange so far assumes the human whose
> decision
> > > > > > needs proving is the account holder, the party the agent acts
> for.
> > > > > > There's a class where no such party exists. Where an agent reads
> an
> > > > > > identity attribute about a third person, that person is neither
> the
> > > > > > agent nor its principal and holds no authorisation role anywhere
> in
> > > > > > the catalogue. No session to be present in, no consent surface to
> > > > > > complete, no grant. Christopher's caller-class consent still has
> the
> > > > > > account holder deciding about their own data, whereas here the
> human
> > > > > > who must decide isn't a party to the grant at all.
> > > > > >
> > > > > > That subject should be able to issue a scoped, revocable consent
> grant
> > > > > > for a specific read which names the permitted reader, the
> attributes
> > > > > > and a revocation path, independent of the agent's own grant.
> Where the
> > > > > > read is paid for, the subject should be settled a share of what
> the
> > > > > > reader pays.
> > > > > >
> > > > > >
> https://datatracker.ietf.org/doc/draft-morrison-consent-settlement/
> > > > > >
> > > > > > Mohamad, the commitment-over-rendered-parameters shape carries
> across
> > > > > > whereas the timing inverts. There's no session to bind to so the
> > > > > > subject signs ahead of the read and the reader presents the grant
> > > > > > rather than a human being asked at execution time. Does psea's
> > > > > > session-independence stretch to a human who is never in the
> > > > > > session?
> > > > > >
> > > > > > Meiling, if it belongs in the catalogue it's one more
> requirement class
> > > > > > - authorisation by the human the data describes, who is neither
> the
> > > > > > client nor the resource owner. I'm happy to draft the subsection,
> > > > > > please advise if you'd rather it sat under one of the existing
> gaps.
> > > > > >
> > > > > > Best,
> > > > > > Blake
> > > > > >
> > > > > >
> > > > > > On Thursday, 9 July 2026 at 04:07, Mohamad Khalil Yossif
> <mohamad=[e-mail]> wrote:
> > > > > >
> > > > > >> Hi Christopher, Meiling,
> > > > > >>
> > > > > >> Two of the points in this exchange coincide with problems I
> have been
> > > > > >> working through, and I think they sharpen the problem
> definition the
> > > > > >> group is assembling. I will keep to those two.
> > > > > >>
> > > > > >> On Christopher's point 3 (consent channels the agent can
> operate).
> > > > > >> This is the crux. Once an agent has browser-automation or
> > > > > >> computer-use capabilities, any confirmation surface reachable
> from
> > > > > >> its execution context can be completed by the agent itself, so a
> > > > > >> plain approval click carries no evidence of a human decision.
> The
> > > > > >> requirement that follows is that the proof of the human
> decision be
> > > > > >> generated at the moment of the action, bound to the specific
> action
> > > > > >> payload, by key material the agent runtime cannot reach. This
> is the
> > > > > >> execution-time, session-independent framing in draft-yossif-psea
> > > > > >> (https://datatracker.ietf.org/doc/draft-yossif-psea/)
> assurance
> > > > > >> that holds whether a session is active, expired, or absent,
> because
> > > > > >> it does not inherit from session state.
> > > > > >>
> > > > > >> Christopher notes that binding the approval to what the user was
> > > > > >> actually shown remains open. One workable direction: the issuer
> > > > > >> forms a commitment over the parameters rendered to the user; the
> > > > > >> user's authenticator signs a response over that commitment at
> > > > > >> execution time; the server verifies the signed selection against
> > > > > >> the commitment before the action proceeds. The authenticator is
> > > > > >> provisioned before the task begins, and its key is outside the
> > > > > >> agent's execution context. WebAuthn with user verification
> supplies
> > > > > >> the human-presence signal; the commitment supplies the
> > > > > >> what-you-approved binding. A confirmation dialog on a device
> where
> > > > > >> the agent controls input does not meet this bar, which is also
> why
> > > > > >> Use Case 4's privilege escalation needs the same treatment. This
> > > > > >> belongs in Section 5 as a security consideration for whatever
> > > > > >> interactive channel the group standardizes.
> > > > > >>
> > > > > >> On the durable record of the authorization event (Christopher's
> > > > > >> first gap-analysis addition). This is the complement to Section
> 5's
> > > > > >> non-repudiation requirement, and I agree it is missing.
> > > > > >> Introspection responses and token claims describe the live grant
> > > > > >> while it exists. They are not a durable record of the event that
> > > > > >> created it: who authorized, which scopes, when, under which
> policy
> > > > > >> version. When an agent's later actions are disputed, that
> record is
> > > > > >> the first thing needed and the first thing absent. This
> granularity
> > > > > >> question is the subject of a survey recently submitted to
> > > > > >> secdispatch, "Authorization Evidence for High-Risk Actions,"
> which
> > > > > >> separates per-action authorization evidence from point-in-time
> > > > > >> signals about the grant. It may warrant either a gap of its own
> or
> > > > > >> an explicit sub-point under Section 5.
> > > > > >>
> > > > > >> I am happy to propose text for both, in coordination with
> > > > > >> Christopher's offer, for the next revision.
> > > > > >>
> > > > > >> Best regards,
> > > > > >> Mohamad Khalil Yossif
> > > > > >> Author, draft-yossif-psea
> > > > > >>
> > > > > >>> On 8 Jul 2026, at 19:40, Christopher Emerson <
> [e-mail]> wrote:
> > > > > >>>
> > > > > >>> 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:
> > > > > >>>    • 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?
> > > > > >>>    • 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
> > > > > >>> Date: 2026-07-07 11:23
> > > > > >>> To: [e-mail]
> > > > > >>> CC: oauth
> > > > > >>> 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
> > > > > >>> _______________________________________________
> > > > > >>> OAuth mailing list -- [e-mail]
> > > > > >>> To unsubscribe send an email to [e-mail]
> > > > > >>
> > > > > >> _______________________________________________
> > > > > >> OAuth mailing list -- [e-mail]
> > > > > >> To unsubscribe send an email to [e-mail]
> > > > > >>
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 12 Aug 2026 10:49:31 +0800
> From: "Meiling Chen" <[e-mail]>
> Subject: [OAUTH-WG] Fw: New Version Notification for
>         draft-chen-oauth-agent-authz-use-cases-02.txt
> To: oauth <[e-mail]>
> Message-ID: <[e-mail]>
> Content-Type: multipart/alternative;
>         boundary="----=_001_NextPart541004557716_=----"
>
> Hi all,
>
> We have published version -02 of the "Agent Authorization use cases and
> gap analysis" draft (draft-chen-oauth-agent-authz-use-cases).
> This new version addresses 11 open issues from the tracker. Specifically,
> the following issues have been resolved:
> #3, #4, #5, #6, #7, #8, #9, #10, #11, #12, and #18
> You can find the latest draft here:
>
> https://datatracker.ietf.org/doc/html/draft-chen-oauth-agent-authz-use-cases-02
> We welcome and appreciate your review and feedback on these changes.
> We plan to address the remaining 6 issues in the next version (-03). These
> are:
> #15, #16, #17, #19, #20, and #26
> All issues can be viewed through
> https://github.com/Maisy-ML/Agent-Authorization-Use-Cases/issues
>
>
> Thanks,
> Meiling
>
>
> [e-mail]
>
> From: internet-drafts
> Date: 2026-08-12 10:35
> To: Chunchi Peter Liu; Jia Chen; Jiankang Yao; Meiling Chen; Peter Liu;
> Yuning Jiang
> Subject: New Version Notification for
> draft-chen-oauth-agent-authz-use-cases-02.txt
> A new version of Internet-Draft
> draft-chen-oauth-agent-authz-use-cases-02.txt
> has been successfully submitted by Meiling Chen and posted to the
> IETF repository.
>
> Name:     draft-chen-oauth-agent-authz-use-cases
> Revision: 02
> Title:    Agent Authorization use cases and gap analysis
> Date:     2026-08-12
> Group:    Individual Submission
> Pages:    35
> URL:
> https://www.ietf.org/archive/id/draft-chen-oauth-agent-authz-use-cases-02.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-02.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-02
>
> 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
>
>
> -------------- next part --------------
> A message part incompatible with plain text digests has been removed ...
> Name: not available
> Type: text/html
> Size: 9111 bytes
> Desc: not available
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
> ------------------------------
>
> End of OAuth Digest, Vol 214, Issue 74
> **************************************
>