El mar, 11 ago 2026, 9:50 p. m., <[email protected]> escribió:
> Send OAuth mailing list submissions to > [email protected] > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > Subject: [OAUTH-WG] Re: New Version Notification for > draft-chen-oauth-agent-authz-use-cases-01.txt > To: oauth <[email protected]> > Cc: "[email protected]" <[email protected]>, > Mohamad Khalil Yossif <[email protected]>, "[email protected]" > <[email protected]> > 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, [email protected] < > [email protected]> 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 > > > > [email protected] > > > > > > From: [email protected] > > > > Date: 2026-07-13 15:54 > > > > To: Mohamad Khalil Yossif; ~blake > > > > CC: oauth; Christopher Emerson; [email protected] > > > > 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 > > > > > > > > [email protected] > > > > > > > > > From: Mohamad Khalil Yossif > > > > > Date: 2026-07-09 22:23 > > > > > To: ~blake > > > > > CC: oauth; Christopher Emerson; [email protected]; > [email protected] > > > > > 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= > [email protected]> 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 > <[email protected]> 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 < > [email protected]> 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 [email protected] < > [email protected]> 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 > > > > > >>> [email protected] > > > > > >>> From: Christopher Emerson > > > > > >>> Date: 2026-07-07 11:23 > > > > > >>> To: [email protected] > > > > > >>> 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 -- [email protected] > > > > > >>> To unsubscribe send an email to [email protected] > > > > > >> > > > > > >> _______________________________________________ > > > > > >> OAuth mailing list -- [email protected] > > > > > >> To unsubscribe send an email to [email protected] > > > > > >> > > > ------------------------------ > > Message: 2 > Date: Wed, 12 Aug 2026 10:49:31 +0800 > From: "Meiling Chen" <[email protected]> > Subject: [OAUTH-WG] Fw: New Version Notification for > draft-chen-oauth-agent-authz-use-cases-02.txt > To: oauth <[email protected]> > Message-ID: <[email protected]> > 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 > > > [email protected] > > 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 -- [email protected] > To unsubscribe send an email to [email protected] > > > ------------------------------ > > End of OAuth Digest, Vol 214, Issue 74 > ************************************** >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
