What fits in 128 bytes — trust you can re-verify offline
iqa:// · 128-byte attestation envelope · IANA Registered · Provisional · CRI 28 · Sister pillar: rttp:// (IANA CRI 27)
Author: Aicent Stack · Part of the Dual-Pillar series · Attestation pillar
The previous piece covered where the address comes from (derived, not assigned). The address settles who you are and how to find you; the agent world still owes one answer: how do you prove to a third party what you did?
Logs will not do — logs live in the operator's own systems and can be edited afterwards. Screenshots will not do — a screenshot never touches a hash. What is needed is a new vehicle: a cryptographic credential issued synchronously with the event, re-verifiable offline by anyone. We built it as a fixed 128-byte envelope. That is the core of IQA.
1. Why an envelope — and why exactly 128 bytes
The common choice for evidence carriers is JSON: several hundred bytes, plus a JSON parser to walk the fields. CBOR is tighter, but still needs TLV decoding.
IQA takes the opposite trade: a fixed layout, zero parser. 128 bytes, fixed field offsets; any language that can read bytes — Python, Rust, embedded C — handles it with slicing and hash primitives. Parser requirement: none. This is written in the public specification and in the conformance test vectors: fixed inputs, fixed outputs, reproducible byte for byte.
128 bytes is simultaneously the balance point of "enough room for the proof elements" and "small enough to fit any log line, any packet header".
2. Field by field
The envelope's fixed layout, in order: magic → version/algorithm/flags → lease → subject shard → proof → organ → nonce → standing → reserved → extension.
Four fields worth stopping at:
- The subject shard (16 bytes): the shard derived in the previous piece, embedded as-is — the evidence proves its own ownership on arrival; no registry needs to tell the verifier whose evidence this is;
- The lease: the proof's validity window. Expired means void; the window semantics are declared by the issuer;
- The nonce: anti-replay. Sign the same event twice, and the two envelopes differ;
- Standing: a single byte — and the soul of the envelope. The next section is devoted to it.
3. Four standing states — and revocation is also proof
Standing is one byte, drawn from a closed four-state set: Ghost (no evidence to report: unverified / expired / withdrawn / unreachable) / Probation (was attested · now observed) / Radiant (currently compliant · the highest state evidence can reach — lease-based, never permanent) / Genesis (era anchor).
The first three form the evidence axis — from "no evidence" to "held up by evidence". Genesis is not on that axis: it is the constitutive state of an era (era anchor), takes no application path, and is not "higher-tier compliance". The four states are not a ladder; one state, one assertion.
The interesting part is revocation: revocation does not "delete the record" — it issues a new envelope with standing set to Ghost. The old envelope still holds — it proves "the fact at the moment of issuance"; the new envelope holds too — it proves "what happened later". Side by side, the two envelopes form a complete timeline that neither party can deny.
The highest form of audit is not managing logs; it is making the logs carry their own mathematics.
4. Fail-closed: REJECT is a result, not an error
Verification is constant-time, whole-frame HMAC-SHA256: it covers all 128 bytes, recomputing with the proof field zeroed. Change any one byte — flip a single bit — and the MAC breaks: REJECT.
Two disciplines deserve their own lines: constant time means verification leaks no hint of where the change was (no targeting information for attackers); fail-closed means any format anomaly, any non-compliant field, is REJECT — malformed input is never charitably treated as partially valid.
REJECT is not an exception; it is one of this system's normal outputs. Like PASS, it is a conclusion that can be re-checked.
5. The honest boundary
The envelope proves the fact at the moment of issuance; it does not predict the future. It replaces no gateway's real-time risk control — detection is detection's business, evidence is evidence's. Delegation-chain semantics are explicitly unspecified in this version (community input is welcome). Distribution of organ keys is a deployment-layer trust decision; the specification does not overreach to answer it.
We do not claim to have solved "trust" — we only turned the part of it that can become mathematics into 128 bytes.
The iqa:// scheme is registered with IANA (Provisional · CRI 28); the AE-128 envelope is defined in draft-li-rttp-iqa-addressing (under review in the IETF independent submission stream); the conformance vector (AE128-VECTOR-1) is public and reproducible; reference implementations ship in three languages (PyPI / npm / crates.io).
Repos: github.com/Aicent-Stack · Spec & evidence chain: iqa.org · Addressing pillar: rttp.com
One sentence: institutions say "trust me"; the envelope says "compute it yourself".