IETF · 14 September 2026 (editor's copy)

AAuth Rich Resource Requests (R3)

draft-hardt-aauth-r3 (editor's copy; exploratory)

D. Hardt

Individual draftDraft — expect changeAuthorizationAgent-specificField guide

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.

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

Editor's copy draft-hardt-aauth-r3-latest, published 14 September 2026 (catalog previously cited 3 September), expires 18 March 2027, marked 'Status: Exploratory Draft'. Not obviously on datatracker as a numbered I-D at fetch time — canonical HTML is the GitHub editor's copy.

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 the R3 editor's copy: 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: R3 can state the AAuth access mode for an individual operation. Editor AAuth registry includes per-call as an R3 addition.

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, maybe not on datatracker
Do not treat R3 as a stable IETF document. Confirm whether a given revision is posted to datatracker. Pin the GitHub HTML you implemented.
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

Editor's copy https://dickhardt.github.io/AAuth/draft-hardt-aauth-r3.html dated 14 September 2026, exploratory, expires 18 March 2027. Source markdown in the AAuth GitHub repo. Individual work, 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

Marked exploratory on aauth.dev. Confirm whether a given revision is on the datatracker; the canonical HTML at research time was the editor's copy. Do not confuse with OAuth RAR (RFC 9396), which is the stable structured-scope mechanism inside vanilla OAuth.

Relationship to others

Primary sources

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