Skip to content
Verify

Change one field. Watch it fail.

Edit any part of a sealed receipt and every signature stops verifying, offline in your browser.

Tool · pask-verify

No live Pask dependency: an auditor, insurer, or regulator reaches the same verdict on their own machine. compliance → full spec →

Licensed AGPLv3Reference code with first pilotSample receipt
Run it yourself, offline: chain.json verify.mjs
Sample receiptThe receipts below are worked examples. Every check runs in your browser; nothing is sent to Pask.
Input · receipt
Verification level
Replay this attestation

A stale-but-valid attestation replayed here breaks the recomputed hash. The freshness nonce is folded into the seal pre-image, so a replayed nonce fails the L2 binding check.

Revoke signer key (as-of now)

Applies an offline revocation status-list as of the current date. When a signer key an already-sealed receipt relied on is revoked after sealing, the receipt is downgraded from INTACT to a distinct SUSPECT verdict: the hashes still verify, but the key behind one signature is no longer trusted. Try it on PASK-00041.

Hash-chain verification runs entirely in your browser (Web Crypto SHA-256) over the receipt and the local log, with no network and no live Pask.

pask-verify
hashing · SHA-256
integritysealsignaturesattestationnoncechain
$ pask-verify PASK-00041.cbor --level 3 --hash sha256 --log ./receipts.log
signer chain (signatures verified live; demo keys)0Approval→1validator→2reviewer→3Seal
Computed in your browser

Content-hash tamper evidence, the seal’s hash-commitment, which signer breaks first, hash-chain continuity, the attestation set-membership check, and the freshness-nonce binding are recomputed in-browser with crypto.subtle SHA-256. Each signer’s Ed25519 (native Web Crypto, with a noble fallback) and ML-DSA-65 signature is also generated and verified live over its commitment prefix, so editing any field breaks both the recomputed hash and the covering signature.

Ephemeral demo keys · illustrative lines

The signing keys are an ephemeral demo keyring generated in your browser and regenerated each load, not the production identity keyring; ML-DSA-65 uses a self-audited library. RFC 3161 QTSP timestamps and the charter / mesh version cross-checks stay illustrative: the production identity and timestamp stack is not wired in yet.

This site runs on our own reference deployment. Pilots on partner sites begin when partner sites are onboarded.

Tamper evidence

Once the seal is applied, the receipt body is fixed: any change to any field yields a different SHA-256 and breaks the earliest signer that committed to it. This preview proves that property, both in the recomputed hash and in the ephemeral-demo-keyring signature that covers it.

The Wilder site carries no reference_db_state and a null baa_version; the compliance field semantics live at receipt §5.7.