The Compliance Problem
Your customer needs to hand a session record to their auditor. The session shows what was reviewed, who approved it, what gates fired, what overrides were recorded, and on what justification. Standard options:- Send a PDF. Not machine-verifiable. Tampering is undetectable at the field level.
- Give the auditor a read-only login. Massive blast radius. The auditor has access to everything, not just the one session.
- Provide a JWT and a verifier endpoint. The auditor must reach your endpoint. If you go offline or block them, audits stall. Their security team will block the cross-origin call anyway.
The Pattern
Sign the session record with Ed25519 over canonical JSON. Embed the public key in the token itself. Any third party with the token can verify it using a standard library — no network calls, no JWKS endpoint, no STRATT access.Why It Stands Up
| Property | How |
|---|---|
| Tamper-evident at the field level | Any payload change → signature fails |
| Issuer-independent verification | Public key embedded; no lookup |
| Time-bounded | TTL at mint replaces revocation lists |
| Standards-aligned | Ed25519 is FIPS, IETF, and every modern crypto library |
| Privacy-respecting | Internal actor IDs can be redacted by default; opt-in unmask requires a second signature |
What It Enables
- Customer to auditor: handoff is a URL.
- Customer to opposing counsel: cryptographic proof without discovery.
- Customer to regulator: filing-grade artefact that survives the issuer going offline.
- Customer to customer: supply-chain provenance with no shared infrastructure.
The Engineering Cost
@stratt/signature is ~80 lines on top of @noble/ed25519. Tests cover round-trip, tamper, expiry. Reuses @stratt/fingerprint for the canonical-JSON layer that makes signatures reproducible across implementations.
The whole audit bridge — sign endpoint + public viewer page + middleware exemption — landed in one taskset.