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-10·Draft-10 §4.1.1 — 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-10 (6 August 2026) has four modes. Person-identity and aa-person+jwt are the editor's fifth. Individual Internet-Draft — not an RFC, not an OAuth WG document. AAuth vs OAuth.
| Aspect | Vanilla OAuth 2.x + OIDC | AAuth (draft-hardt-oauth-aauth-protocol-10) |
|---|---|---|
| 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. Editor's copy is moving (four vs five access modes). Implement only with pinned revisions. |
| Access modes | Grants: authorization code, client credentials, refresh, plus extensions (CIBA, 8693, 7523). | Draft-10: four modes (identity-based, resource-managed, PS-asserted, federated). Editor's copy: five (adds person-identity). Governance (missions) is orthogonal. |
| 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'.
Pin draft-10 if you need a datatracker snapshot. Pin the editor's copy if you need person tokens (aa-person+jwt) and person_token_endpoint. Interop between those two snapshots will fail on typ and endpoint names (token_endpoint vs auth_token_endpoint).