Attestation Standing Reference.
iqa is a URI scheme for citing the attestation standing of a subject — reported by one of three named organs (forge · tss · gateway) — without carrying the underlying proof. The scheme is submitted to IANA (Provisional, pending).
Citable standing
The address says where to ask; the state says what is currently true. Reading the syntax establishes nothing about any subject — standing is established only by the seal and by the answering organ.
One click — nothing installed, no administrator rights, removable later in the browser's protocol-handler settings.
The address is iqa://<subject>.<organ>.<root>/<action>. Reaching it from a web page adds the browser's own reserved prefix, which is the same address, not a second protocol — same authority, same path, same derived ROUTE_SHARD. The form without that prefix reaches the same place through a one-time operating-system registration instead.
Coverage: the identical handler shape (see rttp.com) was measured on Windows Chrome.
The resolver page needs no registration at all.
RFC-009 §10 / §11
The Speed of Trust
Core Mechanism
Certification
A claim travels as a signed envelope: it carries the AID — SHA-256 of the public key — so a verifier needs no key directory and no issuer (RFC-009 §10).
// The envelope — RFC-009 §10 / §11 pub struct Envelope { pub subject_uri: String, // iqa://<subject>.<organ>.<root> pub organ: Organ, // closed set: forge | tss | gateway pub standing: Standing, // closed set: ghost | probation | radiant | genesis pub aid: [u8; 32], // AID = SHA-256(public key) pub ts: u64, // claim timestamp pub nonce: [u8; 8], // replay guard pub sig: [u8; 64], // Ed25519 over the canonical form }
A 256-bit HMAC-SHA256 seal computed over the canonical claim and bound to the subject AID — a verifier needs nothing but the envelope itself (RFC-009 §10).
// Seal: 32 bytes of HMAC-SHA256 over the canonical claim
The action class decides what is reachable: verify and audit are reads, while attest and revoke are NOT-SAFE and must not be reachable by dereferencing alone (RFC-009 §11).
Verification results are reported to the diagnostic layer (RFC-014). No performance figure is published here without its measurement conditions.
⚠️ Seal requirement
Seal Verification Tax
A request that would execute a state-changing action without a verified seal is refused: only the read path is reachable by dereferencing, and the default is a read (RFC-009 §11).
Operations that require a verified standing are not available to unverified nodes.
A fragmented or unavailable registry does not change a claim: an envelope is verified offline, from the envelope itself (RFC-009 §10.3).
Implementation Standard
Offline Envelope Verification
A verifier needs nothing but the envelope: canonicalise the claim, check the signature against the public key, and require the standing to be inside the closed set. No registry lookup, no network call — and dereferencing only reads (RFC-009 §10, §11).
// RFC-009 §10.2 / §11 — verify an envelope offline envelope = { alg: 'ed25519', aid: '3125ee20b2238281f70ca408192f82152647d365219184fa1fe22c08a42c035e', subject_uri: 'iqa://3f9a1b2c.gateway.iqa', organ: 'gateway', standing: 'radiant', ts: 1760000000, nonce: '0011223344556677', sig: '054b74c8dcd2b2128291ce433409983609d62c63a002138475d5e33bd21ea0b0c6243790db3d926ad6820cdf7e64f49cbd49a794a1b693cb60217a3382a5f007' } verify(aid, canonicalize(envelope), sig) == true // offline, from the envelope itself read → default operation (SAFE) // dereferencing only reads attest → NOT-SAFE // needs an explicit user act (§11.3)