Hi Thumilan, As you said, the idea of separation is very interesting. Thank you for your insightful feedback on the Intent Token draft. We appreciate the opportunity to clarify our thinking, and your analysis is precisely what we need to improve the draft. 1. On the Semantic Gap and the Role of the Signature You are absolutely correct that the AS must still interpret the client's request for a specific access token. The key distinction we aim to introduce with the Intent Token lies in what the AS is basing its decision on. The purpose of the signature is not to prove that the client's interpretation is correct. Instead, its purpose is to provide the AS with a non-repudiable, authentic record of the user's original, high-level instruction. Without the Intent Token: The AS receives a request from the client and must largely trust that the client is faithfully representing the user's wishes. With the Intent Token: The AS receives the client's request along with a verifiable, signed artifact from the user. The AS's job shifts from one of trust to one of validation. It can now programmatically check if the client's specific request for permissions (e.g., read:transaction:123) is a plausible and safe interpretation of the user's signed intent (e.g., "approve payment of $50 to Merchant X"). It moves the trust anchor from the client's request to the user's signed instruction, allowing the AS to make a much more informed and secure decision. We will make this critical point much clearer in the next version of the draft. 2. On the Distinction from Rich Authorization Requests (RAR) Your second question, comparing this to RAR, is equally important. The fundamental difference lies in the purpose, lifecycle, and the nature of the artifact itself. We see RAR (RFC 9396) as a mechanism to structure the authorization request within a single, typically synchronous OAuth flow. Its lifecycle is tied to that grant, and its goal is to produce an immediately usable access token. The authorization_details parameter is a transient part of that request. The Intent Token, by contrast, is designed to be a standalone, portable artifact—a signed JWT that is the output of a user consent process. Its key characteristics are: Artifact, not a Parameter: It is a self-contained credential, not just a parameter in a larger request. Asynchronous Delegation: It is created specifically to decouple the moment of user consent from the moment of execution by an agent. It represents a long-lived, delegated mandate that can be used later, perhaps multiple times, to mint specific, short-lived access tokens. Different Lifecycles: RAR's context is a single authorization grant. An Intent Token's context is the entire lifecycle of a user-delegated task, which could span hours, days, or even longer. Best, Meiling
[email protected] From: Thumilan Date: 2026-10-25 08:36 To: Meiling Chen CC: oauth; [email protected]; [email protected] Subject: [OAUTH-WG] Re: Follow-up on OAuth Interim Discussion: New Draft "Agent Intent Token" for Review 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/ 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: Capture Intent: Before an Agent begins any action, it negotiates and confirms a clear "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 authenticity. Pass Context: The Agent carries this Intent Token along with its subsequent requests to the Authorization Server. 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 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]
