How to Verify a Receipt
Check a WitnessOps receipt or proof bundle offline without relying on WitnessOps to stay in the middle.
How do I check a receipt or proof bundle offline, and how should I read valid, invalid, and indeterminate results?
Public tool first: if you only need to check receipt JSON you were given, use Verify a receipt — upload or paste, then read the result. This page is the technical procedure behind that path and the optional offline modes.
This page answers one practical question: how to verify a receipt or proof bundle without collapsing public receipt checks, bundle-complete offline review, and anchored replay into the same claim.
1. Problem this page solves
Many teams can export artifacts but cannot say which checks were actually proven.
Verification needs a deterministic sequence that separates:
- proof that passed
- checks that were missing
- trust dependencies that still sit outside the proof bundle
This page defines that sequence.
2. What you should understand after reading
After this page, you should understand:
- the minimum artifacts needed to verify a receipt
- the exact order of checks for independent verification
- what each verdict means (
valid,invalid,indeterminate) - what is proven and what still depends on trust
- how the public
/verifyresult differs from bundle-complete verification
3. Verification modes and claim boundaries
Keep these modes separate before relying on a result.
| Mode | Input | What the result can claim |
|---|---|---|
| Public receipt-first v1 | Supported receipt JSON submitted to /verify | Receipt-scoped checks passed or failed for that JSON. Artifact bytes and bundle completeness are not revalidated. |
| Bundle-complete offline | Receipt, manifest, referenced artifact bytes, signatures, timestamp material, and trust material | The verifier can recompute artifact hashes, check manifest integrity, and evaluate declared proof layers that are actually present. |
| Anchored replay | Bundle-complete material plus reviewer-supplied trust anchor | The package is tested against a continuity or identity anchor obtained outside the package. |
A public valid result on /verify should be read as receipt-scoped. It does not prove the full runtime story, complete bundle custody, or artifact-byte integrity. The public adapter may present an internal limited-pass as valid.
4. Minimum artifact set
At minimum, start with the receipt material and trusted key material. Independent checks require authentic keys or anchors; without them, signature results are not meaningful.
| Artifact | Status | Why it matters |
|---|---|---|
| Receipt JSON or exported proof bundle | required | Core proof statement and references |
| Signing public key or trusted key source | required | You cannot check signature authenticity without it |
| RFC 3161 timestamp token + chain | conditional | Required when the receipt claims trusted time and you need full time proof |
| Log checkpoint + inclusion proof | conditional | Required when the receipt claims append-only publication |
5. Procedures by mode (do not collapse)
A. Public /verify only (receipt-first v1)
This is the default public product path.
- Submit supported receipt JSON to
/verify(or/api/verify). - Confirm schema, proof stage, digest relationships, and other receipt-level checks the public adapter runs.
- Read
validas receipt-scoped (including when the adapter maps internallimited-pass→valid). - Do not treat the result as artifact-byte revalidation, bundle completeness, or full offline proof.
B. Offline bundle-complete (optional; requires offline tooling)
Use only when you have a full package and offline verifier tooling (not the public /verify upload path).
- Confirm receipt + manifest + referenced artifact bytes + signatures + any timestamp/inclusion material.
- Recompute listed hashes from artifact bytes; check manifest integrity.
- Verify the signature against trusted keys.
- Verify structure and bindings.
- If claiming trusted time, fully validate the RFC 3161 token and chain.
- If claiming log inclusion, validate inclusion proof and checkpoint signature.
- Verify continuity links when present.
Integrity and signature checks come before higher-layer interpretation.
6. Expected results and interpretation
| Check | Outcomes |
|---|---|
| Proof-bundle integrity | pass / tampered |
| Signature | valid / invalid / missing key |
| Structure and binding | well-formed / malformed / digest mismatch |
| Timestamp layer | valid / invalid / not present |
| Log inclusion layer | valid / invalid / not present |
| Continuity layer | proven / not present |
Public surface note: /verify currently runs receipt-first v1. The public adapter may present an internal limited-pass as valid. Read that result as receipt-scoped: supported receipt checks passed, but artifact revalidation was not performed.
Verdict interpretation:
valid: the required checks for the declared claim set and selected mode passed. In public receipt-first mode, this does not prove bundle completeness or artifact-byte integrity.invalid: one or more proof-bearing checks failed.indeterminate: the proof bundle may be coherent, but a required outside trust condition could not be established locally.
7. What is proven vs what remains trusted
Proven when checks pass
- in public receipt-first mode, supported receipt structure and receipt-level consistency only
- issuer-bound signed statement integrity
- digest and artifact consistency
- optional trusted-time and inclusion claims when the matching material is present and valid
Still trusted externally
- key distribution authenticity
- TSA trust and time-source trust
- log-operator trust model, unless additional witness policy is satisfied
8. Common failure modes
- Missing file or hash mismatch → tampered or incomplete proof bundle.
- Signature failure → issuer authenticity not established.
- Timestamp failure → trusted-time claim not established.
- Inclusion proof failure → append-only publication claim not established.
Report failures by layer instead of collapsing everything into one vague pass/fail line.
9. Next-page handoff
Next, read Receipts to inspect the proof statement this verification flow is evaluating.
Then use Anchored Replay when reviewer-supplied trust-anchor continuity is required.