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

["[e-mail]" <[e-mail]>]

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]
>