This is the reviewer entry point. Every claim H33 makes about its substrate has a reproduction
path on this page. If you cannot reproduce it, the claim is not yet load-bearing — surface
that through the contact path at the bottom.
No marketing language. No sales language. No claims without a reproduction path.
# 1. Get the frozen federation review bundle. git clone git@gitlab.com:digital-scif/scif-backend.git # access by request — see Contact cd scif-backend git fetch origin git checkout qsign-federation/v0.6-review-bundle # tip ≥ dcf422dad # 2. Run the federation test matrix (should print all green). cargo test -p qsign-fed-registry --tests # expect 11/11 cargo test -p qsign-fed-id --tests # expect 25/25 cargo test -p qsign-fed-receipts --tests # expect 7/7 cargo build -p qsign-nap --bin qsign-nap-verify # should build clean # 3. Run the end-to-end multi-org demo (Acme issues, Zeta verifies, Omega audits). cargo run -p qsign-fed-receipts --bin qsign-fed-multi-org-demo # 4. Read the reviewer handoff (~15 min). It names the load-bearing claims. ${EDITOR:-less} docs/federation/REVIEWER-HANDOFF-v0.6.md
Everything below is frozen for review. No code merges into this bundle during the review window. Source branches remain pushed for per-phase inspection. The four assets named in the brief — federation bundle, architecture docs, schemas, reviewer handoff — are the entire load-bearing surface.
Single branch containing the entire federation chain: Phase 1 registry, Phase 2 URN grammar, Phase 3 NAP-CLI registry wire-up, Phase 4A design + 4B receipts, Phase 6 multi-org demo. Assembled by merging two doc-only branches into the demo branch; no code conflicts.
The canonical orientation document. 30-second demo narrative (Acme → Zeta → Omega), full test command matrix, layered architecture path, open items intentionally excluded, and what a reviewer is expected to do.
Design rationale: why federation, what it guarantees, the threat model (§2), the 6 acceptance criteria (F1–F6), and the 6 open v1 questions (§9). Read this first if you want to attack the substrate at the design layer rather than the code layer.
Two schema documents pinned at v0.1. The URN grammar fixes the form of every cross-org principal identifier. The receipts-and-attestations document fixes the two new artifact types, the canonical encoding, the error model, and what each artifact does not carry.
qsign-fed-registry (append-only hash-chained pubkey log) · qsign-fed-id (URN parser/Display/serde) · qsign-fed-receipts (build + verify + canonical-hash helpers). The verifier wiring lives in qsign-nap-verify --registry <jsonl>.
Three actors, three independent triple-family keypairs, one shared registry replica, one end-to-end run. The demo prints each act's URN, the bytes signed, the emitted hash, and an independent verification pass — both passes resolve to Valid.
Four canonical scenarios. Each maps to one of the buyer-facing pages on this site. Each one must run on a reviewer's own machine — the buyer-facing page is the narrative; the reproduction is the evidence.
Maps to /authority-center/. Reproduces the executive narrative: agent requests $1,800,000, substrate denies, NAP artifact emitted, independent verifier confirms.
cd scif-backend git checkout qsign-federation/v0.6-review-bundle # Emit the canonical denial sample (the same shape used by the page). cargo run -p qsign-nap --bin qsign-nap-emit-sample -- \ --scenario denied-amount \ --amount 1800000 --threshold 500000 \ --output /tmp/auth-center.h33pqv.json # Verify offline; exit 0 = Valid, exit 1 = Invalid. cargo run -p qsign-nap --bin qsign-nap-verify -- \ --artifact /tmp/auth-center.h33pqv.json
Maps to /replay/. The web page walks an auditor through ten substrate steps. The CLI reproduces each step deterministically and prints the binding hash that each step contributes.
# Walk the canonical replay frame for the same artifact emitted above. cargo run -p qsign-nap --bin qsign-nap-replay -- \ --artifact /tmp/auth-center.h33pqv.json \ --verbose # Output: timestamps, request_hash, committed_scope_hash, committed_gsrh, # per-axis verdicts, artifact_binding_hash, signature verification. # Each value can be recomputed by hand from the published canonical encoding.
Maps to /attack-center/artifacts/. The page hosts six
downloadable .h33pqv.json files plus an in-browser verifier. The CLI runs the full
triple-family signature check that the browser does not.
# Browser path (fast): open the page, click 'Run this attack' on any card. open https://h33.ai/attack-center/artifacts/ # CLI path (full): download each artifact and pipe through the verifier. for n in 01-forged-receipt 02-replay-attack 03-stolen-key \ 04-revoked-authority 05-modified-policy 06-tampered-registry; do curl -sO https://h33.ai/attack-center/artifacts/${n}.h33pqv.json 2>/dev/null \ || curl -sO https://h33.ai/attack-center/artifacts/${n}.h33pqv.jsonl cargo run -p qsign-nap --bin qsign-nap-verify -- \ --artifact ./${n}.h33pqv.json \ --registry ./registry-state.json done
Maps to the federation bundle. Acme Bank issues a NAP, Compliance Desk Zeta emits a verification receipt, Audit Firm Omega countersigns the receipt corpus. Each act includes an independent verification pass.
cd scif-backend git checkout qsign-federation/v0.6-review-bundle cargo run -p qsign-fed-receipts --bin qsign-fed-multi-org-demo
Six attack classes. Each one ships with a downloadable artifact, an expected rejection reason, and an explicit statement of what it would mean if a reviewer found a bypass. Surface any bypass through the contact path below; we will treat it as a substrate-level finding, not a cosmetic bug.
Construct a JSON that conforms to urn:h33:qsign:fed-verification-receipt:v0.1 but whose signature blocks are not produced by the named principal's registered triple-family keys.
/attack-center/artifacts/01-forged-receipt.h33pqv.json; replace the all-zero sigs with anything else; pipe through the verifier.ReceiptOutcome::Invalid · 2-of-3 threshold fails under principal's pubkeysTake a real, well-signed receipt whose registry_tip_hash_at_verification does not match any tip the auditor has signed off as current.
/attack-center/artifacts/02-replay-attack.h33pqv.json or craft a fresh receipt against a stale tip.StaleRegistryVersion · the receipt's tip is not in the auditor's known-tips listIssue a receipt under a principal whose registry record shows Revoked at verified_at_unix_ms. Revoked is terminal in the substrate; no forward transition is permitted.
/attack-center/artifacts/03-stolen-key.h33pqv.json signs under phishy-verifier-phi which is Revoked at the receipt timestamp.VerifierRevokedAtVerificationTime · pre-revocation receipts remain attributable (accountability property)Same shape as Stolen Key but on the issuer side: the NAP's issuer_principal_id resolves to a Revoked record at issued_at_unix_ms.
/attack-center/artifacts/04-revoked-authority.h33pqv.json issues under rogue-bank-rho.IssuerRevokedAtIssuanceTime · structured reason + revoke timestamp surfacedMutate body.scope_envelope so its canonical hash no longer matches body.committed_scope_hash. Verifier recomputes from the canonical encoding and asserts equality.
/attack-center/artifacts/05-modified-policy.h33pqv.json declares threshold $2M but the signed hash binds $500K.ScopeEnvelopeHashMismatch · production uses SHA3-384 · in-browser layer uses SHA-384 (same detection class)Insert a record whose prev_record_hash does not match the prior record's record_hash. The chain breaks at the splice; the parser rejects at load time, not first use.
/attack-center/artifacts/06-tampered-registry.h33pqv.jsonl breaks the chain at record index 2.RegistryChainBreak at parse · also rejected by append() at insert timeFour groups. Each one names something that is not yet load-bearing in production or is out of scope for this review window. We surface these so a reviewer does not waste time re-discovering them; if you find one we did not name, surface it through the contact path.
/attack-center/artifacts/ runs structural checks (hash mismatch, status lookup, chain walk) but does not run ML-DSA-87 / SLH-DSA-256s / FALCON verification in the browser. For the full check, pipe the same artifact through qsign-nap-verify --registry.SHA-384 (SHA-2; WebCrypto native). Production uses SHA3-384. Both are 384-bit and detect the same class of tampering; byte-level agreement with the production hash requires the CLI.serde_jcs (RFC 8785). Edge cases involving unicode normalisation or numeric formatting may differ; the in-page artifacts do not exercise those edges.cargo build -p qsign-nap --bin qsign-nap-verify).InMemoryRegistry::append() rejects bad prev hashes at insertion; the parser also rejects at JSONL load. Reviewer paths covering each are in qsign-fed-registry/tests/.verifier for auditors./insurance-proof-lab/ are composite. They model anonymized real-world claim patterns; they are not any single customer matter. The substrate properties they demonstrate are real.benches/.qsign-chaos against the substrate; the report lives at qsign-chaos/CHAOS_REPORT.md. Adversarial campaigns added during review are welcome.Three explicit channels. We aim to acknowledge any finding within two business days. If you are reporting something time-sensitive (active exploit, regulatory deadline), say so in the subject; routing accelerates.
Submit a finding against any claim on this site or in the review bundle. Include the artifact, the command run, the observed output, and the expected output. We will reply with an acknowledgement, a tracking identifier, and whether the finding is in-scope for v0.6 or v1.
Open a finding →Access to the GitLab repo, the federation bundle, the chaos report, the production benchmark page, or any artifact named in Known Limitations. We extend access by request to named reviewers; named-reviewer access is the default — public mirroring is a separate decision.
Request access →One-hour walk-through with H33 engineering. Default agenda: architecture, threat model, what we have and have not built, and what an adversarial reviewer should try first. Sessions are scheduled in your time zone and are not recorded by default.
Schedule a session →