IETF · 25 September 2026

AAuth Protocol

draft-hardt-oauth-aauth-protocol-11

D. Hardt (Hellō)

Individual draftDraft — expect changeIdentity + Authn + AuthzAgent-specificField guide

AAuth Protocol (draft-hardt-oauth-aauth-protocol-11) is Individual draft, 25 September 2026. 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.

At a glance

Problem: OAuth 2.0 and OpenID Connect assume pre-registered clients, browser redirects, bearer tokens, and static scopes. Agents discover resources at runtime, need their own cryptographic identity (not just a client_id minted by each AS), must prove possession of a key on every call, and often need mid-task human governance that cannot be reduced to a scope string.
Identity / authn / authz: All three. Agent tokens are identity (who the agent is). HTTP Message Signatures are authentication (proof of the key). Auth tokens, resource tokens, missions, and R3 grants are authorization (what it may do, for whom). AAuth complements OAuth/OIDC rather than claiming to obsolete them.

Actors

Agent (any HTTP client with a key and agent token)
Agent provider (issues the agent token, hosts JWKS)
Resource
Person server (PS) — optional user representative
Access server (AS) — optional resource-side policy engine
User / person

How AAuth works

Animated sequence · AAuth

AAuth — How does an agent prove who it is when there is no authorization server?

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.

Agent providersends

Agentgets

Resource

Person server

User

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.

typ: aa-agent+jwt from the spec
cnf from the spec
iss / dwk from the spec
ps from the spec

Solid = from the spec

Speed← → step · space play

ShareLinkedIn X

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.

In one board · AAuth access modes

Restage the hop

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.

AgentUserResourcePerson serverAccess server

Agent
→ Signed HTTP · local policy →
Resource

Which passes exist

aa-agent+jwtsessionaa-person+jwtaa-resource+jwtaa-auth+jwt

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.

Hop list

Sequence above; this list is the same hops for reading and search. Each row is one message.

1
Agent provider→AgentAAuth draftIssues aa-agent+jwt bound to the agent's signing key
2
Agent provider→Agent providerAAuth draftPublishes JWKS at {iss}/.well-known/{dwk}
3
Agent→ResourceRFC 9421First signed HTTP request: Signature-Key + Signature-Input + Signature
4
Resource→Agent providerAAuth draftFetches JWKS via iss + dwk well-known document
5
Resource→ResourceRFC 9421Verifies RFC 9421 signature, typ, exp, and cnf.jwk
6
Resource→AgentAAuth draftAllows or denies from local policy for that agent identifier
7
Agent→ResourceAAuth draftSigned call; resource sees a ps claim and wants user claims
8
Resource→AgentAAuth draft401 AAuth-Requirement: auth-token, plus a resource token (aud = PS)
9
Agent→Person serverAAuth draftSigned POST of the resource token to the person-server auth_token_endpoint
10
Person server→AgentAAuth draftMay 202 + interaction if the user must approve
11
Person server→UserAAuth draftNotifies the user that this agent wants a grant at this resource
12
User→Person serverAAuth draftAuthenticates at the person server
13
User→Person serverAAuth draftConsents to the mission or scope at the person server
14
Person server→AgentAAuth draftIssues aa-auth+jwt with user claims, cnf-bound to the agent key, aud = resource
15
Agent→ResourceRFC 9421Retries signed HTTP with the auth token
16
Resource→Person serverAAuth draftFetches the person server's JWKS to verify the auth token
17
Resource→AgentAAuth draftVerifies signature + aa-auth+jwt (iss, aud, cnf) and applies policy to (iss, sub)

The gap for agents

OAuth 2.0 and OpenID Connect were designed for applications that a human installs or a developer pre-registers: a client_id minted by each authorization server, a browser redirect for consent, a bearer access token, and a static scope string. An AI agent that discovers a new HTTP resource at runtime has none of those luxuries. It is not a user. It is not a workload identity inside one mesh. It is an HTTP client that must prove who it is to a stranger, then obtain a grant that may involve a human mid-task.

