AAuth Rich Resource Requests (R3)

4.1. Resource Metadata Extensions

R3 extends the /.well-known/aauth-resource.json document defined in AAuth Protocol ([I-D.hardt-oauth-aauth-protocol]):¶

{
  "issuer": "https://calendar.example.com",
  "r3_vocabularies": {
    "urn:aauth:vocabulary:mcp": "https://calendar.example.com/mcp",
    "urn:aauth:vocabulary:openapi": "https://calendar.example.com/openapi.json"
  }
}

r3_vocabularies (OPTIONAL). A JSON object mapping vocabulary URIs to their discovery endpoints. Keys MUST be vocabulary URIs from the urn:aauth:vocabulary: namespace for standard vocabularies defined in this document, or third-party URI namespaces for proprietary vocabularies. Values are vocabulary-specific discovery endpoints (the MCP server URL, the OpenAPI spec URL, the gRPC reflection endpoint, etc.). A resource MAY advertise multiple vocabularies simultaneously.¶

R3 also defines an additional value for the access_mode field, registered in the AAuth Access Mode Value Registry ([I-D.hardt-oauth-aauth-protocol]): per-call, meaning the resource authorizes each invocation individually against that call's parameters Section 10. A resource declares it here when every operation it exposes works that way, and on individual operations otherwise Section 5.¶

4.2. Operation Identifier Scope

Operation identifiers are scoped to the discovery endpoint the resource advertises for that vocabulary in r3_vocabularies. A resource advertises exactly one discovery endpoint per vocabulary, and each underlying format requires operation identifiers to be unique within a single definition (OpenAPI operationId within a document, MCP tool names within a server, GraphQL operation names within a schema, AsyncAPI operationId within a document). Bare identifiers in r3_operations requests, R3 documents, and r3_granted/r3_per_call claims therefore resolve unambiguously against that one definition, and no additional qualifier appears in tokens.¶

A resource that aggregates multiple backend services behind a single resource identifier MUST do one of the following: present them as one valid definition at the discovery endpoint (renaming colliding identifiers as needed to satisfy the format's uniqueness rules), or expose the services under separate resource identifiers (in which case the auth token's aud claim distinguishes them). Identical identifiers at different resources are already disambiguated by token binding: an auth token is bound to one resource via aud, and r3_uri/r3_s256 pin the exact R3 document the grant was drawn from.¶

4.3. Standard Vocabularies

This document defines seven standard vocabularies. Third parties MAY define additional vocabularies using their own URI namespaces. Each vocabulary defines: the vocabulary URI, the structure of operation requests, how the resource maps operations to R3 documents, and the discovery endpoint.¶

Standard vocabularies use the urn:aauth:vocabulary: namespace.¶

{
  "vocabulary": "urn:aauth:vocabulary:mcp",
  "operations": [
    { "tool": "create_calendar_event" },
    { "tool": "modify_calendar_event" }
  ]
}

{
  "vocabulary": "urn:aauth:vocabulary:openapi",
  "operations": [
    { "operationId": "createEvent" },
    { "operationId": "updateEvent" }
  ]
}

{
  "vocabulary": "urn:aauth:vocabulary:grpc",
  "operations": [
    { "method": "calendar.CalendarService/CreateEvent" },
    { "method": "calendar.CalendarService/UpdateEvent" }
  ]
}

{
  "vocabulary": "urn:aauth:vocabulary:graphql",
  "operations": [
    { "operation": "CreateCalendarEvent", "type": "mutation" },
    { "operation": "GetCalendarEvents", "type": "query" }
  ]
}

{
  "vocabulary": "urn:aauth:vocabulary:asyncapi",
  "operations": [
    { "operationId": "publishCalendarUpdate", "action": "send" },
    { "operationId": "receiveCalendarEvent", "action": "receive" }
  ]
}

