AAuth R3

AAuth R3 is the part of AAuth that an API provider can act on without adopting any of the rest of it, because it asks for something most providers already have. Its claim is that the scope string was always a workaround: calendar:write is a name a provider invented, that a human has to guess the meaning of, that a machine cannot map to an operation, and that carries no version. Meanwhile the same provider publishes an OpenAPI document in which every operation already has a unique, versioned, documented identifier. R3 says: authorize against that.

• Seven vocabularies, one per interface style - urn:aauth:vocabulary:openapi (the operationId), urn:aauth:vocabulary:mcp (the MCP tool name), urn:aauth:vocabulary:grpc (package.Service/Method), urn:aauth:vocabulary:graphql, urn:aauth:vocabulary:asyncapi (AsyncAPI operationId plus action), urn:aauth:vocabulary:wsdl, and urn:aauth:vocabulary:odata. Each one resolves to a description format an agent already parses.
• The resource declares its vocabularies in metadata - /.well-known/aauth-resource.json carries an r3_vocabularies map from vocabulary URI to the document that defines it — the OpenAPI URL, the MCP endpoint. A request then names vocabulary and an operations array, and that is the whole authorization request.
• The resource declares the access, not the client - This is the line R3 draws against Rich Authorization Requests (RFC 9396). RAR is client-declared: the agent builds authorization_details and sends it up. R3 is resource-declared: the resource signs a definition of what access it provides, and the agent carries an opaque hash of it. The agent cannot inflate what it is asking for, because it did not write the ask.
• Per-call authorization for the calls that deserve it - An operation marked r3_per_call gets a content-addressed proposal document with the real parameters of the one pending call: parameters inline for small values, or a digest object with s256, excerpt and media_type for large or sensitive ones, so the full value never leaves the agent-resource channel. A display section carries the sentence the human actually reads — “Send an email as you.” The grant is single-use; replaying it returns the retained result rather than executing again.
• Content addressing is what makes the audit real - The proposal is identified by URI plus a SHA-256, the authorization server records the r3_uri, and the resource verifies the parameters match what was approved by structural equality or BASE64URL(SHA-256(value)) before executing. RAR has no equivalent — its detail is inline in the request and versionless.

For a catalog like this one the R3 argument lands harder than the rest of AAuth, because the gap it describes is measurable today. A provider that publishes a complete OpenAPI with a stable operationId on every operation has already done the work R3 depends on. A provider whose security blocks declare one undifferentiated API key, or whose scopes are three words that appear nowhere in its documentation, has not — and the same absence that makes R3 impossible is what makes its scopes unreadable to an agent right now. R3 is a draft with no deployments; the precondition it needs is a scoring dimension regardless of whether the draft ever ships.