Digitale ID zoals het hoort: verifieerbare claims zonder surveillance

Update, 11 feb 2026: Dat ging snel. De leeftijdsverificatie van Discord, aangedreven door k-id en hun partner faceassure, is volledig omzeild. De tool, gebouwd door xyzeva en Dziurwa (met dank aan amplitudes voor eerder werk), laat je account automatisch als volwassen verifiëren op Discord, Twitch, Kick, Snapchat en elk ander platform dat k-id gebruikt. Hoe? Omdat de “gezichtsschatting” van k-id je gezicht volledig op je eigen apparaat verwerkt en alleen metadata naar de server stuurt. Dus je kunt gewoon… nepmetadata sturen. De server kan het verschil niet zien. Dit is geen bug. Het is het onvermijdelijke gevolg van beveiligingstheater bouwen in plaats van echte beveiliging. Als je leeftijd wilt verifiëren zonder een cryptografische vertrouwensketen die in een echte identiteitsprovider wortelt, verifieer je niets. Je voegt alleen wrijving toe waar echte gebruikers een hekel aan hebben en die gemotiveerde omzeilers in een weekend verslaan. Alles hieronder blijft gelden. Lees verder.

Ik ben Australiër. Ik woon in het Verenigd Koninkrijk. Mijn beide regeringen zijn even verantwoordelijk voor de puinhoop die zich nu ontvouwt.

De Online Safety Act van het VK trapte het in juli 2025 af. Elke site met pornografische inhoud moest “zeer effectieve” leeftijdsverificatie invoeren. Dat gold voor een zekere hub die met P begint, een site die gespecialiseerd is in fans, Reddit, het hele rijtje, met boetes tot £18 miljoen of 10% van de wereldwijde omzet bij overtreding.¹ Imgur keek één keer naar de eisen en trok zich helemaal terug uit het VK.² De Online Safety Amendment Act van Australië volgde in december 2025: social media verboden voor kinderen onder de 16, en platforms moeten bewijzen dat ze dat handhaven.³ En het verspreidt zich. Frankrijk keurde in januari 2026 een social-mediaverbod voor kinderen onder de 15 goed.⁴ Spanje kondigde het zijne vandaag aan: onder de 16, met “echte barrières die werken, niet alleen vinkjes.”⁵ Het Deense verbod wordt medio 2026 verwacht. Griekenland werkt aan het zijne. De Digital Services Act van de EU eist al leeftijdsgeschikte bescherming in de hele unie.⁶

Elke grote democratie (op die van de vrijheid na) komt tot dezelfde conclusie: platforms moeten weten hoe oud hun gebruikers zijn. En het instinct klopt. We moeten zich ontwikkelende hersenen beschermen tegen schadelijke inhoud. Het bewijs over de geestelijke gezondheid van tieners en onbegrensde social media is vernietigend, en de status quo waarin 12-jarigen zichzelf met een vinkje volwassen verklaren is al twintig jaar een farce.

Maar dit is het punt. Elke implementatie tot nu toe is ontworpen rond de verkeerde vraag. Overheden vragen “hoe identificeren we mensen?” terwijl ze zouden moeten vragen “hoe verifiëren we claims zonder iemand te identificeren?”

Het resultaat is een wereld waarin leeftijdsverificatie betekent dat je een foto van je paspoort uploadt naar een externe dienst en hoopt dat die niet gehackt wordt. Of dat je gezicht door een AI-model gaat dat je leeftijd raadt aan de hand van je botstructuur, biometrische surveillance onder een andere naam. De aanpak van het VK onder de Online Safety Act zorgde op de eerste dag van de handhaving voor een stijging van het VPN-gebruik met meer dan 1.400%, omdat volwassenen heel redelijk besloten liever hun verkeer via Ierland te sturen dan hun rijbewijs aan een site die gespecialiseerd is in fans te geven.

De overheid moet zich vooral niet met jouw zaken bemoeien. Maar bedrijven moeten erop kunnen vertrouwen dat ze niet aansprakelijk zijn als de leeftijdscheck wordt omzeild. Een 14-jarige met een volle baard kan de gezichtsschatting van nu misschien verslaan. Een geleende creditcard verslaat de betalingscheck. Een VPN verslaat de geoblokkade helemaal.

