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.
Use the hop list beside the stage, or the phase labels, to jump. Every hop has Now, Why, the RFC, and chips — none are skipped.
Actors
Agent · Agent provider · Resource · User (at the resource's interaction URL)
Sequence
Animated sequence · p2p
AAuth — How does a resource run its own consent without an external AS?
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.
Now · 1/8· Discover· AAuth draftYou are here
Agent provider→Agent·Issues aa-agent+jwt bound to the agent's signing key
typ aa-agent+jwt: sub is the agent identifier, cnf binds the signing key.
Why Two-party still starts with identity-based proof. The provider is not an OAuth AS.
A wax-sealed ID card for the agent — not a photocopied pass.
- typ: aa-agent+jwt from the spec
- cnf from the spec
Solid = from the spec
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. Draft-11 calls the opaque credential a session token (session-token) and returns it in AAuth-Access.
Transcript
- 1
DiscoverAgent provider→AgentAAuth draft
Issues aa-agent+jwt bound to the agent's signing key
typ aa-agent+jwt: sub is the agent identifier, cnf binds the signing key.
Why Two-party still starts with identity-based proof. The provider is not an OAuth AS.
A wax-sealed ID card for the agent — not a photocopied pass.
- typ: aa-agent+jwt
- cnf
- 2
ProveAgent→ResourceRFC 9421
Signed call with agent token (RFC 9421 + Signature-Key)
The agent presents typ aa-agent+jwt in Signature-Key and signs the request. No Bearer access token.
Why First contact is still identity-based: which agent is calling.
Knock with a wax seal. No photocopied pass yet.
- Signature-Key
- typ: aa-agent+jwt
- 3
ProveResource→Agent providerAAuth draft
Fetches JWKS and verifies the signature
Resolve {iss}/.well-known/{dwk}, fetch JWKS, verify RFC 9421 + typ + cnf.
Why Do not skip JWKS fetch. The resource must verify the seal before challenging for interaction.
Check the wax against the published signet before handing back a form.
- JWKS
- cnf
- 4
GrantResource→AgentAAuth draft
401/202 + AAuth-Requirement: interaction
AAuth-Requirement asks for interaction. First call can be registration, payment, or consent — not an OAuth authorization-code hop from the agent.
Why The resource wants its own consent or account creation before issuing a session.
The door hands back a note: come complete our own form.
First call can be registration, payment, or consent
- AAuth-Requirement
- interaction
- 5
GrantUser (at the resource's interaction URL)→ResourceAAuth draft
Authenticates at the resource's own page (or existing OAuth/OIDC behind it)
The user proves who they are at the resource's interaction URL. That MAY wrap ordinary OIDC.
Why Authentication and consent are different hops. The human talks to the resource, not to the agent. If that page is OIDC, the agent still never talks to that AS.
The owner shows ID at the door's own desk.
- interaction
- authentication
- 6
GrantUser (at the resource's interaction URL)→ResourceAAuth draft
Completes consent, account linking, or payment at the resource
The user finishes the resource's own form. The agent is waiting on the 401/202 interaction.
Why This is the resource-managed grant. It does not make this hop an authorization-code flow from the agent's point of view.
The owner signs at the door's own desk.
- consent
- OIDC
- 7
GrantResource→AgentAAuth draft
Issues an opaque session (AAuth-Access / session-token)
Draft-11 returns the opaque credential in AAuth-Access and calls it a session token. The agent cannot inspect it as a JWT grant.
Why The session is opaque to the agent and should be bound to the agent's key.
An opaque stamp, still useless without the wax seal.
- session-token
- AAuth-Access
- 8
CallAgent→ResourceRFC 9421
Subsequent calls: signature + Authorization: AAuth <session>
Present the opaque session and keep signing. This is still two HTTP parties and no AS in the agent's path.
Why The signature still binds the request. A stolen session without the key should not replay.
Seal plus opaque stamp. Photocopying the stamp is not enough.
- Authorization: AAuth
- Signature-Key
- 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. Draft-11 calls the opaque credential a session token (session-token) and returns it in AAuth-Access.
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.