AAuth Explorer

Resource Access

Resource Access Mode Comparison

AAuth defines five resource access modes, sorted by what the resource ends up knowing and which party established it — not by how much of the protocol they use. The protocol works in every mode, and adoption does not require coordination between parties. A resource MAY apply different modes to different endpoints. Agent governance (missions, permission, audit, interaction relay) is an orthogonal layer that any agent with a PS can add on top of any mode.

Agent identity

Agent + Resource

Live demo

Resource knows

which agent

Established by

the agent provider

AgentResource
1.
Agent → ResourceHTTPSig w/ agent token
2.
Resource → Agent200 OK (access decision by agent identity)

Tokens

aa-agent+jwt

Infrastructure

None — just the agent and resource

Best for

Replacing API keys with cryptographic identity

Resource-managed

Two-Party

Live demo

Resource knows

which person

Established by

the resource's own flow

AgentResource
1.
Agent → ResourceHTTPSig w/ agent token
2.
Resource → Agent202 + AAuth-Requirement: interaction
3.
User → ResourceCompletes interaction at the resource's own page
4.
Agent → ResourcePoll → 200 + AAuth-Access (session token)
5.
Agent → ResourceSubsequent calls: Authorization: AAuth <session token>

Tokens

aa-agent+jwtsession token (opaque)

Infrastructure

Resource handles auth itself (interaction, OAuth/OIDC, internal policy)

Best for

Resource manages authorization without an external PS or AS

Person identity

Three-Party

Live demo

Resource knows

which person

Established by

the person server

AgentResourcePerson Server
1.
Agent → PSPOST person_token_endpoint {resource}
2.
PS → Agentaa-person+jwt: aud=resource, directed sub, cnf=agent key
3.
Agent → ResourceHTTPSig w/ person token in place of the agent token
4.
Resource → Agent200 OK (access decision by person identity)

Tokens

aa-agent+jwtaa-person+jwt

Infrastructure

Person Server only — never in the path of a call

Best for

Federated login for agents: the resource accepts a login the PS ran

PS authorization

Three-Party

Live demo

Resource knows

person and consented scope

Established by

the person server

AgentResourcePerson Server
1.
Agent → PSPerson token for this resource
2.
Agent → ResourcePOST authorization_endpoint w/ person token
3.
Resource → AgentResource token (aud=PS) — copies ps, sub, person_token_jti
4.
Agent → PSPOST auth_token_endpoint w/ resource token
5.
PS → AgentAuth token (iss=PS, dwk=aauth-person.json)
6.
Agent → ResourcePresent auth token → 200

Tokens

aa-agent+jwtaa-person+jwtaa-resource+jwtaa-auth+jwt (from PS)

Infrastructure

Person Server (no Access Server)

Best for

Resource accepts identity claims and consented scope from any PS

Federated authorization

Four-Party

Live demo

Resource knows

person and policy verdict

Established by

the access server

AgentResourcePerson ServerAccess Server
1.
Agent → PSPerson token for this resource
2.
Agent → ResourcePOST authorization_endpoint w/ person token
3.
Resource → AgentResource token (aud=AS)
4.
Agent → PSPOST auth_token_endpoint w/ resource token
5.
PS → ASFederates: resource_token + agent_token (signed)
6.
AS → PS → AgentAuth token (iss=AS, dwk=aauth-access.json)
7.
Agent → ResourcePresent auth token → 200

Tokens

aa-agent+jwtaa-person+jwtaa-resource+jwtaa-auth+jwt (from AS)

Infrastructure

Person Server + Access Server, PS-AS trust (pre-established or dynamic)

Best for

Cross-domain access with the resource's AS enforcing policy

Progressive Adoption

Each mode is independently deployable. A resource can start by just verifying the agent's signature (agent identity), later accept a login the PS ran (person identity), run its own flow instead (resource-managed), take consented scope from any PS (PS authorization), or deploy its own access server (federated) — without changing the agent's signing approach. What varies is what the resource challenges for and which party mints the eventual auth token. Resource-managed and person identity reach the same destination by different routes: in the first the resource runs its own login, in the second it accepts one the person server ran. A resource serving on identity alone challenges for auth-token only at the operations that need more, and keeps serving the rest on the person token.

Agent identityResource-managedPerson identityPS authorizationFederated authorization

Roles vs. deployment

AP, PS, AS, Resource, and Agent are roles, not deployment units. A single server can fill multiple roles — for example, an organizational deployment may operate AP + PS + AS together for employees and internal resources, with federation only incurred at the boundary. When the agent's PS and the resource's AS are the same server ("PS-AS Collapse"), federation reduces to a single internal evaluation. The wire protocol is unchanged regardless of collocation.