Dus laten we het uitzoeken: kunnen we dit weer rechtzetten?

Ja.

Je gebruikt het meeste van deze techniek al

Dit maakt de hele situatie zo om gek van te worden: de bouwstenen voor identiteitsverificatie met behoud van privacy zijn geen ver onderzoeksproject. Ze draaien nu op je telefoon… terwijl je dit leest.

Elke keer dat je op een website inlogt en die weet wie je bent zonder opnieuw om je wachtwoord te vragen, is de kans groot dat een JSON Web Token (JWT) het zware werk doet.⁷ Een JWT is gewoon een ondertekende klont informatie. Hij heeft drie delen: een header die zegt hoe hij is gemaakt (ondertekend), een payload vol “claims” (wie en wat voor soort mensenvlees je bent) en een handtekening die bewijst dat er niet aan geknoeid is.

Zo ziet een typische JWT-payload eruit als je bij bijvoorbeeld je bank inlogt:

{
  "sub": "user_38291",
  "name": "Will Hackett",
  "email": "will@example.com",
  "iat": 1706918400
}

Zie je dat sub-veld? Dat is een unieke identifier. Daaraan weet de bank dat jij het bent. En dat is prima voor bankieren, want banken zijn wettelijk verplicht te weten wie je bent. Maar kijk nu wat elk leeftijdsverificatiesysteem doet: ze nemen hetzelfde patroon en proppen je hele identiteit erin, alleen om de vraag “is deze persoon oud genoeg?” te beantwoorden.

Dat is alsof je iemand om een paspoort vraagt omdat je wilt weten of diegene thee of koffie lekker vindt.

Wat als het token er zo uitzag?

{
  "over_16": true,
  "over_18": true,
  "over_21": false,
  "iat": 1706918400
}

Geen sub. Geen naam. Geen e-mailadres. Geen geboortedatum. Alleen de antwoorden op de vragen die ertoe doen, ondertekend door iemand die je vertrouwt. De dienst vraagt “ben je ouder dan 18?” en krijgt een cryptografisch true terug. Hij leert nooit je naam, je verjaardag, je adres of het feit dat je een Australische 30-plusser in Londen bent die nog steeds kaas eet, ondanks wat dat met hem doet.

Dat is het hele concept. De rest van dit artikel gaat over hoe je het echt maakt.

Hoe de handtekeningen werken (zonder wiskundestudie)

Een ondertekend token is nutteloos als je niet kunt nagaan wie het heeft ondertekend. Daar komen JSON Web Key Sets (JWKS) om de hoek kijken.⁸ Het is een deftige naam voor een simpel idee: de ondertekenaar publiceert zijn publieke sleutel op een URL, en iedereen die een ondertekend token ontvangt kan het tegen die sleutel controleren.

{
  "keys": [{
    "kty": "EC",
    "kid": "uk-gov-age-verification-2026",
    "use": "sig",
    "crv": "P-256",
    "x": "f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
    "y": "x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0"
  }]
}

Stel je voor dat de Britse overheid er zo een publiceert op gov.uk/.well-known/jwks.json. Als een site die gespecialiseerd is in fans nu een leeftijdsverificatietoken ontvangt dat zegt dat jij ouder bent dan 18, hoeft hij jou niet te geloven. Hij hoeft de overheid niet te bellen. Hij haalt de publieke sleutel op, controleert de handtekening, en de wiskunde klopt of ze klopt niet. Niet terugbellen. Geen API-call. Geen “ik vraag het even na bij HMRC (de belastingdienst).” De publieke sleutel is publiek. De handtekening is wiskunde. Klaar.

Zo werkt elke OAuth-login al. Als je op “Inloggen met Google” klikt, belt de site waar je op inlogt Google niet om te vragen of je token klopt. Hij pakt Googles gepubliceerde JWKS en controleert de handtekening lokaal.

Dit doen we al meer dan tien jaar. De infrastructuur staat er letterlijk te verpieteren.

Wacht maar even, ongeduldige… we komen zo bij het privacygedeelte.

