Compare
AAuth is an individual IETF draft for agent-to-resource authorization with cryptographic client identity. It complements OAuth; it does not have an RFC number.
In one board · AAuth access modes
Draft-11·Draft-11 §4.2.1 — Agent Identity Access, the AAuth meaning of p2p
Agent and resource only. The resource decides from who the agent is. No person server, no access server, no grant of operations.
→ Signed HTTP · local policy →
Which passes exist
Dimmed tickets are not in this mode. Sealed tickets ride with a wax seal (RFC 9421). The session is a photocopy-proof opaque pass: the agent cannot open it.
The resource learns which agent called — not which human it serves. That is p2p in the AAuth sense, not A2A and not did:peer.
Draft-11 (25 September 2026) defines five modes, including person-identity and aa-person+jwt. Individual Internet-Draft — not an RFC, not an OAuth WG document. AAuth vs OAuth.
Animated sequence · AAuth
Identity-based, then three-party
Identity-based AAuth is signed HTTP with an agent token — no Agent Card, no AS in the path. JWKS fetch is a real hop. If the resource needs user claims, it steps up to a person server (not an OAuth AS) via 401 AAuth-Requirement and a resource token. Four-party adds a resource-side access server. That is still not A2A.
Now · 1/17· Discover· AAuth draftYou are here
Agent provider→Agent·Issues aa-agent+jwt bound to the agent's signing key
The agent provider issues typ aa-agent+jwt (sub = agent identifier, cnf binds the key). Optional ps names a person server — unused until three-party.
Why The provider attests the key. It is not an OAuth authorization server and mints no Bearer access token.
A wax-sealed ID card for the agent — not a photocopied pass.
Solid = from the spec
Not A2A (no Agent Card, no tasks). Not did:peer (the identifier is published so a stranger can verify a first request). Draft-11 has five modes, including person identity. Agent-identity mode has no AS. PS authorization uses a person server, not an OAuth AS.
| Aspect | Vanilla OAuth 2.x + OIDC | AAuth (draft-hardt-oauth-aauth-protocol-11) |
|---|---|---|
| Client identity | client_id issued by each AS. Meaningless at another AS. DCR or CIMD to mint one at runtime. | Agent identifier aauth:local@domain bound to a key, published at a well-known URL. No per-resource pre-registration. |
| Proof on the API call | Bearer token, or DPoP/mTLS if you opted in. | HTTP Message Signatures (RFC 9421) on every request. Stolen JWT without the key is useless. |
| How authorization starts | Redirect the user to /authorize, or CIBA, or client credentials. | Call the resource; receive AAuth-Requirement. First call can be the registration. Optional person server for user claims. |
| User identity | OIDC ID Token at the client; sub in the access token at the API. | Person server asserts claims (sub, email, groups, …) in an auth token. Identity is (iss, sub) at that PS. |
| Open-world discovery | RFC 9728 + RFC 8414. Still usually needs a client identifier at the AS. | Designed so an agent that knows only a hostname can sign a request and be understood. |
| Governance mid-task | Step-up (RFC 9470), CIBA, or a new authorize request. | Missions (natural language, s256-bound), permission/audit/interaction relay at the PS, optional R3 per-call. |
| Maturity | RFCs plus a late-stage 2.1 draft. What MCP and banks actually run. | Individual Internet-Draft, not a WG item. Published snapshot is draft-11 (five access modes). Implement only with a pinned revision. |
| Access modes | Grants: authorization code, client credentials, refresh, plus extensions (CIBA, 8693, 7523). | Draft-11: five modes (agent identity, resource-managed, person identity, PS authorization, federated authorization). Governance (missions) is orthogonal. Draft-10's four-mode table is obsolete. |
| Registration | Pre-register, DCR (RFC 7591), or CIMD (URL as client_id). | No AS-issued client_id. Agent provider issues aa-agent+jwt; resource fetches JWKS via iss+dwk. |
Use OAuth 2.1 where the API already is an OAuth RS (including MCP). Evaluate AAuth when the agent must identify itself to strangers without portals, or when you want signed requests instead of bearer tokens. Many systems will run both.
AAuth's own text says it complements OAuth. An MCP HTTP server in 2026 is still an OAuth 2.1 RS. Putting AAuth signatures on that same server is an extra profile, not what the MCP spec requires. CIMD is the OAuth WG's milder answer to 'no portal'.
The datatracker snapshot is draft-11 (25 September 2026). It includes person tokens (aa-person+jwt), person_token_endpoint, and auth_token_endpoint. Draft-10 does not. Interop between those two snapshots fails on typ and endpoint names.