OAuth scopes vs mandates: what a token allows and what a person approved

OAuth scopes are for limiting what an access token lets a client do at a resource server, using short strings that the authorization server defines, such as orders:read. Mandates are for recording, in a signed form any verifier can check, the specific action a person approved an agent to take and the limits on it, so the business can confirm the approval before it acts.

A scope describes a permission category that a client holds. A mandate describes a decision a principal made. Agent traffic needs both answers, and the two mechanisms are converging from opposite ends: OAuth grew Rich Authorization Requests to describe specific transactions, while mandate formats such as AP2’s describe specific transactions from the start.

Status as of September 26, 2026. OAuth 2.0 (RFC 6749, 2012) and Rich Authorization Requests (RFC 9396, May 2023) are IETF standards. OAuth 2.1 is still an Internet-Draft; its latest revision, draft-ietf-oauth-v2-1-16, is dated September 3, 2026. Several individual Internet-Drafts propose OAuth profiles for AI agents, such as draft-mishra-oauth-agent-grants-02 (August 30, 2026); none is an OAuth working group document. The concrete mandate format examined here is AP2’s, from the Agent Payments Protocol. AP2 v0.2, released April 28, 2026, replaced the earlier Intent and Cart Mandates with Checkout and Payment Mandates, and on the same day Google announced it is donating AP2 to the FIDO Alliance. Emissar’s own Mandate module, a general-purpose credential of this kind, has the status Spec in progress.

What OAuth scopes are for

In OAuth 2.0 a client asks an authorization server for an access token and names the access it wants in the scope parameter. RFC 6749 section 3.3 defines scope as a list of space-delimited, case-sensitive strings whose meaning the authorization server defines. The server may grant less than requested, and must then say which scope it granted.

Scopes work well for standing permissions: a mail client that may read mail, an integration that may create invoices. They are coarse by design. payments:write says the client may make payments. It does not say which payment, to whom, how much, or that the account holder approved this one.

RFC 9396, Rich Authorization Requests, fills that gap. A client sends authorization_details, a JSON array of objects. Each object has a required type and may use common fields such as locations, actions, datatypes, identifier and privileges, plus fields its type defines. The authorization server shows the details to the user for consent and returns the granted details with the token. Illustrative request for a single cancellation:

[
  {
    "type": "subscription_change",
    "locations": ["https://api.streaming.example/"],
    "actions": ["cancel"],
    "identifier": "SUB-3310"
  }
]

Other OAuth extensions complete the picture for agents. RFC 8693 token exchange can mark a token with an act claim naming the party acting for the user. DPoP (RFC 9449) binds a token to a key the client proves it holds on each request. RFC 7009 lets a token be revoked at the authorization server.

What mandates are for

A mandate records the principal’s decision itself. It is signed so that it traces back to the principal’s approval, bound to the agent that will present it, and specific enough for a verifier to compare against the request in front of it. The verifier does not need to trust the agent’s word or share an authorization server with anyone.

AP2 v0.2 is the concrete example. A user approves mandate content on a Trusted Surface, an interface the specification requires to be non-agentic. Two mandate types result, each an SD-JWT verifiable credential:

AP2 v0.2 mandate	What it covers	Checked by
Checkout Mandate	What is bought; bound by hash to a checkout the merchant signed	The merchant
Payment Mandate	How that checkout is paid	The credential provider, the payment network and the merchant’s payment processor

Each comes in two forms. A closed mandate covers one specific transaction, approved while the user is present. An open mandate carries constraints the user approved in advance. In a human-not-present flow, the agent later signs closed mandates within those constraints, with a key the open mandate names. AP2 v0.2 defines no revocation mechanism; it relies on expiry and on single-use rules instead.

The gap between them in A2A

A2A agents meet this question directly. When an agent needs approval mid-task, it moves the task to TASK_STATE_AUTH_REQUIRED. Section 7.6.4 of the specification says the protocol does not define the scope, representation, validity or revocation of the resulting credential, and that the state change alone must not be treated as authorization for any operation. Section 7.6.3 recommends that credentials passed in-band be bound to the requesting agent. Whether you fill the gap with an OAuth token carrying authorization_details, an AP2 mandate, or another signed credential is up to the implementation or an extension.

Side by side

	OAuth scopes and RAR	Mandates (for example AP2 v0.2)
Purpose	Limit what an access token lets a client do	Prove what a principal approved an agent to do, within stated limits
Layer	Authorization framework between client, authorization server and resource server	Signed credential presented to any verifier in a transaction
Who talks to whom	The client obtains a token; the resource server checks it	The agent presents the mandate; each party in the flow verifies it
Transport	Token requests over HTTPS; tokens usually in the Authorization header	Carried inside another protocol; AP2 is designed as an extension for A2A, MCP and UCP
Discovery	Authorization server metadata; resource indicators	Defined by each mandate format; AP2 specifies which roles verify which mandate
Auth	Scope strings or typed authorization_details; optional DPoP or mTLS binding	Principal’s signature; agent binding through a key in the mandate
State	Token lifetime; revocation (RFC 7009) and introspection	Expiry and single-use rules in AP2 v0.2; no revocation defined
Governance and status	IETF RFCs; OAuth 2.1 still a draft	AP2 v0.2 (April 28, 2026), being donated to the FIDO Alliance; no general standard yet

When to use each

Use OAuth scopes to give an agent standing access to an API: read order history, create support tickets, check balances. Keep scopes narrow, bind tokens to the agent with DPoP or mutual TLS, and keep lifetimes short.

Use RFC 9396 authorization details when one authorization server and its resource servers need to know the exact action a user approved, and all of them trust that server.

Use a mandate when the approval must travel. If a merchant, a card network and a payment processor each need to check the same approval independently, or a business needs evidence it can keep and show in a dispute, a signed mandate carries the decision itself.

Using both

They stack. OAuth authenticates the agent and gives it access to APIs; the mandate proves the principal approved this particular action. In an A2A exchange, the client can authenticate with the OAuth scheme declared in the Agent Card, and present a mandate when the remote agent enters TASK_STATE_AUTH_REQUIRED. The remote agent checks the token for who is calling and the mandate for what was approved, then logs both. Delegated authority walks through a complete example.

Common misconceptions

“A payments:write scope proves the user approved this payment.” It proves the client may make payments. The approval of a specific payment has to be recorded somewhere else: in authorization_details, a mandate, or a step-up with the user.

“Mandates replace OAuth.” A mandate carries the principal’s decision. Services still need to authenticate the client that presents it and control that client’s access to their APIs, which is the job OAuth does.

“TASK_STATE_AUTH_REQUIRED defines a credential.” It signals that one is needed. A2A leaves its format, scope, validity and revocation to others.

“A signed approval stays valid until it expires.” A signature proves who approved. Whether the approval still stands needs a check: OAuth has revocation and introspection, and a mandate format needs its own expiry and revocation rules.