Appendix E — Comparative architectures (Sigstore, SLSA, C2PA, …)

Canon is not the first system to sign JSON or assert provenance. Several adjacent standards address parts of the same problem. This appendix locates Canon in that ecosystem: what each system signs, how, and where the design choices diverge from Canon's evidentiary requirements.

The key divergence is epistemic scope. Sigstore, SLSA, and C2PA sign artifacts — a build output, a media file, a software package. Canon signs claims about artifacts: what the artifact says, what was inferred from it, what was declined, and why. The distinction matters for litigation: an exhibit must carry not only proof that its bytes are intact, but proof that the inferences drawn from it are declared and falsifiable.

The table below covers systems current as of May 2026. Verify currency before citing in any submission.

Source: dossier 02 (research/02_verifiable_evidence_ecosystem.md) — read that for the full citations. | System | Primary purpose | What it signs | Hash | Sig | Container | Closest analog to Canon | Key difference | |---|---|---|---|---|---|---|---| | Canon | Personal-data evidence reasoning | JSON attestation (W/F/R/S) | SHA-256 | Ed25519 | RFC 8785 raw | — | inference types + declared gaps + applied/declined challenges | | Sigstore Rekor v2 (Oct 2025) | Software supply chain | Build artifacts | SHA-256 | Ed25519 / ECDSA P-256 | DSSE / in-toto | Append-only log + identity-bound sigs | Keyless via OIDC; public global log; no claim graph | | in-toto / SLSA v1.1 (2025) | Build provenance | Subject hash + predicate | SHA-256 | Ed25519 / ECDSA | DSSE | Predicate-extensible signed envelope | Predicates describe build steps, not epistemic state | | C2PA Content Credentials v2.2 (May 2025) | Media provenance | Embedded manifest in media | SHA-256 | Ed25519 / ECDSA | COSE_Sign1 (RFC 9052) | Embedded chain-of-custody manifest | CBOR not JSON; no inference types; no declared gaps; no refutation | | W3C Verifiable Credentials 2.0 (May 2025) | Issuer-signed claims | JSON-LD VC | SHA-256 | EdDSA / ECDSA | Data Integrity 1.0 (URDNA2015) or JOSE | Signed JSON-LD claims | Trust anchored in DID; selective disclosure; no challenge model | | OpenTimestamps | Timestamping | Hash → Bitcoin OP_RETURN | SHA-256 | (none — uses chain) | .ots proof | Existence at time | No content claims; complementary, not competing | | Trillian / Tessera (alpha 2025) | Append-only log infrastructure | Any leaf | SHA-256 | Co-signed log heads | Tile-based | Audit-log substrate | Infrastructure, not a claim format | | JWS (RFC 7515) | Signed JSON | Header + payload + signature | configurable | configurable | Base64 envelope | Signed JSON | Wraps payload (no canonicalization required); not minimal | | COSE (RFC 9052/9053) | Constrained-environment signing | CBOR object | configurable | EdDSA / ECDSA | Deterministic CBOR | Compact signed payload | Different serialization; used by C2PA, FIDO2 | | JAdES v1.2.1 (Jul 2024) | EU eIDAS-qualified signing | JWS + ETSI AdES qualifiers | SHA-256/512 | configurable | JWS extended | Long-term-validity envelope | Adds qualifying signature semantics for cross-border admissibility | | Witness (in-toto/witness, CNCF) | Step-level attestation wrapping | Activity envelope | SHA-256 | Ed25519 | DSSE | "Wrap an action, emit attestation" pattern | Wraps build steps; has policy engine (Rego) | | Mithril Security AICert | TPM-attested model cards | Weights + training data hash | SHA-256 | TEE quote + Ed25519 | TPM EventLog | Hardware root of trust | Closes a gap raw Ed25519 cannot — TEE attestation | | ZKPROV (arXiv 2506.20915, Jun 2025) | Provable LLM provenance | LLM response + dataset commitment | (zk circuit) | zk-SNARK | (custom) | Closest academic analog to SearchAttestation | Hides weights/data; high prover cost | | RAGShield (arXiv 2025) | Cryptographic ingestion-side trust | Document attestation + provenance | SHA-256 | various | C2PA-inspired | Ingestion-side signing | Closer to Observation+Search chain end-to-end | ## v0.2.0 comparisons ### DSSE vs. bare Ed25519 Canon v0.2.0 adopts DSSE; v0.1.x used bare Ed25519 over JCS bytes. | Dimension | Bare Ed25519 (v0.1.x) | DSSE (v0.2.0) | |---|---|---| | Domain separation | None — same bytes produce same signature regardless of context | PAE mixes payload_type into the signed message; different types cannot share signatures | | Cross-protocol attack surface | A signature over JCS bytes could be replayed in any protocol using the same key over the same bytes | PAE prevents this; payload_type is a required discriminator | | Interoperability | Proprietary to Canon | CNCF standard; interoperable with SLSA provenance, in-toto link files, TUF metadata | | Complexity | Simpler; sign(SHA-256(JCS(obj))) | Slightly more complex; sign(PAE(payload_type, JCS(obj))) | | Adoption | Canon v0.1.x only | SLSA, in-toto, TUF, Sigstore | The domain separation PAE provides is not hypothetical. When two systems use the same Ed25519 key for different protocols, a signature from one can theoretically satisfy the other's verification if the byte sequences collide. PAE makes the payload type an explicit part of the signed message, eliminating the collision surface. ### C2PA vs. hash-only media attestation | Dimension | Hash-only (SHA-256 + attestation) | C2PA Content Credentials | |---|---|---| | Provenance location | External database record; must be linked to the file | Embedded in the file itself (JUMBF box in JPEG, mdat in MP4) | | Travels with file | No; provenance and file can be separated | Yes; manifest is part of the file bytes | | Standard | Canon-specific | CNCF/CAI industry standard (Adobe, Microsoft, BBC, etc.) | | Dependency | None beyond SHA-256 | c2pa-python; heavier compile dependency | | Inference types | Canon full model (W/F/R/S) | Limited; no refutation model | For media files (images, audio, video) that will be distributed outside the database — shared with opposing counsel as file attachments, embedded in court filings — C2PA embeds provenance directly in the container. A Canon hash-only attestation requires the recipient to look up the database record. When those can be separated, C2PA provides stronger chain-of-custody guarantees at the file level. SHA-256 fallback is always available; use it when c2pa-python is not installed or when the file format does not support embedded manifests. ### Rekor vs. no transparency log | Dimension | No transparency log | Rekor (Sigstore) | |---|---|---| | Timestamp trust | Relies on custodian's clock | Publicly anchored in append-only Merkle tree | | Public auditability | None; must trust the issuer | Anyone can confirm the attestation existed before a given date | | Privacy | Private by default | Entries are public — full envelope is visible | | Dispute resistance | "Trust us" | Independently verifiable; surviving even if the issuer disappears | | Private option | N/A | Deploy a private Rekor instance; same auditability, access-controlled | Rekor is optional (MERIDIAN_REKOR_ENABLED=0 by default) because entries are public. For matters where the existence of an attestation is itself sensitive, use a private Rekor instance or publish only the envelope hash rather than the full payload. ### ParadeDB vs. tsvector | Dimension | tsvector (default) | ParadeDB / pg_search | |---|---|---| | Relevance ranking | Inverse document frequency (GIN index) | Tantivy BM25; supports BM25F field weighting | | Setup | Built into PostgreSQL; no extension needed | Requires pg_search extension install | | Query operator | Standard SQL (@@) | Non-standard (@@@) | | Scale | Good to ≈10M chunks | Better headroom; Tantivy index is Rust-native | | Recall for legal terms | Adequate | Better for long-tail technical and legal vocabulary | Enable with MERIDIAN_USE_PARADEDB=1. The dispatcher in meridian.query.search handles both paths. For capstone-scale corpora (< 10M chunks), tsvector is sufficient and has no additional dependencies. ### pgvectorscale vs. ivfflat | Dimension | ivfflat (default) | pgvectorscale StreamingDiskANN | |---|---|---| | Index type | RAM-based IVF; clusters of centroids | Disk-backed streaming DiskANN; navigable small world graph | | Scaling | Limited by RAM; degrades at > 10M vectors | Scales beyond RAM; recall stays stable at high N | | Setup | Bundled with pgvector; no extra step | Separate extension; requires schema/B2_pgvectorscale.sql | | Recall at 1M vectors | Adequate | Better | | Insert cost | Lower | Slightly higher; builds graph incrementally | For corpora with dense-vector sets under ≈5M chunks, ivfflat is adequate and requires no additional setup. Switch to StreamingDiskANN when recall degrades under load or when the embedding set exceeds available RAM.

Patterns to import

1. Sigstore's transparency-log discipline. When CASEFORUM ships, Trillian-Tessera is the right substrate; do not roll your own Merkle layer.
2. Witness's attestor-plugin architecture. Per-source attestors should follow this model.
3. C2PA's manifest store. When evidence is media (image/video/audio) and the recipient may strip sidecar JSON, embed the manifest in the media file.
4. OpenTimestamps as a complementary anchor. Notarize public-key fingerprints; defends against retroactive substitution.
5. JAdES for EU eIDAS-qualified signing. Migration target if cross-jurisdictional admissibility is required.

Patterns to not import

1. Keyless / ephemeral-cert signing (Sigstore Fulcio model). Canon requires long-lived issuer identity for evidentiary purposes; an OIDC-bound ephemeral cert does not provide it.
2. CBOR-only encoding (COSE). Canon attestations must be human-readable for review; JSON is the right tradeoff.
3. Selective disclosure (BBS+, SD-JWT). Selective disclosure is at odds with the falsifiability model — a recipient must verify the full artifact, not a redacted view.

Source: dossier 02. Verify currency before citing.