Hi Meiling, I find the idea of separating high-level user intent from resource-level authorization interesting. However, I have a couple of questions regarding how the proposed mechanism addresses the semantic gap and how it differs from existing OAuth capabilities.
*1. How does the Intent Token address the intent-to-permission semantic gap?* The draft mentions that the Intent Token bridges the gap between high-level user intent and resource-level permissions. However, Section 3.3 leaves the interpretation of the intent claim to the AS. As I understand it, signing the intent ensures its integrity, but it doesn't necessarily help the AS determine whether a requested permission aligns with the original intent. For example, if a user authorizes an agent to "plan a trip," and the agent later requests payment.execute, how does the AS determine whether that permission falls within the user's original intent? Wouldn't this still depend on AS-specific logic, regardless of whether the intent is represented as a signed token? *2. Why is a separate Intent Token needed instead of using RAR?* RFC 9396 already supports structured authorization details, including custom types and constraints. Couldn't we represent the user's intent using RAR, obtain consent, and then issue narrower access tokens based on the approved authorization details? I'm trying to understand what additional security or interoperability benefit a separate Intent Token provides over RAR combined with existing OAuth mechanisms. Best regards, M.Thumilan On Fri, 23 Oct 2026 at 14:43, Meiling Chen <[email protected]> wrote: > Hi all, > > During the recent OAuth Interim Meeting (interim-2026-oauth-09), we had a > productive discussion around Use Cases and Gaps, with a significant focus > on the "Authorization Context Gap." > > A key challenge we discussed was the risk of 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" highlighted this problem > perfectly. The consensus was that relying solely on the agent's judgment is > unreliable, and we need a mechanism to ensure that subsequent actions, like > authorization requests, strictly adhere to the user's original, confirmed > intent. > > Inspired by this discussion and to address this gap, a new IETF draft has > been written: *"OAuth Agent Intent Token".* > > Draft Link: > <https://datatracker.ietf.org/doc/draft-chen-oauth-agent-intent-token/> > https://datatracker.ietf.org/doc/draft-chen-oauth-agent-intent-token/ > > *What is an "Intent Token"?* > > The core idea is to create a signed, structured data object (e.g., a JWT) > that encapsulates the user's original intent. The flow works as follows: > > 1. Capture Intent: Before an Agent begins any action, it negotiates > and confirms a clear "intent" with the user. > 2. Generate Token: This confirmed intent is then packaged into an > "Intent Token" and signed by a trusted entity to ensure its integrity and > authenticity. > 3. Pass Context: The Agent carries this Intent Token along with its > subsequent requests to the Authorization Server. > 4. Validate & Decide: The Authorization Server can then validate the > token's signature, parse the intent, and compare the current request > against the original intent recorded in the token. This enables a more > precise and secure authorization decision. > > This mechanism aims to fill the authorization context gap, ensuring that > even if an agent is "confused" or untrusted, the final authorization > decision remains faithful to the user's will, while also providing a better > framework for protecting user privacy. > > This draft is our initial attempt to formalize the ideas from our > discussion, and we would greatly appreciate your feedback and insights. We > invite you all to review the draft and share any questions, suggestions, or > comments on the mailing list. > > Thank you for the engaging discussion during the meeting. We look forward > to collaborating with you to refine this proposal. > > Best, > Meiling > ------------------------------ > [email protected] > > > *From:* internet-drafts <[email protected]> > *Date:* 2026-10-20 04:05 > *To:* [email protected] > *Subject:* I-D Action: draft-chen-oauth-agent-intent-token-00.txt > Internet-Draft draft-chen-oauth-agent-intent-token-00.txt is now available. > > Title: The Intent Token - A Credential for Delegated User Intent > Authors: Meiling Chen > Li Su > Peter Chunchi Liu > Name: draft-chen-oauth-agent-intent-token-00.txt > Pages: 8 > Dates: 2026-10-19 > > Abstract: > > In the scenario of AI agent authorization, how to ensure that a > user's high-level, natural-language intent is correctly and safely > converted into low-level, specific authorization grants. A > misunderstanding or malicious interpretation during this translation > can lead to significant security vulnerabilities. This document > introduces the "Intent Token," a new type of security token designed > to bridge this semantic gap. The Intent Token is a signed credential > that immutably captures the user's original intent. It decouples the > act of granting an intent from the act of issuing specific access > tokens. A client presents this Intent Token to an Authorization > Server, which acts as a trusted intermediary. The Authorization > Server's responsibility is to interpret the user's stated intent and, > based on its policies, issue narrowly-scoped, short-lived access > tokens for specific resources, thereby ensuring the principle of > least privilege is upheld throughout the process. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-chen-oauth-agent-intent-token/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-chen-oauth-agent-intent-token-00.html > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > _______________________________________________ > I-D-Announce mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