{
  "vocabulary": "urn:aauth:vocabulary:wsdl",
  "operations": [
    { "operation": "CreateCalendarEvent", "service": "CalendarService" }
  ]
}

{
  "vocabulary": "urn:aauth:vocabulary:odata",
  "operations": [
    { "operation": "Events", "methods": ["GET", "POST", "PATCH"] },
    { "operation": "Events/SendCancellation" }
  ]
}

5.1. Access Mode Annotation

The access mode annotation carries one of the access_mode values defined in AAuth Protocol ([I-D.hardt-oauth-aauth-protocol]) and extended by Section 4.1:¶

session-token MUST NOT appear in an annotation. A resource that manages its own authorization does so for the whole resource, and says so in access_mode.¶

The first three values are ordered by increasing requirement, and a credential satisfying a later one satisfies an earlier one: every request carries an agent token, and a resource MUST have verified a person token before issuing the resource token that an auth token is obtained with ([I-D.hardt-oauth-aauth-protocol]). An agent holding an auth token for a resource may therefore call that resource's person-token and agent-token operations without obtaining anything further.¶

per-call is not a fourth rung on that ladder. It says that no credential held in advance is sufficient: the resource challenges every invocation, builds a proposal from that call's parameters, and the grant that results is consumed by that one call. An agent planning unattended work uses per-call to identify the operations that will block on a person.¶

5.2. Budget Annotation

The budget annotation is a boolean. true means invoking this operation draws down a budget ([I-D.hardt-aauth-budgets]), and an agent intending to call it states a ceiling in its authorization endpoint request.¶

The annotation names no unit and no amount. The resource sets unit and decimals when it mints the resource token, by which point it has seen the agent's r3_operations request and knows which of its operations are in play. Any amount the agent proposes is narrowed by the resource, the PS, and the AS in turn.¶

A budget is carried in the budget claim of an auth token, so an annotated operation requires at least an auth token. Where the access mode annotation is absent, a budget annotation of true implies auth-token rather than the resource-wide access_mode. A resource MUST NOT combine a budget annotation of true with an access mode of agent-token or person-token; an agent encountering that combination MUST treat the operation as auth-token.¶

5.3. Applying Annotations

Annotations are sparse. An operation with no access mode annotation takes the resource's access_mode. A resource whose operations all work the same way annotates nothing.¶

An annotation replaces the default rather than intersecting with it. A person-token annotation on a resource declaring access_mode: auth-token lowers the requirement for that operation. This is what lets a metered resource serve balance and history calls without an authorization round trip.¶

Annotations are advisory. As with access_mode itself ([I-D.hardt-oauth-aauth-protocol]), a resource MAY return any AAuth-Requirement at runtime regardless of what it published. An agent MUST be prepared for a 401 on any operation, including one annotated as needing no more than the agent already holds. Annotations let an agent plan; the runtime requirement is authoritative.¶

Annotations are not an enforcement surface. A resource enforces r3_granted and r3_per_call from the auth token Section 9.1. An annotation is a published expectation about what an operation needs, and a resource MUST NOT rely on an agent having read one.¶

5.4. Vocabulary Encodings

Each vocabulary encodes the two annotations using its own format's extension mechanism, on the definition of the operation:¶

For OData, the annotation is applied to the entity set or bound operation the R3 operation identifier names Section 4.3.7.¶

OpenAPI, using a specification extension on the Operation Object:¶

"/datasets/{id}/purchase": {
  "post": {
    "operationId": "purchaseDataset",
    "x-aauth-access-mode": "per-call",
    "x-aauth-budget": true
  }
}

MCP, using _meta on the tool with a prefix per that specification's convention:¶

{
  "name": "purchase_dataset",
  "_meta": {
    "aauth.dev/access-mode": "per-call",
    "aauth.dev/budget": true
  }
}

The OpenAPI encoding deliberately does not use the Operation Object's security field. AAuth does not correspond to any OpenAPI security scheme type, and tooling acting on a misdeclared scheme would do the wrong thing, where an unrecognized x- extension is ignored.¶

