One protocol can't hold it: why addressing and attestation are two schemes
Merged spec: draft-li-rttp-iqa-addressing (IETF independent submission review) · rttp:// registered with IANA (Provisional · CRI 27) · iqa:// registered with IANA (Provisional · CRI 28)
Author: Aicent Stack · Part of the Dual-Pillar series · Architecture
When agents start calling each other across domains, they need two things: a semantic addressing scheme (turning "to whom, doing what" into a parseable address) and a trust attestation scheme (turning "who, in what standing, under what authority" into verifiable evidence). In today's protocol stack both are incomplete; and cramming them into one protocol costs more than it seems. This piece explains why the final form is one draft, two schemes.
1. Gaps in the real protocol stack
- DNS + CA: domain addressing rests on DNS; identity binding on CA-issued certificates. Verifying one chain means querying two authoritative facilities online; the trust anchor is the CA system itself;
- OAuth / OIDC: complete authorization semantics, but every check calls home to the IdP — freshness and revocation are always online;
- DID / VC (the W3C route): identity can be self-generated, but DID resolution goes back to the network (registry / DID method), and VC validity checks likewise lean on online endpoints;
- MCP: standardized tool calling — but identity, authorization state, and execution evidence fall outside its semantics.
Read the list as one picture: addressing and proof are scattered across protocols, yet never treated as two independent problems, each given an offline solution. Every "find you, trust you" between cross-domain agents means an online callback to some third party.
2. Two layers, two anchors: the price of forcing them together
The semantic addressing layer needs: determinism (same authority, same address — always), offline-ness (no registry resolution), statelessness (no issuing body). Its trust anchor is the hash function itself — address = SHA-256(authority string)[:16], self-evident on arrival.
The trust attestation layer needs: a state machine (four standing states), leases and revocation, anti-replay, separation of issuance from verification. Its trust anchor is the organ key — a proof is a signature fact.
The two anchors come from different sources; that is the essential constraint. Force both into one scheme, and:
- the addressing format gets dragged along by the attestation layer's evolution (envelope extensions change version, so must the address grammar — and addresses are already written into other people's evidence, nearly unchangeable);
- review and implementation boundaries blur: registrants and implementers must untangle two semantics inside one mixed grammar;
- lightweight "addressing only" scenarios inherit the attestation layer's dependencies.
3. How the two layers interlock
Separate definitions do not mean mutual estrangement. The interlock lives at the byte layer: the 16-byte shard derived by the addressing layer (SHA-256[0:16]) is embedded, unchanged, in the attestation envelope's subject shard field. The same 16 bytes are ROUTE_SHARD (WHERE) in the addressing frame and subject binding (WHETHER) in the attestation envelope. The verifier checks on arrival: a shard mismatch voids either side; a match closes the loop with no callback.
4. The landing form: one draft, two schemes
In the merged specification draft-li-rttp-iqa-addressing, rttp:// and iqa:// each state their own grammar and semantics, sharing one set of terms and test vectors. Evolution cadences decouple (the addressing format is near-frozen; the envelope is free to iterate with deployments), review boundaries stay clean (the registries are cited separately), and zero-dependency deployments remain legitimate (pure addressing scenarios may use rttp:// alone).
5. The honest boundary
This piece does not claim the dual-pillar design solves all of cross-domain trust: delegation-chain semantics are explicitly unspecified in this version; organ-key distribution is a deployment-layer decision; real-time risk control is out of scope — the design only makes "provable after the fact" possible.
One sentence: the address's anchor is a hash; the evidence's anchor is a key — two anchors will not fit in one protocol, but they fit in one draft, interlocked in one set of shards.