Compare
'P2P' is overloaded. Next to AAuth it means two-party/identity-based access. In other rooms it means A2A communication or did:peer/DIDComm. None of those is a single IETF 'p2p RFC'.
In one board · four doors
Wrong cousin: Not AAuth identity-based: there is very much an AS. Putting this pass on an A2A call without aud and actor binding is a confused deputy.
There is no IETF RFC titled P2P in this cluster. The word is meeting shorthand. Pick one door and stay in it.
| Aspect | User-delegated (agent acts for a human) | Peer / agent-to-agent (no user in the hop) |
|---|---|---|
| Who is the principal? | The user (OIDC sub) plus the agent as actor (client_id or act). | The calling agent (AAuth agent token, WIMSE/SPIFFE ID, A2A card, or did:peer). Pick one stack — they are not interchangeable identifiers. |
| AAuth meaning of p2p | AAuth three-party (PS-asserted) and four-party (federated) still have a user in the loop via the person server. | AAuth identity-based: signed request, resource policy on agent identity, no PS, no AS. AAuth resource-managed (two-party): still no external AS; the resource runs its own login and issues an opaque session bound to the signature. |
| A2A meaning of p2p | A2A can carry a user-delegated OAuth token if the Agent Card says so (authorization code flow on the card). | A2A v1.0 is a task protocol. Discovery is an Agent Card. Request auth is ordinary HTTP (OAuth, OIDC, mTLS, API keys) obtained out of band. Signed cards prove card integrity, not the request. |
| did:peer / DIDComm meaning of p2p | Not a user-delegation protocol. A VC about a user could be presented later, but that is OpenID4VP, not did:peer itself. | Pairwise, self-certifying DIDs stored by the parties. DIDComm authcrypt messages. Not globally resolvable. Poor fit for a stranger's first HTTP call to an open API. |
| Typical protocol (delegated vs peer) | OAuth 2.1 authorization code / CIBA / XAA / AAuth three- or four-party. | AAuth identity-based or two-party; A2A with mTLS/OAuth client credentials; WIMSE WIT+WPT inside a mesh; DIDComm authcrypt in SSI stacks. |
| Consent | Required unless enterprise policy (XAA) already authorized the connection. | Resource policy on agent identity; no human in the hop. Humans may have pre-authorized the agent. AAuth two-party is the exception: the resource may still run a login page. |
| Tokens | Access token with sub=user, client_id/act=agent, aud=API. Prefer DPoP/mTLS. | AAuth: agent token in Signature-Key, optional opaque session. A2A: often Bearer client-credentials. WIMSE: WIT+WPT, never WIT as bearer. did:peer: keys in the DID document, no OAuth token. |
| Failure mode | Confused deputy: agent uses user authority at the wrong API (missing aud / resource). | Impersonation of a high-privilege agent; unconstrained agent-to-agent chaining (WIMSE §3.4.11 warns about this). A2A in-band credentials leak across hops. |
Design the hop explicitly: is this call on behalf of a user, or is it one workload talking to another? Then pick OAuth-delegation machinery or one specific peer stack — AAuth two-party, A2A, or did:peer — not a mash-up. Putting a user access token on an A2A call without audience and actor binding is how you mint a confused deputy.
Searching datatracker for a document titled P2P in this cluster will not yield a protocol. The word is a meeting shorthand. This site uses 'p2p' on flow pages only with a qualifier: AAuth identity-based, AAuth two-party, or A2A.
AAuth resource-managed mode is still HTTP request/response with RFC 9421 signatures and an optional opaque session. A2A is tasks, skills, Agent Cards, JSON-RPC/gRPC. You can run A2A on top of AAuth-signed HTTP, but neither spec requires the other.
Identity-based AAuth publishes an agent identifier at a well-known URL so a stranger can verify a first request. did:peer is deliberately not globally resolvable; the parties already exchanged DID documents. Use did:peer for private pairwise relationships; use AAuth identity-based for open-world HTTP APIs.
The editor's copy adds person-identity: the resource accepts who the person is from a person server without a grant of operations. That hop has a user identifier and no AS, which confuses the delegated-vs-p2p binary. Treat it as federated login, not as identity-based agent access.