AAuth is the AAuth Protocol, published as the individual Internet-Draft draft-hardt-oauth-aauth-protocol-11 (Dick Hardt, 25 September 2026). It defines cryptographic agent identity and agent-to-resource authorization using HTTP Message Signatures. It is not an RFC and not an OAuth Working Group document. Pin a snapshot before you implement.

What is the difference between p2p and A2A?

They are different doors. Next to AAuth, p2p usually means identity-based or two-party HTTP access: the agent and the resource, with no authorization server. A2A (Agent2Agent) is a Linux Foundation protocol for agent-to-agent tasks, using Agent Cards. did:peer and DIDComm are a third sense of p2p. This site treats those three as distinct.

What is the difference between OAuth 2.1 and OAuth 2.0?

OAuth 2.1 is not a new protocol. It is OAuth 2.0 with the unsafe bits removed and current practice folded in: authorization code plus PKCE, no implicit grant, no password grant, no access tokens in URLs, exact redirect matching. As of 1 November 2026 it is still a Working Group draft (draft-ietf-oauth-v2-1-17, 31 October 2026), not an RFC.

What are the four principals in agent identity?

User (which human this is for), agent instance (which running agent is calling), workload (which binary in which trust domain), and resource (which API). Each principal has a different proof. Putting the user into a SPIFFE ID, or treating an ID Token as an access token, collapses the map.

No. It is an individual Internet-Draft: not endorsed by the IETF, no RFC number. Draft-11 (25 September 2026) describes five resource access modes, including person identity. Read the datatracker HTML for the snapshot you pin.

Does OpenID Connect replace OAuth for AI agents?

No. OIDC is the user-identity layer on OAuth. OAuth 2.1 still does not tell a resource who the human is. User-delegated agents still use OIDC so the authorization server knows which person consented; the access token is what the API sees.

IETF · OIDF · W3C · 2025–2026

AI agent identity, authentication, and authorization

Who is the user?Who is the agent?Which binary?Which API?

If those collapse into one token, agent auth is already wrong. This site is a map of the RFCs and drafts people mean by OAuth 2.1, OIDC, AAuth, MCP, A2A, SPIFFE, and WIMSE: what each one is for, how they nest, and which door you are in (delegated OAuth vs AAuth p2p vs A2A vs did:peer).

Look for: the four seats below, then the four doors, then a spec page when you need the hop-by-hop flow. Not a new protocol. Not legal advice.

Open the catalog Open the patterns Walk a delegated call

Four principals

User, agent, workload, resource. Four names, four proofs. Do not smash them into one string.

Mental model · four seats

Click a seat

Most broken agent-auth designs collapse these four names. Keep them separate, then pick a proof for each. Arrow keys move the seats.

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.

How the specs nest

OAuth is the basement. Agent drafts are the attic. Do not skip floors.

ShareLinkedIn X

Identity — who

Four names, four identifiers. Do not collapse them.

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

Authentication — proof

Prove a key or a session. Bearer is a photocopy; DPoP glues the pass to a key.

RFC 9421 · DPoP · mTLS · OIDC · CIBA

Authorization — may

What the agent may do after you know who it is.

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

Deployment decides which floor you are on Sequences live on Flows, not on this map

Four doors named p2p

Delegated OAuth, AAuth p2p, A2A, and did:peer are four doors — not one protocol.

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

Ship RFCs. Pin drafts. Vendor protocols are real; they are not RFCs.

Stable enough to ship
You can implement these without pinning a moving draft.
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
Close to done. Still cite the revision you implemented.
OAuth 2.1 (draft-17, 31 Oct 2026; Dec 2026 IESG milestone), identity chaining (RFC Editor queue, still Awaiting First editor), transaction tokens (write-up), SD-JWT VC (IESG Evaluation, draft-23, 5 Nov 2026 telechat), CIMD, WIMSE suite, AIMS (WIMSE WG aims-00).
Individual drafts — expect churn
The table of modes will move. Pin a snapshot.
AAuth (draft-11, 25 Sep 2026, five modes), HTTP Signature Keys, AAuth R3 (draft-00, 28 Sep 2026, still exploratory), agent-grants, AAP (expired draft-01), WIMSE AI-agent identity (draft-04, 27 Oct 2026).
Vendor / foundation protocols
Real and deployed. They are not RFCs.
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

These are the papers people mean when they say AAuth, OIDC, OAuth 2.1, and SPIFFE in the same breath.

All 61 in the catalog →

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-17

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-06

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-11

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.

Questions people actually ask

Short answers you can quote. The compare pages and catalog carry the rest.

What is AAuth?: AAuth is the AAuth Protocol, published as the individual Internet-Draft draft-hardt-oauth-aauth-protocol-11 (Dick Hardt, 25 September 2026). It defines cryptographic agent identity and agent-to-resource authorization using HTTP Message Signatures. It is not an RFC and not an OAuth Working Group document. Pin a snapshot before you implement.
What is the difference between p2p and A2A?: They are different doors. Next to AAuth, p2p usually means identity-based or two-party HTTP access: the agent and the resource, with no authorization server. A2A (Agent2Agent) is a Linux Foundation protocol for agent-to-agent tasks, using Agent Cards. did:peer and DIDComm are a third sense of p2p. This site treats those three as distinct.
What is the difference between OAuth 2.1 and OAuth 2.0?: OAuth 2.1 is not a new protocol. It is OAuth 2.0 with the unsafe bits removed and current practice folded in: authorization code plus PKCE, no implicit grant, no password grant, no access tokens in URLs, exact redirect matching. As of 1 November 2026 it is still a Working Group draft (draft-ietf-oauth-v2-1-17, 31 October 2026), not an RFC.
What are the four principals in agent identity?: User (which human this is for), agent instance (which running agent is calling), workload (which binary in which trust domain), and resource (which API). Each principal has a different proof. Putting the user into a SPIFFE ID, or treating an ID Token as an access token, collapses the map.
Is AAuth an RFC?: No. It is an individual Internet-Draft: not endorsed by the IETF, no RFC number. Draft-11 (25 September 2026) describes five resource access modes, including person identity. Read the datatracker HTML for the snapshot you pin.
Does OpenID Connect replace OAuth for AI agents?: No. OIDC is the user-identity layer on OAuth. OAuth 2.1 still does not tell a resource who the human is. User-delegated agents still use OIDC so the authorization server knows which person consented; the access token is what the API sees.

See AAuth, OAuth 2.0 vs 2.1, delegated vs p2p, and the glossary.