PrismPass Ecosysteem — Anoniem Notificatiekanaal

Meldingen ontvangen
zonder naam of e-mailadres

Je bent ingelogd op een breiforum. Iemand reageert op je bericht. Je krijgt een melding. Het forum heeft nooit geweten wie je bent. Gebouwd op echte Privacy Pass cryptografie — RFC 9576/9578, dezelfde standaard als Cloudflare en Apple.

Hoe het werkt

Jouw apparaat genereert een blind token request — de issuer ondertekent het zonder de inhoud te zien. Na finalisatie heb je een geldig, anoniem bezorgtoken. De site stuurt notificaties naar dat token. Jij ontvangt ze. De site weet niet wie je bent.

Stap 1
Sessie geldig WebAuthn + ZKP + wearable. Server weet: echte gebruiker. Niet: wie.
Stap 2 — RFC 9578
Blind token request Apparaat blindt de nonce. Issuer ondertekent zonder inhoud te zien.
Stap 3 — RFC 9576
Token finaliseren Apparaat unblind het antwoord. Geldig, unlinkable delivery token.
Stap 4
Registreer bij forum Forum ontvangt token. Weet: stuur hier notificaties naartoe. Niet: van wie.
Stap 5
Bericht ontvangen Notificatie bezorgd op apparaat via token. Geen e-mail. Geen naam.

Authenticatie vergeleken

Wat weet de server over jou bij elke loginmethode?

Criterium Wachtwoord OAuth (Google/Facebook) PrismPass
Server slaat op ✗ Wachtwoord-hash + e-mail ✗ OAuth-token + profiel-ID ✓ Alleen commitment (wiskundig bewijs)
Herleidbaar naar persoon ✗ Ja — direct via e-mail ✗ Ja — via identity provider ✓ Nee — ZKP bewijst zonder te onthullen
Relay-aanval mogelijk ✗ Ja — gestolen token herbruikbaar ✗ Ja — token geldig tot expiry ✓ Nee — nonce eenmalig, tijdgebonden
Datalek risico ✗ Hoog — centrale database met credentials ✗ Middel — provider kent alle logins ✓ Minimaal — niets bruikbaars opgeslagen
Derde partij betrokken Nee ✗ Ja — Google/Facebook volgt je logins ✓ Nee — volledig gedecentraliseerd
GDPR-risico ✗ Hoog — persoonsdata in database ✗ Hoog — datadeling met provider ✓ Minimaal — by design geen persoonsdata

Vergelijking notificatiekanalen

Scenario Huidig systeem PrismPass notificatiekanaal
Forumreactie Forum stuurt naar e-mailadres — weet wie je bent ✓ Stuurt naar token — weet niet wie
Bestelbevestiging Webshop kent naam, adres, e-mail ✓ Webshop stuurt naar token — geen profiel
Geverifieerde ontvanger ✓ E-mail bevestigd ✓ ZKP bewijst echte gebruiker achter token
Tokens koppelbaar ✗ E-mail = identiteit ✓ Unlinkable — RFC 9576 §3.1
Wegwerp-email ✗ Geen echte gebruiker — spam-risico ✓ ZKP-bewijs van echtheid — geen misbruik
Werkende demo — Echte Privacy Pass cryptografie RFC 9576/9578 · @cloudflare/privacypass-ts
1
2
3
4
5
Stap 1: Publieke sleutel ophalen van issuer
Jouw apparaat (client)

Stap 1 — Haal issuer publieke sleutel op:

— wacht —

Stap 2 — Maak blind token request:

— wacht op sleutel —

Stap 3 — Finaliseer token (unblind):

— wacht op response —

Stap 4 — Registreer bij forum:

— wacht op token —
Server / Forum (ziet dit)

Issuer ziet bij blind signing:

— wacht —

Forum ziet bij registratie:

— wacht —

Server ziet NOOIT:

✗ Naam   ✗ E-mailadres   ✗ Wie dit is   ✗ Nonce-inhoud bij signing

Unlinkability check:

Breiforum — Jouw bericht Anoniem ingelogd — notificaties actief

"Heeft iemand ervaring met Drops Alpaca yarn? Ik brij momenteel een trui en vraag me af of het kriebelvrij is."

Cryptografisch log — wat er werkelijk gebeurt
--:--INFOKlik "Haal publieke sleutel op" om te beginnen

Technische basis — wat hier echt gebeurt

Dit is geen simulatie. De browser voert echte VOPRF cryptografie uit via @cloudflare/privacypass-ts v0.8.1 — dezelfde library die Cloudflare in productie gebruikt. Het blind signing protocol (RFC 9578) zorgt ervoor dat de issuer de nonce nooit ziet tijdens het ondertekenen. De unlinkability-garantie (RFC 9576 §3.1) is cryptografisch — niet beleidsmatig. Twee tokens van dezelfde gebruiker zijn wiskundig niet te koppelen, zelfs niet door de issuer zelf.

Verdieping — Technisch / Bewijs