Two roads to a client_id: the DID-native road and the metadata road

2026-10-22 · RTTP · IQA

Reading the Draft · No. 10 · Sources cited in this piece: W3C AI Agent Protocol CG meeting minutes, 21 October 2026 (quoted verbatim) · draft-ietf-oauth-client-id-metadata-document-02 · W3C DID Core 1.1 · our draft draft-li-rttp-iqa-addressing-00 · Sister pillars: rttp:// (CRI 27) · iqa:// (CRI 28)

The longest single stretch of the W3C Agent Protocol CG's 21 October meeting went to a deceptively small question: when an agent walks up to an OAuth authorization server, what string does it present as client_id? Two roads were laid on the table. The minutes record that neither was chosen — “No final selection between the two authorization approaches, adoption decision, or PR merge was recorded.” This entry reads both roads anyway, because the interesting part is not the choice between them. It is what both roads quietly concede.

Figure 1: the two onboarding roads as the meeting laid them out. Road A puts a DID where the URL goes and binds the metadata to a digest of its exact bytes; road B keeps the URL and adds an optional DID binding. Neither was adopted; both end at an authorization-server policy gate.

The metadata road, in its own words

The standard road is the Client ID Metadata Document (CIMD), currently an OAuth working-group internet-draft. Its abstract: “This specification defines a mechanism through which an OAuth client can identify itself to authorization servers, without prior dynamic client registration or other existing registration. This is through the usage of a URL as a client_id in an OAuth flow, where the URL refers to a document containing the necessary client metadata.” The URL is tightly constrained — it “MUST use the https URL scheme”, must carry a path, must not carry userinfo or a fragment — and the identity of the client is, in the end, a document published at a location the client controls, fetched and string-matched by the server.

The DID-native road, in the minutes' words

The proposal before the CG puts something else in that slot. The minutes: “Use the agent DID as the OAuth client_id. A validated DID Document identifies authorized authentication keys and links to self-published, CIMD-style client metadata. The shared slides describe binding the metadata URL to a SHA-256 digest of its exact bytes.” The alternative road keeps CIMD and adds a binding: “Keep the HTTPS metadata URL as client_id and the normal CIMD/OAuth path, while adding a verifiable association with a DID.” And the meeting's honesty clause, in the minutes' own recording: neither road was adopted, and the second “remains an alternative for discussion, not a second normative path already implemented.”

The SHA-256 that entered the room

The quietly notable part of road A is not the DID — it is the digest. Binding a metadata URL to “a SHA-256 digest of its exact bytes” means anchoring trust in computation over canonical bytes rather than in a mutable pointer. That is the same instinct our schemes are built on: in our addressing layer, the address is the hash — SHA-256(canonical_authority)[:16], sixteen hex characters computed from the authority itself, no document to fetch and no pointer to follow. The two moves share a philosophy and diverge on a detail that turns out to be everything: what the hash computes over, and what it buys. In the proposal, the hash binds a document that still lives at a URL that still must be fetched before anything is verified. In ours, the hash is the name; verification never leaves the machine.

The landlord count

W3C DID Core 1.1 states the aspiration beautifully — DIDs are “designed so that they may be decoupled from centralized registries, identity providers, and certificate authorities.” The practice, on both roads under discussion, still walks a chain of landlords before a token moves: method-specific resolution, document hosting, digest validation, admission policy at the authorization server. The minutes say it without varnish for road B: “A server that validates the extension can rely on the verified DID as identity evidence. A server performing only ordinary CIMD checks has not thereby validated a DID.” Every one of those checks is a network round-trip to infrastructure somebody else holds — and infrastructure somebody else holds can be closed to you.

Figure 2: where the two roads and our addressing layer part ways. Both onboarding roads verify through a chain of online gates; the derived address is computed, not fetched, and its freshness statement travels in the bytes themselves.

What we are not claiming

We do not score a fight that has not happened: no adoption was recorded, and we claim no outcome. We note only what the minutes put on the record — that the vocabulary of hash-anchoring, exact bytes and byte-level binding has entered the room where client onboarding is being designed. That is precisely where an addressing layer and an authorization layer can eventually meet without either swallowing the other: the addressing layer computes the name, the authorization layer decides the token, and neither pretends to do the other's job. Our two pillars already live on those two sides of the line — RTTP (rttp://) computes the name, and IQA (iqa://) vouches for whether a claim about it still stands.

One line: two roads, one shared instinct — trust less in pointers, more in arithmetic; the roads diverge at the question of who keeps the bytes honest over time, and that is a lease question, not a registration question.