# Independent Verification Guide **Kit version:** 1.0 **Issued:** 2026-06-02 **Issued by:** H33, Inc. This document is the canonical walkthrough for an external party to independently verify the H33-CANONICAL-AUTH-v1 first operational proof and its downstream proofs. It assumes no H33 access, no NDA, no proprietary tooling. Every step uses public artifacts, standard cryptographic primitives, and the values listed in [`artifact-manifest.json`](artifact-manifest.json). If you finish this guide and the values check, you have independently verified that: 1. A real customer identity was issued by a real production Auth1 deployment. 2. That identity was bound to a real authority grant in a canonical event log. 3. The decision the customer asked for was authorized against a real policy. 4. The resulting receipt was anchored cryptographically with three independent post-quantum signature families. 5. The anchored receipt was embedded in a customer artifact that you can fetch right now. If any step fails, that's a finding. Publish it. We will respond with the gap or the fix; we will not argue. --- ## Step 0 — Read the proofs you're going to verify Open these in another tab: - [V101 first-proof page](https://h33.ai/proofs/v101-first-operational-proof/) — the report you're verifying. - [Regulator Replay #001](https://h33.ai/proofs/regulator-replay-001/) — the determinism proof. - [Multi-Tenant Isolation #001](https://h33.ai/proofs/first-multi-tenant-proof/) — the isolation proof. These describe what H33 claims. Your job is to confirm each claim by reproducing the value. --- ## Step 1 — Fetch the bundle The bundle is publicly retrievable: ```bash curl -sS https://app.v101.ai/v101/bundle/d9adcfb0-e0bc-426b-8725-fc12d555692b | jq . ``` Verify: - `bundle_id` = `d9adcfb0-e0bc-426b-8725-fc12d555692b` - `schema` = `v101-bundle-v1.1` - `creator_id` (or `creator_uuid`) = `44962d9b-25f5-5622-bd9a-98d5580bb8a2` - `h33_74_receipt.status` = `anchored` - `h33_74_receipt.anchor_ref.chain` = `h33-substrate-v1` - `h33_74_receipt.anchor_ref.tx_reference` length = **148 hex characters** - `h33_74_receipt.anchor_ref.commitment_hex` = first 64 hex chars of `tx_reference` If any field is missing or mismatched, that's a finding. --- ## Step 2 — Verify the SHA3-256 commitment The `commitment_hex` is `SHA3-256(canonical_JSON(IssuedReceipt))`. Recompute it. **Canonical JSON form:** the IssuedReceipt's fields are serialized as a single JSON string with these properties: - Keys sorted alphabetically (RFC 8785 JCS approximation). - No whitespace between tokens. - `null` for an absent `policy_basis` (here it is present). The exact canonical form used by H33 for this receipt: ``` {"audience":"substrate-receipts","authority_id":"auth_44962d9b-25f5-5622-bd9a-98d5580bb8a2_v101_export","authority_principal":"princ_customer_9","decision":"first anchored V101 bundle proof for princ_customer_9 (eb@h33.ai customer_id=9 creator_uuid=44962d9b-25f5-5622-bd9a-98d5580bb8a2)","issued_at_ms":1780359626000,"policy_basis":"pol_v101_exporter_v1","source_jti":"jti-1780359511-cf79e5f189cb41fd"} ``` Compute SHA3-256 of those exact bytes (UTF-8 encoded, no trailing newline): ```bash python3 -c " import hashlib canonical = b'{\"audience\":\"substrate-receipts\",\"authority_id\":\"auth_44962d9b-25f5-5622-bd9a-98d5580bb8a2_v101_export\",\"authority_principal\":\"princ_customer_9\",\"decision\":\"first anchored V101 bundle proof for princ_customer_9 (eb@h33.ai customer_id=9 creator_uuid=44962d9b-25f5-5622-bd9a-98d5580bb8a2)\",\"issued_at_ms\":1780359626000,\"policy_basis\":\"pol_v101_exporter_v1\",\"source_jti\":\"jti-1780359511-cf79e5f189cb41fd\"}' print(hashlib.sha3_256(canonical).hexdigest()) " ``` Expected output: ``` ff770fc838fde707d91f35248946d6928b0a3a999dbd28a2906ce4f0274745e7 ``` This must equal the `commitment_hex` you read from the bundle in Step 1 (and the first 64 hex chars of `tx_reference`). If not, that's a finding — either the receipt was tampered with, the canonical-JSON convention is mis-documented, or your computation is off. --- ## Step 3 — Verify Auth1 published the EdDSA public key for the Bearer's kid The Bearer that triggered the bundle issuance carries header `kid = kid-eddsa-prod-active-2026-06-01-d31134fbc177`. Auth1 publishes the corresponding public key in its JWKS: ```bash curl -sS https://auth.h33.ai/.well-known/jwks.json | jq '.keys[] | select(.kid == "kid-eddsa-prod-active-2026-06-01-d31134fbc177")' ``` Expected output (the public key material): ```json { "kty": "OKP", "crv": "Ed25519", "kid": "kid-eddsa-prod-active-2026-06-01-d31134fbc177", "use": "sig", "alg": "EdDSA", "x": "" } ``` The `x` field is the Ed25519 public key. Keep it for Step 4. If the kid is absent from the JWKS, the Bearer's signature cannot be verified — that's the worst possible finding (means H33 cannot defend its own claim). Report it. --- ## Step 4 — (Optional) verify a fresh Bearer's signature This step requires you to obtain a fresh Bearer, which means going through the Auth1 OTP login flow as your own customer (or asking H33 to provide a verifiable Bearer for a structural test customer). The Bearer is short-lived (15 min), so coordinate timing. When you have a Bearer: ```bash BEARER="" # Split header.payload.signature echo "$BEARER" | cut -d. -f1 | base64 -d | jq . # header — kid, alg=EdDSA echo "$BEARER" | cut -d. -f2 | base64 -d | jq . # claims — sub, iss, aud, jti, iat, exp # Verify signature using the public key from Step 3 against the signing input # (header.payload, exact bytes including dot). ``` Reference verifier (Python): use `pynacl` or `cryptography.hazmat.primitives.asymmetric.ed25519`. Reference verifier (Node): use `jose` package. Confirm: - `alg = EdDSA` - `iss = https://auth.h33.ai` - `aud = substrate-receipts` (or another receipt-issuing audience) - `sub` is shape `princ_*` - Signature verifies against the JWKS public key If the Bearer's signature does not verify, that's a finding. --- ## Step 5 — (Verify the 74-byte H33-74 receipt) The `tx_reference` is a 74-byte object encoded as 148 hex chars. Layout: - Bytes 0..32 (hex chars 0..64): `signing_message` = SHA3-256 of the canonical JSON of the IssuedReceipt (= `commitment_hex` from Step 2). - Bytes 32..74 (hex chars 64..148): `CompactReceipt` — a 42-byte fixed-width binding. The 42-byte CompactReceipt layout: ``` Offset (bytes) Length Field 0 1 version 1 32 verification_hash = SHA3-256("h33:pq3:v1:full:" ‖ signing_message ‖ length-prefixed dilithium_pk ‖ length-prefixed falcon_pk ‖ length-prefixed sphincs_pk ‖ length-prefixed dilithium_sig ‖ length-prefixed falcon_sig ‖ length-prefixed sphincs_sig) 33 8 verified_at_ms (u64 big-endian) 41 1 algorithm_flag ``` `length-prefixed` means: each variable-length field is preceded by a 4-byte little-endian length, then the bytes. This prevents concatenation ambiguity. To verify the CompactReceipt's `verification_hash` you need: the signing_message (you have it), the three substrate public keys (currently held in the operator's secret store; published fingerprints are listed in `artifact-manifest.json`), and the three signatures (currently NOT exposed in the bundle — they are summarized into the verification_hash, which is the design). **Current limitation:** the receipt as published binds the signatures into the verification_hash but does not expose the raw signatures. To verify the three PQ signatures directly, the substrate public keys and individual signatures must be obtained through a separate channel. H33 will publish a `h33-verifier` binary that performs this verification given the public keys and the bundle; that release is part of the locked roadmap item #8 (Verifier Track) but not shipped in v1.0. For now: confirm that the 148-hex `tx_reference` decomposes cleanly into `signing_message ‖ CompactReceipt`, that `version` byte is `0x01`, that `algorithm_flag` is `0x07` (all three families: bit 0 = dilithium, bit 1 = falcon, bit 2 = sphincs), and that `verified_at_ms` is a plausible Unix-ms within the issuance window. ```python import binascii tx = "ff770fc838fde707d91f35248946d6928b0a3a999dbd28a2906ce4f0274745e7016fb294cb7ddf8073700a2cd13531a352da28068b4921c05839b82b8633547fdd0000019e85bb875107" b = binascii.unhexlify(tx) assert len(b) == 74 signing_message = b[:32] compact = b[32:] assert len(compact) == 42 version = compact[0] verification_hash = compact[1:33] verified_at_ms = int.from_bytes(compact[33:41], 'big') algorithm_flag = compact[41] print("version =", version) # expect 1 print("signing_message =", signing_message.hex()) # expect ff770fc838...745e7 print("verification_hash =", verification_hash.hex()) print("verified_at_ms =", verified_at_ms) # expect ~1780360120145 area print("algorithm_flag =", algorithm_flag) # expect 7 (all three) ``` --- ## Step 6 — Verify the determinism claim (Regulator Replay #001) The Regulator Replay proof claims: replaying the canonical event log at T = 1780359626000 produces `state_id = 96a29047010a201dfa2a5254897a664ee2c20b9ac437406f61609f7144beae4a`, byte-identically, every time. To reproduce, you need access to the canonical event log (table `canonical_auth_events` filtered to `tenant_id = 'tenant_v101_44962d9b-25f5-5622-bd9a-98d5580bb8a2'`). H33 will coordinate read-only access on request. You then run, against scif-backend at SHA `d310d8134`: ```bash H33_TEST_PG_URL='postgres://...?sslmode=require' \ cargo test --test regulator_replay_001 -- --ignored --nocapture ``` Expected captured `state_id`: ``` 96a29047010a201dfa2a5254897a664ee2c20b9ac437406f61609f7144beae4a ``` Two replays of the same input produce the same `state_id`. If your replay produces a different value, that's a finding — either the canonical event log was modified between H33's run and yours, the replay engine was modified, or the determinism claim is wrong. --- ## Step 7 — Verify the multi-tenant isolation claim (Multi-Tenant Isolation #001) Similar reproduction. Run against scif-backend at SHA `2be2df3f8`: ```bash H33_TEST_PG_URL='postgres://...?sslmode=require' \ cargo test --test multi_tenant_isolation_001 -- --ignored --nocapture ``` Expected captured values: ``` state_id_A = 24a06e845ce573dd773298451ad9a05da213cea52068e8b93e054ae9166f9db9 state_id_B = c11b3ca74742c191bf1f2846970f91a104b78a2e375bcceef23c48f116e20f15 injection verdict = ProvenanceBroken, active_grants = 0 ``` If you reproduce these, the isolation claim holds. If not, that's a finding. --- ## Step 8 — Publish your findings Use [`attestation-template.md`](attestation-template.md) as the starting point for your published statement. Sign it with your standard mechanism (PGP, Sigstore, S/MIME, corporate letterhead — your choice). Send the signed statement to the H33 contact in `artifact-manifest.json` and publish on your own surface (LinkedIn post, company blog, GitHub gist, etc.). H33 will link your published findings from `/proofs/independent-verification-kit/` with attribution. **Negative findings are published too.** If a step failed, the finding is the proof — that's the whole point. --- ## What this kit does NOT cover - **Scale validation.** This kit verifies the single-decision chain. Scale is Proof #5. - **Failover validation.** This kit verifies normal operation. Failover is Proof #6. - **Disaster recovery.** This kit verifies live state. DR is Proof #7. - **Source-code audit.** This kit verifies the runtime behavior matches published claims. Source-code audit is a separate engagement; H33 will coordinate. - **Cryptographic strength of the underlying primitives.** This kit assumes the NIST-standardized algorithms (FIPS 203/204/205, RFC 8032 EdDSA, SHA3) are sound. That's a separate research question. --- ## Acknowledgments and license This kit is released under CC-BY 4.0 — you may redistribute, modify, and reuse. Attribution: "Verification kit by H33, Inc., 2026." If your verification finds an issue, you keep authorship of the finding. We will not claim it as ours and we will not suppress it. --- *Issued by H33, Inc. — Eric Beans, CEO. Independently reconstructable from [`artifact-manifest.json`](artifact-manifest.json).*