Flow · p2p
Peer-to-peer: AAuth identity-based access
No authorization server in the path. The agent signs the request; the resource decides from cryptographic identity. This is the 'p2p' that sits next to AAuth.
Actors
Agent · Agent provider (JWKS) · Resource
Sequence
- 1
Agent provider→Agent
Issues aa-agent+jwt bound to the agent's signing key
- 2
Agent→Resource
Signed HTTP request: Signature-Key (jwt) + Signature-Input + Signature
- 3
Resource→Agent provider
Fetches JWKS via iss + dwk well-known document
- 4
Resource→Agent
Allows or denies based on local policy for that agent identifier
No token exchange, no person server, no OAuth redirect. 401 requirement=agent-token if the signature was missing.
Caveats
The resource learns who the agent is, not necessarily which human it serves. For user claims, step up to two-party interaction or three-party PS-asserted mode. Individual draft — pin a revision. Draft-10 has four modes; the editor's copy adds person-identity as a fifth.
Why this hop looks this way
This is the AAuth meaning of p2p: agent and resource, no authorization server, no person server. It is as complete as AAuth two-party for the identity question and weaker for the user question.
It is not A2A (no Agent Card, no tasks). It is not did:peer (the identifier is published at a well-known URL so a stranger can verify a first request). It is not OAuth client-credentials (no client_id, no Bearer access token).
Wire: Signature-Key (scheme=jwt, aa-agent+jwt) + RFC 9421 Signature-Input/Signature. Cover signature-key in the signature base. Resource metadata access_mode=agent-token is advisory.