The gap AAuth names is therefore four principals, not one: the user (person), the agent instance (cryptographic identity), the resource (the tool or API), and optionally a resource-side access server. Vanilla OAuth collapses the agent into 'the client' and gives it no portable identity. SPIFFE/WIMSE name the binary inside a trust domain but do not, by themselves, get the agent accepted at an arbitrary internet resource or carry user consent. MCP authorization reuses OAuth 2.1 for host-to-tool access and still assumes an AS that will issue a client identifier.

AAuth's premise, quoted from draft-11's introduction, is that every agent has its own cryptographic identity: an identifier of the form aauth:local@domain bound to a signing key, published at a well-known URL, verifiable by any party — no pre-registration, no shared secrets, no dependency on a particular server. At its simplest the agent signs a request and the resource decides from who the agent is. That agent-identity access (the figure is still titled Identity-Based Access) is the foundation; authorization, governance, and federation are additive.

Actors and trust boundaries

The agent is any HTTP client with a key and an agent token. It trusts its agent provider (who issued the agent token and hosts JWKS) and, if it has one, its person server. It does not have to trust the resource's access server until a four-party hop; it never treats a resource-issued opaque session token as something it can inspect.

The agent provider is an identity issuer, not an OAuth authorization server. It attests 'this key speaks for this agent identifier'. Compromise of the provider's signing key is compromise of every agent it vouches for. The resource fetches the provider's JWKS via the token's iss and dwk; that fetch is a trust-boundary crossing (SSRF, mix-up of iss, stale JWKS).

The resource is the verifier of signatures and the enforcer of its own policy. In identity-based and resource-managed modes it never talks to a person server. In three-party mode it issues a resource token whose audience is the person server and later verifies an auth token whose issuer is that PS. In four-party mode the resource token's audience is the resource's own access server; the PS federates to that AS. The resource must not confuse a person token (identity of the user) with an auth token (a grant).

The person server represents the user: consent, missions, permission/audit/interaction relay. It is the only party that calls an access-server token endpoint in four-party mode. The user/person authenticates to the PS or to the resource's own login, never by handing a password to the agent. An agent with no person server cannot satisfy requirement=person-token.

