Verify a signed report without asking us.

Run the check

One file: the .zip the report was delivered in. Everything the check needs is inside it — the report bytes as they were signed, the attestation over them, and the certificate naming the key that signed it. Choose the archive and press verify. If you were sent the .attestkeep.json on its own, paste that instead.

Where the key comes from

You do not enter one. The page carries the only key you are asked to trust — ours:

kid:     ak1
ed25519: e287aabe4712197cfa5b6fdf9ea8f2d7f0333ce16ca69aac7e4a3f1e84c04179

Everything else is vouched for in a chain. The licence certificate is a document we sign with that key; inside it, the cnf.jwk field names the evidence signing key of the licensed installation. That key signs the DSSE envelope, and the envelope's digest pins the report. The page also cross-checks that the certificate and the report name the same cluster fingerprint — without that step, a genuine certificate could be laid next to a genuine envelope from some other installation, and the pair would look like proof.

The chain exists because the old way had a hole in it. A verifier that accepts a public key from whoever brought the document proves only that the document is consistent with itself: a forger mints a key pair, signs an invented report, and hands you both. The chain replaces "the key the report's author handed you" with "the key we certified for that installation" — one trust anchor, held by a party with no stake in the report's contents.

The manual-key path under the form is exactly that weaker check, kept for a reader who has an envelope but no certificate. Its result carries the caveat with it.

What a pass proves — and what it does not

A green result above proves exactly two things:

• the documents have not changed since they were signed — alter one character, even inside a timestamp, and the check fails;
• the report came from the installation our certificate names — its envelope was signed by the key the certificate vouches for, and both name the same cluster.

It does not prove more than that, and the two limits are worth stating in full:

It is not a legal electronic signature. No qualified certificate is involved and no e-signature statute — eIDAS in the EU, Law 5070 in Türkiye — applies to it. It is a cryptographic integrity check. If your process requires a legally recognised signature, this does not substitute for one.

It does not prove when the document was signed. The generated_at timestamp and the audit period are the installation's own declaration, read from its own clock. No timestamping authority is involved, so a signature made today over yesterday's date would verify just the same. If you need the time proven, that proof has to come from somewhere else.

One more honest line: the signature vouches for the document, not for the world. It proves the report is exactly what that installation produced — not that the events the report describes happened as described.

Nothing leaves this page

The verifier is ordinary JavaScript served from this site — the hashing and the Ed25519 arithmetic included, with no third-party library and no CDN. You do not have to take that on faith: open your browser's network panel and watch while you verify, or load the page, disconnect from the network entirely, and verify offline. The result is the same, because neither document is ever transmitted.

The format — every predicate field, the envelope shape, the certificate, the encoding that gets signed — is specified in the compliance evidence attestation, v1, which also carries a real signed example to try against this page.

Last updated: 29 August 2026