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

["jiangyuning (A)" <[e-mail]>]

Hi Meiling and Blake,

Blake, thanks for catching this. I saw #26, and I agree with the fix: carry the Data Subject requirement into the UC6 gap analysis, then align the Table 2 note with it. I also agree with your note on the wording, the first clause stays as a requirement on the system, while the second belongs in the gap analysis.

I have one wording suggestion on the proposed gap text, mainly that framing it as the absence of standard semantics holds up better than saying there is nowhere to carry it. I'll put that on #26 rather than here.

The execution-layer item is separate, the generic gap is already captured in Section 5, so I'll open a separate issue for the UC6-specific part rather than folding it into #26.

Thanks again for the close read.

BR,
Yuning

> -----Original Message-----
> From: Blake Morrison <blake=[e-mail]>
> Sent: Thursday, August 13, 2026 12:13 PM
> To: oauth <[e-mail]>
> Cc: Meiling Chen <[e-mail]>; Mohamad Khalil Yossif
> <[e-mail]>; [e-mail]
> Subject: [OAUTH-WG] Re: New Version Notification for draft-chen-oauth-
> agent-authz-use-cases-01.txt
> 
> Hi Meiling,
> 
> Not a problem, glad to be of assistance.
> 
> I've read -02. The note under Table 2 says use-case-specific gaps stay with
> the individual scenarios and names data-subject authorization and
> execution-layer evidence in UC6 as two of them. UC6's own Gap Analysis has
> two entries (chains and context passing) and neither is either of those.
> Execution-layer evidence turns up in Section 5 item 6 instead and data-
> subject appears nowhere as a gap.
> 
> So the requirement is stated and the gap it implies isn't which is what
> #26 carries. Holding it for -03 works if the Table 2 note moves with it since as
> it stands the draft sends a reviewer to UC6 for something that isn't written
> there.
> 
> Best,
> Blake
> 
> 
> On Wednesday, 12 August 2026 at 1:18 PM, Meiling Chen
> <[e-mail]> wrote:
> 
> > Hi Blake,
> >
> > Thanks for the note, and we're happy the edits landed well.
> >
> > More importantly, thank you for proactively opening Issue #26 for the gap
> analysis text. That is the perfect way to handle it.
> >
> > Your observation connecting Mohamad's "third shape" in #15 to the Data
> Subject case is particularly helpful.
> >
> > And finally, thank you for the reminder on the draft versioning. You were
> absolutely right that we needed to get the new version out for the group.
> We have now published -02, which incorporates all the issues resolved to
> date. The remaining open issues, including your new #26, are now officially
> on the roadmap for the -03 version. This gives the entire working group a
> clear baseline to review.
> >
> > Best,
> > Meiling
> >
> > [e-mail]
> >
> > > > From: Blake Morrison
> > > > Date: 2026-08-12 09:46
> > > > To: oauth
> > > > CC: [e-mail]; Mohamad Khalil Yossif;
> > > > [e-mail]
> > > > Subject: [OAUTH-WG] Re: New Version Notification for
> > > > draft-chen-oauth-agent-authz-use-cases-01.txt
> > > > 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/is
> > > > > > > sues/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-s
> > > > > > > > >ettlement/
> > > > > > > > >
> > > > > > > > > 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-us
> > > > > > > > >>>er-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]
> > > > > > > > >>
> 
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]