IETF · 28 September 2026

AAuth Rich Resource Requests (R3)

draft-hardt-aauth-r3-00

D. Hardt

Individual draftDraft — expect changeAuthorizationAgent-specificField guide

AAuth Rich Resource Requests (R3) (draft-hardt-aauth-r3-00) is Individual draft, 28 September 2026. If you want consent over 'create_invoice(amount=…)' rather than 'scope=invoices', this is the AAuth-shaped design. MCP tool lists are the obvious vocabulary.

ShareLinkedIn X

At a glance

Problem: Agents already speak OpenAPI, MCP tools, gRPC, and GraphQL. OAuth scopes and even RAR types are a second vocabulary. R3 lets a resource publish a content-addressed authorization document in the agent's native vocabulary, including per-call operations that still need a human.
Identity / authn / authz: Authorization detail and consent UX. Extends AAuth; does not replace identity.

Actors

Agent
Resource
Person server / access server

The gap for agents

OAuth scopes are strings like invoices.write. RAR (RFC 9396) adds typed JSON authorization_details, still in a vocabulary the AS invented. Agents already speak OpenAPI operations, MCP tool names, gRPC methods, GraphQL fields. Asking a human to approve a second vocabulary is how you get rubber-stamp consent.

R3 lets a resource publish a content-addressed authorization document in the agent's native vocabulary, including which operations are fully grantable and which still need a human per call. That is the agent-native cousin of RAR, sitting on AAuth rather than on an OAuth authorize query string.

Actors and trust boundaries

The resource authors the R3 document and the vocabulary. The person server or access server shows it to the user and puts hashes and granted operations on the auth token. The agent must not be able to swap the document after approval (r3_s256). The resource must enforce the granted set, not trust the agent's memory of the conversation.

Mechanics

Published snapshot draft-hardt-aauth-r3-00, 28 September 2026, expires 1 April 2027. The introduction still marks Status: Exploratory Draft. Datatracker HTML is https://datatracker.ietf.org/doc/html/draft-hardt-aauth-r3-00. The editor HTML was regenerated 3 October 2026; the markdown last changed with the -00 submission.

Resources advertise r3_vocabularies in metadata and annotate individual operations with the credential each requires (so an agent can plan before a 401). Agents include r3_operations when requesting authorization. Auth tokens carry r3_uri, r3_s256, r3_granted, and optional r3_per_call. Fully granted operations execute immediately; per-call operations require a proposal bound to that invocation.

The document addresses five limits of scopes: human comprehension, machine precision, audit completeness (which version was approved), call-specific consequence (parameters and state, not just the operation name), and agent planning (per-operation credential requirements rather than one resource-wide access_mode).

r3_uri / r3_s256from spec: Quoted from draft-hardt-aauth-r3-00: content-addressed R3 document in effect at approval time. The hash is the audit provenance.
r3_grantedfrom spec: Quoted: operations fully authorized by the grant. Resource enforces this set.
r3_per_callfrom spec: Quoted: operations that still need per-invocation approval (proposal bound to that call).
access_mode per operation (R3 annotation)from spec: Quoted direction from draft-00: R3 can state the AAuth access mode for an individual operation, so an agent holding a person token can see which operations it can already call.

Step-by-step flows

Flow 1

Grant with vocabulary operations

1
Resource publishes an R3 document and vocabularies; metadata points at them and hashes them.
2
Agent requests authorization including r3_operations in the native vocabulary (for example MCP tool names).
3
PS/AS shows a human-displayable rendering. User approves a subset. Auth token gets r3_uri, r3_s256, r3_granted, maybe r3_per_call.
4
Agent calls a granted operation with the usual AAuth signature + auth token. Resource checks hash and set.
5
For a per-call operation the agent submits a proposal; the PS interaction path approves that invocation.

Identity vs authentication vs authorization

Authorization detail and consent UX. Does not replace AAuth identity or HTTP signatures. Does not replace OAuth RAR inside vanilla OAuth — if you are on MCP/OAuth, RFC 9396 is the structured-scope tool; R3 is the AAuth-shaped analogue.

How it composes

AAuth
Extension. Core AAuth still works with scopes. R3 attaches when the resource advertises vocabularies.
RAR
Cousin, not a profile. RAR is RFC 9396 authorization_details on OAuth requests. R3 is content-addressed vocabularies on AAuth auth tokens. Do not send R3 fields to an OAuth AS and expect them to work.
MCP authorization
MCP tool lists are the obvious vocabulary. That does not change MCP's OAuth 2.1 transport. Bridging would be a new profile.
OAuth 2.1
No direct wire relationship. If you stayed in OAuth, use RAR + PAR instead of R3.

What bites agent implementers

Exploratory, even though it is on the datatracker
draft-hardt-aauth-r3-00 is posted, and its introduction still says Status: Exploratory Draft. Pin -00. Do not treat it as a stable IETF document.
Hash swap
If you check r3_granted but not r3_s256 against the document you published, the agent can pair an old grant with a new, wider document.
Per-call is still human-in-the-loop
r3_per_call is not 'the model may always drop_table'. It is CIBA-shaped approval for that invocation, in AAuth clothing.

Stability — what you can ship

draft-hardt-aauth-r3-00, 28 September 2026, expires 1 April 2027, individual, still marked Exploratory Draft. https://datatracker.ietf.org/doc/draft-hardt-aauth-r3/. Source markdown in the AAuth GitHub repo. Not a WG item. Ship only in experiments that already pin AAuth.

Catalog claims (short form)

r3_uri / r3_s256: Content-addressed R3 document in effect at approval time.
r3_granted: Operations fully authorized.
r3_per_call: Operations that still need per-invocation approval.

Implementer notes

Published snapshot is draft-hardt-aauth-r3-00 (28 September 2026, expires 1 April 2027). The introduction still marks Status: Exploratory Draft. The editor HTML was regenerated 3 October 2026; the markdown last changed with the -00 submission, so pin -00. Not a WG item. Do not confuse with OAuth RAR (RFC 9396), which is the stable structured-scope mechanism inside vanilla OAuth.

Specs

Deployment patterns

Primary sources

Datatrackerhttps://datatracker.ietf.org/doc/draft-hardt-aauth-r3/
HTML of draft-00https://datatracker.ietf.org/doc/html/draft-hardt-aauth-r3-00
Editor's copyhttps://dickhardt.github.io/AAuth/draft-hardt-aauth-r3.html
Source markdownhttps://github.com/dickhardt/AAuth/blob/main/draft-hardt-aauth-r3.md