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

[Meiling Chen <[e-mail]>]

Hi Morgan,
Thank you for this incredibly insightful and detailed analysis regarding Use Case 3. 
You've perfectly articulated a nuance we had overlooked. Your breakdown of the two distinct gaps―the "agent activity distinction and abuse detection" problem versus the classical "cross-principal authority misuse"―is exactly right. The distinction between a detection gap and a binding gap is a critical one that absolutely deserves to be treated separately in the draft.
We completely agree with your assessment and will adopt your suggestion. We will restructure the document to keep the current content under a more accurate name and introduce a new, distinct use case for the classical Confused Deputy problem. 
We were particularly grateful for your offer to propose text. We would be delighted to accept. 
Since you've already created an issue for this, please feel free to add the proposed text there or create a PR directly―whichever is more convenient for you.
Thanks again for your invaluable contribution to improving this draft.
Best,
Meiling


[e-mail]
 
From: morganLR
Date: 2026-08-05 03:50
To: [e-mail]
CC: mohamad=40yuthent.com; blake; oauth
Subject: [OAUTH-WG] Re: New Version Notification for draft-chen-oauth-agent-authz-use-cases-01.txt
Meiling, all,

Following up on a note I promised in July, separate from the UC5 discussion: a terminology observation on UC3, offered because I think the draft is currently naming one gap where it has found two, and both deserve to survive.

UC3 as written describes service providers struggling to distinguish legitimate agent activity from abuse, and labels this the Confused Deputy Problem. The gap it describes is real and important: relying parties today often cannot tell agent-originated activity from human-originated activity, or well-behaved agent traffic from abusive traffic that presents the same credentials. But that is an agent-distinction and abuse-detection gap, and it has recently become load-bearing well beyond UC3 itself: in the WIMSE discussion of what verification can and cannot establish, the resource-side option for excluding ambient-authority bypass (a resource declining ambient-credential access for agent-originated requests) presupposes exactly the distinction UC3 says providers cannot make today. UC3's gap is a precondition for that entire enforcement class, which I would count as an argument for keeping it, prominently, under a name that says what it is.

The classical confused deputy (Hardy's compiler, 1988) is a different failure with a different shape: a program that legitimately holds authority is induced to exercise it on behalf of the wrong requester. Nothing about the deputy's traffic is distinguishable as abuse; every credential it presents is genuine and every action is within its granted scope. The failure is that the authority was applied for a principal other than the one the grant served. In agent terms: an agent authorized for a class of action is induced, by prompt injection, cross-request contamination, or a smuggled instruction, to apply that authority to a resource belonging to someone other than the principal it acts for. The requirements shape of the defense is also different: it is not detection but binding, conveying the on-behalf-of principal immutably along the delegation chain and authorizing on the conjunction of agent permission and principal entitlement, so that the deputy's authority is simply not exercisable for the wrong principal. (Stated mechanism-neutrally as R5 and R6 in draft-reece-wimse-cross-org-delegation, though the point is older than any current draft.)

Concrete, low-cost suggestion, entirely the editors' call: keep UC3's content and give it a name that matches it, something like "agent activity distinction and abuse detection," and record the classical deputy as its own case or sub-case, something like "cross-principal authority misuse," with the Hardy sense noted. Two named gaps where the draft currently has one label covering half of each. I am happy to propose text in whatever form is easiest, and I will mirror this note as an issue on the repository so it is trackable alongside #16, #17, and #18.

Morgan

On Friday, July 24th, 2026 at 9:33 AM, [e-mail] <[e-mail]> wrote:
Hi Morgan,

Thank you for your thorough review of the draft and for your very constructive feedback. We especially appreciate your generous offer to contribute the companion use case and the requirements mapping.
To ensure we track this properly, I have opened two issues on our GitHub repository:
Issue #17: Enhance UC5 with Cross-Draft Alignment
Issue #18: Add New Use Case for Cross-Organizational Delegation
Could you please take a look to confirm that these issues correctly capture the work you proposed?
You can view all open issues at the following address: https://github.com/Maisy-ML/Agent-Authorization-Use-Cases/issues
We look forward to your contribution and continuing the discussion on GitHub for this two issue.
Best,
Meiling


[e-mail]
 
From: morganLR
Date: 2026-07-23 22:01
To: Mohamad Khalil Yossif
CC: Blake; oauth; [e-mail]
Subject: [OAUTH-WG] Re: New Version Notification for draft-chen-oauth-agent-authz-use-cases-01.txt
Meiling,
 
Thank you for the session presentation and for the -01 revision. The gap analysis is exactly the kind of foundation the group needs before mechanism selection, and I want to engage with two parts of it.
 
First, on Use Case 5. During the session you referenced a prior list discussion of the cold-start scenario; in case it helps the record, that framing aligns with requirement R2 of draft-reece-wimse-cross-org-delegation-00 (cross-organizational verification without an interaction-specific prior arrangement), which I also applied in my July 20 note on the cross-domain transaction token thread. Your UC5 gap statement, no universal secure protocol for scoped, revocable access in a zero-trust, no-pre-channel initialization, is a very good articulation of it, and I would be glad to see it survive into whatever this document becomes.
 
Second, an offer. UC5 as drafted covers the case where the service side lacks authorization infrastructure entirely. There is a companion case that I believe belongs alongside it: both sides have full trust infrastructure, the agent's organization and the service's organization each operate their own, and there is still no pre-authorization channel between them because they have never interacted. This is the ordinary condition of cross-organizational agent delegation, and its requirements are stricter in some dimensions (the service must be able to verify delegated, attenuated authority from another organization, potentially without a runtime callback to it) and looser in others. I would be happy to contribute that use case in your document's format, along with a mapping of the -01 gaps to the R1-R9 requirement set from the draft above, as review input rather than as competing structure. I also have a couple of small terminology notes, including one on the classical confused-deputy framing in UC3, that I will send separately so they do not clutter this thread.
 
Thank you again for anchoring the discussion at the use-case level.
 
Regards,
Morgan
 
 
 
Sent with Proton Mail secure email.
 
On Wednesday, July 22nd, 2026 at 7:36 AM, Mohamad Khalil Yossif <mohamad=[e-mail]> wrote:
 
> Following the axis you both settled on: the execution-time class in
> that split is exactly where a delegation-constraint layer sits, and
> the ex-ante piece is where the human-signed mandate lives before the
> agent acts.
> 
> I have posted a short problem statement on that upstream piece:
> 
>   draft-yossif-agent-mandate-problem-00
>   https://datatracker.ietf.org/doc/draft-yossif-agent-mandate-problem/
> 
> No protocol, no mechanism. It states the gap between an authorized
> agent and an authorized action, and the requirements any solution
> would need to meet. draft-yossif-psea covers the execution-time
> evidence; this new draft covers the ex-ante mandate the evidence is
> verified against.
> 
> For the catalogue: this may be worth citing as a problem reference
> under the delegation class, alongside the existing entries.
> 
> Feedback welcome on the framing.
> 
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>