Skip to content
Agent Identity

IETF · OIDF · W3C · 2025–2026

Identity, authentication, and authorization for AI agents

A readable map of the specifications people mean when they say AAuth, p2p, OIDC, and OAuth 2.1 — plus the surrounding cluster that actually exists on datatracker, at the OpenID Foundation, and in MCP/A2A. 61 documents, researched 15 September 2026. Drafts change; this is a field guide, not a substitute for the source. The four principals below are the mental model; click a seat to see how that party proves itself.

Four principalsDeployment patternsOpen the catalog

Mental model · four seats

Four principals — click one

Most broken agent-auth designs collapse these four names. Keep them separate, then pick a proof for each. This board is the map; the catalog is the shelf.

User

User / person / resource owner

OpenID Connect (ID Token, UserInfo), AAuth person/auth tokens from a person server, sometimes a Verifiable Credential.

ID Tokenaa-person+jwt

Not the same as: The agent process. Putting the user into a SPIFFE ID or using an ID Token as an access token collapses this distinction.

Typical id: OIDC / person server

One HTTP call can prove more than one of these. Do not smash them into a single string. Tokens are passes; signatures are wax seals.

Identity — who

User / person. Agent instance. Workload. Tool/resource. Four names, four identifiers. Do not collapse them.

OIDC sub · AAuth agent token · SPIFFE/WIMSE · RFC 9728 resource

Authentication — proof

Prove control of a key or a session. Redirects and CIBA for humans. Seals, mTLS, DPoP, WPT for machines. Bearer is a photocopy; DPoP glues the pass to a key.

RFC 9421 · DPoP · mTLS · OIDC · CIBA

Authorization — may

Grants, audiences, attenuation, missions, human approval. What the agent is allowed to do after you know who it is.

OAuth 2.1 · RFC 8693 · RAR · AAuth missions · FAPI 2.0

How the specs nest

  1. Foundation

    OAuth 2.0 as constrained by RFC 9700, heading toward OAuth 2.1. OIDC answers who the user is. JWT profiles carry claims. Discovery via RFC 8414 and RFC 9728.

  2. Delegation extensions

    Token exchange, identity chaining, XAA, transaction tokens — how an agent acts for a user across hops and domains without minting a new protocol.

  3. Workload identity

    SPIFFE and WIMSE name the binary. They do not replace user delegation; they sit beside it.

  4. Agent-native drafts

    AAuth (including its two-party / identity-based “p2p” modes), AIMS, R3. Individual or early WG work. Pin revisions.

  5. Application protocols

    MCP authorization is an OAuth 2.1 profile. A2A is how agents talk; it reuses OAuth/OIDC/mTLS. GNAP is a finished IETF alternative to OAuth, not the default path.

Deployment → protocol

How the agent actually runs decides which of those specs apply: product UI, headless worker, MCP host, mesh sidecar, AAuth p2p HTTP. Not the same cut as the sequence diagrams under Flows.

Interactive delegated · MCP host · AAuth p2p · sidecar

Four doors named p2p

Delegated OAuth, AAuth identity-based / two-party, A2A tasking, and did:peer are four different doors. Click through which has an AS, which token shows up, and which cousin people mix in.

AS in path? · what token? · wrong cousin

What AAuth actually is

AAuth is draft-hardt-oauth-aauth-protocol (rev 10, 6 August 2026), an individual IETF Internet-Draft by Dick Hardt. It is not draft-oauth-aauth as a working-group item and it is not an RFC. It gives every HTTP client a cryptographic identity. The published snapshot defines four resource access modes (identity-based, resource-managed two-party, PS-asserted three-party, federated four-party) plus optional missions. The editor's copy (September 2026) adds a fifth mode — person-identity — and aa-person+jwt. It builds on RFC 9421 and draft-hardt-httpbis-signature-key-09. It reuses OIDC claim vocabulary and says it complements OAuth rather than replacing it.

Restage the access modes

What “p2p” actually is

There is no current IETF RFC or WG draft whose title is simply 'P2P' in the AAuth cluster. When people list 'aauth, p2p, OIDC, OAuth 2.1' they usually mean AAuth's identity-based and two-party modes: the agent and the resource speak directly, with HTTP Message Signatures, without an authorization server in the path. Identity-based: the resource decides from the agent token alone. Two-party (resource-managed): the resource runs its own login and issues an opaque session bound to the agent's key. Separate meanings you will also hear, and must keep apart: (a) A2A agent-to-agent task protocol — Agent Cards and out-of-band HTTP auth, not AAuth signatures; (b) did:peer + DIDComm pairwise identity — not globally resolvable, not for a stranger's first HTTP call. The editor's AAuth person-identity mode is a fifth access mode that carries a user identifier without a grant — federated login, not identity-based p2p. This site labels those explicitly so they are not mashed together.

