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]
