The Intent Token - A Credential for Delegated User Intent
draft-chen-oauth-agent-intent-token-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Meiling Chen , Li Su , Peter Chunchi Liu | ||
| Last updated | 2026-10-19 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-chen-oauth-agent-intent-token-00
OAuth Working Group M. Chen
Internet-Draft L. Su
Intended status: Standards Track China Mobile
Expires: 22 April 2027 P. C. Liu
Huawei
19 October 2026
The Intent Token - A Credential for Delegated User Intent
draft-chen-oauth-agent-intent-token-00
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.
Status of This Memo
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.
Chen, et al. Expires 22 April 2027 [Page 1]
Internet-Draft Intent Token October 2026
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. The Semantic Gap in Authorization . . . . . . . . . . . . 2
1.2. Core Concept: Separating Grant from Execution . . . . . . 3
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. The Intent Token . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Format . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Claims . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3.1. Example Intent Token Payload . . . . . . . . . . . . 6
4. Interaction Model using Token Exchange . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
1.1. The Semantic Gap in Authorization
Traditional OAuth 2.0 [RFC6749] relies on a pre-defined set of scope
values that a user consents to. This model works well when the
requested permissions are simple and easily understood by the user
(e.g., "read your profile," "access your calendar").
However, modern applications, especially those driven by AI and
agents, operate based on high-level user goals, not low-level API
permissions. A user might command an agent: "Plan my business trip
to the IETF meeting in Singapore next month." Such natural language
Chen, et al. Expires 22 April 2027 [Page 2]
Internet-Draft Intent Token October 2026
instructions need to be interpreted by AI agents, which then
determine the specific resource requests required to complete the
task.
For example, to fulfill the abovementioned task, the agent might need
to: * Read the user's calendar to check for conflicts
(calendar.read). * Access the user's contacts to find travel
companions (contacts.read). * Search for flights and hotels
(flight.search, hotel.search). * Book the chosen options using a
stored payment method (payment.execute).
The core problem is the *semantic gap*: the user approves a high-
level _intent_, but the system must translate this into a set of low-
level _permissions_. If this translation happens unchecked on the
client side, it creates a major security risk. A malicious or buggy
client could request far more permissions than the intent strictly
requires, and the user would have no way of knowing. This breaks the
principle of least privilege. Therefore, authorizing the user's
original intent—even if it contains a certain degree of vagueness
(such as natural language)—helps verify whether the agent's
subsequent resource requests align with that intent, thereby
preventing 'intent drift.
1.2. Core Concept: Separating Grant from Execution
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*.
1. *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
Chen, et al. Expires 22 April 2027 [Page 3]
Internet-Draft Intent Token October 2026
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.
2. *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.
1.3. Requirements Language
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].
Chen, et al. Expires 22 April 2027 [Page 4]
Internet-Draft Intent Token October 2026
2. Terminology
*Intent* 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.
*Intent Token* 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.
*AI Agent (Client)* 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.
*Authorization Server (AS)* 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.
*Resource Server (RS)* The OAuth 2.0 Resource Server, which hosts
the APIs the AI Agent needs to call. It receives access tokens
issued by the AS.
3. The Intent Token
3.1. Overview
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.
3.2. Format
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.
3.3. Claims
An Intent Token contains the following claims:
* *iss* (Issuer): REQUIRED. As defined in [RFC7519].
* *sub* (Subject): RECOMMENDED. As defined in [RFC7519].
Represents the user who granted the intent.
Chen, et al. Expires 22 April 2027 [Page 5]
Internet-Draft Intent Token October 2026
* *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.
* *iat* (Issued At): REQUIRED. As defined in [RFC7519].
* *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.
3.3.1. Example Intent Token Payload
TBD
Chen, et al. Expires 22 April 2027 [Page 6]
Internet-Draft Intent Token October 2026
4. Interaction Model using Token Exchange
TBD
5. Security Considerations
TBD
6. IANA Considerations
This document has no IANA actions.
7. Acknowledgements
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.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
RFC 6749, DOI 10.17487/RFC6749, October 2012,
<https://www.rfc-editor.org/rfc/rfc6749>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/rfc/rfc7519>.
Chen, et al. Expires 22 April 2027 [Page 7]
Internet-Draft Intent Token October 2026
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/rfc/rfc8693>.
8.2. Informative References
[RFC7009] Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "OAuth
2.0 Token Revocation", RFC 7009, DOI 10.17487/RFC7009,
August 2013, <https://www.rfc-editor.org/rfc/rfc7009>.
[RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T.
Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication
and Certificate-Bound Access Tokens", RFC 8705,
DOI 10.17487/RFC8705, February 2020,
<https://www.rfc-editor.org/rfc/rfc8705>.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396,
DOI 10.17487/RFC9396, May 2023,
<https://www.rfc-editor.org/rfc/rfc9396>.
Authors' Addresses
Meiling Chen
China Mobile
BeiJing
China
Email: chenmeiling@chinamobile.com
Li Su
China Mobile
BeiJing
China
Email: suli@chinamobile.com
Peter Chunchi Liu
Huawei
China
Email: liuchunchi@huawei.com
Chen, et al. Expires 22 April 2027 [Page 8]