Hi Jia, Thank you for the review of Use Case 4, your analysis of the "dangling requirements" was spot on. We have incorporated your proposed text into the draft to address the issues you raised. The changes are as follows: 1, updated the descriptions for "Task-Scoped Permissions" and "Secure Privilege Escalation" to be more precise.
Task-Scoped Permissions: Permissions should be granted for the duration of a specific task and automatically revoked upon completion. The task lifecycle is typically maintained by a remote agent service, and the OS must have a way to understand or be informed of task boundaries so that permissions can be properly bound to the task's lifetime. Secure Privilege Escalation: If a task requires elevated permissions, there must be a secure, user-approved mechanism for the agent to request them just-in-time, rather than running with high privileges constantly. Such a mechanism must account for the fact that the requester is an autonomous agent—a non-human subject with uncertain operational status—rather than assuming a fully capable and responsible human user is always present and in control. 2, replaced the previous gap descriptions with your more accurate and detailed analysis. No Protocol-Level Link Between Task Lifecycle and Permission Lifecycle: There is no standard protocol to connect an agent's high-level task intent (often determined in the cloud or maintained by a remote agent service) to a secure, fine-grained grant of local OS permissions on the device. More fundamentally, even if a task lifecycle is tracked by the agent service, the OS has no visibility into that lifecycle and no standard way to understand when a task begins, updates, or completes. Without a protocol-level link between task state and permission state, the OS cannot bind a permission grant to the duration of a specific task or automatically revoke it upon task completion. No Elevation Mechanism Suitable for Agent Subjects: While operating systems provide privilege escalation mechanisms (e.g., sudo, UAC, macOS authorization dialogs), these are designed for human users who are capable of acting autonomously and taking responsibility for their actions. Their core assumption is that the requester is a responsible human subject. An autonomous agent, however, is a non-human subject with uncertain operational status—it may make errors, enter unexpected states, or require human intervention. Existing elevation mechanisms do not support a non-human subject requesting elevation on behalf of a user, nor do they provide a way to attribute accountability when an agent's elevated action causes harm. As a result, developers are forced to choose between two undesirable outcomes: either the agent runs with persistent broad permissions (violating least privilege), or every elevation request requires human intervention (defeating the purpose of automation). The gap is not merely the absence of a mechanism for one-time elevation, but the absence of a mechanism designed for agents as a distinct subject type with built-in safety and accountability guardrails. Best, Meiling [email protected] From: Jia Chen Date: 2026-08-14 21:53 To: Meiling Chen; yaojk; jiangyuning2; liuchunchi CC: oauth Subject: Re: draft-chen-oauth-agent-authz-use-cases-01 Subject: UC3 and UC4 Dangling Requirements Review Results Hi Meiling and all, Following your call for a quality check on dangling requirements, I have reviewed the latest version of the draft (draft-chen-oauth-agent-authz-use-cases-02) with a focus on Use Case 3 and Use Case 4. Here are my findings. For Use Case 3 (Agent as User's Full Proxy to Access Third-Party Tools), the check passed. All six requirements listed in UC3 have corresponding entries in the Gap Analysis section. No dangling requirements were found. For Use Case 4 (Agent as User's Proxy to Access Operating System Resources), I found issues. Two requirements lack explicit corresponding analysis in the Gap Analysis. The first is "Task-Scoped Permissions". The Gap Analysis does not address why existing OS permission models cannot support task-bound lifecycle management or automatic revocation upon completion. The second is "Secure Privilege Escalation". The current Gap Analysis only mentions "Over-Privileging by Default" as a consequence, but it does not analyze why existing elevation mechanisms (such as sudo, UAC, or macOS authorization dialogs) are unsuitable or insecure for agent-initiated requests, nor why "just-in-time" and "user-approved" elevation are difficult to achieve in this context. I have prepared an issue on our GitHub repository to track this discrepancy. You can find it at the link below. https://github.com/Maisy-ML/Agent-Authorization-Use-Cases/issues/27 In the issue, I have also included proposed text for the missing Gap Analysis entries, which can be used directly for the -03 revision. Let me know if you would like me to draft a pull request with the proposed changes. Best regards, Jia Chen [email protected] 在 2026/8/13 17:56, Meiling Chen 写道: Hi usecase co-authors, I'm writing to ask for your help with a crucial quality check as we prepare for the -03 submission of our agent authorization draft. Recently, we received some excellent and precise feedback from Morgan on Use Case 6 (UC6). He pointed out a significant inconsistency: a requirement had been added to the "Requirements" list, but its corresponding analysis was completely missing from the "Gap Analysis" section. This created a broken link for the reader and weakened the argument for that use case. While I have already fixed the specific issue in UC6, this incident highlights a potential systemic risk in our document. As the draft has evolved and we've added or refined requirements, we may have inadvertently created similar inconsistencies in other use cases. Call to Action: To prevent this from happening again and to strengthen the overall quality of our draft, I am asking each of you to please review all use cases (or at least the ones you are most familiar with) with a specific focus on the following: Please verify that for every single requirement listed in a use case, there is a corresponding and explicit entry or discussion in the What's Missing (The Gap) or What Works (Partially) section for that same use case. The goal is to ensure there are no "dangling requirements" where we state a need but fail to analyze why the existing landscape (the gap) makes it necessary. Please try to complete your review by this Friday. If you find any discrepancies, please reply to this email thread or, even better, open an issue on our GitHub repository so we can track it formally. Thanks for your help in ensuring the consistency and integrity of our work. This proactive check will make the document much stronger for the next round of community review. Best regards, Meiling [email protected]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