Maar wat als we maar een deel van het token laten zien?

Gewone JWT’s hebben een probleem: de handtekening dekt de hele payload. Je kunt de velden die je niet wilt delen er niet uit halen zonder de handtekening te breken. Als de overheid een token ondertekent met je leeftijdscategorieën, de hash van je naam en je biometrische sjabloon, moet je het geheel laten zien of niets.

Dan komen Selective Disclosure JWT’s (SD-JWT’s) om de hoek.⁹ Het idee is prachtig simpel. De uitgever ondertekent het volledige credential, maar elke claim krijgt een eigen disclosure. De houder, dat ben jij, op je telefoon, kiest welke claims je onthult. De rest blijft verborgen, maar de handtekening blijft kloppen.

De overheid geeft jou dit uit:

{
  "iss": "https://identity.gov.uk",
  "iat": 1706918400,
  "over_13": true,
  "over_16": true,
  "over_18": true,
  "over_21": false,
  "name_hash": "sha256:a1b2c3d4...",
  "biometric_template": "...",
  "nationality": "AU"
}

Maar als de site die gespecialiseerd is in fans om leeftijdsverificatie vraagt, toont je apparaat alleen dit:

{
  "iss": "https://identity.gov.uk",
  "iat": 1706918400,
  "over_18": true
}

De handtekening klopt nog steeds. De site krijgt zijn antwoord. En hij leert nooit je naam, je nationaliteit of het ronduit gênante feit dat je nog geen 21 bent in welk rechtsgebied dat ook maar nog uitmaakt.

W3C Verifiable Credentials gaan nog een stap verder met zero-knowledge proofs, cryptografische methoden waarmee je kunt bewijzen dat een bewering waar is zonder de onderliggende gegevens te onthullen.¹⁰ “Is deze persoon ouder dan 18?” is dan geen gegevensverstrekking meer maar een wiskundig bewijs. De site ontvangt geen "over_18": true. Hij ontvangt een bewijs dat de bewering klopt, zonder gegevens erbij.

Het is alsof een uitsmijter je leeftijd kan controleren door naar een verzegelde envelop te kijken zonder hem open te maken. Cryptografen zijn vreemde en prachtige mensen.

Hoe dit op je telefoon zou moeten werken

Goed, laten we alles bij elkaar leggen. Ik beloof dat dit minder ingewikkeld is dan het huidige proces: een selfie uploaden met je paspoort in je hand, naar een externe verificatiedienst die volgend jaar misschien wordt overgenomen door een bedrijf waar je nog nooit van hebt gehoord.

Stap 1: Haal je credential op (eenmalig). Je apparaat biedt een framework voor het beheren van verifieerbare claims. Je authenticeert één keer bij de identiteitsprovider van je overheid, op het apparaat zelf. In Estland is dat je eID. In de EU is dat eind 2026 je EUDI Wallet.¹¹ In het VK zou het GOV.UK One Login kunnen zijn, of wat die uiteindelijk ook vervangt. De IdP van de overheid geeft een verifieerbaar credential uit aan je apparaat: leeftijdscategorieën, naamhash, biometrisch sjabloon, ondertekend met de sleutel van de overheid en te controleren tegen hun gepubliceerde JWKS-endpoint.

Het leeft in de secure enclave van je apparaat. Je doet dit één keer. Daarna vergeet je het.

Stap 2: Het platform verpakt het. Je platformleverancier (Apple, Google) treedt op als proxy-uitgever. Die neemt het door de overheid ondertekende credential en geeft het opnieuw uit met een dubbele handtekening: de oorspronkelijke van de overheid plus de eigen van het platform. Een verifiërende dienst kan nu twee dingen bevestigen: de claim komt van een echte IdP van de overheid, en wordt getoond via een legitiem platform. Cruciaal is dat noch de overheid noch het platform leert aan welke dienst je het toont. De overheid ziet “Apple vroeg een credential aan.” Apple ziet “er is een credential opgeslagen.”

Geen van beiden ziet “Will probeert om 2 uur ‘s nachts op een dinsdag een site te openen die gespecialiseerd is in fans.” Wat belangrijk is. Niet voor mij persoonlijk… maar in het algemeen.

