Universal Receipt Checker

One page for an agent receipt from any vendor. It gives one of three answers for your run: VERIFIED, BROKEN, or COULD NOT LOOK. It also tells you whether anyone else has ever checked the receipt, and today the honest answer is BLIND: nobody has. Everything runs in this page. Nothing is uploaded, and nothing is fetched.

Receipt

Drop one receipt file here (JSON, or a binary .cbor / .cose SCITT statement), or
Optional: the signer's public key, and a payload or original file
Optional: for a SCITT transparency receipt, the service's key and the statement

A receipt is checked by recomputing the Merkle root from the statement and the proof path (RFC 9162), then checking the service's signature over that root (RFC 9942). The log entry is taken to be the statement with its unprotected header emptied (RFC 9943 s6.3); a service that logs something else will not verify here.

What each answer means, and what this page cannot see

VERIFIED: every core check for this format ran here and passed. It says the receipt was not altered and was signed by the key named. It does not say the receipt is true, or who holds that key.

BROKEN: a check ran and failed. The receipt was altered, is malformed for its own format, or does not verify under the key given.

COULD NOT LOOK: the page could not run the check. The format was not recognized, or was ambiguous, or the key or payload was not available, or the algorithm does not run in a browser. It is never folded into either of the other two.

COULD NOT LOOK in grey, on a single row: that claim is out of reach for this page by construction, and the row says why. A grey row never decides your run's answer; only the core checks do.

BLIND, on the record: nobody has published a check of this receipt. That is a state of the record over time, not a result of your run, and a VERIFIED run does not change it.

Formats read today: Arcaeon receipts (body digest, plus the same attachment checks as verify-receipt.html: a witness block that contradicts the ledger block, its own pin or the pin's self digest is BROKEN, and so is an attestation signature made over another digest; the witness, ledger and anchor are otherwise the issuer's claims, CLAIMED and not looked at), Agent Receipts (schema and Ed25519 proof), SCITT Signed Statements (RFC 9943 headers, hash envelope digest, and the COSE signature for ES256, ES384, ES512, EdDSA, PS256 to PS512, RS256 to RS512), and SCITT transparency receipts (RFC 9942) for the one registered data structure, RFC9162_SHA256: the inclusion proof is walked from the statement's own leaf to a root, and the service's signature is checked over that root with the key you supply. A receipt on its own, or attached to its statement, both work. Other data structures (such as the CCF ledger profile), consistency proofs, and a receipt with no service key are COULD NOT LOOK. Signet receipts are recognized and answered COULD NOT LOOK, because Signet publishes no schema for them. Certificate chains, who a transparency service key belongs to, Agent Receipts chains, and RFC 3161 timestamps are grey COULD NOT LOOK rows.

The failure cases this page is tested against are published with it: tests/fixtures/universal/README.md. A checker that only ships happy paths cannot be told apart from one that always says yes.