5.5. Vocabularies Without an Encoding

This document defines no encoding for three vocabularies:¶

• gRPC. Custom options survive in descriptors but are interpretable only by a caller that already holds the extension definition, so server reflection does not deliver them to a generic agent.¶
• GraphQL. Standard introspection returns directive definitions, not the directives applied to schema elements, so an agent using the discovery mechanism cannot see an annotation placed as a directive.¶
• WSDL. No encoding is defined.¶

A resource using one of these advertises what it expects through the resource-wide access_mode and relies on AAuth-Requirement for anything more specific. Nothing else in R3 depends on annotations being present.¶

6.1. Request

The agent sends r3_operations in the authorization endpoint request:¶

POST /authorize HTTP/1.1
Host: calendar.example.com
Content-Type: application/json
Signature-Input: sig=("@method" "@authority" "@path" "signature-key");created=1741824000
Signature: sig=:...signature bytes...:
Signature-Key: sig=jwt;jwt="eyJhbGc..."

{
  "r3_operations": {
    "vocabulary": "urn:aauth:vocabulary:openapi",
    "operations": [
      { "operationId": "createEvent" },
      { "operationId": "updateEvent" }
    ]
  }
}

r3_operations (OPTIONAL). An object containing:¶

• vocabulary (REQUIRED). A URI identifying the vocabulary. MUST be supported by the resource as advertised in r3_vocabularies.¶
• operations (REQUIRED). An array of operation requests. Structure is vocabulary-specific; see Section 4.3.1 through Section 4.3.7.¶

When r3_operations is present, the resource maps the declared operations to an appropriate R3 document and includes r3_uri and r3_s256 in the resource token. When r3_operations is absent, the resource MAY still include R3 claims in the resource token based on its own policy.¶

6.2. Response

The resource returns a resource token as defined in AAuth Protocol ([I-D.hardt-oauth-aauth-protocol]), extended with R3 claims:¶

{
  "resource_token": "eyJhbGciOiJFZDI1NTE5IiwidHlwIjoiYWEtcmVzb3VyY2Urand0In0..."
}

The resource token contains r3_uri and r3_s256 identifying the R3 document that covers the requested operations. The resource's internal mapping from operations to R3 documents is opaque to the agent.¶

6.3. Operations Spanning Multiple Definitions

A resource MAY organize its authorization definitions into multiple R3 documents internally — for example, one document per scope or operation group. A single resource token carries exactly one r3_uri/r3_s256 pair, and the resulting auth token therefore pins exactly one R3 document.¶

When an agent's r3_operations request includes operations that the resource maps to more than one of its internal definitions, the resource MUST compose a single R3 document that covers all of the requested operations and reference that composed document in the resource token:¶

• operations is the union of the requested operations, expressed in the request's vocabulary.¶
• display describes the combined access. The resource MAY merge the display sections of the underlying definitions (for example, concatenating implications and unioning data_accessed) or author a purpose-built summary for the combination.¶

The composed document is served at a fresh content-addressed r3_uri exactly like any other R3 document (see Section 7.2): the resource builds it on the fly and persists the serialized bytes so the hash remains stable across the AS and PS fetches. Because R3 documents are content-addressed, an identical combination of operations reduces to the same hash and MAY be cached and reused across requests.¶

This composition is opaque to the agent. The agent sees one r3_uri/r3_s256 in the resource token regardless of how many internal definitions the requested operations were drawn from, and the auth token's r3_granted and r3_per_call claims express the granted operations against that single composed document.¶

7.1. Fields

vocabulary (REQUIRED). The vocabulary URI identifying how operations are expressed. MUST match one of the vocabularies the resource advertises in r3_vocabularies.¶

