Resource Access
Resource Access Mode Comparison
AAuth defines four resource access modes, from simple identity verification to full four-party federation. The protocol works in every mode — adoption does not require coordination between parties. Agent governance (missions, permission, audit, interaction relay) is an orthogonal layer that any agent with a PS can add on top of any mode.
Identity-Based
Agent + Resource
Tokens
Infrastructure
None — just the agent and resource
Best for
Replacing API keys with cryptographic identity
Resource-Managed
Two-Party
Tokens
Infrastructure
Resource handles auth itself (interaction, OAuth/OIDC, internal policy)
Best for
Resource manages authorization without an external PS or AS
PS-Asserted
Three-Party
Tokens
Infrastructure
Person Server (no Access Server)
Best for
Resource accepts identity claims (sub, email, tenant, groups, roles) from any PS
Federated
Four-Party
Tokens
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 (identity-based) and later add interaction-based authorization (resource-managed), accept identity claims from any PS (PS-asserted), or deploy its own access server (federated) — without changing the agent's signing approach. The main change is what the resource returns in its `401` challenge and which party mints the eventual auth token.
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.