✓ Frozen snapshot — specification version v1.2.8 (September 2026)
draft-li-rttp-iqa-addressing-00 (Independent Submission, Informational; posted 24 September 2026) is based on this version of the reference specification it cites as [IQA-SPEC]. The deferred material — the standing vocabulary, the attestation algorithm, the action safety classes and the conformance material — is exactly as shown on this frozen page.
Change control: any change to the deferred material requires a new revision of the draft; this snapshot remains retrievable at this URL unchanged. The conformance vector set that pins the algorithm is shipped inside the published packages (sha256 8529549e…).
The living page (possible later versions): iqa.org/URI/ · Combined draft: archive HTML
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.
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.2.8 · npm · @aicent/iqa 1.2.8 · crates.io · iqa-org 1.2.8-alpha
$ pip install iqa-org && python -m iqa.selftest # [PASS] all 75 checks (3 skipped) — core install
$ pip install "iqa-org[ed25519]" && python -m iqa.selftest # [PASS] all 78 checks — with the Ed25519 backend
$ npm install @aicent/iqa && npx @aicent/iqa # [PASS] all 32 checks — npm, individual implementation
$ cargo add iqa-org@1.2.8-alpha && cargo test # 37 checks (1 skipped) 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.
Versioning: 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.