operations (REQUIRED). An array of operations covered by this R3 document, using the vocabulary-specific structure defined in Section 4.3.1 through Section 4.3.7. This is the same format used in the agent's r3_operations request and in the auth token's r3_granted and r3_per_call claims.¶

account (OPTIONAL). Present when the authorization endpoint request carried an account parameter ([I-D.hardt-oauth-aauth-protocol]), carrying that same value. It identifies which account at the resource this authorization covers.¶

When account is present, the display section SHOULD name the account in terms the person recognises. The value itself is an identifier in the resource's namespace and may be opaque — a numeric company id, a workspace key — so a consent screen rendering it verbatim tells the person nothing about which of their accounts is being authorized. The resource holds the human-readable name and display is where it belongs; a PS renders display and is not expected to interpret account.¶

display (RECOMMENDED). Human-readable descriptions of the consequences of granting this access. The resource describes what it does, not what the agent intends:¶

• summary (REQUIRED if display present). A short plain-language description suitable for a consent screen.¶
• implications (OPTIONAL). Side effects of granting this access: emails sent, records modified, costs incurred.¶
• data_accessed (OPTIONAL). What data becomes visible to the caller.¶
• irreversible (OPTIONAL). Plain-language description of actions that cannot be undone.¶

7.2. Content Addressing

The R3 hash (r3_s256) is computed as the SHA-256 hash of the bytes of the R3 document as served by the resource, base64url-encoded without padding.¶

The resource's serialization is the document. There is no canonicalization step — verifiers hash the bytes received over the wire, not a normalized form. Resources MUST serialize the R3 document once and serve those exact bytes verbatim on every request for the same r3_uri. Re-serialization between hash computation and serving (e.g. middleware that parses and re-stringifies JSON, CDN minification, response framework helpers that reorder keys) will produce different bytes and break hash verification. Resources that build R3 documents on the fly SHOULD persist the serialized bytes (e.g. in a key-value store keyed by r3_uri or r3_s256) rather than re-build the document per request.¶

The r3_s256 hash is the document's identity, not the URI. The AS caches documents by hash. If a resource updates the document at the same URI, existing auth tokens still reference the previous hash (which the AS has cached). New resource tokens reference the new hash. This enables:¶

• Infinite caching by the AS. A document that verifies against its hash need never be re-fetched.¶
• Permanent audit records. An auth token carrying r3_s256 identifies the exact authorization semantics that were approved, regardless of subsequent changes at the same URI.¶

7.3. Resource Token Extensions

R3 extends the resource token defined in AAuth Protocol ([I-D.hardt-oauth-aauth-protocol]) (a JWT with typ: aa-resource+jwt) with two additional payload claims. When a resource includes R3 information, it MUST include both.¶

Base claims (from AAuth Protocol): - iss: Resource URL - dwk: aauth-resource.json - aud: Auth server URL - jti: Unique token identifier - ps: The iss of the person token the resource verified - sub: The sub of that person token, identifying the person this authorization is for - presented_jti: The jti of that person token, binding this resource token to it - agent_jkt: JWK Thumbprint of the agent's signing key - iat: Issued at timestamp - exp: Expiration timestamp - scope: Requested scopes (optional)¶

A resource token carries no agent identifier; the recipient learns the agent's identity from the agent token that signs the token request.¶

R3 extension claims: - r3_uri (REQUIRED for R3): The URI where the AS can fetch the R3 document. The AS authenticates itself using an HTTP Message Signature. - r3_s256 (REQUIRED for R3): The SHA-256 hash of the R3 document at r3_uri, base64url-encoded without padding.¶

{
  "typ": "aa-resource+jwt",
  "alg": "Ed25519",
  "kid": "resource-key-1"
}

