AAuth identity-based / two-party (true p2p HTTP)

No authorization server in the path. The agent signs the HTTP request; the resource decides from cryptographic identity (identity-based) or runs its own consent and issues a session (two-party). AAuth + RFC 9421 + Signature-Key. OAuth Bearer does not apply.

When you see it

Open-world HTTP clients that will not pre-register at every API's AS. A personal agent calling a small resource that is willing to trust an agent token and a signature. Two-party: the resource already has a login page and would rather issue its own session than stand up OAuth. Individual draft — pin a revision.

Actors and trust

AgentAgent instance
Holds an aa-agent+jwt bound to its signing key. Identifier is portable (aauth:local@domain), not an AS client_id.
Agent providerOther
Issues the agent token and hosts JWKS. The resource fetches keys; it does not call an AS token endpoint.
ResourceResource
Verifies RFC 9421 + Signature-Key, then applies local policy. In two-party it also runs interaction and issues an opaque session.
User (two-party only)User
Completes the resource's own page. May be ordinary OIDC behind that page; the agent never talks to that AS.

Topology

Agent provider (JWKS)AgentResourceUser (two-party)

Agent provider (JWKS)→ aa-agent+jwt bound to the signing key →Agent
Agent→ Signature-Key (jwt) + RFC 9421 Signature-Input/Signature →Resource
Resource→ Fetch JWKS at iss / well-known →Agent provider (JWKS)
Resource→ Two-party only: resource-managed interaction →User (two-party)
Resource→ Allow, or AAuth-Access session for subsequent signed calls →Agent

Two HTTP parties. The agent signs; the resource verifies. No token endpoint in the path.

Primary

AAuthdraft / churn
Individual draft (draft-10 vs editor's copy). Pin a revision.
HTTP Message Signatures
RFC 9421.
HTTP Signature Keysdraft / churn
Signature-Key header. Individual draft.

Optional

AAuth R3draft / churn
Fine-grained operations, including per-call. Individual draft.
OpenID Connect Core
Only as the resource's own login page in two-party mode — not as the agent–resource hop.

Do not use

Bearer tokens
Bearer access tokens are not this hop. Do not present Authorization: Bearer as AAuth p2p.
OAuth 2.1
No authorization server in the path. If you need one, that is interactive delegated, not p2p.
A2A (Agent2Agent)
A2A is agent-to-agent tasks with Agent Cards. Different protocol.
did:peer
Not globally resolvable; not a first-request HTTP identity.
DIDComm
Messaging, not signed HTTP resource access.

Why these, and not those

The whole point of this row is that there is no AS minting a Bearer access token. Authentication is RFC 9421 over the HTTP request, with the key conveyed by Signature-Key (draft-hardt-httpbis-signature-key) carrying the agent JWT. Authorization is local policy on that identity, or a resource-issued session in two-party mode. Optional R3 and missions constrain what the agent may do without turning the hop into OAuth. Listing OAuth Bearer as applicable would describe a different pattern. A2A is a task protocol with advertised OAuth; did:peer is pairwise and not resolvable by a stranger. Keep all three apart.

Related flows

Sequence diagrams, not this topology cut. All flows