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.
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
(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.
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/.