Three maps, one fence: layers of trust, axes of conformance, three questions

2026-10-23 · RTTP · IQA

Reading the Draft · No. 12 · Sources cited in this piece · the W3C AI Agent Protocol CG list, October 2026 thread, quoted verbatim from message 0021 · 0022 · 0020 · our letters 0009 · 0015 · our draft draft-li-rttp-iqa-addressing-00 · our first-pass answers · Sister pillars: rttp:// (CRI 27) · iqa:// (CRI 28)

Something rare is happening on the W3C AI Agent Protocol CG list this week: instead of specifications and position papers, the thread is drawing maps — pictures of where trust lives in an agentic stack. Three of them appeared within days, drawn from three different seats at the table. One maps trust as three layers. One maps it as a single separation between assessment and authority. Ours maps it as three questions, restated in letter 0015 as a claim table with two boxes checked and one deliberately empty. The remarkable thing is not that three maps exist. It is that all three draw the same fence — and that the few places where they differ are exactly the places a fair conformance experiment must score carefully.

Figure 1: three maps drawn in one week, one fence. Layer taxonomies, assessment-versus-authority, and three questions all place enforcement decisions on the far side of the same line — the line where verification ends and authorization begins.

Map one: three layers of trust

The first map came with the cleanest one-line summary the thread has produced: “Identity proves who you are, credentials prove what you are allowed or qualified to do, and behavioral evidence proves that you are actually acting as claimed.” (message 0021). As a taxonomy it is honest and useful: communication trust rests on keys, entity trust on credentials, behaviour trust on runtime evidence. Its strength is coverage. Its risk is the basket — the third shelf collects runtime attestation, trusted-execution proofs, verifiable computation, audit logs, challenge-response and reputation onto one row, mechanisms with nothing structurally in common except that they produce confidence. And the first shelf quietly assumes the hardest part: that controlling a key settles who you are talking to. Our first question to this list was aimed at exactly that row.

Map two: assessment is not authority

The second map arrived as a single sentence doing the work of a specification: “A verified identity does not automatically establish trustworthiness. Likewise, evidence of trustworthiness does not automatically establish delegated authority.” (message 0022). This is the fence, stated flat. Evidence accumulates; authority is granted; the two currencies do not convert. The same reply goes further and locates enforcement where it belongs — in the calling system's policy — while treating communication, credentials and behavioural evidence as layers other systems may supply. That is a map we can work inside unchanged.

Map three: three questions, two of them claimed

Our own map started as four questions (letter 0009) and compressed, by letter 0015, into a claim table. Evidence freshness: claimed — every statement carries its 120-second lease in-band, checked locally against the verifier's own clock, offline. Authority validity: claimed — a named organ answers for a subject in a closed four-state set (ghost, probation, radiant, genesis), and the standing read is a safe, read-only operation. Action-time authorization: not claimed — deliberately; authorization belongs to the calling layer, and the protocol's job is to make the verification answers trustworthy and cheap. The two claimed boxes are carried by RTTP (rttp://) and IQA (iqa://): the address is the first 16 bytes of SHA-256 over a canonical authority, so an in-use authority cannot be substituted without breaking the binding — the preimage row that map one does not have. We asked for it in 0009: “which layer answers preimage defense against impersonation of an in-use authority?”

The strand that agrees, for a narrower reason

One more voice in the same thread argued that trust should not be normative in a protocol at all: “If we force the agent to use which cryptographic way, the trust is limited to getting the right signature.” (message 0020). Our fence partially agrees, for a narrower reason: the protocol hands over verification answers and never decides. Where we part ways is on the hand-over itself — we hold that the answer must be re-earned on a clock and bound by derivation, or “many sources of trust” collapses into whichever source spoke last. A fence nobody maintains is not open; it is unguarded.

Figure 2: the shape of a fair run. Each axis is scored separately, each run declares its mode, and an unclaimed box is reported as out of scope rather than graded as a failure — the reporting discipline three maps are now converging on.

Why one fence matters now

The list is converging on an experiment: a shared timeline — attest at T=0, revoke at T=10, attempt at T=30, 60 and 119, plus a replay case and a revocation-unavailable case — scored per axis, with every run declaring its mode and its claims. That design is only fair if the three maps are recognized as one fence. Score evidence freshness separately from authority validity, because a lease bounds staleness and does not answer revocation. Report action-time authorization as “not claimed” wherever it is not claimed, and never grade a statement-only mechanism as if it enforced anything. A statement is not a decision — the fence everyone keeps redrawing, from three different seats, in three different vocabularies.

One line: three maps, one fence — hash names, attestation vouches, and the swinging of the sword stays with the layer that holds the mandate; the experiment's only job is to keep the fence honest, axis by axis.