AAuth

AAuth is Dick Hardt’s answer to a problem he helped create. He wrote OAuth 2.0 for a world where a client was built at compile time, registered with a specific provider, handed a secret, and then called a known set of endpoints in a known order. An agent does none of that. It assembles its toolchain at runtime, against services nobody registered it with, and decides what to call next based on what the last call returned. AAuth is the protocol for that caller, filed as an Internet-Draft on 20 August 2026, intended status Standards Track, with a companion bootstrapping draft and the Rich Resource Requests vocabulary layer.

• The agent gets an identifier, and it is portable - aauth:local@domain, lowercase ASCII with a reserved + as the sub-agent delimiter, max 255 characters. It belongs to the agent, not to a registration record inside one provider’s database, which is the whole point: the same agent is the same subject at every resource it visits.
• The shared secret is gone - Every client holds a keypair. Requests are signed with HTTP Message Signatures (RFC 9421) plus Content-Digest, and the draft is blunt about the algorithm: a fully-specified identifier is REQUIRED, Ed25519 is RECOMMENDED, and implementations MUST NOT accept none, the polymorphic EdDSA identifier, or any symmetric algorithm. There is no API key to copy into a workload and no client secret to leak.
• Five JWT types, each with a job - aa-agent+jwt carries the agent’s own identity with its public key in cnf and an optional ps naming its person server; aa-person+jwt names the human the agent acts for, aud-bound to a single resource, one-hour maximum, optionally carrying mission_s256 — a hash of the approved mission; the resource token states what access is required; aa-auth+jwt is the grant; and the session token is opaque, returned in AAuth-Access and replayed as Authorization: AAuth.
• Discovery is four well-known documents - /.well-known/aauth-agent.json, /.well-known/aauth-person.json, /.well-known/aauth-access.json and /.well-known/aauth-resource.json, each carrying a jwks_uri. That is four probeable paths, which makes AAuth adoption something you can actually measure at a domain — unlike the composition-only AI Agent Auth framework, which defines no path of its own.
• The 401 is a conversation, not a dead end - A resource answers 401 with an AAuth-Requirement header saying exactly what is missing: requirement=agent-token, person-token, auth-token, or interaction; url="..."; code="..." when a human has to look at something. 202 Accepted with a Location holds the request open while that happens. This is the mid-task consent that OAuth’s up-front authorization screen cannot express.
• Five access modes, adopted incrementally - Agent identity only (the resource just recognises the sub); resource-managed two-party; person identity; three-party with a person server issuing the auth token; and four-party federated, where the resource sets aud to an access server and the person server federates policy across trust domains. A resource can start at mode one and stop there.
• Bootstrapping is a separate, deliberately non-normative draft - Hardware-backed durable keys (Secure Enclave, StrongBox, non-extractable WebCrypto) anchor enrollment with an agent provider; a fresh ephemeral key per token issuance is what actually lands in cnf.jwk and signs the request. A self-hosted agent needs no provider at all — publishing its JWKS at /.well-known/aauth-agent.json is the enrollment, and it self-issues its own agent tokens.
• It is explicitly not a replacement for OAuth - OAuth 2.1 remains right for the known, registered client. AAuth handles the case where the resource has never heard of the caller. SPIFFE and WIMSE give a workload identity inside a trust domain; AAuth is about carrying identity and delegation across domains. The overlap with Token Exchange, Transaction Tokens and CIBA is real and unresolved — those are the OAuth-native answers to the same three questions.
• The stated motivation is MCP - The project says plainly that OAuth is not a good fit for MCP servers. The MCP authorization story today is Protected Resource Metadata (RFC 9728) plus Dynamic Client Registration — a client registering itself with every server it meets, which is exactly the registration ceremony AAuth deletes.

What makes this worth tracking is that it is falsifiable. Most agent-identity proposals are frameworks: they recommend how to compose things that already exist, and there is nothing at a provider’s domain to probe. AAuth defines four well-known paths, three JWT typ values, and three response headers. Either https://example.com/.well-known/aauth-resource.json returns a document with an issuer and a jwks_uri or it does not. That is the same shape of check the catalog already runs for RFC 9728, and it means AAuth adoption can be counted rather than asserted.

The honest caveat is that adoption is currently near zero and the draft has not been adopted by a working group. It expires 21 February 2027. There are reference SDKs in Node, .NET and Go under the aauth-dev organization and a Python demo, an active IETF Slack channel, and monthly office hours — which is roughly the profile of a proposal with real engineering behind it and no deployed base yet. Weigh it as a strong reading of where agent authorization is heading, backed by the person who wrote the protocol it is trying to succeed, not as something to conform to this quarter.