Identity proof is not authorization: the split the whole room converged on

2026-10-22 · RTTP · IQA

Reading the Draft · No. 9 · Sources cited in this piece: W3C AI Agent Protocol CG meeting minutes, 21 October 2026 (quoted verbatim) · RFC 6749 §1.3–1.4 · W3C DID Core 1.1 · uber/ADR #163 · Proof x401 launch release, 15 Oct 2026 (via Manila Times mirror) · our scope declaration, CG post 0015 · Sister pillars: rttp:// (CRI 27) · iqa:// (CRI 28)

On 21 October the W3C AI Agent Protocol CG spent its central hour on a question this series has circled since the first entry: when an agent presents an identity proof, what exactly has been established? The meeting's answer was a line drawn with unusual clarity — and it happens to be the line our third axis is built around. Four ecosystem voices, one boundary, converged from four different directions in one month.

Figure 1: the division of labor as the CG meeting stated it. Each layer has its own product; the red strip lists what none of them establishes alone. The proposal under discussion at the meeting does not blur these layers — it refuses to.

Three layers, three different products

The meeting minutes state the division verbatim: “DID and authentication proofs establish the agent's identifier and control of an authorized key. They do not by themselves establish an organizational role, user consent, or resource permission.” The middle layer gets the same treatment: “Verifiable Credentials (VCs) can carry signed claims about roles or direct mandates. A verifier still needs to assess issuer authority, holder binding, credential status, constraints, and local policy.” And the third: “OAuth manages resource-side grants, scopes, access tokens, refresh, and revocation. The authorization server and resource server make and enforce access decisions independently of identity discovery.”

Nothing in that split is new to anyone who has read the standards. OAuth has kept its two currencies apart since 2012 — “An authorization grant is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token,” and “Access tokens are credentials used to access protected resources.” A grant is evidence of permission; a token is the usable form of that permission; neither is an identity. What was new on 21 October was a room of protocol designers restating the separation as the load-bearing wall of an agent authorization proposal — and the minutes recording that the separation survived contact with the discussion: no approach was adopted that blurs it.

The DID's own fine print

The identity layer deserves its own reading, because the enthusiasm around agents occasionally outruns the specification. W3C DID Core 1.1 says: “Decentralized identifiers (DIDs) are a new type of identifier that enables verifiable, decentralized digital identity,” and its central promise is precise — “the design enables the controller of a DID to prove control over it without requiring permission from any other party.” Read that carefully: control, not entitlement. The specification's achievement is that you can prove you hold the keys. It has never claimed to answer what the keys entitle you to do. The CG discussion adds the institutional reading on top: even where a credential claims a role, the verifier must still weigh issuer authority, binding, status, constraints and local policy — five assessments, none of them performed by the proof itself.

Where the third axis sits

In the conformance thread on the same list, we pre-registered our scope before the meeting: we claim evidence freshness and authority validity; action-time authorization is deliberately not claimed — by design (post 0015). The meeting's split is that design principle restated by a room that owes us nothing and quoted none of our text. That is the strongest form of agreement a specification can get: convergence without coordination.

And the convergence is now measurable. rugsnare, a production attestation system for MCP tool contracts, confirmed on Uber's ADR #163 that separating attestation from verdict is “a primitive we already run in production”. Proof's x401 asks the website's question in two halves — “prove who it's acting for and what that person approved” — identity and permission as two distinct proofs in one flow. Four ecosystem voices, one boundary, arrived at independently: the axis is real, and everyone can feel where it runs.

Figure 2: our conformance scope as pre-registered in post 0015, against the meeting's division. We claim the first two axes; the third is deliberately left to the layer that owns the resource. A protocol that vouches for everything can be trusted for nothing.

What we are not claiming

Our own protocols stop at the same line. RTTP (rttp://) names where and when an intent is addressed — the address is derived from the authority, and nothing in it is a permission. IQA (iqa://) attests whether a subject's statement stands within a lease — and nothing in it is a grant. Neither scheme carries an authorization decision, because neither scheme owns the resource the decision would open. Authorization stays where it has always lived: with the party that has something to lose.

One line: identity proof answers who holds the keys; authorization answers what the keys may open; a specification that knows the difference between the two is the only kind that can be audited for either.