AICENT.COM
← Back to Blog

What revision -01 of draft-li-rttp-iqa-addressing adds: the lease, the wire, and the answer semantics

2026-10-28 · RTTP · IQA
Reading the Draft · No. 14 · Sources cited in this piece · the revision under reading, quoted verbatim: draft-li-rttp-iqa-addressing-01 (full text) · the prior revision it supersedes: draft-li-rttp-iqa-addressing-00 (full text) · the series page: datatracker · the working paper that carried the wire formats first: iqa.org/whitepaper/ · the byte-level dissection of 9 October: What fits in 128 bytes · the release histories measured for this piece: iqa-org · rttp · the conformance laboratory named by §8.3: Agent-Authority-Conformance · Sister pillars: RTTP (rttp://, CRI 27) · IQA (iqa://, CRI 28)

On 27 October 2026, revision -01 of draft-li-rttp-iqa-addressing entered the Independent Submission queue. The arithmetic first: 34 pages against -00's 16, 1,937 lines against 911 — the document slightly more than doubled. But the doubling is not evenly spread, and where it did not land is the news: sections 1 through 5, the shared addressing model and both schemes' syntax and client requirements — the derived-address core this series spent thirteen pieces reading — are structurally untouched. What -01 adds are three new top-level sections (the trust lease, the wire formats, the answer semantics), a related-work section, and a security considerations chapter rebuilt from its foundations. This piece reads the additions in order, from the primary text only.

-00 → -01 · what moved and what did not16 pp / 911 lines (24 Sep 2026) → 34 pp / 1937 lines (27 Oct 2026)§1–§5 · UNTOUCHEDshared model · rttp syntax · ROUTE_SHARD derivation · iqa syntax · client rules§6 · NEW · Trust Lease and Freshnesslease_expiry in-band · offline check · cached-lease vs live-standing-read§7 · NEW · Wire FormatsPulseHeader128 + extension block · AE-128 envelope · test vector AE128-VECTOR-1§8 · NEW · Attestation Response Semanticsfive refusal reasons · priority order · grant_ref · observation rulealso new: §12 Related Work · Security Considerations rebuilt (truncation account · RFC 9846)section lists diffed from the two IETF archive texts; page counts per the ISE listing
Figure 1: the anatomy of the revision. The derived-address core is byte-stable; the growth is three new load-bearing blocks — the lease, the wire, the answer sheet — plus a related-work map and a rebuilt security chapter.

The lease: freshness moves in-band

The first new section, §6 Trust Lease and Freshness, gives the iqa answer its clock. The rule is compact: every attestation answer carries its freshness window in the answer itself — the lease_expiry field of the envelope — and a verifier checks that instant against its own clock, offline. No cache header, no lookup result, no out-of-band agreement. An expired lease MUST be refused; a verifier MUST NOT extend, renew, or reinterpret one except by obtaining a new answer. Freshness stops being a property of the channel and becomes a property of the bytes.

Then the number, stated with unusual care: “Current deployments use 120 seconds. The number constrains the verifier's honesty, not the speed of any channel: a verifier that accepts a statement older than its lease is asserting more than it knows.” Operators MAY configure other windows; the mechanism does not depend on the value — the draft is careful to make 120 seconds a deployment observation, not a protocol constant.

§6.2 names the two operating modes, and the naming does real work. In cached-lease mode the verifier relies on a previously obtained, unexpired answer — checked locally and offline, which the draft calls the design point of the mode, not a degradation. But the mode makes no claim about the present: a policy that demands a current observation refuses with authority_not_determined; a policy that accepts lease-fresh evidence admits it, with exposure bounded by the lease. In live-standing-read mode the verifier consults the organ at each request, and the failure rule is the one this series has quoted before: “an organ that cannot be reached is not read as silent consent.” Both modes share two normative floors — expired leases MUST be refused, and an unreachable organ MUST NOT be read as affirmative standing.

§6.3 closes the section by closing its own border: store-and-forward and archival uses — verifying a statement long after its lease, with its age stated in the bytes — are out of scope, and explicitly not contradicted: a statement that makes no freshness claim is never falsified by one.

The wire: two 128-octet frames

The second new section, §7 Wire Formats, is the one implementers will read most, because it is the one that can be executed. Two fixed-length frames, one per scheme, both exactly 128 octets, both big-endian, both fail closed: a receiver MUST reject any frame whose length is not exactly 128 or whose magic or version it does not know. And one design decision sits at the center: the derived address of the subject appears at a fixed offset in both formats, the same 16-octet value §4.4 derives. In the draft's own words: “One subject has one derived address and two carriers.” The two frames also split the WHEN of a claim between them — the pulse states when it was emitted (TIMESTAMP, absolute nanoseconds), the answer states until when it may be relied on (lease_expiry) — and the draft draws the moral directly: “the schemes' job is to make the where, the when, and the whether trustworthy and cheap.”

The rttp pulse header (§7.1) is fixed-offset: RTTP magic, VERSION_ID 130, SEQUENCE_ID, TIMESTAMP, TTL and priority bytes, the ROUTE_SHARD, the 32-octet AID_ORIGIN, and a 26-octet extension block. That extension block (§7.1.1) is quietly the most pragmatic paragraph in the document. It occupies bytes that were previously reserved and zero — without moving or redefining any earlier field and without incrementing VERSION_ID — so implementations reading only offsets 0x00–0x65 continue to validate unchanged. Inside it: a SPEC_REV byte, a FLAGS byte whose only current bit is URI_ANCHORED (routing between nodes MUST require it; a clear flag means the shard has no globally routable semantics), and a 16-byte ACTION field carrying the open action token — with the rejection rules stated fail-closed, and the open set kept open: “enumerating an open set would close it,” so an unrecognised verb MUST be treated as having unknown safety, never silently defaulted.

The time fields (§7.1.2) are deliberately narrow. TIMESTAMP is an absolute count of nanoseconds since the Unix epoch, and subtracting it from the receiver's clock yields the pulse's age offline, from the bytes alone: “a pulse states how old it is, whatever channel carried it.” But age is not standing — a receiver MUST NOT treat it as a statement about the subject's validity; the pulse's moment becomes decision-relevant only against an answer's lease. TTL_PULSE is a hop count that bounds forwarding, nothing more. SEQUENCE_ID orders a sender's own emissions — no cross-sender meaning, no global ordering.

The iqa envelope (§7.2) carries the answer: IQAE magic, version, the HMAC-SHA256 algorithm byte, lease_expiry, the subject's intent_shard, the attestation, the organ tag, a per-verdict nonce, and the standing byte. That standing byte takes one of exactly four values — 0x00 ghost, 0x01 probation, 0x02 radiant, 0x03 genesis — a closed set fixed by the document, with the semantics pointed where they belong: “this document fixes only the wire encoding.” The attestation covers the entire frame with the attestation field itself zeroed, so a swapped organ tag, a flipped verdict, or a replayed frame with an exchanged standing byte does not survive verification. The verification procedure is four steps, all local. And then the part that turns prose into physics: §7.2.1 publishes AE128-VECTOR-1, a complete 128-octet frame — authority f3b2a1c4.pillar.example, shard 557c8154d3780cb78cc5fa1bd72b331c, HMAC and all — that any implementation MUST reproduce byte for byte from the parameters alone. A spec that ships its own test vector has already had the argument about ambiguity.

§8.1 · the refusal ladder · first match winsnull refusal = the only representation of "permitted" · no affirmative granted value exists1 evidence_binding_mismatchevidence bound to a different grant or subject than requested2 evidence_expiredthe lease of the presented evidence has expired3 authority_not_determinedunreachable source refused here · never read as assent4 authority_revokedthe authority for the subject has been revoked5 operation_not_permittedeverything else the subject or grant forbidsclosed set · MUST NOT emit outside it · MUST NOT reinterpret · a response without its reason is not conformant
Figure 2: the refusal ladder of §8.1. Five values, a priority order that is part of the definition, and one discipline: an unreachable authority source is refused under its own name, never folded into a substantive verdict.

The answer sheet: refusals with names, grants with receipts

The third new section, §8 Attestation Response Semantics, defines the two fields every attestation response carries: a refusal reason and a grant reference. The refusal reason starts from a negative: “A null refusal reason is the only representation of “permitted”; there is no affirmative “granted” value.” A permit asserts nothing beyond the lease; only a refusal says anything. The five refusal values form a closed set with a priority order that is itself part of the definition — implementations MUST NOT emit values outside the set and MUST NOT reinterpret an emitted value — and a response that reports an outcome without its reason is simply not conformant: the reason is what makes a refusal auditable.

The grant reference (§8.2) is the receipt side: every response, permit or refusal, names the authorisation it relied on — the grant identifier, the evidence identifier, the issue and expiry instants, and observation_as_of_ms, the as-of instant of the standing observation the answer relied on, or null. That last member carries the section's sharpest rule, aimed at the quietest way to inflate an answer: “observation_as_of_ms is null whenever the observation the answer relied on is absent or not fresh, even if a later, successful observation is available at answer time.” A diagnostic read performed after the relied-on evidence expired does not backfill the field — “diagnostic reads do not participate in authorisation and do not renew evidence” — and the draft states the principle in one line: the member records “the age of what the answer actually relied on, not the freshness of the freshest thing the implementation happened to see.”

§8.3 then labels the vocabulary's provenance, and the label is precise: the closed set and its priority order are defined by this document; the vocabulary has been exercised in public conformance runs recorded by the Agent-Authority-Conformance laboratory of the Linux Foundation Decentralized Trust — “the laboratory records runs and certifies nothing.” Deployment history and normative definition, kept in separate sentences.

None of this is new: the wire shipped before the draft did

One clarification before the security chapter, because a reader arriving from the past few weeks of public activity could get the direction of this revision exactly backwards. Nothing in the new sections was learned anywhere recently — and the honest record is cleaner than a mere lag: when -00 was submitted on 24 September, the AE-128 envelope did not yet exist in shipped code, so -00 could not have carried it. The two halves of §7 shipped at different depths. The rttp pulse header — the 128-byte frame of §7.1 — has been public from the start: it was demonstrated wire-exact, VERSION_ID 130 and all, in the public semantic demo on 12 September, and it ships in the rttp package from the 1.2.8 line (measured in the wheel). The iqa attestation envelope — the 128-octet IQAE frame of §7.2 with its HMAC and lease — shipped in iqa-org 1.3.1, published on 4 October 2026 on all three registries: twenty-three days before -01 codified it. The rttp package has carried its offline self-test in the box since the 1.2.8 line: 83 checks, zero network calls, re-measured the day this piece was written.

The public record trails the code, never leads it. On 9 October, five days after the envelope shipped, we published a byte-level dissection of the 128-byte frame under the title “What fits in 128 bytes — trust you can re-verify offline”. On 23 October the working paper v0.6 printed the same twelve-field layout and the same test vector that -01 §7.2 now carries as AE128-VECTOR-1; the day -01 landed we compared the two byte by byte and found the layouts identical. The draft did not borrow the wire format from the working paper, and neither borrowed it from any discussion — the working paper documented what the packages already did.

So the honest sequence for the new sections reads: pulse frame demonstrated (12 September), URI schemes codified (-00, 24 September), envelope shipped (4 October), public dissection (9 October), working paper (23 October), codification (27 October). -00 codified what existed on the day it was submitted; -01 codifies what exists now. A specification that documents running code twenty-three days after the code shipped is not a confession of novelty; it is a correction of latency.

The same direction holds for the conformance line. The lease-revocation vectors contributed to the lab's corpus, and the public runs §8.3 cites, exercised a vocabulary this implementation already spoke — the laboratory records runs and certifies nothing, and the learning in §12's map runs from deployed artifacts toward specifications, never from hallways toward code. Nothing said on any wall in recent weeks taught us these bytes; the walls are where the bytes happened to be independently exercised in public.

Security, restated honestly — and the new map

The security considerations chapter (§9) is rebuilt. It opens with foundations that now apply to both schemes explicitly: no lookup and no resolver to poison, no userinfo and therefore no secrets in a URI, and unknown action verbs carrying unknown safety. Then it adds what -00 never had: the truncation account, stated honestly. The derived address is the first 16 octets of a SHA-256 digest; what the construction defends against is finding a second authority that yields the same address — approximately 2128 operations — not collision search in the abstract, where a birthday collision exists at approximately 264 and additionally requires a second, independent party to adopt the colliding label. And the 8-hex display forms are fenced off as display conveniences: a 32-bit space whose birthday bound lands around 216 adoptions makes them unfit as sole identifiers. The chapter also names the transport layer for the first time — the frames may ride HTTP, TLS (citing RFC 9846, TLS 1.3, July 2026), QUIC, or gRPC — with no transport required and none excluded.

The new §12 Related Work draws the map that -00 lacked. CWT and RATS solve portable attestation with rich claim vocabularies and general parser stacks — where rich claims are needed, the draft says, those remain the right tools; the envelope trades expressiveness for fixed-offset determinism, so that a verifier with nothing but SHA-256 and a key can verify with zero dependencies. The W3C AI Agent Protocol Community Group's three-axis discussion is credited and, crucially, bounded: this document claims evidence freshness and authority validity — the first two axes — and deliberately does not claim the third, action-time authorization, which belongs to the calling layer. AAE answers what an agent may do and composes naturally with both schemes, neither depending on the other. And the APS family is cited as the corpus on which the conformance laboratory's lease-revocation-axes work builds — with independent runs against it, including the author's own, noted as public.

What the revision does not do

Worth stating as clearly as the additions. -01 does not claim action-time authorization; it says so. It does not define what the four standing values mean or how a subject moves between them; it says that too, and points at the reference specification. It changes no IANA registration facts — both schemes stand where they stood, provisional CRI 27 and CRI 28. The acknowledgements now thank the independent implementers and reviewers who exercised the response vocabulary in public runs, with reviewers of this revision to be recorded as their reports arrive. The core that thirteen earlier pieces read — derivation, syntax, the consent rules, the fail-closed defaults — is exactly where it was. The revision doubled the document around that core, not over it.

One line: revision -01 keeps the derived-address core byte-stable and adds three load-bearing blocks — a lease that makes freshness a property of the bytes, two 128-octet wire formats with a byte-exact test vector, and an answer sheet whose refusals carry names and whose grants carry receipts — the where, the when, and the whether, now executable.

SEALED rttp://dfc0dfca.blog.aicent · iqa://dfc0dfca8e197983ba3f5e744a7b6fc5.forge.iqa · seal record