Walk the identity-based flow

In one board · four doors

Delegated · AAuth p2p · A2A · did:peer

AS in path?
Yes — an authorization server mints the access token
What token?
Bearer or DPoP pass; sub is the user; agent is client_id or act
access token
UserAgent (client)ASAPI

Wrong cousin: Not AAuth identity-based: there is very much an AS. Putting this pass on an A2A call without aud and actor binding is a confused deputy.

Open this door →

There is no IETF RFC titled P2P in this cluster. The word is meeting shorthand. Pick one door and stay in it.

Honest maturity

  • Stable enough to ship

    RFC 6749 family as constrained by RFC 9700; OIDC Core; PKCE; PAR; DPoP; mTLS; RFC 9068; RFC 8693; RFC 9728; RFC 9421; GNAP RFCs; FAPI 2.0; CIBA; SSF/CAEP; MCP-over-OAuth as a protocol (while its cited OAuth 2.1 revision lags).

  • Late-stage drafts

    OAuth 2.1 (WG, Dec 2026 IESG milestone), identity chaining (RFC Editor queue), transaction tokens (write-up), SD-JWT VC (Last Call as of 15 Sep 2026), CIMD, WIMSE suite.

  • Individual drafts — expect churn

    AAuth (draft-10 vs editor's five-mode copy), HTTP Signature Keys, AAuth R3, AIMS, agent-grants, AAP, WIMSE AI-agent identity.

  • Vendor / foundation protocols

    MCP specification, A2A v1.0 under AAIF/Linux Foundation, SPIFFE, DIDComm, did:peer. These are real and deployed; they are not RFCs.

Start with these documents

All 61 →
RFCStableAuthorizationFoundationField guide
OAuth 2.0
RFC 6749

Almost every production 'agent calls an API on behalf of a user' design is still an OAuth 2.0 client using an authorization grant. AAuth, MCP authorization, and A2A security schemes all assume you know this model so they can extend or replace parts of it.

WG draftDraft — expect changeAuthorizationFoundationField guide
OAuth 2.1
draft-ietf-oauth-v2-1-16

This is the security baseline MCP, FAPI 2.0 thinking, and most 'agent as OAuth client' designs now assume: PKCE always, no implicit, no password grant, no tokens in URLs. If your agent SDK still does implicit or stores refresh tokens unbound in local storage, it is not 2.1-shaped.

RFCStableIdentity + Authn + AuthzFoundationField guide
OAuth Security BCP
RFC 9700 (BCP 240)

Agent runtimes leak tokens through logs, traces, and model context. RFC 9700's push toward sender-constrained, audience-restricted, short-lived tokens is the cheapest security upgrade you can make before AAuth or WIMSE.

RFCStableAuthorizationFoundationField guide
Token Exchange
RFC 8693

This, plus RFC 9068 JWT access tokens, is the backbone of 'the agent acts for the user at an API'. Multi-agent call chains that stay in OAuth-land are token exchanges with act, not new protocols.

RFCStableAuthorizationFoundationField guide
JWT access tokens
RFC 9068

When an agent calls an API, the RS should see both who the user is (sub) and which agent/client is calling (client_id), plus optional act. Opaque tokens hide that from the RS unless it introspects.

RFCStableIdentity + Authn + AuthzFoundationField guide
Protected Resource Metadata
RFC 9728

This is how an agent goes from 'I have a URL' to 'I know which AS to use and which audience to request' without a human pasting client IDs.

WG draftDraft — expect changeIdentity + Authn + AuthzFoundationField guide
Identity chaining
draft-ietf-oauth-identity-chaining-17

Enterprise agents that read mail in tenant A and file tickets in SaaS B are exactly this pattern. XAA is a profile of this draft for IdP-brokered app-to-app access.

WG draftDraft — expect changeAuthorizationAgent-specificField guide
Cross-App Access (ID-JAG)
draft-ietf-oauth-identity-assertion-authz-grant-04

This is the emerging 'enterprise agent may call SaaS APIs as the employee' path that scales past per-tool OAuth popups. Still a draft; pin versions and test interoperability.

Individual draftDraft — expect changeIdentity + Authn + AuthzAgent-specificField guide
AAuth
draft-hardt-oauth-aauth-protocol-10

This is the draft people mean by 'AAuth'. It is the most complete attempt at agent-native identity plus authorization that still reuses OIDC claim vocabulary and HTTP. If you are evaluating whether agents can skip OAuth client registration, start here — and stay honest that it is an individual draft.