Hi Yuan, Thank you for your excellent feedback. Your suggestion to add a discovery mechanism for supported intent types is a fantastic point that addresses a critical aspect of interoperability. To ensure we track this properly, I have created a GitHub issue to capture your proposal. It is tracked as Issue #6. https://github.com/Maisy-ML/Agent-Intent-Token/issues/6 We would be delighted to have you collaborate with us on this. Please feel free to add any further thoughts or help us refine the proposal directly on the issue. Best, Meiling
[email protected] 发件人： niyuan 发送时间： 2026-11-05 10:34 收件人： 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, Thanks for clarifying. A small set of common fields with room for extensions makes sense to me. An AS can already advertise supported scopes and authorization details types through OAuth metadata. Yaron’s Authority Metadata draft builds on this by describing the permissions associated with them (https://datatracker.ietf.org/doc/draft-zehavi-oauth-authority-metadata/). I wonder whether we could apply a similar approach to intent types. For example, the AS could advertise the intent types it supports, with references to definitions of their fields and meanings. The Intent Token issuer could consult this information when constructing the intent object, so it knows what the AS can understand. My initial thought is that this might help with deployment while preserving flexibility for different applications. I look forward to hearing your thoughts. Best, Yuan 发件人: Meiling Chen <[email protected]> 发送时间: 2026年11月5日 10:16 收件人: niyuan <[email protected]>; oauth <[email protected]> 抄送: Zhukeyi(Kaiyin,Datacom Standard&Patent) <[email protected]> 主题: Re: 回复: [OAUTH-WG] Follow-up on OAuth Interim Discussion: New Draft "Agent Intent Token" for Review 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]
