Verify, Don't Trust.
This page is the reference specification [IQA-SPEC] cited by the
combined Internet-Draft. As that draft states, it carries the attestation
algorithm, the standing vocabulary and
the conformance material for the iqa URI scheme.
The interactive demos live in the Demo Center.
PulseHeader128 carrying timestamp, sequence and TTL), iqa states WHETHER
(a 128-byte AE-128 envelope). Hover any field for what it does; click to pin the note.
The same 16-byte intent shard — one derivation of the
authority, carried at offset 0x36 in the question and at offset 16 in the answer —
is the seam where question and answer lock together — where the two agree, action begins.
Engineering rationale — why two fixed 128-byte frames (click to expand)
I. Symmetric fixed-length frames — the full optimum for constrained devices.
1 · Static memory, zero heap allocation. Ask 128, answer 128 — a node allocates two fixed buffers at compile time; the hot path has no variable-length parsing, no TLV walking, no malloc. On MCU-class devices "no heap" directly means no fragmentation, no leak surface, predictable real-time behavior. This is the engineering delivery of the zero-parser claim: verification needs only the SHA-256/HMAC primitives plus fixed-offset reads.
2 · One review technique, two carriers. Both frames are fixed-layout, so reading them uses the same trivial method — constant offsets and hash primitives — and each reader can be audited in isolation. The carriers remain independent codecs (the specification requires that they do not parse each other); what is shared is the discipline, and that is what keeps every audit small.
3 · Fixed length → constant-time-friendly. The MAC comparison runs over a fixed layout with no variable-length loops, shrinking the side-channel surface; fields are O(1) reads — standing at offset 80 is an array index, not a "parse then extract". The validator is also total: every 128-byte input is either accepted or rejected whole, never partially parsed, and the rule set is small enough to reason about exhaustively, rule by rule.
4 · 128 is backed by hard constraints. A power of two (aligned allocation) and exactly two cache lines; above all, one datagram, no fragmentation: 128 bytes plus roughly 60 bytes of IPv6/UDP/CoAP header overhead fits comfortably inside the 1280-byte minimum MTU — fragmentation means reassembly buffers, reassembly means heap, and heap is a death sentence on constrained nodes. The upgrade runway is proven, not promised: the pulse frame tail (0x66–0x7F) went from zero bytes to the v1.2.6 extension block without changing the total length, and AE-128 reserves its own zero bytes (reserved + extension) for the same future.
II. The shared shard — the cryptographic handshake of the Q&A.
The amber link on the map is the most valuable stroke: the intent_shard at 0x36 in the question and at 16 in the answer are the same 16 bytes. Three engineering layers:
1 · One round trip. Addressing (WHERE + WHEN) and standing (WHETHER) ride the same exchange: one question, one answer — one round trip does what used to take two. On duty-cycle-powered LPWAN links, round trips are the dearest resource.
2 · The answer is bound to its subject. The MAC covers the intent_shard, so an answer cannot be re-targeted: swap in another subject’s shard and the bytes no longer authenticate — fail-closed. Freshness is carried separately, by the lease and the organ’s per-verdict nonce.
3 · From document pairing to byte pairing. "One datagram carries WHERE, WHEN and WHETHER" is no longer prose: two 128-byte frames sharing one constant is the physical implementation.
III. What is saved, against current practice.
| Carrier | Size | Parser required |
|---|---|---|
| JSON envelope (the original AE route) | hundreds of bytes | JSON parser + field walking |
| CBOR encoding | compact | CBOR decoder (TLV logic) |
| AE-128 / PulseHeader128 | 128 bytes each, capped | none — fixed offsets + hash primitives only |
Citable standing — this page is [IQA-SPEC]
An iqa URI names the attestation state of a subject as reported by one of three named organs (forge · tss · gateway), without carrying the underlying proof. Reading the syntax establishes nothing about any subject — standing is established only by the seal and by the answering organ.
This page is the reference specification cited as [IQA-SPEC] by
draft-li-rttp-iqa-addressing (-00 as submitted)
(The rttp and iqa URI Schemes: Derived-Address Intent and Attestation Addressing; Independent Submission, Informational; posted 24 September 2026). What the draft defers here: the standing vocabulary — a closed set of four values, ghost · probation · radiant · genesis (AICENT-009-C §3) — and the safety classes of its Table 1 carry over unchanged: a bare standing read and verify are SAFE; audit, attest and revoke are NOT SAFE.
0 · The Grammar — verbatim from the I-D
iqa://<subject>.<organ>.<root>[/<action>]
The authority comprises exactly three dot-separated segments, in this order (I-D §5.1, quoted):
- subject — 8, 32 or 64 lowercase hexadecimal digits (a derived routing hash), or a readable label; both forms are opaque to a client.
- organ — one of the three organ names, forge, tss or gateway. This is a closed set; no other value is valid.
- root — the root label of this scheme. Like every other segment it is a name and is never resolved.
- action — when present, a single path segment and one of the four operation names verify, audit, attest or revoke. This is also a closed set.
iqa-URI = "iqa://" iqa-authority [ "/" iqa-action ] iqa-authority = subject "." organ "." iqa-root subject = hash-subject / name-subject hash-subject = 8( iqa-lowhex ) / 32( iqa-lowhex ) / 64( iqa-lowhex ) name-subject = 1*( %x61-7A / DIGIT / "-" ) organ = "forge" / "tss" / "gateway" iqa-root = 1*( %x61-7A / DIGIT / "-" ) iqa-action = "verify" / "audit" / "attest" / "revoke" iqa-lowhex = DIGIT / %x61-66
iqa://3f9a1b2c.gateway.iqa (routing hash, standing read)
iqa://0000004149434e531c5b21d80403358b.forge.iqa
iqa://3f9a1b2c.tss.iqa/audit (explicit fidelity audit)
iqa://master-authority.gateway.iqa/verify (readable label form)
Exclusions (I-D §4.2 + §5.2): the canonical form is lowercase US-ASCII — uppercase is invalid input, never normalised; no userinfo, port, query or fragment is defined (a URI carrying any of them is not valid); a canonical URI contains no percent-encoded octets; there is no "iqas" scheme and no protocol fallback — a client that does not implement the scheme fails closed; and the hexadecimal subject form is a routing hint, not evidence — it carries no verification weight.
Default operation (I-D §5.3): dereferencing without an action requests a standing read — safe: it creates no obligation, transfers no value, and mutates no state. Normative rule: dereferencing an iqa URI, by itself, MUST NOT transition any subject's standing state.
Parsing is not attestation: reading the syntax establishes nothing about any subject — standing is established only by the answer of the named organ, under the rules of the reference specification [IQA-SPEC] (I-D §5.5.1).
Source: draft-li-rttp-iqa-addressing-01, §5.1–§5.5. Sister scheme: the rttp:// grammar (rttp.com/URI) — same model, intent side.
Version & stability
Specification version: v1.3.1 (October 2026). The frozen snapshot of this version is permanently retrievable at iqa.org/URI/v1.3.1/. The exact text draft-li-rttp-iqa-addressing-00 (Independent Submission, Informational; posted 24 September 2026) is based on — specification v1.2.8 — is itself frozen at iqa.org/URI/v1.2.8/.
Change control: material changes to the deferred items (standing vocabulary, attestation algorithm, action safety classes, conformance material) require a new revision of the draft. The algorithm is pinned by the published conformance vector set (sha256 8529549e…), shipped inside the packages and replayed by three independent implementations. The AE-128 envelope (companion draft v0.3) is pinned the same way: ae128-vectors-v1.json, sha256 ceff2d11…, shipped inside the 1.3.1 packages.
1 · Standing vocabulary — defined here
standing — The attestation answer an organ returns for a subject. The values it may take are defined by the reference specification [IQA-SPEC], not here. — the combined draft, §2 (quoted)
That reference is this page. The values it defines are a closed set of four (AICENT-009-C §3); no other value is valid in any claim payload, and the set cannot be extended without revising this specification.
Every envelope's payload.standing is validated
against this set — see the envelope verifier in the
Demo Center. Narrative descriptions of the four values live in the Aicent Stack narrative
(v1.3.0, source.txt).
2 · The attestation algorithm
An attestation envelope is a JSON object with the fields
v (=1), alg ("ed25519"), aid,
pub, ts (unix seconds), nonce,
sig and payload
({subject_uri, organ, standing}). Verification is fail-closed, in order:
- Fields.
aidandpubare 32-byte lowercase hex,sig64-byte,nonce8-byte;tsis an integer. A case variant is rejected, never normalised. - Freshness. |now − ts| ≤ 120 s. Archival mode — for published vectors and audit records — skips this check.
- Claim.
payload.subject_uriparses per the §5.1 grammar;organandstandingare in their closed sets;payload.organmatches the subject URI's organ. - AID self-certification. aid == SHA-256(pub).
- Signature. Ed25519 over the canonical signing input: the ASCII string
"iqa-attest-v1\n"followed by sorted-key, whitespace-free JSON of {alg, aid, nonce, payload, pub, ts}.
Nothing is accepted because a check was skipped: a check that cannot be performed is a failure.
3 · Action safety classes
As carried in the combined draft's Table 1 (draft-li-rttp-iqa-addressing-00, §5.4):
| Action | Semantics | Class |
|---|---|---|
| (omitted) | Read the current standing — the default operation. | SAFE read-only |
| verify | Compare a presented seal against the subject. No state is written. | SAFE comparison |
| audit | Request a fidelity measurement of the subject's execution. | NOT SAFE |
| attest | Request that a seal be issued for the subject. | NOT SAFE |
| revoke | Withdraw the subject's standing. | NOT SAFE |
Dereferencing an iqa URI, by itself, MUST NOT transition any
subject's standing state. audit, attest and revoke MUST be requested
explicitly and MUST NOT be reachable by dereferencing a URI that omits the action.
Try it — the interactive parts moved
The envelope verifier and the sealer now live in the Demo Center's envelope scenario (four more scenarios there) — same code paths, same published vectors, one home for all demos.
4 · Conformance material
pypi · iqa-org 1.3.1 · npm · @aicent/iqa 1.3.1 · crates.io · iqa-org 1.3.1
$ pip install iqa-org && python -m iqa.selftest # [PASS] all 108 checks (3 skipped) — core install
$ pip install "iqa-org[ed25519]" && python -m iqa.selftest # [PASS] all 111 checks — with the Ed25519 backend
$ npm install @aicent/iqa && npx @aicent/iqa # [PASS] all 32 checks — npm, individual implementation
$ cargo add iqa-org && cargo test # 18 tests + 2 doc tests replayed — crates.io, SHA-256 written in-crate
Three implementations share no code; all replay the same published vector set
(sha256 8529549e…, shipped in each package) and agree byte for byte. Apache-2.0. The v1.3.1 packages additionally carry AE-128 — the fixed 128-byte answer carrier (companion draft v0.3): its own vector set (ae128-vectors-v1.json — 1 positive, 11 fail-closed, 7 tampered frames; one sha256 across the three mirrors) and a 200,000-case deterministic mutation harness ride inside the iqa packages.
Versioning: 1.3.1 on all four channels — PyPI, npm, crates.io (the first formal, non-pre-release release) and GitHub — and the counts asserted above are the 1.3.1 self-tests. Historical: 1.2.8 on PyPI and npm,
1.2.8-alpha on crates.io. 1.2.8 carries a large conformance expansion and no protocol
change: the asserted check counts grew to 75 (default) and 78 (with the optional Ed25519 backend) on
PyPI, 32 on npm and 37/38 on crates.io; the package metadata now carries the IETF naming; and
verify_envelope keeps returning its documented error instead of raising NameError
when the optional [ed25519] backend is absent (fixed in 1.2.7). Modules, vectors and
wire format are unchanged.
The same material is pinned by the conformance challenge — implement the spec, replay the vectors, byte for byte — and demonstrated in the Demo Center's envelope verifier.
Companion scheme: the rttp side of the combined draft
(intent addressing, §4 — ROUTE_SHARD derivation included) is specified in the draft itself;
its implementation-status material lives at
rttp.com/URI.
5 · Six questions, answered
Q1 · What is IQA? · click to expand
IQA denotes Identity Quality Assurance — the attestation pillar of the pair. An iqa:// URI asks a named Organ for a verdict about a subject's standing: one of Ghost, Probation, Radiant, Genesis — a closed set (§11.1.1). A verdict is an answer, not a computation: seals are HMAC-SHA256 over the canonical claim, bound to the subject's key material, verifiable offline — no issuer, no key directory, no network call. "I QA" — I, the answerer.
Q2 · What is RTTP? · click to expand
RTTP denotes Resonant Time Transfer Protocol — the addressing pillar. An rttp:// URI names an intent against an authority (intent.pillar.root); the address is derived by computation — one SHA-256, no DNS, no registry, no fetch. The name is a claim: intent addressing under a real-time constraint — addressing by intent, synchronized in time; resolution latency is bounded and does not scale with the network.
Q3 · Why not just use regular https URLs? · click to expand
A https URL states where a resource lives — you must fetch it to know anything. An rttp URI is computed, not looked up: the address is derived from the authority by SHA-256 (§4.4), with no DNS, no registry query and no fetch. The intent is part of the identifier itself, and anyone can verify the derivation offline.
Q4 · Why two schemes instead of one? · click to expand
Because they answer different kinds of questions. rttp resolves where — and when — by pure computation, needing no one's word. iqa states whether — a named Organ's verdict about a subject. Splitting them into two namespaces keeps the question channel and the attestation channel apart: the computation never depends on anyone's word, and the attestation never pretends to be computation.
Q5 · Isn't hash addressing just content addressing (like IPFS)? · click to expand
Relatives, not twins. Content addressing derives an address from the bytes of a blob. rttp derives from the authority only and is action-independent: the same authority under different actions yields the same address — an address is where, not what (§4.4). It names the place of an intent in the grid, not the bytes of a file.
Q6 · What about security? · click to expand
The default operation is read-only (§11.1); every state-changing operation requires explicit consent, enforced in the client and again server-side (§4.5.3, §5.4). An unreachable endpoint fails closed (§12) — silence is never treated as assent. Seals are HMAC-SHA256 over the canonical claim, bound to the subject's key material: verification is offline and needs no issuer, no key directory, no network call.
Don't take our word for any of it — replay the vectors at iqa.org/challenge/ or run the demos at iqa.org/demo/.