AICENT.COM
← Back to Blog

What revision -02 of draft-li-rttp-iqa-addressing adds: the moment of use, the interpreter's seat, and the review on the record

2026-11-01 · RTTP · IQA
Reading the Draft · No. 22 · Sources cited in this piece · the revision under reading, quoted verbatim: draft-li-rttp-iqa-addressing-02 (full text) · the prior revision it supersedes: draft-li-rttp-iqa-addressing-01 (full text) · the series page and revision history: datatracker · the intent concept root the map now cites: RFC 9315 · the conformance laboratory of §12 and §14: Agent-Authority-Conformance · the reference specifications: rttp.com/URI/ · iqa.org/URI/ · Sister pillars: RTTP (rttp://, CRI 27) · IQA (iqa://, CRI 28)

Revision -02 of draft-li-rttp-iqa-addressing was submitted on 1 November 2026 at 06:48 UTC — squarely inside November, as this blog's October summary, published the day before, had filed it. The ISE listing stamps the revision 31 October: that is the queue server's own calendar, five days after -01 entered the queue on 27 October. One revision, two dates, both true. What the five days bought is the subject of this piece. The arithmetic first, per the ISE listing: 40 pages against -01's 34, 2,279 lines against 1,937. But the arithmetic is the least of it. This is the first revision in this series whose every addition answers a question a named person asked in public, and whose every addition can be pointed at the section that carries the answer. Five days is not haste; it is the time it took for the questions to arrive and for the answers to find their sections. The grammar of both schemes — derivation, syntax, safety classes, the fail-closed defaults this series has read piece by piece since No. 1 — is untouched; the wire formats are byte-stable, VERSION_ID and all. What -02 adds is semantics, receipts, and a first for this document: a set of acknowledgements that reads like a review ledger, every debt anchored to the section that repaid it. This piece reads the additions in order, from the primary text only.

-01 → -02 · what moved and what did not34 pp / 1937 lines (27 Oct 2026) → 40 pp / 2279 lines (31 Oct 2026) · per the ISE listing§4.1–§5.4 · GRAMMAR UNTOUCHEDderivation · syntax · action safety classes · both wire formats byte-stable§4.5.4 · NEW · No Lookupno DNS · no registry · no fetch — use is a local computation§6.2–§6.3 · lease: two momentsexpressed at delegation · judged at invocation · mid-task re-check armed by lease§8.1–§8.4 · answer: legible refusalcredential-sharing rationale · race receipts · interpreters consume, never overrule§12/16 + §14 · map and ledgeropen verb set · delegator-reporting open problem · RFC 9315 · five named reviewerswire encoding unchanged · VERSION_ID unchanged · Appendix B lists all eleven bullets
Figure 1: the anatomy of the revision. The grammar and both wire formats are byte-stable; the growth is six semantic blocks, each answering a question that was asked in public — and one acknowledgements section that records who asked.

Two moments, one receipt

The new §6.3, Evaluation at the Moment of Use, is the section the whole revision turns on, and it opens by splitting time in two: “An access policy is expressed when the delegation is made; the condition it states is judged when the resource is invoked. This document fixes only the second moment.” The facts a condition consumes — who the subject is, and whether that subject's authority stands verified — MUST be re-derivable at the moment of use, and the lease is what carries that re-derivability. The sentence that closes the paragraph is the sharpest thing in the revision: “A condition evaluated only at grant time says nothing about the state of the world at invocation.”

The boundary case is stated honestly rather than wished away. “A revocation that arrives just before, or just after, an invocation ends is a boundary no protocol can erase; the wire's job is to make that boundary legible.” An answer read past its expiry MUST be answered as expired, never replayed as fresh — and where an answer cannot arrive in time, the deployment's declared mode and the residual treatment apply, so the caller decides “with the age on the table instead of on a silent assumption.” The companion addition to §6.2 settles the mid-task case with the same discipline: when a lease expires mid-task — an employee whose authority has ended, a grant whose window has closed — the next verification answers authority_revoked or evidence_expired, and the caller, which has held the expiry timestamp since the first answer, “can arm its halt at the boundary before the boundary arrives.” The physical act of halting remains enforcement and stays with the calling layer — the wire supplies the freshness, never the sword.

Why a refusal must be legible

The addition to §8.1 is the most argumentative paragraph in the document, and it is aimed at a failure mode that has a body count in every access-control deployment: silent refusal. “If a refusal is fatal and unexplained, sharing credentials becomes the rational shortcut for the blocked party. A legible refusal — a closed set of reasons with an auditable receipt — gives the caller something to read, degrade on, retry, or reroute, and attenuation survives precisely because a refusal can be read, re-derived by a third party, and answered to.” That is the credential-sharing argument: illegibility does not add security, it prices the legitimate caller into borrowing someone else's key.

The argument is then enforced, not just asserted: “a refusal reason MUST be computed over the authority facts the response carries — facts a third party can re-derive from pinned inputs. A refusal computed over labels, opinions, or unrecorded context alone is not auditable.” The companion addition to §8.2 makes the receipt double as a race record: the grant reference states when the authority-side facts were effective (issued_at_ms, expires_at_ms) and when they were observed (observation_as_of_ms) — together with §6.3, this “lets the caller decide with the age of its inputs on the table — an expired read is answered as expired, never replayed as fresh.”

The interpreter takes a seat, not a vote

The second wholly new section, §8.4 Interpreters Consume the Answer, is one paragraph long and settles a question that was going to be asked sooner or later — most likely by whoever wires a language model to an authorization decision. The rule: a reader that interprets policy, “a rule engine, a human, or a probabilistic program — MAY consume the answer as an input and rank what is permitted within it; it MUST NOT overrule it. Policy interpretation sorts choices among operations the authority layer has already allowed; it does not get a vote on whether the claimant stands.”

Two properties follow, and both are structural rather than rhetorical. First: “the audit target is the wire record: the answer is bytes a third party can re-derive from pinned inputs, while a model's reading of a mandate is an opinion about what the mandate meant — no reader can argue a timestamp into the future.” Second, the split is what makes the schemes usable where no interpreter exists at all: air-gapped, degraded, and store-and-forward deployments have no model to ask, and fail-closed behaviour there requires the closed wire semantics. The closing line places the boundary with geometric calm: “If interpretation by language models works, it works one layer up — exactly where this document already places policy.”

§14 · the review on the record · five names, five anchorsevery acknowledgement names the section that carries the answer — no unanchored gratitudeAlan Karpthree days of head-on public engagement → §6.3 moment split · §8.1 rationale · §12 gap named openLarry Lewischair, W3C ATP CG → lease-revocation-axes experiment · independent runner reproductionTymofii Pidlisnyimaintainer, LF Decentralized Trust lab → two reporting defects surfaced and fixed · frozen corpus heldLars Kersten Kroehlauthor, AAE → §8.1 refusal value · §8.2 grant-naming rule · §6.2 one-window-per-read refinementTetsuroh Horiclean-room recomputation over the frozen vectors — filed without prior contact"the laboratory records runs and certifies nothing" · Appendix B lists the same debts as bullets
Figure 2: the acknowledgements as a review ledger. Each name is tied to the artifact it contributed and the section that adopted it; the laboratory's posture — records runs, certifies nothing — is quoted where the runs are cited.

The map grows where the argument went

The additions to §12 are three, and each closes a door that had been left ambiguous. The first is the verb sentence. The document now states, in one breath, both halves of its action model: “this document defines no open enumeration of action verbs — the actions of "iqa" are a closed set of organ operations (Section 5.4), and the action of "rttp" is an open token that this document deliberately leaves unpopulated — it defines no vocabulary for policy text: standardizing the constraints someone happened to think of first would close an open set.” Closed where closure is the design; open where openness is — and the refusal to standardize a policy vocabulary is stated as a positive act, not an omission.

The second is the delegator-reporting open problem, named and left standing: no deployed delegation system this document is aware of reports back to the delegator, and none carries a standard slot for the reason a specific policy was violated. The schemes do not fill that slot either — “the delegator learns from the receipt when the delegator chooses to look, not because the verifier pushes. Naming the delegator-reporting slot as an open problem is, as of this revision, where the problem stands.” A specification that names its own missing piece, with the audit path that already exists (the grant reference) doing the work a push channel would do, is harder to accuse of scope creep than one that quietly fills the gap.

The third is a root: the map now reaches back to RFC 9315, Intent-Based Networking, and claims the next step on that path in one sentence: “IBN defines what an intent is; the schemes define where an intent claim is addressed and whether the claimant stands verified, and they carry no network configuration semantics.” The schemes, in other words, “make an intent addressable and attestable rather than merely stated” — the concept lineage stated, the boundary drawn, and the transport-adjacent question (what IBN readers would expect next) explicitly declined.

What did not move

Worth stating as precisely as the additions. The grammar — §4.1 through §5.4 — is byte-stable: no syntax changed, no derivation changed, no safety class changed. Both wire formats are untouched: VERSION_ID stands at 130, the extension block keeps its offsets, and the AE-128 envelope keeps its twelve fields and its test vector. The one sentence that did change in §7.2 changed in the direction of restraint: whether a subject moves between standing states is now explicitly deferred to the reference specification rather than asserted — the wire encoding is unchanged. The new §4.5.4 gives the no-lookup requirement its client-requirements home — “A client MUST NOT perform a lookup in order to use an rttp or iqa URI: no DNS query, no registry query, and no fetch of any resource named or implied by the URI” — a home it always implied but had never been assigned. The references gained the rttp reference specification and RFC 9315, the iqa reference was retargeted at its canonical site, and the demos reference was retitled to cover both schemes. Nothing here touches the IANA registration facts: both schemes stand where they stood, provisional CRI 27 and CRI 28. And the document remains what it was — an Informational specification of two experimental addressing schemes, published for the public record.

One line: revision -02 keeps the grammar and the wire byte-stable and answers, in numbered sections, what five days of public review actually asked — when the facts are judged (the moment of use), why silence is a vulnerability (the legible refusal), who gets a vote (the interpreter does not) — and records the questions and their askers in an acknowledgements section built like a ledger.

SEALED rttp://1d6dec71.blog.aicent · iqa://1d6dec71a975c15b299597b7b9db84ea.forge.iqa · seal record