Skip to content
AutomotiveMCP

Prove what a shopper consented to. Portably.

One party captures consent. The next party in the chain is about to contact the same person, on a consent it never captured. This is how it verifies that consent before it sends, with evidence instead of an assumption.

This is the one differentiator that is real and demoable today, not a roadmap promise. It runs entirely in your browser: the cryptography below is genuine ES256 via the Web Crypto API. There is no server and no network call. If it verifies here, the mechanism works.

Livereal ES256 in your browser · no server

The capturing party (a CRM) issues a signed consent receipt for one SMS marketing consent, bound to the relying party (a scheduler). The relying party verifies it before it is allowed to send. Break a guarantee and watch the check that catches it.

    Outcomerunning…

    What each step is doing

    • A signed receipt, not a flag. The capturing party issues a JSON Web Signature over the consent claims. A relying party can verify who issued it and that nothing was changed, without calling the capturing party at all.
    • Audience binding. The receipt names exactly one relying party in aud. A receipt issued to one business cannot be presented by another. This is what keeps a portable consent from becoming a tradeable one.
    • The disclosure is load-bearing. The receipt carries the SHA-256 of the verbatim text the person was actually shown. Change one character of that text and the hash no longer matches.
    • Revocation is checked, not assumed. A signature proves a receipt was issued; it cannot prove the consent still stands. For marketing, the relying party MUST check current status before it sends, and a STOP reply blocks the send.

    Run it yourself

    The same flow runs headless against the reference server. Start the server and point the reference client at it:

    # terminal A
    node packages/reference-server/server.mjs
    
    # terminal B
    node packages/reference-client/client.mjs

    The reference server issues receipts via the consent.issue_receipt tool, publishes its JWK Set at /.well-known/consent-jwks.json, and serves a PII-free status endpoint, exactly as the spec requires.

    The full normative definition is in Specification §9, Consent Portability. It is written domain-neutral on purpose: the problem is not specific to retail automotive, and neither is the format.