{
  "iss": "https://calendar.example.com",
  "dwk": "aauth-resource.json",
  "aud": "https://as.example.com",
  "jti": "rt-8f3a2b",
  "ps": "https://ps.example",
  "sub": "8f14e45fceea167a5a36dedd4bea2543",
  "presented_jti": "pt-3ab910",
  "agent_jkt": "NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs",
  "r3_uri": "https://calendar.example.com/r3/a1b2c3d4",
  "r3_s256": "aBcDeFgHiJkLmNoPqRsTuVwXyZ0123456789abcd",
  "iat": 1741824000,
  "exp": 1741824300
}

Resource tokens MAY include both scope (as defined in AAuth Protocol ([I-D.hardt-oauth-aauth-protocol])) and R3 claims. When both are present, the AS MUST enforce both independently.¶

8.1. AS Processing

When the AS receives a resource token containing r3_uri and r3_s256, it MUST:¶

1. Validate the resource token signature per AAuth Protocol ([I-D.hardt-oauth-aauth-protocol]).¶
2. Fetch the R3 document at r3_uri. The AS MAY use a cached copy if the cache entry was stored with the same r3_s256 value.¶
3. Compute the SHA-256 hash of the bytes received and compare it to r3_s256. If the hashes do not match, the AS MUST reject the resource token.¶
4. Record r3_uri and r3_s256 in its audit log alongside the token issuance event, the timestamp, ps and sub from the resource token, agent_jkt from the resource token, and the agent identifier.¶
5. Use the operations section for policy evaluation.¶
6. Include r3_uri, r3_s256, r3_granted, and (if applicable) r3_per_call in the issued auth token.¶

The agent identifier in step 4 does not come from the resource token. No token a resource issues carries one ([I-D.hardt-oauth-aauth-protocol]): the resource token binds to the agent's key through agent_jkt and names the person through ps and sub. The AS takes the agent identifier from the sub of the agent_token, which the PS is REQUIRED to send alongside the resource token on the PS-to-AS token request. Where the PS also sends a subagent_token, that token's sub is the agent the auth token is bound to and is the identifier the AS records; the agent_token's sub is its parent, and an AS that distinguishes them SHOULD record both.¶

An AS reached any other way than a PS-to-AS token request has no agent token and therefore no agent identifier. It can still record agent_jkt, which is what a later presentation of the auth token is checked against, but it MUST NOT infer an agent identity it was not given.¶

8.2. Caching

The AS is not required to retain R3 documents beyond their immediate use in token issuance. Its audit log records r3_uri and r3_s256, which is enough to re-fetch and verify the document later.¶

9.1. Resource Enforcement

The resource matches each incoming API call against the auth token claims:¶

1. Match in r3_granted: serve the request.¶
2. Match in r3_per_call: build a per-call proposal Section 10 and return AAuth-Requirement with a resource token referencing it. The AS evaluates the specific call against the proposed parameters.¶
3. No match: reject the request.¶

No token introspection or R3 document fetch is needed at enforcement time. The resource uses the vocabulary it already understands.¶

When r3_operations was not used (the agent received the resource token via a 401 rather than the authorization endpoint), the AS populates r3_granted and r3_per_call based on the operations defined in the R3 document and its own policy. The AS decides which operations to grant outright and which to make per-call.¶

10.1. Proposal Document

In addition to the R3 document fields Section 7, a per-call proposal carries:¶

operations (REQUIRED). The single r3_per_call operation being invoked, in the resource's vocabulary.¶

parameters (REQUIRED). The concrete parameters of the call, machine-readable, for the AS to evaluate and the resource to bind. A large or sensitive value MAY be represented by a digest object in place of the inline value:¶

• s256 (REQUIRED). BASE64URL(SHA-256(value-bytes)) of the parameter value as it will be presented at call time.¶
• excerpt (OPTIONAL). A short, human-readable excerpt of the value for display.¶
• media_type (OPTIONAL). The media type of the value.¶

display (RECOMMENDED). Per-call human context for the user's approval decision. In addition to the structured fields defined in Section 7, a proposal's display MAY include a detail Markdown string. The following sections are RECOMMENDED as a convention (not normative requirements): ## Action, ## To / ## Recipient, ## Details, ## Content (excerpt), ## Irreversible.¶

