Verify a mandate in your own browser .
Paste an agent mandate or entitlement token below. This page fetches our public key and checks the EdDSA signature, expiry, and not-before on your machine — the only network call is for the public key itself. Verification never contacts our API, needs no account, and requires trusting no one.
1. fetch public JWKS · 2. import Ed25519 public key · 3. WebCrypto verify() · 4. check exp / nbf
Verify offline No token? Mint a sample Flip one character How does this work? See a session’s story
✕
How this works
No cryptography degree needed — three steps.
1 The seal. Every receipt and permission here is a small package of facts — who may act, on what, until when. Before it leaves, it is sealed on the server with a private key : the half of the lock only the server holds.2 The pairing. You hold the other half — the public key , published for everyone. Press Verify and your browser pairs your public half with the server-sealed package. A match unlocks the payload as genuine; if even one character was changed after sealing, the pairing fails and the check reads INVALID.3 The ledger. Every grant and every check then lands on a ledger where each entry locks in the one before it — think “blockchain,” without the coins. History can be visibly broken, never quietly edited.
What’s an “asymmetric key”? A lock split into two halves that only work as a pair. You already use them: the SSH key or PAT you add to GitHub, the chip in your bank card, the padlock behind every https://. Same rule as any .env file — the public half can be published anywhere; the private half stays on the server and is never committed.
What the artifacts look like: the receipt, the verify result, and the QR that carries it. The same QR slot is where GS1 identifiers plug in — GTIN, the number under every retail barcode, and GLN, its location sibling — the Sunrise 2027 thread.
✕
One session, four panes
Two different objects, two doors: a token is a sealed credential you verify (the math-gated door above); a session bookmark is a pointer you look up (the role-gated door — these four are opened for the demo). Bookmarks grant nothing.
1 A session bookmark names one visit’s record. Every consent interaction on the store — grant, deny, reset — writes a row with a fresh bookmark (a random UUID). It contains nothing and grants nothing — like a receipt number, it only says which record; the server still decides who may read it.2 Four panes, four questions. What did they consent to? Who are they allowed to be? What did they buy? How did they engage? One screen, all keyed to that single session ID.3 The rule that matters. Revoke consent and the engagement pane goes dark from the next session — enforced in the data path itself, not by the cookie banner. That is the behavior regulators ask about.
Open a real one — live records from the platform’s own test identity (no customer data). Three show the reset rule in action; one shows the no-signal case:
What this proves. A relying party — an auditor, a partner platform, an agent runtime — can confirm a mandate is authentic and unexpired using only the public key at https://crm-sync.dev/.well-known/jwks.json. If we altered a mandate’s cap, scope, or subject after signing, the signature would fail here. Source keys rotate; retired keys keep verifying until their not_after.