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> 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> > *Date: *Thursday, July 24, 2025 at 2:14 PM > *To: *Lombardo, Jeff <jeff...@amazon.com> > *Cc: *Jonathan Rosenberg <jdros...@gmail.com>, oauth@ietf.org < > oauth@ietf.org>, agent2ag...@ietf.org <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> > 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> > *Sent:* July 24, 2025 10:06 AM > *To:* dick.ha...@gmail.com > *Cc:* oauth@ietf.org; 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> 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> > 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, where I have also posted notice of this draft. > > > > Thx, > > Jonathan R. > > -- > > Jonathan Rosenberg, Ph.D. > jdro...@jdrosen.net > http://www.jdrosen.net > > _______________________________________________ > OAuth mailing list -- oauth@ietf.org > To unsubscribe send an email to oauth-le...@ietf.org > >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
