Reproducibility & open-source plan

Note

This page is explicit about what is available today versus what is planned. We do not claim open-source publication or provenance levels we have not yet reached.

---

OpenReceipt specification

Item	Status
Spec document	Published — signedreceipts.org/spec
Extension registry	Published — signedreceipts.org/spec/extensions
Spec source archive	In preparation — SHA-256 source manifest published at signedreceipts.org/source/spec; no downloadable archive yet
Version	OpenReceipt v3 (client-signed + gateway-countersigned; legacy v1/v2 continue to verify)

The OpenReceipt wire format is the envelope used by CloakAPI for all signed receipts. The published specification defines the JSON envelope, the canonicalisation rules (RFC 8785 JCS), the signing procedure (ECDSA P-256 over the canonical serialised body), the chain-linking structure, the three trust tiers (gateway-countersigned / beacon-anchored / local-only), and the gateway countersignature. The current envelope version is v3: the receipt is signed by the client that performed the tokenisation before egress, and optionally countersigned by the gateway. Legacy v1/v2 receipts remain verifiable indefinitely.

---

Reference verifiers

Item	Status
Live browser verifier	Published — app.cloakapi.io/receipt-verifier (runs entirely in your browser)
In-browser JS verifier	Published — signedreceipts.org/verifier; the TypeScript library it derives from is described at /source/reference-typescript (source distribution in preparation, not yet published)
Python reference verifier	Planned — not yet implemented; see signedreceipts.org/implementations for current status
Rust reference implementation	In preparation — described (with SHA-256 source manifest) at /source/reference-rust; no tarball or crates.io release yet
Verifier CLI	In preparation — described at /source/verifier-cli; built from source, not yet distributed via any package channel
Verification guide	Verifying a receipt

The published verifiers are standalone (no CloakAPI SDK dependency). Any third party can verify a receipt given only:

1. The receipt JSON envelope. v3 receipts are self-contained — the attester public key is embedded, so verification works fully offline.
2. For gateway countersignatures: the JWKS from https://api.cloakapi.io/api/.well-known/cloakapi-receipt-pubkeys.jwks.
3. (Optionally) the transparency seed feed.

Reference sources are being prepared for publication as versioned tarballs under signedreceipts.org/source — the project is developed in a private tree and will be published there, not on GitHub. Today each artefact page carries a SHA-256 source manifest; no tarball is published yet. The verify receipt guide documents the manual steps.

---

Conformance test suite

Item	Status
Conformance test suite	Documented — suite definitions + pass criteria at signedreceipts.org/conformance
Test vectors	In preparation — SHA-256 corpus manifest at /source/conformance; a sample fixture is live at /conformance/fixture-pass.json, full corpus distribution not yet published

The conformance suite defines canonical test vectors for:

• Valid receipt verification (positive cases).
• Invalid signature rejection (tampered body, wrong key, expired kid).
• Chain hash validation (gapless seq, prev_hash continuity, fork rejection).
• JWKS resolution and revoked: true handling.

Once the corpus distribution is published, third parties implementing an OpenReceipt verifier will be able to run this suite to confirm conformance and claim the badge. Today the suite definitions and pass criteria are documented and badge submissions are reviewed manually.

---

SLSA build provenance

Caution

CloakAPI build provenance is currently at SLSA Level 0 — no formal provenance is generated or published. The roadmap targets SLSA Level 3.

SLSA level	Description	CloakAPI status
L0	No provenance	Current
L1	Provenance exists (unsigned)	Not yet
L2	Signed provenance, hosted build	Not yet
L3	Hermetic, reproducible builds; signed provenance	Roadmap

What SLSA L3 would provide

• Build recipes are verifiably complete — no implicit inputs.
• Build environment is hermetic — network access blocked during build.
• Provenance is generated and signed by the build platform.
• Consumers can verify that a published artifact matches a specific source commit.

Roadmap path

1. Add SLSA L1 provenance generation to CI (next milestone).
2. Adopt hermetic build environments (L2).
3. Publish signed provenance bundles alongside container images and gateway releases (L3 target).

---

Summary table

Artifact	Published today	Where
OpenReceipt spec (v3)	Yes	signedreceipts.org/spec
Extension registry	Yes	signedreceipts.org/spec/extensions
Live browser verifiers	Yes	app.cloakapi.io/receipt-verifier + signedreceipts.org/verifier
Python reference verifier	No — planned	signedreceipts.org/implementations
Reference library sources (Rust / TS / CLI)	No — manifests published, distribution in preparation	signedreceipts.org/source
Conformance test suite	Documented — corpus distribution in preparation	signedreceipts.org/conformance
SLSA L1 provenance	No	Next milestone
SLSA L3 provenance	No	Roadmap
JWKS endpoint	Yes	https://api.cloakapi.io/api/.well-known/cloakapi-receipt-pubkeys.jwks
Transparency seed feed	Yes (opt-in)	https://api.cloakapi.io/api/v1/transparency/seeds.jsonl
Receipt verification guide	Yes	Verifying a receipt