Independent Verification Model

A formal model of vendor-independent evidence verification: trust assumptions, threat model, verification protocol.

This page formalizes the independent verification model H33 evidence is designed for. It specifies the trust assumptions, the threat model the verification is robust against, the verification protocol's properties, and the conformance requirements for verifier implementations.

Why independent verification needs a formal model

Most verification systems have an implicit model: trust the vendor, trust the system that retains it, trust the tooling. Independent verification has different requirements. The verifier may have no relationship with the entity that produced the evidence. The verifier may be reviewing evidence years after the producing entity ceased to exist. The verifier may be adversarial to the producing entity. The verifier may be in a different jurisdiction. The verification must work. The model that makes it work must be specified precisely.

The verification setting

The verification setting has the following participants. The Producer — the entity that generated the H33 evidence bundle. Has signing keys. May no longer exist at verification time. The Holder — the entity in possession of the bundle. May be the original producer, a transferee, a regulator, or any party. The Verifier — a party validating the bundle's integrity. Has the open-source verifier, the bundle, and optional chain RPC access. Does not have signing keys; does not have producer trust. The Chain (optional) — a public blockchain to which the bundle's commitment may have been anchored. The Adversary — a party attempting to make the verifier accept a forged or modified bundle, or reject a legitimate bundle.

Trust assumptions

The verification model rests on a small set of trust assumptions. T1. Cryptographic primitives. The signature algorithms and hash functions are not cryptographically broken. The three-family design hedges this: only one of three must remain intact. T2. Public key authenticity. The verifier has authentic copies of the producer's public keys, established through out-of-band channels. T3. Schema specification. The bundle's schema version is specified clearly enough for the verifier. T4. Verifier implementation. The verifier implementation correctly implements the verification protocol. T5. Chain integrity (if anchoring is used). The blockchain is operating with its expected security properties. Notably absent: trust in H33, trust in the producer's current operational state, trust in the holder's representations, trust in any cloud provider.

Threat model

The verification protocol is robust against several adversary types. A1. Bundle modification. Verifier detects because signatures no longer verify. A2. Bundle substitution. Verifier detects because the substituted bundle's anchor refers to a different chain transaction or does not match an out-of-band reference. A3. Signature forgery. Verifier rejects unless the adversary has compromised signing keys across all three algorithm families simultaneously. A4. Chain replay. Verifier detects because the chain RPC reports the actual anchor's actual block. A5. Schema confusion. Verifier rejects because schema-version checks are applied to a non-conforming structure. A6. Sidecar substitution. Verifier detects because the sidecar's digest no longer matches the referencing EC object. A7. Selective disclosure abuse. Verifier handles via structural verification independent of content.

Verification properties

The protocol provides: P1. Determinism. Two parties running conformant verifiers on the same bundle reach the same verdict. P2. Soundness. If the verifier returns PASS, the bundle's content is authentic to the producer's keys. P3. Completeness. If the bundle is unmodified and signed correctly, the verifier returns PASS. P4. Vendor independence. The verification does not depend on any vendor's continued operation. P5. Offline verification. Base verification requires no network access. P6. Reproducibility. The verifier's output is reproducible across implementations. P7. Schema stability. The verifier's behavior for schema version N is frozen at release.

Common questions

Can multiple verifier implementations exist?
Yes. The verification protocol is published. Alternative implementations in Python, Go, TypeScript are welcomed.

How is implementation conformance tested?
A conformance test suite includes known-good artifacts (must validate) and known-bad artifacts in each adversary scenario (must fail).

What if the producer's keys are compromised after legitimate signing?
Bundles signed before the compromise remain valid. Bundles signed after the compromise are forgeable; the verifier may not detect them unless the compromise has been disclosed and the producer's keys have been revoked.

Can the verifier be compromised?
The verifier's open-source code allows external audit. Diversity of verifier implementations further reduces compromise risk.

Is this model standardizable?
Yes. The formal model and protocol are designed for submission to standards bodies.

Get Started

Run the demo Download the verifier Download a bundle