AAuth Explorer
r3

Vocabulary-Based Access

An agent discovers a resource's MCP vocabulary and declares the exact tools it needs. The resource maps declared operations to an R3 document — a signed, content-addressed authorization definition — and returns a resource token carrying the document's URI and SHA-256 hash. The agent sends this to its Person Server (PS), which federates with the AS. The AS fetches and verifies the R3 document, then issues an auth token with r3_granted. The resource enforces access directly from the token with no introspection call.

R3 §4–6
AgentCalendar ResourcePerson ServerAuth Server1GET /.well-known/aauth-reso…2002POST /authorize + r3_operat…3POST /token + resource toke…4PS federates: POST /token +…5GET /r3/a1b2c3d4 (AS fetche…6200 auth token (r3_granted …7POST /mcp/tools/call (creat…
GET https://calendar.example.com/.well-known/aauth-resource.json200

Agent fetches well-known metadata to discover which vocabularies the resource supports.

r3_vocabularies maps vocabulary URIs to discovery endpoints — the MCP server URL, OpenAPI spec URL, etc.

Instead of guessing at scope strings, the agent can now declare the exact operation names the resource itself uses.

The resource advertises two vocabularies here. The agent will use MCP since it's interacting via an MCP server.

1 / 7
speed

Step 1: GET /.well-known/aauth-resource.json → r3_vocabularies

Request / response
Token Lifecycle
Resource Tokenresource+jwt
Auth Tokenauth+jwt
GEThttps://calendar.example.com/.well-known/aauth-resource.json
Host

calendar.example.com