EdSSA transparency log

What this is

Every EdSSA deployment running Tier-4 audit seals its event stream into an hourly Merkle root. Those roots form a hash-chain: rewriting any past root breaks the chain forward, so tampering is internally detectable.

But an internal chain is only tamper-evident against a copy the operator also controls. So each sealed root is additionally anchored into an append-only transparency log the operator does not control (Sigstore Rekor). After that, an operator who rewrites the local chain cannot also rewrite history in the external log — the divergence is detectable by anyone, offline.

This page publishes those anchored roots so a data owner, an auditor, or a regulator can verify them independently. The client-facing reports EdSSA produces from this same evidence — control-by-control, one per regulatory framework — are shown as downloadable example reports.

Any roots shown here today are from EdSSA's own reference deployment — a small sibling-device fleet we run — not customer evidence. That is deliberate: it lets you exercise the whole verify-it-yourself flow against real, live log entries before any customer deployment goes public. Customer roots appear here as deployments choose to publish.

What a published root proves — and what it doesn't

It proves: that you, a stranger, can verify EdSSA's evidence flow end-to-end without our help; that a recorded history, once sealed, cannot be silently rewritten; and that each state existed by a specific time, attested by a log we do not control. It does not prove that the recorded events are true or complete, nor anything about a customer's deployment (these are our reference fleet), nor the security of the authentication protocol itself. It is proof that the evidence pipeline works and is operator-independent — bounded honestly. The two open edges — content honesty and completeness — are exactly why the design distributes attestation across parties rather than trusting one log; see below.

The canonical record

Each anchored root is submitted as a stable, sorted-key, compact JSON record built only from public fields — re-derivable by anyone holding a published log line, without running EdSSA:

{"count":3600,"fleet_id":"<fleet>","prev_root":"<64hex>","root":"<64hex>","schema":"edssa.anchor-witness.v1","timestamp_ns":<ns>}

(tenant_id is inserted, in sorted position, only for tenant-scoped deployments. Shown wrapped for readability — the canonical record is a single line.) The SHA-256 of this record is what the external log records.

How to verify — without trusting us

Each row below links to its entry in the external log. To check it yourself, fully offline, against the log's pinned public key:

edssa-admin verify-anchor --against-witness rekor \
  --fleet <fleet> [--tenant <tenant>] \
  --db <your-copy-of-merkle.db> --pubkey <pinned-log-key>.pem

Exit codes: 0 ok · 2 chain break · 3 tamper (a receipt is present but invalid/inconsistent) · 4 gap (un-witnessed window; add --require-witness to fail on it) · 5 misconfig. The verifier replays the log's RFC-6962 inclusion proof, its signed entry timestamp, and its signed checkpoint — none of which the operator can forge.

The honest boundary

An external witness proves the integrity and timing of what was recorded. It does not prove completeness — an operator who simply stops sealing events produces nothing to witness, and a log cannot attest to the absence of events it never saw. Closing that gap requires the parties generating the events to co-anchor their own view; that is a future capability, and we say so plainly rather than overstate what a transparency log can do.

The full design, threat model, and limits are in the public specification: roadmap/specs/transparency-witness-rekor.md.