Hi Meiling, Thanks for the Intent Token draft. The separation between approving a task and issuing individual access tokens overlaps with questions I've been working through in Mission-Bound Authorization <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-mission-architecture.html> .
Authenticating the user's instruction and approving the authority to carry it out seem like different problems to me. A signature protects the issuer's assertion, but does not by itself establish that a requested scope correctly interprets the instruction. A few questions: 1. Where does the authority ceiling come from? Is it fixed when the Intent Token is issued, or set by AS policy at each exchange? 2. When authorization_details is present, can later interpretation of the intent exceed it? 3. Who issues the Intent Token, and what does it attest about the user's consent? In Mission's direct approval flow <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission.html#direct-approval-steps>, the Approver sees the task description alongside a structured Authority Set. Subsequent issuance stays within the approved authority and is gated on Mission state. This makes the approval boundary explicit; it does not prove that the proposed authority faithfully interprets the original instruction. Depending on its consent semantics, an Intent Token might also fit as authenticated input through Intent Submission Evidence <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission.html#intent-submission-evidence>. I'd welcome exploring that mapping together. I'm presenting Mission at the OAuth interim on Monday, October 26, at 17:00 UTC <https://datatracker.ietf.org/meeting/interim-2026-oauth-10/session/oauth>. Please join if you can. -Karl On Fri, Oct 23, 2026 at 2:13 AM 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]
