Hi Xiang Liu, Thank you so much for your interest in the draft-chen-oauth-agent-authz-use-cases and for your thoughtful contribution. We also appreciate you following the process by opening an issue on GitHub to facilitate the discussion. We are very excited to receive contributions from the industrial domain, and your proposed "Industrial Agent for Equipment Maintenance" use case is an excellent addition. It precisely captures the complex authorization challenges of dynamic, progressively authorized, and delegated tasks that are common in real-world industrial settings. This will significantly enrich the draft and make it more comprehensive. I have reviewed Issue #31 on GitHub and have already added some initial comments. To keep the discussion organized, let's continue refining the specific text and technical details within that issue. Regarding your offer to join the author team, we would be delighted to welcome you as a co-author. Thank you for your proactive engagement and valuable contribution. We look forward to collaborating with you. Best regards, Meiling
[email protected] From: Xiang Liu Date: 2026-10-10 22:05 To: Meiling Chen CC: oauth; draft-chen-oauth-agent-authz-use-cases Subject: Re: [OAUTH-WG] Re: draft-chen-oauth-agent-authz-use-cases: data on responding to resource server challenges Hi Meiling and all, This is Xiang Liu from Pengcheng Laboratory. I would like to contribute a new use case, “Industrial Agent for Equipment Maintenance,” to draft-chen-oauth-agent-authz-use-cases. I have also opened issue #31 in the GitHub repository to share the proposal and invite discussion. Scenario Description: A manufacturing enterprise uses an industrial agent to coordinate equipment maintenance. The agent delegates diagnostic and corrective tasks to specialized agents, including some operated by an equipment supplier. The participating organizations have an established trust relationship but manage authorization independently. The required actions and participating agents may only become known as the workflow progresses. For example, a task may initially require permission to read equipment data and later require separate approval to make an operational change. The authorization challenge is to maintain a clear link between the original task, subsequent approvals, and delegated authority throughout this evolving workflow. I would appreciate your feedback on whether this use case would be a useful addition to the draft and would be happy to refine the text with the group. I would also welcome the opportunity to join the author team as a co-author and contribute to the draft’s ongoing development. Best regards, Xiang Liu Pengcheng Laboratory 2026年10月9日 16:46，Meiling Chen <[email protected]> 写道： Hi Laxmikant, Just a quick follow-up to let you know that we have seen the proposed text you submitted on GitHub (Issue #30). Thank you for putting this together and opening the issue so quickly! We will review the text and incorporate it into the draft as soon as possible. We will keep you and the working group updated once the new version is ready. Best regards, Meiling [email protected] From: Laxmikant Sharma Date: 2026-09-25 12:58 To: oauth CC: draft-chen-oauth-agent-authz-use-cases Subject: draft-chen-oauth-agent-authz-use-cases: data on responding to resource server challenges 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]
