Flow · p2p
Peer-to-peer: AAuth two-party (resource-managed)
Still no external AS. The resource runs consent/account creation itself, then issues an opaque session token for subsequent signed calls.
Actors
Agent · Resource · User (at the resource's interaction URL)
Sequence
- 1
Agent→Resource
Signed call with agent token
- 2
Resource→Agent
401/202 + AAuth-Requirement: interaction
First call can be registration, payment, or consent
- 3
User→Resource
Completes the resource's own page (or existing OAuth/OIDC behind it)
- 4
Resource→Agent
AAuth-Access session token (opaque to the agent)
- 5
Agent→Resource
Subsequent calls: signature + Authorization: AAuth <session>
Caveats
The resource may wrap an ordinary OAuth token inside the opaque session. Two-party is 'p2p' in the sense of agent↔resource, not in the DIDComm sense. Editor's copy calls the opaque credential a session token (session-token) rather than aauth-access-token.
Why this hop looks this way
Compare with identity-based: both are two HTTP parties and no AS. Identity-based stops at 'I know this agent'. Two-party adds 'the resource ran its own consent and issued a session bound to the agent's key'. Stolen session without the signing key should not replay.
Compare with A2A: the resource here is an HTTP API, not an A2A server advertising skills. Compare with did:peer: the resource may never have seen the agent before; discovery is a 401 AAuth-Requirement, not an exchanged DID document.
The resource's login page MAY be ordinary OIDC. That does not make this hop an OAuth authorization-code flow from the agent's point of view — the agent never talks to that AS.