Content Addressing & User Consent

The R3 document's display section drives informed user consent — the resource describes what IT does, including irreversible actions. The agent's Person Server (PS) fetches the R3 document and presents it to the user before approving. The r3_s256 hash baked into the final auth token creates a permanent, content-addressed audit record: even if the resource later updates the document at the same URI, the approved semantics are pinned forever.

R3 §5 — R3 Document, §6 — Auth Token Extensions

POST https://calendar.example.com/authorize200

Agent requests two MCP tools: create_calendar_event and send_calendar_invite.

Resource maps these to an R3 document. This R3 document has a display.irreversible field — sent invitations cannot be recalled.

The resource token carries r3_uri (where the doc lives) and r3_s256 (SHA-256 of its content).

aud=PS URL in the resource token — this is a 3-party flow. The PS is the token authority and will handle consent.

The agent cannot read the R3 document. It only carries the hash — 'agent opacity'.

1 / 5

speed

Step 1: POST /authorize + r3_operations → resource token (r3_uri + r3_s256)

Request / response

Token Lifecycle

Resource Tokenresource+jwt

Auth Tokenauth+jwt

User Consent Flow

→

POSThttps://calendar.example.com/authorize

Host

calendar.example.com

Content-Type?

application/json

Signature-InputAAuth?

sig=("@method" "@authority" "@path" "signature-key");created=1741825000;alg="ed2…

Signature-KeyAAuth?

sig=jwt;jwt="eyJhbGciOiJFZERTQSIsImtpZCI6ImFnZW50LWtleS0xIiwidHlwIjoiYWEtYWdlbnQ…

SignatureAAuth?

sig=:Q29udGVudEFkZHJlc3NpbmdBdXRob3JpemVTaWduYXR1cmVCYXNlNjQ=:

Body

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

Resource Tokenaa-resource+jwt

Header

{"alg":"ES256",
"kid":"resource-key-1",
"typ"?Token type identifier. aa-agent+jwt = Agent Token, aa-resource+jwt = Resource Token, aa-auth+jwt = Auth Token:"aa-resource+jwt"
}

Payload

{"iss"?Issuer — who created and signed this token:"https://calendar.example.com",
"dwk"?Discovery Well-Known — the metadata document path for key discovery (e.g. aauth-agent.json):"aauth-resource.json",
"aud"?Audience — which party should accept this token:"https://ps.example",
"jti"?JWT ID — unique identifier for this token (prevents replay):"rt-ca-890a",
"agent"?Agent identifier in aauth: URI format (e.g. aauth:local@domain):"aauth:local@agent.example",
"agent_jkt"?JWK Thumbprint of the agent's signing key — used for key binding:"NzbLsXh8uDCcd-6MNwXF4W_7noWXFZAfHkxZsRGC9Xs",
"r3_uri"?URI of the R3 document defining the authorized operations for this token:"https://calendar.example.com/r3/a1b2c3d4e5f67890",
"r3_s256"?SHA-256 hash of the R3 document (base64url). Content-addressed — enables immutable audit trail and infinite AS caching.:"ZzKlMnOpQrStUvWxYz0123456789AbCdEfGhIjKlMn",
"iat"?Issued At — Unix timestamp when the token was created:1741825000,
"exp"?Expiration — Unix timestamp after which the token is invalid:1741825300
}

sig: MEYCIQDcontent_addressing_resour…