Mohamad, Indeed, sometimes mistakes do occur even when one is busy. I have now added your suggested text to the "Challenges" list in the UC1. As the change has been integrated, I have gone ahead and closed issue #15 on GitHub. Your contribution has significantly improved the clarity of this point, and I appreciate your help in getting it right. Best, Meiling
[email protected] From: Mohamad Khalil Yossif Date: 2026-08-13 03:44 To: Meiling Chen CC: oauth Subject: Re: [OAUTH-WG] New Version Notification for draft-chen-oauth-agent-authz-use-cases-02.txt Meiling, No apology needed. Two people reading the same issue and reaching different conclusions is how it should work. I read the UC1 text in -02. The three requirements Yuning added cover the gap - Pre-Authorized Constraints, Admission-to-Execution Binding, and Action-Specific Approval are the right three, and the new Table 1 row for Verifiable, Action-Specific Consent places it correctly. One thing is not yet visible, and it is what I flagged. Every failure described in the scenario is about a request Alice receives and cannot evaluate well - context collapse, binary choices, task-level revocation. All three assume she is asked. The case I raised is the one where she is not asked at all. The grant is valid, unexpired and unrevoked, the agent is acting inside it, and no request is generated. That failure is invisible to everything the current text describes, because there is no consent screen to get wrong. One sentence in the Challenges list would close it. Something like: Silent Execution Within a Valid Grant: where an action falls inside an existing grant, no fresh approval is triggered at all. A high-impact or irreversible action can therefore execute with valid authority and without any human having approved that specific action. The failure is not a bad consent screen; it is the absence of one. Add that and I am satisfied - close #15. Wording is yours to adjust. Mohamad On 12 Aug 2026, at 16:59, Meiling Chen <[email protected]> wrote: Hi Mohamad, Thank you for your email. First and foremost, please accept my sincere apologies for the conflicting guidance and the confusion this has caused. You were absolutely right to flag the contradictory instructions, and I appreciate you asking for a clear direction before proceeding. After you pointed this out, I went back and reviewed Yuning's recent, detailed comments on Issue #15 and the corresponding updates to Use Case 1. I now agree completely with your and Yuning's assessment. The approach to enhance UC1 is the correct one, and we do not need a new standalone use case for this. The updated text, which covers the three points Yuning listed (binding constraints, preserving admission basis, and verifying evidence), appears to address the core requirements you outlined. The crucial next step is to ensure this solution works for you. Could you please review the latest version of the UC1 text and confirm that it fully resolves the issue from your perspective? In particular, we want to be sure it meets the excellent point you raised: does the text make it clear that this is a failure where "the agent had authority and the specific action was never approved by anyone"? Your confirmation on this would be invaluable before we close the issue. Thank you again for your diligence and for pushing for clarity. It's greatly appreciated, and I'm sorry for the detour. Best, Meiling [email protected] From: Mohamad Khalil Yossif Date: 2026-08-12 21:09 To: chenmeiling CC: oauth Subject: Re: [OAUTH-WG] New Version Notification for draft-chen-oauth-agent-authz-use-cases-02.txt Meiling, Yuning, Before I open a PR I need one thing settled, because the two answers I have point in opposite directions and whichever I build will conflict with the other. Yuning wrote on #15 yesterday that the scenario is better handled inside UC1, that UC1 has already been updated to cover it, and that #15 can be closed as merged. Meiling wrote this morning that a new standalone use case is the clearest approach, and asked me to open a PR in that shape. I am happy to write either. Tell me which and I will send it. For what it is worth, my own view sits closer to Yuning's, and I want to say why in case it helps you decide rather than just defer. The three points Yuning added to UC1 are the right ones - binding approved constraints to later execution, preserving the admission basis through to the endpoint, and verifying execution-time evidence before the action takes effect. Those cover the gap. If they are in UC1 already, a separate use case would restate the same requirements under a different narrative, and the catalogue gets longer without getting clearer. The one thing I would check before closing #15 is whether the UC1 text keeps the distinction visible. The failure is not that the agent lacked authority, and not that the wrong principal acted. The agent had authority and the specific action was never approved by anyone. If UC1 now carries that as a stated requirement rather than as narrative context, then #15 is genuinely covered and I have no objection to closing it. If instead you want it standalone because the point gets lost inside UC1, that is a reason I would accept, and I will write it that way. On Gap C, the enrollment dependency, Yuning is right that it is cross-cutting rather than UC1-specific. It sits under every use case in the catalogue where a key is resolved to a person. If it is useful I can propose short text for it as a cross-cutting concern rather than attached to any single use case. Mohamad
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
