What a signed attestation proves, and what it does not

Under each signed run on a report page there is a link to an attestation. It looks official, which is exactly why it deserves a precise description. A signature is a narrow instrument; used honestly it proves one thing very well and nothing else.

The shape of the thing

An attestation is a DSSE envelope: the public Dead Simple Signing Envelope specification, three fields long. A payloadType, a base64 payload, and a list of signatures. Ours are signed with Ed25519, and the payload is a JSON document that names:

• the target endpoint and the run’s timestamp;
• every assertion the run produced, with its state and its structured reason;
• the fingerprints computed on that run (tool set, schemas);
• which code ran: from payload version 0.3 on, a suite_commit, which is a commit in our repository, and a suite_digest, which is a SHA-512 taken over the git tree listing of the check suite at that commit. Earlier payloads carry only a suite_digest under an older definition that cannot be recomputed, and their attestation pages say so.

The envelope is shown in full on the attestation page, and you can save it as a file. The signature is over the payload bytes, so any change to any field, however small, invalidates it.

What it proves

Exactly this: on this date, our probe, running this specific code, observed these things about this endpoint, and nobody has altered the record since.

Each clause matters.

Our probe. The signature ties the record to our signing key. A report page can be forged; a valid signature over a forged payload cannot, unless the key leaks. The key lives only inside the signing service and never in the website, the database, or the repository.

This specific code. The suite_digest is the part people skip and the part that carries the most weight. A check’s meaning depends on how it was implemented. “The handshake failed” means something different under a probe that only accepted a 400 as a legacy fallback than under one that accepts any 4xx (we shipped both; the first was a bug). On a version 0.3 payload, the digest lets anyone with the repository at that commit recompute it and confirm which behaviour produced the record.

Nobody has altered it. This is the ordinary property of a signature, and the one that makes the record useful to a third party who does not trust our website.

What it does not prove

It does not prove the server is good. It does not prove the server behaved the same way one hour later. It does not prove anything about what the tools do when called, because we never call them. It does not prove the checks are the right checks. It is a notarised observation, and an observation is only as useful as the reader’s understanding of what was observed.

This is also why unsigned observations are drawn without colour: a colour with no signature behind it would lend them a weight they haven’t earned.

Verifying one yourself, today

The envelope follows a public specification, and the verifier is a script in our public repository, github.com/mcpcheckup/checks. The public keys that verify our signatures are published at /.well-known/mcpcheckup-keys.json and listed for people at /keys. Download the key file, then run the verifier on the envelope you saved from the attestation page:

curl -fsS https://mcpcheckup.com/.well-known/mcpcheckup-keys.json -o keys.json
node packages/verifier/verify-attestation.mjs --envelope <id>.json --keys keys.json

The verifier looks up the envelope’s keyid in that file and fails if it is not there. It also fails if the key was revoked, or if the payload’s observed_at falls outside the key’s valid_from to valid_until window. It reads only the files you give it and makes no network request.

For a version 0.3 payload you can also recompute the suite_digest if you hold the repository at the named commit; the attestation page carries the command. Signatures don’t expire, but a key can be revoked: an envelope you saved today can be checked later against a newer key file, and if that file lists the key as revoked, the envelope fails. A retired key stays in the published list, and envelopes whose observed_at is at or before its end date stay valid.

Why we signed before the keys were published

Because the discipline had to exist before the audience did. Signing from day one means no signed observation in the record could have been edited since. Now that the keys are published, verification covers every signed observation whose key is in the published list, not only those made after publication.