Research notes — AAuth spec family

Engineering notes distilled from the AAuth Internet-Drafts and the companion HTTP Signature Keys draft, written while building this Agent Provider. They are the “why” behind the code and a sufficient reading of the spec to connect agents and resources/MCP to an AP without re-reading every draft. Normative statements carry the spec’s MUST/SHOULD meaning; design decisions specific to this implementation are called out as such.

Note	Covers	Read it if you’re…
01 — Protocol overview	Parties, tokens, the five access modes, every shared primitive (requirements, deferred responses, interaction codes, identifiers, JWKS discovery, revocation), missions & delegation at a glance	…new to AAuth, or want one document that maps the whole protocol
02 — The Agent Provider role	The AP’s normative obligations, the two-key/single-key key model, identifier strategy, the endpoints this AP defines, multi-instance & security requirements	…working on apd itself, or writing another AP
03 — HTTP signatures	RFC 9421 signature base, the AAuth profile, every Signature-Key scheme (hwk/jwt/jkt-jwt/jwks_uri), Signature-Error, structured fields, JWK/thumbprint, egress admission	…implementing signing or verification
04 — Connecting agents	End-to-end agent lifecycle: enroll → refresh → sign → talk to resources → PS flow → sub-agents → events, plus a failure-handling cheat sheet	…building an agent that uses this AP
05 — Connecting resources & MCP	The resource adoption ladder, verifying agent identity, resource metadata, AAuth-Access, resource/auth tokens, and the MCP integration points	…putting AAuth in front of an API or MCP server
06 — AAuth Events	The AP-as-inbox model, subscribe/event tokens, the normative /events validation order, and AP→agent delivery patterns	…implementing async event delivery
07 — Implementing a Person Server	A complete build spec for the PS role: metadata, agent–person binding, directed identifiers, the person- and auth-token endpoints, verification, retention, revocation, missions, and a phased build order	…building a Person Server, or wanting to know what the PS owes you
08 — RFC: psd, a Person Server implementation	The build plan for a psd binary: deployment shapes, technology decisions, data model, config, HTTP surface, CLI, milestones, open questions. Seed document — moves to the psd repo when it exists	…deciding whether and how to build a Person Server

Source drafts (as read, 2026-08)

• draft-hardt-oauth-aauth-protocol-11 — the core protocol. Adds the person token (aa-person+jwt, PS-issued), a fifth access mode, accept_signature_algs in metadata, mission_s256 in place of the mission object, and removes the AAuth-Mission header. -10 added the fully-specified alg requirement, unsupported_algorithm, and the account request parameter.
• draft-hardt-aauth-bootstrap-01 — informational AP enrollment/refresh patterns
• draft-hardt-aauth-events-00 — event subscription & delivery
• draft-hardt-httpbis-signature-key-08 — Signature-Key/Signature-Error/Accept-Signature; §3.3 Algorithm Determination (fully-specified alg, no polymorphic EdDSA), §4.2 Accept-Signature-Alg
• draft-hardt-aauth-budgets — exploratory: a budget claim and the AAuth-Budget response header, to cap what an agent may spend at metered resources. Builds on TPX. Budget and approval, not payment. The Agent Provider has no role — the draft says so explicitly: where the AP pays for inference, “nothing in this document applies”.
• draft-hardt-aauth-r3-* — Rich Resource Requests / vocabularies (directional; MCP mapping)
• interop-demo-profile.md — the five interop surfaces

AAuth is an evolving set of Internet-Drafts; check the upstream repo for newer revisions before treating any detail here as final.