Where the trust anchor lives: registry, federation, or derivation
Sources cited in this piece · IETF draft-aip-agent-identity-protocol-00 (NVIDIA et al., 2026-03) · W3C AI Agent Protocol Community Group technical report (2026-09-24) · Sister pillars: rttp:// (CRI 27) · iqa:// (CRI 28)
The previous piece asked what makes a signer trustworthy (a signature is not trust). This one asks one level deeper: where does the trust anchor live? In 2026 the same question received three official answers. These are not three schools trading slogans — each answer carries formal text. We put the three papers on one table and walk them row by row.
1. Route one: the registry
The IETF Agent Identity Protocol draft (co-authored by NVIDIA) is the most direct: Layer 1 assigns every agent a unique identifier and a key pair "registered with an AIP Registry"; the agent signs every outbound action with that key; Layer 2 interposes a proxy that verifies the signature, evaluates a declarative policy, and produces an allow or deny.
Credit where due — the draft is honest about its own anchor. Its security considerations state in plain text: "A proxy MUST be configured with an explicit list of trusted registry hostnames and the TLS certificate fingerprint (or CA) for each. Agent Records from registries not on this list MUST be rejected." The anchor of trust is a configuration file. The revocation mechanics are stated with equal candor: "In the worst case, a revoked agent can continue making calls for up to 60 seconds after revocation."
The advantages are obvious: revocable, auditable, enterprise-controllable — regulated markets will want this. The costs are written on the same page: the registry is a gatekeeper, verification must reach the registry online, and the final endorsement of the anchor is a list maintained by hand.
2. Route two: the federation
The W3C technical report answers with a federated identity architecture, citing its own model — "a viable agent identity scheme should draw on the successful experience of email systems": each platform manages its own account system in a centralized manner, cross-platform interop rides on standard protocols, and identity documents are hosted on the agent's own domain.
The strength of this route is pragmatism: no rebuild of existing systems; platforms start from what they already do. Its boundary is equally clear: the unit of trust is still the platform — to verify an agent is first to trust the domain hosting its identity document; the document carries no built-in freshness and no built-in offline path. Federation dilutes the registry's O(N²) bilateral trust into O(N) hosted trust — a successful dilution, but not a reduction to zero.
3. Route three: derivation
Our paper sits in the third cell. In the Resonant Time Transfer Protocol (RTTP), the address is derived — the first 16 bytes of SHA-256(canonical authority). Derivation is occupancy: no registry can reject you, and no registry can revoke you; the address is freehold, and the landlord is mathematics. Identity Quality Assurance (IQA) writes "who vouches for this statement" into the signed envelope itself: the vouching subject, the organ, the scope — all fields verifiable inside the envelope.
Time lives inside the protocol: every envelope carries a 120-second freshness lease (standing), a closed set of ghost / probation / radiant / genesis — against the draft's "up to 60 seconds" revocation latency, our answer is to build expiry into every statement rather than depend on a registry's revocation stream. Verification completes fully locally: zero network, zero third parties, fail-closed. Thirty seconds to verify a piece of evidence with your own hands (the tooling piece).
The honest ledger: derivation has its own initial-value problem — who signs the first piece of evidence? Our answer sets genesis as an off-axis epoch anchor: unearnable, unlosable, and owned by no one (who signs the first evidence). There is no free lunch in this cell, only clearly marked prices.
4. Three papers, one table
Placed side by side, the conclusion is not that one route annihilates the others: regulated markets will likely pick the registry, platform ecosystems will likely pick federation, and permissionless open collaboration can only pick derivation. The three routes will coexist for a long time — that is not fence-sitting, it is the reality of deployment environments.
But one row is a choice of exactly one: WHERE and WHEN. Where does an agent's stable address come from, who vouches for it, and how long does it live — the registry route entrusts the answer to a configuration list, the federated route entrusts it to a domain, and the derivation route hands it to mathematics and a lease. There is no middle option in this row, because "who is the landlord of the address" is a question that must be answered — and refusing to answer is itself an answer.
rttp and iqa are provisionally registered at IANA (2026-09-22 / 2026-10-13, verified 2026-10-17). Our paper lives at draft-li-rttp-iqa-addressing-00 — the same datatracker that hosts NVIDIA's AIP draft. Line-by-line reading is welcome.
Sources [1] IETF draft-aip-agent-identity-protocol-00 (J. Cao · Montcao / C. Arango Gutierrez · NVIDIA, 2026-03-16), §1, §5.3, §9.5 Registry Trust, §9.7 Revocation Latency; quotations taken verbatim from the archived copy [2] W3C AI Agent Protocol Community Group technical report, 2026-09-24, federated identity architecture section [3] IANA URI Schemes registry, verified 2026-10-17 [4] draft-li-rttp-iqa-addressing-00.
One line: the registry puts its anchor in a configuration list, the federation puts its anchor in a domain, derivation puts its anchor in mathematics — you must pick one, because "who is the landlord of the address" is not a question that can be left hanging.