Four questions, four answers: our hand-in to the Agentic Web report
Follow-up to · After the W3C Agentic Web report (2026-10-17) · the four questions are quoted there verbatim, from §6 · Sister pillars in this piece: rttp:// (CRI 27) · iqa:// (CRI 28)
Yesterday we posed four public questions to the W3C AI Agent Protocol Community Group — how to defend against impersonation of an in-use authority, who vouches for a description document's own address, whether agent trust has a lease, and whether interoperability must run at platform granularity (the review that carries them). Questions are cheap; here are our answers — one hand-in, not the answer. If the Community Group's own mechanisms answer any of the four better, that answer wins.
A1 — Preimage defense: protocol, not luck
Q1 asks whether detecting a swapped identity document is a matter of protocol or of luck. Our design keeps the name and the trust in two different places, so a swap fails twice, independently. First, the name is derived: the first 16 bytes of SHA-256 over the canonical authority — the verifier recomputes the derivation from the claimed authority and compares. Impersonating an in-use authority means finding a second preimage that lands in a 128-bit space: a cost wall, not a detection problem. The birthday gate sits at 2^64, and even a collision still has to pass the second gate. Second, and more important: the name carries no trust at all. Hash names, attestation vouches — every statement travels in a signed envelope (Identity Quality Assurance, IQA) that must verify locally before it counts. A swapped document that somehow passes the derivation still fails the envelope; a forged envelope still fails the derivation. Two independent gates, both verifiable offline.
A2 — Address assurance: the algorithm vouches, and yes, split the layer
Q2 asks who vouches for the address of a description document itself, and whether addressing should be split out of "discovery" and specified as an independent layer. Our answer to the second half is yes — the split is already done: Resonant Time Transfer Protocol (RTTP) is addressing specified independently, a namespace plus a time layer, with discovery deliberately left to others. To the first half: in a derived namespace nobody vouches for an address the way a registrar vouches for a domain — the derivation algorithm is the voucher, public and recomputable by anyone. The address of the authority is the root; the description document is an optimization for humans and crawlers, not the trust root. Remove the indirection and there is little left to hijack: you verify the authority you were handed, not the host you were sent to.
A3 — Trust has a lease: 120 seconds, in-band
Q3 asks whether an agent's trust has a lease, and which layer carries the freshness and expiry of statements. Ours does: 120 seconds, carried in-band inside every signed statement — not in an out-of-band certificate store. A closed four-state set — ghost / probation / radiant / genesis, with genesis as the off-axis epoch anchor — replaces the binary valid-or-expired of TLS. The design point is where the lease lives: freshness is a property of statements, not of identities. An identity holds no lease of its own; each of its statements expires on its own clock, and verification — which completes locally — checks that clock offline. Trust is re-earned every two minutes, or it lapses.
A4 — Granularity: complementary, and the unit is the verifiable one
Q4 asks whether cross-platform interoperability must take the platform as its unit (federated), or can sink to the statement as its unit (registry-free). Our answer: the two are complementary, because they answer different questions — platform granularity answers governance; statement granularity answers verification. Our design sinks to the statement: no registry, no landlord; the address is freehold and the landlord is mathematics. Nothing in it excludes platform federation — a federated platform can itself hold a derived root address and carry statement-level leases internally. The test we would propose for choosing a unit of interoperability: pick the unit you can verify without asking permission. Statements qualify. Platforms sometimes do.
Closing
All four answers are falsifiable and independently checkable: the specification is draft-li-rttp-iqa-addressing-00, and rttp and iqa are provisionally registered at IANA (2026-09-22 and 2026-10-13 respectively, verified 2026-10-18). We stand by the questions as much as the answers: each one is a gap we could not find closed in the report or anywhere else, and if a better answer arrives — from the Community Group's own mechanisms or from anyone else — we will adopt it, and say so in public.
Sources [1] The four questions, first posed in our review of the W3C Agentic Web report (2026-10-17), quoted there from the report's requirements discussion [2] draft-li-rttp-iqa-addressing-00 — derivation, envelope signature, and the 120-second lease are specified there [3] IANA URI Schemes registry, rttp and iqa, both Provisional, verified 2026-10-18 [4] The 2^128 second-preimage and 2^64 birthday figures are properties of a 16-byte SHA-256 truncation, stated as cost walls, not as claims about any particular implementation.
One line: we asked four questions in public — so we answer them in public, as one hand-in, not the answer.