Proof bundle

A proof bundle is the artifact you receive from Vitrified after your submission has been witnessed. It contains everything required to verify the attestation offline against the public trust infrastructure of each witness mechanism.

Shape

{
  "schema": "vitrified.proof-bundle.v1",
  "submission": {
    "id": "sub_01J...",
    "leaf_sha256": "9f86d081884c7d65...",
    "metadata": { "schema": "purl", "purl": "pkg:npm/[email protected]" }
  },
  "batch": {
    "id": "btc_01J...",
    "root_sha256": "1a2b3c4d...",
    "merkle_path": [
      { "side": "right", "hash": "..." },
      { "side": "left",  "hash": "..." }
    ]
  },
  "witnesses": {
    "eidas":    { "status": "ok", "token_b64": "...", "tsa_cert_chain": [...] },
    "rfc3161":  { "status": "ok", "token_b64": "...", "tsa_cert_chain": [...] },
    "rekor":    { "status": "ok", "log_id": "...", "uuid": "...", "inclusion_proof": {...} },
    "ots":      { "status": "ok", "ots_b64": "..." },
    "evm":      { "status": "ok", "chain_id": 8453, "contract": "0x...", "tx_hash": "0x...", "log_index": 0 },
    "dsse":     { "status": "ok", "envelope": {...}, "vitrified_key_id": "..." }
  },
  "trust_roots": { ... }
}

The authoritative JSON Schema lives at spec/manifest/proof-bundle.schema.json and is bundled into every verifier implementation.

Field semantics

• schema — bundle format version. Vitrified follows semver; minor revisions are additive (new fields, never breaking).
• submission.leaf_sha256 — SHA-256 of the canonicalized submission envelope. Deterministic; same inputs always produce the same leaf.
• batch.merkle_path — the audit path from your leaf to the batch root. RFC 6962 construction. A verifier reconstructs batch.root_sha256 from submission.leaf_sha256 plus the path; if the reconstructed root matches what each witness witnessed, your submission is in the batch.
• witnesses.<mechanism> — one entry per witness mechanism. Each entry's status is ok, partial, or failed. A bundle with any failed mechanism is still independently verifiable through any mechanism that landed ok.
• trust_roots — the trust roots required to verify offline (TSA certificate chains, Sigstore log public key, Vitrified DSSE signing key fingerprint, OpenTimestamps calendar URLs, EVM contract address + ABI fragment). Embedded so verification needs nothing further from Vitrified.

Verification verdict

Every verifier implementation produces the same Verdict shape:

type Verdict = {
  isVerified: boolean;
  overall: "verified" | "partial" | "failed";
  message: string;
  mechanisms: Record<Mechanism, MechanismVerdict>;
};

type MechanismVerdict = {
  status: "verified" | "verified_partial" | "failed" | "skipped";
  detail?: string;
};

The closed-vocabulary status values and per-mechanism verification depth are pinned in spec/verifier-matrix.md. Every conformant verifier — Python SDK, JS SDK, CLI, MCP, browser web — produces the same verdict for the same bundle plus the same optional inputs.

Long-term verification

A bundle remains independently verifiable for as long as the witness mechanism's public trust infrastructure remains operational. Practical durability windows:

For maximum durability, Bitcoin via OpenTimestamps is the strongest anchor. The other mechanisms provide standards-conformance for specific compliance frameworks; OTS provides the long tail.

See also

• Witnessing — how the bundle is produced.
• Verifier CLI — offline verification on the command line.
• API reference — the HTTP endpoint that returns bundles.