The access server (AS in AAuth's vocabulary) is a resource-side policy engine, not the user's IdP. Do not mash it together with an OIDC OP. Four-party federation is PS → resource AS, which is also not OpenID Federation 1.1.

Mechanics

Wire authentication is HTTP Message Signatures (RFC 9421) plus HTTP Signature Keys (draft-hardt-httpbis-signature-key). Every signed request carries Signature-Key, Signature-Input, and Signature. AAuth presents the agent token, or a person token or auth token in its place, in Signature-Key with scheme=jwt. The cnf.jwk in that JWT is the signing key; a stolen JWT without the private key cannot produce a valid signature.

Challenges replace browser redirects. A 401 carries AAuth-Requirement (for example requirement=agent-token, person-token, interaction, or auth-token). AAuth-Capabilities advertises what the resource can do. Subsequent resource-managed calls may present an opaque session token via Authorization: AAuth <token> and/or AAuth-Access. Missions are bound by mission_s256, not by an AAuth-Mission header (draft-11 removed that header). These header names are from the draft; do not invent parallel names.

Well-known documents are discovered with the dwk ('dot well-known') parameter from Signature-Key: aauth-agent.json, aauth-resource.json, aauth-person.json, aauth-access.json at {iss}/.well-known/{dwk}. Resource metadata may declare access_mode (advisory). Draft-11's registry is agent-token, person-token, session-token, and auth-token. The older name aauth-access-token is gone.

JWT types in draft-11: aa-agent+jwt (identity of the agent; sub is the agent identifier; cnf.jwk binds the key; optional ps names the person server; SHOULD NOT live longer than 24 hours), aa-person+jwt (directed identifier of the person at one resource; identifies, does not authorize; MUST NOT exceed one hour), aa-resource+jwt (issued by the resource to describe the access that needs authorizing; aud is the PS or AS that may redeem it; SHOULD NOT exceed five minutes), aa-auth+jwt (the grant; iss is PS or AS; required aud, ps, and a directed sub; no agent identifier and no act; cnf bound to the agent's key; MUST NOT exceed one hour). Implementations MUST check typ and MUST reject aa-person+jwt where an auth token is required.

Person-server endpoints in draft-11 are person_token_endpoint and auth_token_endpoint (renamed from token_endpoint). A resource issues a resource token only after verifying a person token or an auth token; otherwise it answers requirement=person-token. The agent presents a resource token to auth_token_endpoint. Four-party: the PS discovers {aud}/.well-known/aauth-access.json and calls the AS token endpoint. Call chaining uses upstream_token / subagent_token so a sub-agent signs with its own key. Draft-11 removed act: the person server holds the chain. The agent identifier reaches a resource only in agent-identity and resource-managed modes; in the other three, no token the resource reads carries one, and an auth token carries no agent identifier.

Governance is orthogonal to access mode. Missions are natural-language (Markdown) intent, immutable via s256. Permission, audit, and interaction relay through the PS even when the resource is in identity-based mode. R3 (companion draft) replaces coarse scopes with vocabulary operations, including per-call approval.

typ: aa-agent+jwtfrom spec: Quoted from draft-11: agent identity JWT. sub is the agent identifier (aauth:local@domain). cnf.jwk is the signing key. Optional ps names the person server. Agent tokens SHOULD NOT live longer than 24 hours.
typ: aa-auth+jwtfrom spec: Quoted from draft-11: the grant. Required payload claims include aud (the resource), ps, and a directed sub, plus iss, dwk, jti, iat, exp, and cnf.jwk. It carries no agent identifier and no act. Lifetime MUST NOT exceed 1 hour. Optional scope, account, mission_s256, and tenant; other IANA or OIDC Core §5.1 claims MAY be added. R3 adds its own claims.
typ: aa-resource+jwtfrom spec: Quoted from draft-11: issued by the resource; aud is the PS (three-party) or AS (four-party). SHOULD NOT exceed five minutes. Issued only after the resource has verified a person token or an auth token.
typ: aa-person+jwtfrom spec: Quoted from draft-11 §7.1 and §13.11: directed person identifier at one resource. Identifies, does not authorize. Implementations MUST reject aa-person+jwt where an auth token is required.
AAuth-Requirement / AAuth-Access / AAuth-Capabilitiesfrom spec: Quoted header names from draft-11. Challenges, opaque session presentation, and capability discovery. Not WWW-Authenticate: Bearer. There is no AAuth-Mission header.
Signature-Key: scheme=jwtfrom spec: Quoted usage: the JWT (agent, person, or auth token) rides in Signature-Key. Cover the signature-key component in the RFC 9421 signature base so the header cannot be swapped.
access_mode=agent-token | person-token | session-token | auth-tokenfrom spec: Quoted from draft-11 resource metadata. Advisory. The older value aauth-access-token is not in this registry. R3 annotates the same modes per operation.
Authorization: AAuth <session>illustrative: Illustrative of resource-managed presentation in draft-11 examples. The session token is opaque to the agent; the signature still binds the request. Do not copy example token values from blogs as test vectors.

Step-by-step flows

Flow 1 of 5

Identity-based (peer) — no PS, no AS

Draft-11 §4.2.1 Agent Identity Access. The figure is still titled Identity-Based Access. The resource decides from cryptographic agent identity alone. This is the AAuth meaning of p2p.

1
Agent provider issues aa-agent+jwt bound to the agent's signing key and publishes JWKS at the well-known document named by dwk.
2
Agent sends a signed HTTP request: Signature-Key (scheme=jwt, the agent token) + Signature-Input + Signature covering method, authority, path, and the key-identifying header.
3
Resource verifies RFC 9421, checks typ, exp, cnf.jwk against the signature, and fetches/caches issuer JWKS if needed.
4
Resource applies local policy to the agent identifier (allow, deny, or rate-limit). No token exchange, no redirect, no person server.
5
If the request lacked an AAuth agent token, the resource MAY 401 with requirement=agent-token.

The resource learns who the agent is, not which human it serves. For user claims, step up to resource-managed, person-identity, or PS-authorization mode.

Flow 2 of 5

Resource-managed (two-party)

Draft-11 §4.2.2. Still no external AS. The resource runs consent, account linking, or payment itself.

1
Agent makes a signed call with its agent token.
2
Resource returns 401 or 202 with AAuth-Requirement describing interaction (URL, wait, etc.). First call can be registration.
3
User completes the resource's own page — which MAY wrap ordinary OAuth/OIDC behind the resource.
4
Resource returns an opaque session token in AAuth-Access, bound to the agent's signature.
5
Subsequent calls: HTTP signature plus the opaque credential. Stolen session without the key should not replay.

Two-party is p2p in the sense of agent↔resource, not DIDComm. The resource may stuff an OAuth access token inside the opaque session; the agent must not fish it out and replay it as Bearer elsewhere.

Flow 3 of 5

Person identity

Draft-11 §4.2.3. Resource accepts who the person is from the PS, without a grant of operations. The draft calls this federated login for agents.

1
Agent token carries ps. Resource challenges with requirement=person-token. The header carries no parameters.
2
Agent calls the PS person_token_endpoint with resource, mission_s256, optional subagent/upstream tokens.
3
PS authenticates the person (if needed) and issues aa-person+jwt directed at that resource. Consent here is 'may this agent act at this resource as this person', not a scope list.
4
Agent retries with the person token in Signature-Key. Resource verifies typ aa-person+jwt and serves whatever it serves to signed-in people.
5
If a later operation needs a grant, the resource must demand an auth token; it MUST NOT treat the person token as one.

Draft-11 §13.11: implementations MUST check typ and MUST reject aa-person+jwt where an auth token is required. Skipping typ fails open. Draft-10 peers that never heard of person tokens will not interoperate.

Flow 4 of 5

PS authorization (three-party)

Draft-11 §4.2.4. Resource has no AS. User claims and consent come from the agent's person server.

1
If the request carries neither a person token nor an auth token, the resource 401s with requirement=person-token and does not yet issue a resource token.
2
Agent obtains aa-person+jwt from person_token_endpoint and retries with it in Signature-Key.
3
Resource, having verified that person token, 401s with requirement=auth-token and a resource token (aa-resource+jwt, aud = PS, SHOULD NOT exceed five minutes). The same requirement MAY arrive as a 202.
4
Agent POSTs the resource token to the PS auth_token_endpoint, signed with the agent key.
5
If the user must approve a mission or scope, PS returns 202 + interaction. User approves at the PS, not at the resource.
6
PS issues aa-auth+jwt with aud = resource, a directed sub, ps, cnf bound to the agent key, and exp that MUST NOT exceed 1 hour. Optional scope or R3 grants. No agent identifier and no act.
7
Agent retries; resource verifies the auth token (iss = PS, aud = itself, cnf matches the signature) and applies its own policy to (iss, sub).

sub is directed per issuer. The same email from two person servers is two subjects. The resource still decides what that subject may do.

Flow 5 of 5

Federated (four-party)

Draft-11 §4.2.5. Resource has its own access server. The agent still talks only to the resource and its PS. The person-token prerequisite is the same as three-party.

1
Same first call as three-party, but the resource token's aud is the resource's access server URL.
2
Agent still POSTs the resource token to its PS auth_token_endpoint. The agent does not call the AS.
3
PS discovers {aud}/.well-known/aauth-access.json and federates to the AS token endpoint with the resource token and the agent token.
4
AS evaluates resource policy and returns an auth token (iss = AS, dwk = aauth-access.json). PS may pass clarifications back via 202.
5
Agent presents the auth token to the resource. Resource verifies against the AS JWKS.

This is not OpenID Federation and not identity chaining (RFC 8693 + 7523 across OAuth domains), though it rhymes. The PS is the only party that calls AS token endpoints.

Identity vs authentication vs authorization

Identity: the agent token says which agent; the person token and the auth token's directed sub say which person; (iss, sub) at the PS is the user identifier. An auth token carries no agent identifier. The agent identifier is not a client_id and not a SPIFFE ID.

Authentication: RFC 9421 signatures proving possession of cnf.jwk on every request. Not bearer possession of a JWT. Signature-Key is how the verifier gets the key; it is not itself a grant.

Authorization: auth tokens, opaque sessions, missions, R3 grants, and the resource's local policy. Identity-based mode is authorization-by-identity-list at the resource. Do not call a person token an authorization.

How it composes

OAuth 2.1
AAuth says it complements OAuth rather than replacing it. Where the API is already an OAuth 2.1 resource server (MCP included), keep PKCE, PAR, audience-restricted tokens. Use AAuth when the agent must identify itself to a resource that will not mint a client_id, or when you want signatures instead of bearer tokens.
OpenID Connect Core
Auth-token user claims reuse OIDC names (sub, email, groups, roles) so identity-aware resources can keep their user model. AAuth does not issue an ID Token and does not make the resource an OpenID relying party. The person server may itself be backed by OIDC for how the human signs in.
HTTP Signature Keys
Normative dependency. Without Signature-Key schemes (jwt, jwks_uri, …) and dwk well-known discovery, the resource cannot bootstrap a stranger's key on the first request.
HTTP Message Signatures
The cryptographic primitive. AAuth profiles RFC 9421 rather than inventing HMAC headers. Cover @method, @authority, @path, and signature-key.
Token Exchange
Draft-11 removed act from AAuth tokens. Call chaining is upstream_token / subagent_token, and the person server holds the chain. That is not the OAuth token-exchange grant, and there is no AS token endpoint in agent-identity or two-party modes. Cross-domain OAuth hops still use RFC 8693 + 7523 / identity chaining, where nested act is still the actor record.
DPoP
Different PoP. DPoP is an application-layer proof JWT on OAuth resource requests (Authorization: DPoP). AAuth uses HTTP Message Signatures. Do not stack proofs naively or skip covering the key header.
WIMSE architecture
Overlapping problem, different deployment scope. WIMSE/SPIFFE name the workload inside and across systems that share trust anchors. AAuth targets open-world HTTP resources that will fetch a well-known JWKS. An agent can have both: WIT/WPT inside the mesh, AAuth at the internet resource.
MCP authorization
MCP HTTP authorization is OAuth 2.1 + RFC 9728. It does not give the model a cryptographic agent identity. If an MCP server also verified AAuth signatures, that would be a profile on top — not what the 2026-07-28 MCP spec requires.
AAuth R3
Optional structured authorization. Scopes remain in the core protocol; R3 is how operations in OpenAPI/MCP/GraphQL vocabularies become the grant, including per-call.
AIMS (agent auth BCP)
AIMS says compose existing IETF tools (WIMSE + OAuth). AAuth says those tools are insufficient for open-world HTTP clients. Read both; they disagree on whether you need a new protocol.

What bites agent implementers

Pin draft-11, not draft-10
Datatracker HTML of draft-hardt-oauth-aauth-protocol-11 (25 September 2026, expires 29 March 2027) defines five resource access modes, including person identity, aa-person+jwt, person_token_endpoint, and auth_token_endpoint. Draft-10's four-mode table does not. The editor HTML was regenerated 3 October 2026; the protocol markdown last changed with the -11 submission, so pin draft-11. Interop with a draft-10 peer fails on typ and endpoint names.
typ confusion (fail open)
Draft-11 §13.11: check typ before acting on any AAuth JWT; MUST reject aa-person+jwt where an auth token is required; deployments SHOULD test this because it fails open. A person token and a PS-issued auth token share iss, dwk, aud, sub, and cnf. Mixing them is the local analogue of using an ID Token as an access token.
Sender constraint is the signature
If you accept the JWT from Signature-Key without verifying RFC 9421 over the request and the key header, you have reinvented bearer tokens. Cover signature-key in the signature base.
Audience and confused deputy
Auth tokens are audience-restricted to the resource. Resource tokens are audience-restricted to the PS or AS. Presenting an auth token minted for resource A at resource B is a confused-deputy bug. Missions bind intent via s256; do not let the agent swap mission text after approval.
Call chaining is not nested act
Draft-11 removed act. Earlier revisions recorded the upstream chain there; the draft now says that claim served no reader at the resource. The person server holds the chain. Call chaining uses upstream_token / subagent_token, and the immediate caller signs with its own key. Attenuate what a sub-agent may do. Never expand grants at a hop. Do not import RFC 8693 act into an AAuth auth token.
Token replay and lifetime
Draft-11: resource tokens SHOULD NOT exceed five minutes; person and auth tokens MUST NOT exceed 1 hour; agent tokens SHOULD NOT live longer than 24 hours. An agent SHOULD refresh an agent, person, or auth token when fewer than five minutes remain. exp is judged by the verifier's clock; the document defines no tolerance for clock skew on exp. Revocation is best-effort via endpoints; verifiers check signatures locally and may not hear a revoke.
Mix-up of iss / dwk / well-known fetch
The resource fetches JWKS from a URL derived from iss + dwk. Validate TLS, bind iss, and do not let an attacker point dwk at an unexpected host (SSRF). This is the AAuth-shaped cousin of OAuth mix-up.
Individual draft, not a WG item
Not endorsed by the IETF, no RFC number, intended standards track only as a personal statement. Do not tell compliance it is 'the IETF agent standard'. Pin revisions. Complements OAuth; does not obsolete RFC 9700.

Stability — what you can ship

Published snapshot: draft-hardt-oauth-aauth-protocol-11, 25 September 2026, expires 29 March 2027, individual Internet-Draft, replaces draft-hardt-aauth-protocol. Author: D. Hardt (Hellō). Datatracker: https://datatracker.ietf.org/doc/draft-hardt-oauth-aauth-protocol/. HTML: draft-hardt-oauth-aauth-protocol-11. Five access modes are in this snapshot.

Editor HTML at https://dickhardt.github.io/AAuth/draft-hardt-oauth-aauth-protocol.html was regenerated with a 3 October 2026 publication date (expires 6 April 2027). The protocol markdown's last commit is the 25 September -11 submission, so that date stamp is not a newer revision. aauth.dev and explorer.aauth.dev track the moving copy. Implementations (TypeScript @aauth/*, .NET AAuth NuGet samples) exist; this October check did not re-audit their coverage.

What you can ship today: experiment behind a pin; do not bet a compliance program on wire stability. For production user-delegated APIs, ship OAuth 2.1 + RFC 9700 now and keep AAuth in the evaluation track. Re-read datatracker before every release.

Catalog claims (short form)

aa-agent+jwt: Agent identity. sub is the agent identifier (aauth:local@domain). cnf.jwk binds the signing key. Optional ps claim names the person server.
aa-person+jwt: Directed identifier of the person at one resource (draft-11 person-identity mode). Identifies, does not authorize. A resource MUST reject it where an auth token is required.
aa-resource+jwt: Issued by the resource to describe the access that needs authorizing; aud is the PS or AS that may redeem it.
aa-auth+jwt: The grant. Required aud, ps, and a directed sub, bound to the agent's key. No agent identifier and no act chain. Optional scope, mission_s256, tenant, or R3 grants.
AAuth-Requirement / AAuth-Access / AAuth-Capabilities: HTTP headers for challenges, session/auth presentation, and capability discovery.

Implementer notes

Individual Internet-Draft: not a WG document, not endorsed by the IETF, no RFC number. Published snapshot is draft-11 (25 September 2026, expires 29 March 2027) and defines five resource access modes: agent identity, resource-managed (two-party), person identity, PS authorization (three-party), and federated authorization (four-party). Person tokens and auth_token_endpoint (renamed from token_endpoint) are in that snapshot; draft-10's four-mode table is obsolete. The editor HTML was regenerated 3 October 2026 (expires 6 April 2027); the protocol markdown last changed with the -11 submission, so pin draft-11. Replaces earlier draft-hardt-aauth-protocol. Complements OAuth: where pre-registered clients and bearer tokens work, keep them. Implementations exist (TypeScript @aauth/*, .NET samples); several features were still incomplete in the JS packages at the September 2026 research pass. Do not implement from blog posts; read the draft.

Primary sources

Datatrackerhttps://datatracker.ietf.org/doc/draft-hardt-oauth-aauth-protocol/
HTML of draft-11https://datatracker.ietf.org/doc/html/draft-hardt-oauth-aauth-protocol-11
Editor's copyhttps://dickhardt.github.io/AAuth/draft-hardt-oauth-aauth-protocol.html
aauth.devhttps://www.aauth.dev/
Protocol explorerhttps://explorer.aauth.dev/
Sourcehttps://github.com/dickhardt/AAuth