{
  "vocabulary": "urn:aauth:vocabulary:mcp",
  "operations": [ { "tool": "send_email" } ],
  "parameters": {
    "to": "mom@example.com",
    "subject": "Dinner Sunday?",
    "body": { "s256": "aBcD…", "excerpt": "Hi Mom, are you free…", "media_type": "text/plain" }
  },
  "display": {
    "summary": "Send an email as you",
    "detail": "## Action\nSend an email\n\n## To\nmom@example.com\n\n## Details\nSubject: Dinner Sunday?\n\n## Content\nHi Mom, are you free…"
  }
}

10.2. Flow

1. Per-call challenge. The agent invokes an r3_per_call operation. The resource builds the proposal, persists it keyed by its r3_s256, and returns AAuth-Requirement with a resource token whose r3_uri/r3_s256 reference the proposal — either as a 401 the agent retries, or as a 202 Accepted deferred delivery that holds the invocation ([I-D.hardt-oauth-aauth-protocol]). A resource that can hold the invocation SHOULD use 202: the parameters never leave its hands, so the verification in step 3 disappears and the agent never reconstructs the call. The token carries only the reference, not the parameters.¶
2. Approval. The AS fetches the proposal and evaluates parameters per policy; the PS renders display for user consent. On approval, the AS issues a per-call auth token that echoes the proposal's r3_uri/r3_s256 and lists the now-approved operation in r3_granted.¶
3. Enforced completion. Under 202, the resource executes the held call when a valid per-call auth token arrives at the pending URL; there are no parameters to verify, because the agent never re-sends the call. Under 401, the agent retries the actual call with the per-call auth token, and the resource recovers the proposal from its store via r3_s256 and MUST verify that the agent's actual parameters match the approved proposal: inline parameter values MUST be compared structurally (JSON value equality — member order and insignificant whitespace do not affect the result), and for any parameter represented as a digest the resource MUST verify that BASE64URL(SHA-256(presented-value)) equals the stored s256, so the agent MUST present those values byte-identically. If anything differs, the resource MUST reject the call. An approval to email one recipient cannot be replayed against another.¶
4. Single use. The grant is consumed by the call it approved, on either delivery. A resource MUST NOT execute more than one invocation under one per-call auth token: under 202, completion consumes the pending record; under 401, the resource MUST mark the stored proposal consumed when it executes the call. A repeated presentation of the same per-call auth token MUST be answered from the retained result of the executed call, not executed again — the first response can be lost in transit, and the agent cannot otherwise distinguish "not executed" from "executed, response lost". The resource SHOULD retain the result at least until the auth token's exp.¶

10.3. Large and Sensitive Payloads

Representing a parameter as a digest keeps large or sensitive payloads out of every token and away from the PS: only the s256 and a short excerpt appear in the proposal. The full bytes travel directly from the agent to the resource at call time, where the resource verifies them against the digest. This is also a privacy control — the resource chooses what the PS (and through it, the user-facing surface) sees versus what stays between the agent and the resource.¶

Whether the AS or PS additionally machine-evaluates parameters (for example, auto-denying a payment over a threshold) or treats the proposal as display-for-human-consent only is deployment policy. The parameters are present in the proposal either way, so machine policy can be layered on without a format change.¶

11.1. R3 Document Access Restriction

A party fetching r3_uri MUST authenticate itself with an HTTP Message Signature as defined in the AAuth Protocol ([I-D.hardt-oauth-aauth-protocol]). The resource MUST reject any request that is not signed by a party entitled to that document. Two parties are:¶

• the AS named in the aud of a resource token carrying that r3_uri; and¶
• the PS that issued the person token the resource verified before issuing that resource token, which is the ps claim of the resource token itself ([I-D.hardt-oauth-aauth-protocol]).¶