Stap 3: Beantwoord vragen, geen dataverzoeken. Als een dienst een claim moet verifiëren, ziet de uitwisseling er zo uit:

Fans specialist → Your device: "Is this user over 18?"
Your device → Secure Enclave: [biometric check, signature generation]
Your device → Fans specialist: { "over_18": true, "sig": "..." }

“Fans specialist” is in dit geval… de dienst die je probeert te openen…

De dienst stelt een vraag. Je apparaat beantwoordt die. De dienst krijgt een cryptografisch ja of nee. Niets meer. Niet “wat is je geboortedatum?” maar “ben je ouder dan 18?” Niet “wat is je naam?” maar “komt deze SHA-256-hash overeen?” Niet “laat je gezicht zien” maar “slaagt de biometrische check op het apparaat?”

Voor naamverificatie stuurt een dienst een hash, de SHA-256 van voor-, tweede en achternaam, en het credential geeft terug of die overeenkomt. De dienst ziet je echte naam nooit. Voor fotoverificatie bevat het credential een biometrisch sjabloon (een wiskundige weergave, geen foto). De controle draait lokaal op je apparaat. Het resultaat, match of geen match, wordt ondertekend en teruggestuurd. De biometrische gegevens verlaten je apparaat nooit. Nooit.

Estland had de architectuur goed. Jammer van de reikwijdte.

Ik heb eerder over het digitale identiteitssysteem van Estland geschreven.¹² Ze draaien al sinds 2002 nationale eID’s, met X-Road als interoperabiliteitsruggengraat die meer dan 450 organisaties verbindt.¹³ Elke burger boven de 15 heeft een digitale identiteit. 99% van de overheidsdiensten is online. Het systeem bespaart naar schatting 2% van het bbp per jaar.¹⁴ Het is echt indrukwekkend. Als je je ooit slecht wilt voelen over GOV.UK, besteed dan een middag aan lezen over hoe Esten hun belastingaangifte doen.

Maar het systeem van Estland is een gesloten ecosysteem. Het werkt briljant voor Estse diensten, zoals overheid, bankieren, gezondheidszorg en belasting, omdat de hele stack Ests is. Je kunt je Estse eID niet gebruiken om je leeftijd op Instagram te verifiëren, en Instagram heeft absoluut geen reden om voor een land van 1,3 miljoen mensen te integreren met Estlands X-Road. Terecht.

De Digital Identity Wallet van de EU, verplicht gesteld onder eIDAS 2.0 voor uitrol eind 2026, moet die kloof overbruggen.¹⁵ Elke lidstaat moet minstens één EUDI Wallet aanbieden. Zeer grote online platforms moeten hem accepteren voor sterke authenticatie. De wallet gebruikt W3C verifiable credentials met selective disclosure ingebouwd.¹⁶ Dat komt dichter bij het juiste model. Maar het positioneert de wallet nog steeds als identiteitstool in plaats van claimstool. De verschuiving die nodig is, is die van “bewijs wie je bent” naar “beantwoord deze specifieke vraag.” Het lijkt een klein verschil, maar het is het hele spel.

Apple en Google zijn er voor 90% al

Dit is niet alleen een probleem van overheden. De platformleveranciers moeten de integratielaag bouwen, en het goede nieuws is dat ze het meeste ervan al min of meer per ongeluk gebouwd hebben.

Apple beheert de Secure Enclave, een hardwarematig geïsoleerde processor die speciaal is ontworpen voor cryptografische bewerkingen en biometrische gegevens.¹⁷ Passkeys, gebouwd op de FIDO2/WebAuthn-standaard, gebruiken exact deze infrastructuur al voor wachtwoordloze authenticatie.¹⁸ De privésleutel verlaat het apparaat nooit. Biometrische verificatie gebeurt lokaal. De server ziet alleen een cryptografisch bewijs. Klinkt bekend? Het is hetzelfde patroon.

