Hi Laxmikant and Iman, Sorry for the delayed response. I've just returned from a long vacation and am now catching up on emails. Thank you both for this excellent and productive discussion on the draft. @Laxmikant, thank you especially for conducting the tests and sharing the real-world results. This empirical data is incredibly valuable for validating the gaps we've identified. It provides concrete evidence that this is a real-world problem, not just a theoretical one. @Iman, your architectural insights and proposed refinements are equally appreciated. You've articulated the nuances perfectly. We agree that this should be a distinct use case rather than an extension of UC5. The concept of a missing "machine-readable terminal disposition" is a brilliant way to frame the gap, and we will definitely highlight that in Section 6. Thank you also for the reminder to maintain the clear boundary between the grant-layer and execution-layer concerns. Based on this feedback, we are now working on the v04 draft. We look forward to the GitHub issue with the proposed text from [第一位专家的名字], and we will integrate these valuable contributions. Thanks again to both of you for your significant contributions to improving the document. Best regards, Meiling
[email protected] From: Iman Schrock Date: 2026-09-25 13:55 To: oauth CC: draft-chen-oauth-agent-authz-use-cases Subject: Re: [OAUTH-WG] draft-chen-oauth-agent-authz-use-cases: data on responding to resource server challenges Laxmikant, This is useful data. I think it belongs in the document, but as a distinct case from Use Case 5. Use Case 5 has no authorization front channel or authorization-server relationship. Your test had both. The interoperability failure was that clients did not expose a consistent disposition after receiving the same resource-server challenge. The server could not tell whether the client needed user interaction, did not support the flow, refused it by policy, or had simply stopped. I would split those two concerns in Section 6. A client that cannot complete the advertised challenge should return a machine-readable terminal disposition rather than leave the resource server to infer meaning from silence. Your harness results are strong evidence for that requirement. There is one other boundary worth preserving. Completing the OAuth challenge establishes grant-layer access. It does not by itself bind a human decision to the exact parameters of a consequential action. The current draft already separates that execution-layer evidence in Sections 4.1.2 and 6; that is where EMILIA composes rather than replacing the OAuth flow. I would support opening the issue with the results and proposed text. Best, Iman On Thu, 24 Sep 2026 21:58:14 -0700, Laxmikant Sharma <[email protected]> wrote: Hi all, Ahead of the 19 October interim on agent authorization use cases and gaps, here is some data on one of the gaps in draft-chen-oauth-agent-authz-use-cases. Section 6 (item 2) notes that the framework has no built-in mechanism for an agent "to respond to a real-time authorization challenge from a resource server". In September I ran eight shipped AI agents that act as MCP clients, in their mid-September releases, against a resource server that answered the first request with 401 and a WWW-Authenticate header carrying resource_metadata. The authorization server offered the authorization code grant with PKCE and accepted both client ID metadata documents and dynamic registration. Each client ran in a terminal on a machine with a browser, and a scripted test user completed any sign-in page a client opened or printed. In one-shot mode, one client completed the grant on its own, and a second did so only after the user set a per-server flag in its configuration. Two fetched the protected resource metadata, one of them also registered a client, and both stopped there. The other four made no authorization attempt, although one of them opened the browser within seconds and completed the grant when run as an interactive session instead. In a separate run the day before, all eight completed the same grant through their own sign-in steps. So every client can run the grant, and whether it runs it on a challenge is left to the client. A client that won't act on the challenge also has no standard way to say so, which leaves the resource server nothing to fall back on. Use Case 5 (Section 4.1.6) covers first connection when there is no front channel. This is the complementary case, where the front channel exists and the client doesn't use it. If the authors think it belongs in the document, I'm glad to open an issue on their tracker with proposed text. I also plan to publish the harness and the records once each client's maintainers have seen their results. Thanks, Laxmikant Sharma
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