In three-party access these are the same party — aud is the PS. In four-party access both fetch, and for different reasons: the AS reads operations to evaluate policy, the PS reads display to render consent Section 8. Any other signer MUST be rejected.¶

Agent opacity — the agent carries the hash of a document it cannot read — depends entirely on this restriction. A resource that does not require the signature, or that accepts signatures from other keys, lets an agent follow the r3_uri in its resource token and read the document. Implementations SHOULD verify the restriction during deployment testing.¶

11.2. Hash Verification

The AS MUST verify r3_s256 against the fetched document before using it. Failure to verify allows a resource to serve different content than what was hashed in the resource token.¶

11.3. Audit Log Integrity

The AS MUST write audit log entries atomically with token issuance. An auth token issued without a corresponding audit log entry creates an undetectable gap in the observability record. Implementations SHOULD use transactional writes or equivalent mechanisms.¶

11.4. Operation Validation

For all vocabularies, the resource MUST validate declared operations against its authoritative definition (MCP tool list, OpenAPI spec, .proto file, GraphQL schema, AsyncAPI spec, WSDL document, or OData $metadata) before issuing a resource token.¶

11.5. Operation Access Annotations Are Not Authorization

An operation access annotation Section 5 is published in a document any agent can fetch, and it is a statement of expectation, not a grant. A resource MUST NOT treat the presence of an annotation as evidence of anything about the caller, and MUST enforce every request against the credential actually presented and the claims it carries. An agent that has read an annotation has learned only what the resource expects to ask for.¶

The converse also holds. Annotations reveal which of a resource's operations are gated and which are metered. That is the information the mechanism exists to publish, and a resource unwilling to disclose its authorization posture per operation omits the annotations and challenges at runtime instead.¶

11.6. Grant Enforcement

Resources MUST enforce r3_granted and r3_per_call claims in auth tokens. Operations in r3_granted define fully authorized access. Operations in r3_per_call MUST trigger an AAuth-Requirement before being served. The resource MUST reject API calls that do not match an operation in either claim.¶

12.1. JWT Claims Registration

This document requests registration of the following JWT claims in the IANA JSON Web Token Claims registry:¶

12.2. AAuth Access Mode Value Registration

This document requests registration of the following value in the AAuth Access Mode Value Registry established by AAuth Protocol ([I-D.hardt-oauth-aauth-protocol]):¶

12.3. R3 Vocabulary Registry

This specification establishes the AAuth R3 Vocabulary Registry. The initial contents are:¶

New values may be registered following the Specification Required policy ([RFC8126], Section 4.6).¶

A.1. Why Not RAR

OAuth 2.0 Rich Authorization Requests ([RFC9396]) defines authorization_details as a structured extension to authorization requests. RAR is a natural reference point for this work. R3 deliberately does not use or profile RAR for the following reasons:¶

Directionality. RAR is client-declared: the agent constructs authorization_details and sends it to the AS. The agent defines what it wants. R3 is resource-declared: the resource defines what access it provides and signs that definition. The agent cannot modify or reframe it. This is the opposite directionality, and the security properties depend on it.¶

Agent opacity. In R3, the R3 document is fetched by the AS directly from the resource, restricted to AS-only access. The agent carries a hash of a document it cannot read. RAR has no equivalent because the client constructs the authorization details and necessarily knows their content.¶

Content addressing. R3 uses a content-addressed URI plus SHA-256 hash to pin the exact authorization semantics in effect at approval time. An auth token carrying r3_uri and r3_s256 is a permanent, verifiable record. RAR carries no equivalent versioning or integrity guarantee.¶

Audit trail. The AS records r3_uri in its audit log, creating a durable reference to the exact R3 document version. This is not possible with RAR's inline authorization_details structure.¶

RAR and R3 are complementary. RAR remains appropriate for client-declared authorization detail. R3 addresses the resource-declared case that RAR was not designed for.¶