Dit uitbreiden naar verifieerbare claims is architectonisch eenvoudig. Apple levert een framework. Je authenticeert via dat framework bij de IdP van je overheid. Het credential wordt opgeslagen in de Secure Enclave naast je passkeys. Als een dienst een claim opvraagt, is de flow identiek aan een passkey-authenticatie: biometrische check op het apparaat, cryptografisch bewijs naar de server. De dienst weet dat de claim geldig is. Hij weet niet wie je bent. Android heeft gelijkwaardige mogelijkheden met StrongBox en de Trusted Execution Environment.

Browserleveranciers moeten WebAuthn uitbreiden of een parallelle standaard maken voor claimverificatie. Een website moet een geverifieerde claim net zo makkelijk kunnen opvragen als een passkey. Hetzelfde API-patroon. Dezelfde UX. Hetzelfde beveiligingsmodel. De leidingen liggen er. Iemand moet ze alleen nog aansluiten. Gezien het feit dat Apple, Google en de FIDO Alliance al hebben bewezen dat ze kunnen samenwerken aan passkeys, zelf al een klein wonder van bedrijfssamenwerking, is dit niet zo vergezocht als het klinkt.

Wat niemand te zien krijgt

Ik wil specifiek zijn over de privacygaranties, want dit is het punt waar de meeste voorstellen voor digitale ID stranden en mensen terecht gaan mompelen over surveillancestaten.

Je overheid leert nooit welke diensten je gebruikt. De platformleverancier stuurt verzoeken met zijn eigen sleutels via een proxy naar de IdP van de overheid. De overheid ziet “Apple vroeg een credential aan.” Ze ziet niet “Will bezocht een site die gespecialiseerd is in fans.” Dat is belangrijk.

Diensten zien je gegevens niet. Ze ontvangen cryptografische antwoorden op specifieke vragen. Niet je naam. Niet je geboortedatum. Niet je foto. Een ondertekend ja of nee van een vertrouwde uitgeversketen. Dat is alles.

Standaard geen unieke identifiers. Het credential bevat claims, geen identifiers. Er is geen gebruikers-ID waarmee diensten je over platforms heen kunnen koppelen. Je bent een verzameling geverifieerde feiten, geen traceerbare entiteit. Je kunt op vijftig verschillende sites bewijzen dat je ouder bent dan 18 en geen enkele kan zien dat het dezelfde persoon is. Probeer dat maar eens met een paspoortupload.

Voor diensten die je echt moeten identificeren, zoals banken, opsporingsdiensten en gereguleerde sectoren, ondersteunt het systeem een speciale klasse credential met een door de overheid uitgegeven identifier. Maar die identifier kan alleen worden herleid als zowel de platformleverancier als de overheid meewerkt, via een key-splitting-mechanisme dat beide partijen vereist. Eén sleutel alleen is nutteloos. Dat maakt massasurveillance structureel onmogelijk en houdt legitieme identificatie voor gereguleerd gebruik mogelijk. Het is het cryptografische equivalent van twee sleutels die je nodig hebt om een kernraket te lanceren, behalve dat je in plaats van de wereld te beëindigen iemands identiteit verifieert voor een hypotheekaanvraag. Veel minder dramatisch. Dezelfde wiskunde.

Alles gebeurt op het apparaat. Verifier-sleutels verlaten de secure enclave nooit. Geen centrale server verwerkt je biometrie. Geen clouddienst ziet je overheidscredentials. Het bewijs wordt lokaal gegenereerd en naar de dienst gestuurd. Er beweegt verder niets.

Wat er moet gebeuren

De techniek is klaar. De standaarden bestaan. De hardware staat op miljarden apparaten. Wat ontbreekt is de wil om te coördineren, en aangezien het hier gaat om overheden, platformleveranciers en standaardisatie-instanties, zou dat maar… laten we optimistisch zijn en zeggen vijf jaar duren… of honderd in het VK.

Overheden moeten sleutels voor hun identiteitsproviders publiceren en verifieerbare credentials uitgeven die selective disclosure ondersteunen. Estland heeft het zware werk al gedaan. De EU verplicht wallets in 2026. Het VK onderzoekt digitale ID. Australië probeert… nou ja, Australië probeert uit te vogelen hoe het 14-jarigen kan beletten TikTok-accounts aan te maken, en dat zou baat kunnen hebben bij een fatsoenlijk leeftijdsverificatiesysteem in plaats van alleen platforms met boetes dreigen. De infrastructuurtoezeggingen zijn onderweg. Iemand moet ze alleen met elkaar laten praten.

