Why does accessing a resource require a network connection? If I am running something on my local machine and need to access a file (aka a resource), no network connection is required – in fact, I would absolutely *not* want one for various reasons (e.g., latency, security, etc.)
Leonard From: Dick Hardt <dick.ha...@gmail.com> Date: Thursday, July 24, 2025 at 10:33 AM To: Leonard Rosenthol <lrose...@adobe.com> Cc: Lombardo, Jeff <jeff...@amazon.com>, Jonathan Rosenberg <jdros...@gmail.com>, oauth@ietf.org <oauth@ietf.org>, agent2ag...@ietf.org <agent2ag...@ietf.org> Subject: Re: [agent2agent] Re: [OAUTH-WG] Re: Draft on CHEQ - HITL confirmation for AI Agent actions EXTERNAL: Use caution when clicking on links or opening attachments. The problem statement as I understood it is how to access an RS, which implies a network connection, which might be localhost, and OAuth works in that environment. On Thu, Jul 24, 2025 at 10:55 AM Leonard Rosenthol <lrose...@adobe.com<mailto:lrose...@adobe.com>> wrote: One concern with tying this all to OAuth is that it assumes that all agents are operating in “internet space” – yet many agents (and their tools) today (and into the future) operate strictly “on-device’. In which case, a mechanism that is not tried to networking protocols but could be used for local communication as well – just as MCP supports both local and remote communications – needs to also be viable (IMHO). Leonard From: Dick Hardt <dick.ha...@gmail.com<mailto:dick.ha...@gmail.com>> Date: Thursday, July 24, 2025 at 2:14 PM To: Lombardo, Jeff <jeff...@amazon.com<mailto:jeff...@amazon.com>> Cc: Jonathan Rosenberg <jdros...@gmail.com<mailto:jdros...@gmail.com>>, oauth@ietf.org<mailto:oauth@ietf.org> <oauth@ietf.org<mailto:oauth@ietf.org>>, agent2ag...@ietf.org<mailto:agent2ag...@ietf.org> <agent2ag...@ietf.org<mailto:agent2ag...@ietf.org>> Subject: [agent2agent] Re: [OAUTH-WG] Re: Draft on CHEQ - HITL confirmation for AI Agent actions EXTERNAL: Use caution when clicking on links or opening attachments. I may be missing some functionality, but I think the objectives can be accomplished with existing OAuth standards. RAR (RFC 9396 provides the granularity proposed in CHEQ) https://datatracker.ietf.org/doc/html/rfc9396 In your architecture diagram, you are missing the MCP server and the AS. The MCP server is sitting between the agent and the RS and can determine that additional authorization is required to call the RS, and the MCP could then make a PAR (RFC 9126) call with RAR to an AS. The resulting URL could then be passed back to the agent through an elicitation response which would then be loaded for the user to interact with the AS to provide authorization to the RS for the MCP server. In this OAuth flow, note that the MCP server is the client, not the agent. This is similar to related proposals to allow an MCP server to get access to resources downstream from the agent. Once the MCP server has this new access token, it can notify the agent to continue processing. https://datatracker.ietf.org/doc/html/rfc9396 https://datatracker.ietf.org/doc/html/rfc9126 On Thu, Jul 24, 2025 at 10:10 AM Lombardo, Jeff <jeff...@amazon.com<mailto:jeff...@amazon.com>> wrote: The name of the Draft as OAuth in it, OAuth is a working group, Agent2Agent is only a mailing list as far I understand right now. So is there really a second options to submit it to another Working Group? Jean-François “Jeff” Lombardo | Amazon Web Services Architecte Principal de Solutions, Spécialiste de Sécurité Principal Solution Architect, Security Specialist Montréal, Canada ( +1 514 778 5565 Commentaires à propos de notre échange? Exprimez-vous ici<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>. Thoughts on our interaction? Provide feedback here<https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>. From: Jonathan Rosenberg <jdros...@gmail.com<mailto:jdros...@gmail.com>> Sent: July 24, 2025 10:06 AM To: dick.ha...@gmail.com<mailto:dick.ha...@gmail.com> Cc: oauth@ietf.org<mailto:oauth@ietf.org>; agent2ag...@ietf.org<mailto:agent2ag...@ietf.org> Subject: [EXT] [OAUTH-WG] Re: Draft on CHEQ - HITL confirmation for AI Agent actions CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le contenu ne présente aucun risque. What is your view on whether this could be in scope for the OAuth group? On Thu, Jul 24, 2025 at 9:53 AM Dick Hardt <dick.ha...@gmail.com<mailto:dick.ha...@gmail.com>> wrote: I'd like to suggest one mail list for discussion. :) On Thu, Jul 24, 2025 at 9:50 AM Jonathan Rosenberg <jdro...@jdrosen.net<mailto:jdro...@jdrosen.net>> wrote: At the mic just now I mentioned this draft: https://datatracker.ietf.org/doc/html/draft-rosenberg-cheq-00 Abstract: This document proposes Confirmation with Human in the Loop (HITL) Exchange of Quotations (CHEQ). CHEQ allows humans to confirm decisions and actions proposed by AI Agents prior to those decisions being acted upon. It also allows humans to provide information required for tool invocation, without disclosing that information to the AI agent, protecting their privacy. CHEQ aims to guarantee that AI Agent hallucinations cannot result in unwanted actions by the human on whose behalf they are made. CHEQ can be integrated into protocols like the Model Context Protocol (MCP) and the Agent-to-Agent (A2A) protocols. It makes use of a signed object which can be carried in those protocols. Comments and feedback are most welcome, either here on agent2ag...@ietf.org<mailto:agent2ag...@ietf.org>, where I have also posted notice of this draft. Thx, Jonathan R. -- Jonathan Rosenberg, Ph.D. jdro...@jdrosen.net<mailto:jdro...@jdrosen.net> http://www.jdrosen.net<http://www.jdrosen.net/> _______________________________________________ OAuth mailing list -- oauth@ietf.org<mailto:oauth@ietf.org> To unsubscribe send an email to oauth-le...@ietf.org<mailto:oauth-le...@ietf.org>
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
