Hi Karl,
Thank you so much for your feedback on the Intent Token draft. It's also very
encouraging to hear about the conceptual overlap with your work on
Mission-Bound Authorization; it suggests we're converging on a common and
necessary pattern.
Your feedback has already helped clarify how we should position and explain
this concept.
On the Core Problem: Authenticating Intent vs. Approving Authority
You are absolutely right to distinguish between authenticating the user's
instruction and approving the authority to carry it out. Your statement, "A
signature protects the issuer's assertion, but does not by itself establish
that a requested scope correctly interprets the instruction," is the perfect
articulation of the "authorization context gap" we aim to close.
The core design principle of the Intent Token is that the client (the AI Agent)
is NOT the trusted interpreter of the intent. Instead, the Intent Token serves
as a signed, immutable piece of evidence that is presented to the Authorization
Server (AS). The AS is the trusted party responsible for:
Validating the token's authenticity.
Interpreting the natural language intent claim against its own policies, the
user's profile, and any other context.
Issuing narrowly scoped, short-lived access tokens only if the requested scope
is a plausible and permissible interpretation of the original intent.
The signature doesn't prove the interpretation is correct; it proves what the
original instruction was, allowing the AS to make an informed decision about
the interpretation. We will make this crucial point much clearer in the
introduction of the next draft.
Answers to Your Specific 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?
This is a fantastic question. The authority ceiling is a combination of both,
but it is ultimately enforced by the AS at each exchange.
At Issuance: The Intent Token itself does not (and should not) contain a fixed,
exhaustive set of scopes. It contains the inputs for the authorization
decision: the user's intent and optionally, some high-level constraints in
authorization_details (e.g., "max_budget: $500").
At Exchange: The ultimate authority ceiling is determined dynamically by the AS
policy. This policy takes the intent claim, authorization_details, the
requested scope, the client's identity, and the user's overall permissions into
account. For example, the AS policy might state: "For an intent 'plan a trip',
scopes like calendar.read and flight.search are permissible, but
contacts.delete is not."
So,The Intent Token itself carries the fixed, high-level intent ceiling
approved by the user, this provides the long-term strategic guardrails. The
Authorization Server enforces this ceiling and applies its own policies to
issue short-lived, narrowly-scoped access tokens with a dynamic operational
ceiling for each specific task. This ensures just-in-time, least-privilege
security at the tactical level.
2. When authorization_details is present, can later interpretation of the
intent exceed it?
No. The authorization_details claim, being structured and machine-readable (per
RFC 9396), acts as a hard boundary. The natural language intent claim provides
context for decisions within that boundary.
For example, if authorization_details specifies a max_amount of 100 EUR for a
purchase, the AS MUST NOT issue a token that could lead to a charge greater
than that, regardless of how the intent string ("buy me the best new phone") is
interpreted. The structured data provides the non-negotiable guardrails, while
the unstructured intent guides the actions within them. We will add explicit
text to clarify this precedence.
3. Who issues the Intent Token, and what does it attest about the user's
consent?
This is a critical point about the trust model that the current draft needs to
elaborate on.
Issuer: The Intent Token MUST be issued by a party trusted by the Authorization
Server. In the most common flow, the Authorization Server itself would be the
issuer. The user would be redirected to an AS-hosted page (or a trusted
component) where they type or confirm their intent. The AS then captures this,
authenticates the user, and issues the signed Intent Token back to the client.
Attestation: The Intent Token attests to the following: "At time iat, the
authenticated user sub reviewed and consented to the goal described in the
intent claim, and delegated the authority to pursue this goal to the client
client_id."
It is a verifiable record of consent to the high-level goal, not to a specific
set of API permissions. This is the fundamental shift.
Mission-Bound Authorization and Collaboration
We position the Intent Token precisely as such a foundational component. Its
core objective is remarkably focused:
To create a signed, portable, and self-contained artifact that attests to a
user's approval of a high-level intent at a specific point in time.
Viewed from this perspective, our work and yours are perfectly complementary:
The Intent Token is a standalone "foundational primitive": Its value is not
confined to any single architecture. Any system requiring asynchronous
approvals, task delegation, or the decoupling of user consent from subsequent
actions can benefit from the Intent Token.
Mission-Bound Authorization is an "ideal application" for the Intent Token:
Within the broader architecture of Mission-Bound Authorization, our Intent
Token can serve as a perfect, off-the-shelf implementation of the "Intent
Submission Evidence" you mentioned. It addresses the critical question of "how
to securely submit a user-approved intent to the Mission Issuer" in a
standardized manner.
For the interim meeting, the answer is YES.
As the Intent Token design is still in its preliminary phase, we are actively
seeking community contributions to help refine and advance the proposal.
Best,
Meiling
[email protected]
From: Karl McGuinness
Date: 2026-10-25 04:11
To: Meiling Chen
CC: oauth
Subject: Re: [OAUTH-WG] Follow-up on OAuth Interim Discussion: New Draft "Agent
Intent Token" for Review
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.
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:
Where does the authority ceiling come from? Is it fixed when the Intent Token
is issued, or set by AS policy at each exchange?
When authorization_details is present, can later interpretation of the intent
exceed it?
Who issues the Intent Token, and what does it attest about the user's consent?
In Mission's direct approval flow, 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. I'd welcome exploring
that mapping together.
I'm presenting Mission at the OAuth interim on Monday, October 26, at 17:00
UTC. 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/
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]