Platformleveranciers moeten de frameworklaag bouwen: credentialbeheer op het apparaat, proxy-uitgifte, integratie met de secure enclave voor claimverificatie. Apple en Google zijn er voor 90% met passkeys. De resterende 10% is dezelfde architectuur uitbreiden naar verifieerbare claims. Aangezien beide bedrijven maar wat graag de poortwachter van je digitale identiteit zouden zijn (en een bescheiden vergoeding voor dat privilege zouden rekenen), vermoed ik dat de zakelijke prikkel er is.

Browserleveranciers moeten WebAuthn uitbreiden of een parallelle standaard maken voor claimverificatie. Een website moet een geverifieerde claim net zo makkelijk kunnen opvragen als een passkey-authenticatie. Hetzelfde API-patroon. Dezelfde UX. Hetzelfde beveiligingsmodel.

En diensten moeten stoppen met documenten vragen en vragen gaan stellen. “Is deze gebruiker ouder dan 16?” is een ja/nee-vraag. Daar hoort geen paspoort voor nodig te zijn. Geen selfie. Geen foto van je rijbewijs naar een bedrijf met hoofdkantoor in een rechtsgebied dat je niet kunt spellen. Het vraagt om één ondertekende boolean, geverifieerd tegen een gepubliceerde publieke sleutel.

We hebben twintig jaar identiteitssystemen gebouwd die surveillance als feature behandelen. Het wordt tijd er een te bouwen die privacy als architectuur behandelt.

De volgende keer dat iemand je vraagt je paspoort te uploaden om te bewijzen dat je oud genoeg bent om naar memes te kijken, bedenk dan: de techniek om dit goed te doen bestaat al. Hij is een decennium beproefd. Hij draait nu op je telefoon. Het enige wat ons tegenhoudt is hetzelfde wat de meeste goede ideeën in de techniek tegenhoudt: drie groepen mensen die elkaar niet bijzonder mogen zover krijgen dat ze het eens worden over een standaard.

Dus eigenlijk, elke dag nu…

UK Online Safety Act 2023 ↩
The Register: Imgur exits the UK as parent company faces fine, blokkeerde alle Britse gebruikers vanaf 30 september 2025 in plaats van te voldoen aan de leeftijdsverificatie-eisen van de Online Safety Act ↩
Australian Government eSafety Commissioner: Social Media Age Restrictions ↩
Al Jazeera: French MPs approve law seeking ban on social media for children below 15, in januari 2026 goedgekeurd met 116 stemmen tegen 23 ↩
Euronews: Spain to ban social media platforms for children under 16, aangekondigd op 3 februari 2026 op de World Government Summit ↩
European Commission: The Digital Services Act ↩
IETF RFC 7519: JSON Web Token (JWT) ↩
IETF RFC 7517: JSON Web Key (JWK) ↩
IETF: SD-JWT-based Verifiable Credentials (SD-JWT VC) ↩
W3C: Verifiable Credentials Data Model v2.0 ↩
European Commission: European Digital Identity, verplicht EUDI Wallets voor alle lidstaten eind 2026 ↩
Will Hackett: Reclaiming the commons: the case for an accountable internet ↩
e-Estonia: X-Road interoperability platform, verbindt meer dan 450 organisaties via open-source, gedecentraliseerde gegevensuitwisseling ↩
University of Liverpool: As the UK plans to introduce digital IDs, what can it learn from pioneer Estonia? ↩
eIDAS 2.0 Regulation (EU) 2024/1183, in mei 2024 in werking getreden, wallets uiterlijk eind 2026 ↩
W3C: Verifiable Credentials Implementation Guidelines: Selective Disclosure and Zero-Knowledge Proofs ↩
Apple: About the security of passkeys, passkeys gebruiken de Secure Enclave voor sleutelgeneratie en biometrische verificatie ↩
FIDO Alliance: Passkeys, FIDO2/WebAuthn-standaard voor wachtwoordloze authenticatie ↩