Hi Yuan, Thank you for your review and the information provided. This is very important to us. Regarding your question, I am more inclined to believe that it is a small set of common fields that deployments could extend.
Best, Meiling [email protected] 发件人： niyuan 发送时间： 2026-11-04 23:44 收件人： Meiling Chen; oauth 抄送： Zhukeyi(Kaiyin,Datacom Standard&Patent) 主题： 回复: [OAUTH-WG] Follow-up on OAuth Interim Discussion: New Draft "Agent Intent Token" for Review Hi Meiling, I was reading Section 3.3 and had a question about how the `intent` claim would be represented in practice. An earlier AP2 SDK example uses a `natural_language_description` field for the purchase intent confirmed by the user, alongside fields specific to shopping(https://github.com/google-agentic-commerce/AP2/blob/main/code/sdk/python/ap2/models/mandate.py). Do you expect the issuer and the AS to agree on the `intent` format for each deployment, or are you considering a small set of common fields that deployments could extend? Best, Yuan 发件人: Meiling Chen <[email protected]> 发送时间: 2026年10月23日 17:13 收件人: oauth <[email protected]> 主题: [OAUTH-WG] Follow-up on OAuth Interim Discussion: New Draft "Agent Intent Token" for Review Hi all, During the recen= OAuth Interim Meeting (interim-2026-oauth-09), we had a productive discu=sion around Use Cases and Gaps, with a significant focus on the "Authoriz=tion Context Gap." A key challenge we discussed was the risk o= an Agent misinterpreting or failing to accurately verify the user's true=intent. Tim's example of an agent mistakenly trying to "send me $100" hig=lighted this problem perfectly. The consensus was that relying solely on =he agent's judgment is unreliable, and we need a mechanism to ensure that=subsequent actions, like authorization requests, strictly adhere to the u=er's original, confirmed intent. Inspired by this discussion and=to address this gap, a new IETF draft has been written: "OAuth Agent Intent T=ken". Draft Link: https://datatracker.ietf.org/doc/draft-chen-oauth-agent-intent-to=en/ What is a= "Intent Token"? The core idea is to create a signed, struct=red data object (e.g., a JWT) that encapsulates the user's original inten=. The flow works as follows: Capture Inten=: Before an Agent begins any action, it negotiates and confirms a =lear "intent" with the user. Generate Token: This confirmed intent is then packaged into an =Intent Token" and signed by a trusted entity to ensure its integrity and =uthenticity. Pass Context= The Agent carries this Intent Token along with its subsequent req=ests to the Authorization Server. Validate & Decide: The Authorization Server can then v=lidate the token's signature, parse the intent, and compare the current r=quest against the original intent recorded in the token. This enables a m=re precise and secure authorization decision. This mechani=m aims to fill the authorization context gap, ensuring that even if an ag=nt is "confused" or untrusted, the final authorization decision remains f=ithful to the user's will, while also providing a better framework for pr=tecting user privacy. This draft is our initial attempt to forma=ize the ideas from our discussion, and we would greatly appreciate your f=edback and insights. We invite you all to review the draft and share any =uestions, suggestions, or comments on the mailing list. Thank yo= for the engaging discussion during the meeting. We look forward to colla=orating with you to refine this proposal. Best, =0A Meiling [email protected] From: internet-drafts Date: 2026-10-20&nb=p;04:05 To: &n=sp; to bridge this semantic gap. The Intent Token is a signed=credential that immutably captures the user's o=iginal intent. It decouples the act of gr=nting an intent from the act of issuing specific access &nbs=; tokens. A client presents this Intent Token to an Authoriza=ion Server, which acts as a trusted intermediar=. The Authorization Server's responsibili=y is to interpret the user's stated intent and, =based on its policies, issue narrowly-scoped, short-lived access =div> tokens for specific resources, thereby ensuring the prin=iple of least privilege is upheld throughout th= process. The IETF datatracker status pa=e for this Internet-Draft is: https://datatracker.ietf.org/d=c/draft-chen-oauth-agent-intent-token/ T=ere is also an HTML version available at: https://www.ietf.o=g/archive/id/draft-chen-oauth-agent-intent-token-00.html &nb=p; Internet-Drafts are also available by rsync at: <=iv>rsync.ietf.org::internet-drafts = _______________________________________________ I-D-Announce mailing list -- [email protected] To unsub=cribe send an email to [email protected]
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
