AAuth + person server
AAuth three/four-party with person server
Portable agent identity plus a user grant from the person's server. Three-party: the resource has no AS. Four-party: the resource has an access server the PS federates to. OIDC may sit behind the PS to authenticate the person.
When you see it
A personal agent that carries the user's consent to resources that will never register it as an OAuth client. The user approves a mission at their person server once; the agent retries with an aa-auth+jwt. Four-party shows up when the resource already has a policy engine and will not evaluate auth tokens itself.
Actors and trust
AgentAgent instance
Signs every HTTP call. Holds an agent token that names its person server (ps claim).
Person serverOther
Represents the user: consent, missions, auth tokens, optional interaction. May authenticate the person with ordinary OIDC behind the scenes.
User / personUser
Approves at the PS, not at each resource's OAuth screen.
ResourceResource
Issues a resource token (aud = PS), then accepts aa-auth+jwt and applies its own policy to (iss, sub).
Resource access server (four-party)Other
Optional. The PS federates to it; the agent still only talks to the resource and the PS.
Topology
- Agent→ Signed request; resource sees ps on the agent token →Resource
- Resource→ 401 requirement=auth-token + resource token (aud = PS) →Agent
- Agent→ Signed POST of the resource token →Person server
- Person→ Approve mission / scope (OIDC may authenticate here) →Person server
- Person server→ Four-party: PS federates to the resource access server →Resource AS (four-party)
- Person server→ aa-auth+jwt (user claims, cnf-bound) →Agent
- Agent→ Retry signed, with auth token →Resource
Primary
- AAuthdraft / churn
Auth tokens, person server, optional four-party access server. Individual draft.
- HTTP Signature Keysdraft / churn
- HTTP Message Signatures
RFC 9421.
Optional
- AAuth R3draft / churn
Individual draft.
- OpenID Connect Core
Authenticating the person at the PS — not the agent–resource credential.
- AIMS (agent auth BCP)draft / churn
Individual draft — complementary BCP, not this wire.
Do not use
- Bearer tokens
The agent–resource hop is signed AAuth, not Authorization: Bearer.
- Identity chaining
Four-party PS→resource-AS federation is not OAuth identity chaining.
- OpenID Federation
Different federation. Do not mix the documents.
Why these, and not those
You want AAuth's portable agent identity and a user grant, which identity-based p2p does not carry. The grant is aa-auth+jwt from the PS (short-lived, cnf-bound, aud = resource), not an OAuth Bearer access token from a client_id the resource minted. R3 and missions are the authorization language at the PS. Four-party adds a resource-side access server; that federation is not OpenID Federation and not OAuth identity chaining. OIDC belongs behind the PS (authenticate the person), not on the agent–resource hop.
Related flows
Sequence diagrams, not this topology cut. All flows