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.

New: AI cutover checklist for enterprise organizations → What to do now — keys, Cloudflare, Xano, Webflow, Shopify and a governance gate — before an ERP or commerce cutover.

1. fetch public JWKS  ·  2. import Ed25519 public key  ·  3. WebCrypto verify()  ·  4. check exp / nbf


How this works

No cryptography degree needed — three steps.

  1. 1The 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. 2The 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. 3The 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.
The three artifacts: a signed receipt, a verify result, and the QR code that carries the certificate
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. 1A 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. 2Four 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. 3The 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:

The reset rulerevoked now — granted from the next session (N+1); engagement withheld No signal at allno consent row — nothing tracked, panes stay empty Reset rule, second visitsame enforcement on a different session Reset rule, earlier runthe projection stays consistent over time
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.

Channel feed & QA certification, outside the SAP and AEM loop.

Every channel feed run and every QA test check can be sealed the same way as the mandate above: signed at publish with our Ed25519 key, verifiable by anyone with the public key at https://crm-sync.dev/.well-known/jwks.json — offline, with no account and no call to our API. The SAP or AEM team, a marketplace partner, or an auditor can confirm a feed or test result is genuine without joining your SAP or AEM workflow or trusting our servers.

Four ways to “certify,” and what each proves

SAP / AEM document signing (e.g., eMudhra emSigner, DocuSign, AEM Forms, Acrobat Sign)Let’s EncryptXano built-in cryptoCRM Sync signed certification
SignsBusiness documents inside SAP or AEM — invoices, POs, HR letters, PDF forms. Not published content or feeds.Website TLS certificates — proves a domain is who it saysTokens and payloads — JWS signatures, JWE encryptionMandates, entitlements, channel feed runs, QA results
AlgorithmsDigital signature certificates from a public CARSA or ECDSA TLS certificatesECDSA P-256/384/521, RSA, HMACEdDSA (Ed25519)
Trust anchorThe signing vendor’s CA — eMudhra, DocuSign, Adobe, or a regional trust providerISRG, trusted by every browserYour Xano instanceYour own published public keys (JWKS)
Who can verifySAP / AEM workflows and recipientsEvery browser, automaticallyYour own APIsAnyone, offline, on this page
CostPer document or envelope, annual contractFreeIncluded in your planNo per-document fee
LifetimeSet by the CA90 days now; 64 days from Feb 2027; 45 days in 2028You set itYou set it; keys rotate, retired keys verify until not_after
SAP / AEM loopInsideNot involvedOutsideOutside

Why self-hosted signing keys add security in-house

  1. Keys never leave your infrastructure. No outside authority can issue a certification in your name, and no vendor outage stops you signing.
  2. Verification requires trusting no one. A partner, auditor, or the SAP team checks a feed or QA result with the public key alone — exactly what the tool above does.
  3. Your policy, in the signature. Expiry, scope, region, and consent claims are sealed into each certificate — not a vendor’s defaults.
  4. Sign everything, not just the expensive documents. With no per-document fee, every feed run and every test check can carry a certificate.
  5. Independent of the SAP timeline. Feed and QA certification keep working through the ECC to S/4HANA migration.

Your organization’s choice

Data governance can stay inside your organization, or be left to external, offshore, or consulting teams who certify the data on your behalf. Both are common; only one keeps the proof with you.

Signed certification does not replace your consulting partners — it gives their sign-off a verifiable record that your organization owns.

ECC to S/4HANA: signed documents and your data

Documents signed in ECC — through emSigner, DocuSign, or AEM Forms — certify the PDF, not the tables being migrated.

Sign the migration itself: a hash of every extract, mock load, and cutover result, sealed with your own key, gives a chain of custody from ECC to S/4HANA that your organization owns.

What it does not replace

SAP and AEM sign documents inside their own loops. CRM Sync certifies every channel feed and QA check outside them — with your own keys, verifiable by anyone, offline.

Let’s Encrypt lifetimes per letsencrypt.org/docs/cert-lifetimes. SAP has no default signing CA: DocuSign is SAP’s global signature-management partner; eMudhra emSigner is common where Indian Class 3 DSCs are required. AEM signs PDF forms through AEM Forms (DocAssurance) or Adobe Acrobat Sign; its TLS and SAML certificates secure connections and logins, not published content. Xano capabilities per Xano’s XanoScript security functions.