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.
AICENT-009 §10 – §12
What the specification states
IQA-ORG v1.2.8 — published packages
measured against the published artifacts · re-asserted by CI on every push
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 (AICENT-009 §10).
// The envelope — live verifier and vectors at iqa.org/URI/ 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 (AICENT-009 §10).
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 (AICENT-009 §11).
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. Unverified callers get the read path only — everything else fails closed. The envelope signature itself checks offline — demonstrated live, in the browser, at iqa.org/URI/.
// AICENT-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 request (§11.4)
Anticipated Objections
Q1 · Why not just use regular https URLs?
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.
Q2 · Why two schemes instead of one?
Because they answer different kinds of questions. rttp answers where — by pure computation, needing no one's word. iqa answers 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.
Q3 · Isn't hash addressing just content addressing (like IPFS)?
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.
Q4 · What about security?
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/.