Demo Center

Live demonstrations of the two companion URI schemes, from the offline conformance sandbox to a networked multi-agent scenario. All demos are non-normative: they implement the rules of draft-li-rttp-iqa-addressing-00 but prove nothing by themselves — the specification and its conformance vectors do that.

URI Grammar — the two pillars at a glance · draft-li-rttp-iqa-addressing §4.1 / §5.1
rttp://<intent>.<pillar>.<root>[/<action>]  —  derived intent address · WHERE + WHEN · full grammar →
iqa://<subject>.<organ>.<root>[/<action>]  —  attestation address · WHETHER · full grammar →
Lowercase ASCII only · no userinfo / port / query / fragment · every segment is a name, never a host · iqa organ and action are closed sets (forge · tss · gateway / verify · audit · attest · revoke) · parsing establishes nothing — fail closed.
networked · real endpoints · real state

Two Agents & a Live Organ

Two independent agents exchange real HTTP with a live organ service. Standing reads are read-only; attest / revoke / audit really transition state and really refuse without explicit consent. A wire log shows every packet; a watcher lets one agent observe the other's transitions live.
networked · three organs · one contested subject

Three Organs, One Subject

The dispute scenario. Standing is organ-relative by design (5.3): drive three real organs independently, poll them all, and watch a relying party handle disagreement — attributable answers, read-shaped protocol, and the trust decision left exactly where the scheme leaves it.
networked · two implementations · one truth

Browser ↔ Derivation Service

Your browser derives ROUTE_SHARD with its own crypto.subtle while a real derivation service derives it again over HTTP with strict server-side ABNF validation — then the page compares the two byte for byte and anchors both to the published pinned vectors. Batch mode included.
offline · real Ed25519 · published vectors

Envelope Verifier

Verify and mint iqa attestation envelopes entirely in your browser: AID self-certification (AID = SHA-256(pub)), canonical signing input, the 120 s freshness window, the closed sets — and the published pinned vector, replayed byte for byte. Migrated from iqa.org/URI. v1.3.1: the AE-128 fixed envelope — 128 bytes, HMAC over the whole frame — joins this demo.
offline · response-level binding · tamper matrix

Gateway Response Binding

The MCP-gateway scenario: the tool server seals every tool response into an iqa envelope — subject = sha256 of the response bytes, signed by the server's organ key — and the gateway verifies the pair offline: route derivation, response binding, pinned signer AID, Ed25519 seal, the 120 s window. Four tamper cases (a flipped response byte, a flipped standing, an impostor key, a replay), each caught fail-closed, live in your browser.
one scenario · four stacks · eleven fields

Stack Compare

The same agent scenario (Agent A → Agent B → Payment Agent, approve-invoice) walked field by field under A2A + HTTPS/OAuth, A2A + DID/VC, A2A + capability token and A2A + RTTP/IQA. Three stacks as protocol choreography; the fourth executes real browser crypto — shard derivation, envelope verification, the policy gate, fail-closed revocation — with network-call and third-party counters on every field.
one chain · four stacks · nine delegation fields

Delegation Stress Test

The sharper question: Agent A grants €10,000, Agent B attenuates to €2,000 and delegates to a Payment Agent. Can each stack express the attenuation, verify the chain, carry the standing? The capability stack’s native strength and the RTTP/IQA frame’s honest gap — both shown live, gap included.
offline · single file · runs in your browser

Conformance Sandbox

The original single-file demo: strict ABNF parsing, the ROUTE_SHARD derivation (with the published-vector replay), the Table 1 action safety classes, the consent gate, and an 18-case self-test — no network, no state, nothing leaves your browser.

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

More scenarios are reserved on this page. The demos share one shape — one question, one answer: rttp computes where and when an intent lives, iqa states whether an organ stands behind it.