| Internet-Draft | Intent Token | October 2026 |
| Chen, et al. | Expires 22 April 2027 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 22 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The core value of the Intent Token lies in its introduction of a two-stage model for AI agent-driven authorization, which resolves the "semantic gap" between high-level user intent and specific resource access permissions. This model aligns closely with the conceptual framework proposed in draft-chen-oauth-agent-authz-use-cases, which can be understood as the separation of a Semantic Authorization Stage and an Resource Authorization Stage.¶
Semantic Authorization Stage: Establishing Task Intent Baseline¶
User Action: A user expresses a high-level, business-oriented intent to an AI agent via natural language (e.g., "Help me plan a trip to Paris").¶
Core Artifact: This act of authorization by the user no longer results in the direct issuance of a broad, static set of scopes. Instead, it is captured and solidified into a verifiable, signed digital object—the Intent Token.¶
Conceptual Alignment: This Intent Token is the concrete manifestation of the "Semantic Authorization Intent" that the user bestows upon the agent. It represents the authoritative proof that the user "consents to the agent acting to achieve this goal,". While it helps agents determine required resources and allows the AS to verify approvals, it is not the final access permission itself.¶
Resource Authorization Stage: Executing the Intent¶
Agent Action: When the AI agent, based on its planning (e.g., it first needs to search for flights), determines that a specific operational permission is required (e.g., scope=flights:search), it makes a request to the Authorization Server.¶
Core Mechanism: In this request, the AI agent MUST present the Intent Token it previously obtained.¶
Conceptual Alignment: At this point, the role of the Intent Token transforms into "Execution Reference". It proves to the Authorization Server that the currently requested, specific, low-level scope (flights:search) conforms to the user's original, high-level intent ("plan a trip to Paris").¶
In this way, the Intent Token becomes the critical bridge connecting these two layers:¶
It is created at the Semantic Authorization Stage as the carrier of the user's intent authorization, assuring immutability.¶
It is used at the Resource Authorization Stage as indispensable reference for converting that intent into concrete resource permissions, avoiding intent drift.¶
This separation ensures that authorization decisions are no longer a one-time, vague, "all-or-nothing" process. Instead, the Authorization Server can, at each point a specific permission is needed, make a Just-in-Time, Fine-Grained, and Secure decision based on the user's original, immutable intent context provided by the Intent Token. This proposed extension stabilizes the overarching information flow while preserving the flexible selection of agents, thereby balancing the containment of unpredictable agent behaviors with the maximization of their autonomous planning potential.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174].¶
A string representing a high-level goal or objective that a user wishes to accomplish. This is typically captured from the user's natural language input or other user-endorsed information.¶
A security token (e.g., a JWT) that contains the user's intent and associated authorization constraints. It is signed by a trusted entity and serves as a verifiable record of the user's consent to that intent.¶
An OAuth 2.0 client that acts on behalf of the user to fulfill a given intent. It uses an Intent Token to request specific access tokens from the Authorization Server.¶
The OAuth 2.0 Authorization Server. In this context, it is enhanced to understand and process Intent Tokens. It validates the Intent Token and uses its claims as crucial input for authorization decisions.¶
The OAuth 2.0 Resource Server, which hosts the APIs the AI Agent needs to call. It receives access tokens issued by the AS.¶
The Intent Token is a signed assertion of a user's original intent. It is designed to be exchanged at an Authorization Server for one or more traditional Access Tokens. It is not intended to be presented directly to a Resource Server.¶
Intent Tokens are represented as JSON Web Tokens (JWTs) [RFC7519]. They MUST be signed to ensure their integrity and authenticity. The signing algorithm should be negotiated between the token issuer and the Authorization Server.¶
An Intent Token contains the following claims:¶
sub (Subject): RECOMMENDED. As defined in [RFC7519]. Represents the user who granted the intent.¶
aud (Audience): REQUIRED. As defined in [RFC7519]. The primary audience MUST be the Authorization Server that is expected to process the token.¶
client_id(Oauth Client identifier): REQUIRED. The client identifier of the OAuth 2.0 client (the AI Agent) to whom the Intent Token was issued. This binds the token to a specific client.¶
exp (Expiration Time): REQUIRED. As defined in [RFC7519]. Intent Tokens may be long-lived, representing a user's standing instruction.¶
jti (JWT ID): RECOMMENDED. As defined in [RFC7519]. A unique identifier for the token, which can be used to prevent reuse.¶
cnf (Confirmation): RECOMMENDED. The Confirmation claim, as defined in RFC 7800. It provides a mechanism for sender-constraining the token, binding it to a specific client key.¶
authorization_details: OPTIONAL. A JSON array of objects representing the structured authorization data associated with the intent, as defined by OAuth 2.0 Rich Authorization Requests [RFC9396]. This provides a machine-readable definition of the authorization boundaries (e.g., types of actions, locations, budget limits), complementing the natural language intent claim.¶
In addition to the standard JWT claims, the Intent Token defines two new claims:¶
intent_id: RECOMMENDED. A stable and unique identifier for the user's intent. This identifier can be used to correlate multiple token exchange requests that are all part of fulfilling the same high-level intent, which is useful for auditing and logging.¶
intent: REQUIRED. A JSON object that represents the user's delegated intent. The structure and semantics of this object are determined by the policies of the issuer and the Authorization Server. It serves as the canonical, auditable record of the user's goal.¶
This document has no IANA actions.¶
The analysis and use cases in this document are derived from observations of emerging AI agent technologies and their application trends across various industries. Thanks are due to the OAuth community for their past and ongoing efforts in building a secure and interoperable authorization framework, upon which this work is built.¶
The authors would like to thank Blake Morrison, Mohamad Khalil Yossif, niyuan, Dick Hardt, Michael Jones, Christopher Emerson, morganLR, Eric Leleu, Thi Nguyen-Huu, Jeff, Laxmikant and Iman for commenting, contributing and providing feedback on this draft.¶