Waarom we eID toevoegen: de brug naar privacy-first leeftijdsverificatie die u vandaag al kunt gebruiken

We begonnen met de wallet. Dit is waarom we nu de bank toevoegen.

Als u deze blog al langer volgt, kent u onze stelling: de EU Digital Identity Wallet verandert leeftijds- en identiteitsverificatie van een gegevensverzamelexercitie in één enkele cryptografische vraag - is deze persoon ouder dan 18? - beantwoord met ja of nee, zonder geboortedatum, zonder document en zonder dat er een naam van eigenaar wisselt.

Daar geloven we nog steeds in. Dat is de bestemming.

Maar er zit een kloof tussen die bestemming en vandaag, en die kloof heeft een datum. De regels die handelaren verplichten om leeftijd te verifiëren, komen nu eraan. Productieklare EU Digital Identity Wallets, in genoeg handen om tegen te verifiëren, zijn er nog niet - het realistische venster ligt tussen eind 2026 en 2027. Een verifier die alleen "wallet" spreekt, heeft dit jaar niets om mee te praten.

Daarom voegen we eID toe - de bank- en nationale elektronische identiteiten die honderden miljoenen Europeanen al bezitten en vertrouwen. Niet als omweg ten opzichte van de wallet. Als brug ernaartoe. Dit artikel legt de kloof uit, waarom eID daar zo precies op aansluit, het gelaagde model dat we eromheen bouwen, en waarom dit geen zijweg is.

De kloof: verplichtingen nu, wallets later

Kijk naar wat er de afgelopen maanden al is gebeurd:

• Nederland beweegt richting verplichte online leeftijdsverificatie voor alcohol, terwijl de compliance vandaag wordt geschat op slechts een kwart van de webshops - een regulatoir traject dat open ligt en grotendeels onbediend is.
• Google Play vereist sinds 28 januari 2026 dat datingapps opgegeven minderjarigen beperken, onderdeel van een bredere golf van kinderveiligheidsmaatregelen bij de app stores.
• De Digital Services Act en een CJEU-uitspraak van juni 2026 duwen platforms voor volwassenen richting echte leeftijdsborging, geen vinkje.
• De Commissie promoot een witgelabelde EU-leeftijdsverificatie-app voor eind 2026 - terwijl lidstaten openlijk van mening verschillen over hoeveel wallets en apps er uiteindelijk zullen zijn.

Elk van deze verplichtingen is al actief of staat op het punt van ingaan. En elk daarvan komt neer op handelaren die niet kunnen wachten op een wallet-uitrol die in de praktijk nog altijd een gebeurtenis van 2027 is. Als uw enige antwoord op "hoe verifieer ik leeftijd?" luidt: "wacht op de EUDI Wallet", dan vraagt u een webshop die dit kwartaal alcohol verkoopt om de wet te overtreden totdat de infrastructuur is bijgebeend.

Dat is geen echt antwoord. eID wel.

eID is de live brug - en werkt al zoals de wallet zal werken

Bank-eID en nationale eID zijn geen noodoplossing. Het zijn de identiteitsrails waarop een groot deel van Europa al draait:

• iDIN in Nederland - leeftijdsbevestiging via uw eigen banklogin, hetzelfde gebaar als bij een iDEAL-betaling.
• itsme in België - gebruikt door de overgrote meerderheid van de Belgische volwassenen (en, niet onbelangrijk, itsme bezit iDIN, waardoor één samenwerking beide markten bereikt).
• BankID, MitID, Smart-ID, Freja in de Scandinavische en Baltische landen, waar eID-adoptie bijna universeel is.

Het cruciale punt is niet alleen dat deze bestaan. Het is dat een goed ontworpen eID-leeftijdscontrole zich al gedraagt zoals de wallet dat zal doen. Wanneer een handelaar iDIN of itsme vraagt "is deze persoon 18 jaar of ouder?", kan het schema één enkel antwoord teruggeven. De gebruiker authenticeert met een identiteit die hij al bezit, uitgegeven door een verstrekker die een toezichthouder al vertrouwt, en uw platform komt nooit in aanraking met een ID-scan of een biometrische database.

Met andere woorden: eID levert de kernbelofte van de wallet al - selectieve openbaarmaking, overheidsniveau vertrouwen, geen documentverwerking - met infrastructuur die vandaag al in productie draait. De wallet zal dit tot standaard maken in alle 27 lidstaten. eID maakt het deze maand al beschikbaar in uw checkout.

Het echte product: gelaagde verificatie, in de juiste volgorde

eID toevoegen is niet zomaar "nog een integratie". Het is de eerste en belangrijkste laag van het model waar we het hele platform omheen bouwen. We noemen het gelaagde verificatie, en de volgorde is precies het punt:

Laag 1 - eID eerst, altijd. Het privacy-optimale pad, en de enige laag die standaard aanstaat. Een bank- of nationale eID geeft een geverifieerd resultaat zonder document, zonder selfie en met minimale gegevens. De meeste van uw gebruikers in Benelux en Scandinavië kunnen dit in enkele seconden afronden met een identiteit die ze wekelijks gebruiken.

Laag 2 - leeftijdsschatting, optioneel. Voor de gebruiker zonder eID - een nieuwe inwoner, een buitenlandse bezoeker - kunt u desgewenst privacybeschermende gezichtsleeftijdsschatting inschakelen (het soort dat de leeftijd schat op basis van een selfie zonder de persoon te identificeren en de afbeelding onmiddellijk verwijdert). Dit is leeftijdsborging, geen identificatie, en verwerkt bij correcte uitvoering geen bijzondere categorieën identiteitsgegevens. Het is een elegante terugvaloptie - maar een die u bewust inschakelt, niet een standaardinstelling.

Laag 3 - documentscan, optioneel en als laatste. De optie met de meeste gegevens, de meeste wrijving en de hoogste AVG-blootstelling. Als u deze al inschakelt, staat ze achter de eerste twee, als laatste redmiddel.

De lagen die u inschakelt, zijn een handelaarsbeleid, en de standaardinstelling is streng. Elke terugvaloptie is opt-in (allowAgeEstimation, allowDocumentFallback - beide uit tenzij u ze inschakelt). En de flow is fail-closed: als een gebruiker geen enkele laag kan doorlopen die u heeft toegestaan, wordt de verificatie geweigerd - het systeem schakelt niet stilzwijgend over naar een indringendere methode om alsnog een resultaat af te dwingen. Een handelaar die beide terugvalopties uitgeschakeld laat, draait een aantoonbaar eID-only flow die zelfs in principe geen document of biometrisch gegeven kan verzamelen. Dat is het schoonste verhaal over gegevensminimalisatie dat u aan een toezichthouder kunt voorleggen: niet "we verwijderen de gegevens snel", maar "we hebben nooit de mogelijkheid gehad om ze te verzamelen."

De afweging is eerlijk en ligt bij u: een strenger beleid blokkeert het kleine aandeel gebruikers zonder eID, in ruil voor een kleiner gegevensoppervlak. Dat is een beslissing die u per markt en per verticale vastlegt - en omdat ze expliciet en gelogd is, is ze verdedigbaar.

Vrijwel elke gevestigde speler draait deze stack op zijn kop: eerst documentupload, omdat dat is wat ze gebouwd hebben. Die ene omkering - plus het feit dat de indringende lagen iets zijn waar u bewust voor kiest in plaats van iets waar u zich uit moet opt-en - is het verschil tussen een verificatieflow die standaard identiteitsgegevens lekt en een die ze standaard beschermt. eID vooraan zetten, en al het overige achter een schakelaar, is geen functie. Het is de privacyarchitectuur.

Het privacycontract: alleen om het antwoord vragen

Hier moeten we precies zijn, want dit is waar de meeste "privacy-first"-claims stilletjes uit elkaar vallen.

De beste eID-schema's geven ons nooit een geboortedatum. Voor leeftijdsverificatie vragen we het leeftijdsattribuut zelf op, niet de identiteit erachter. iDIN deelt, met toestemming van de klant, eenmalig of deze klant ouder is dan 18 of niet - zonder dat de webshop de exacte geboortedatum hoeft te ontvangen. De Qualify-dienst van itsme bevestigt drempels zoals 16+, 18+, 21+ of 30+ zonder de geboortedatum of een identiteitsdocument bloot te leggen. In beide gevallen wordt het antwoord aan de bron berekend - de bank, of itsme - en wat naar ons wordt doorgestuurd, is een ondertekende ja of nee. Er is niets voor ons om weg te gooien, omdat we het nooit ontvangen.

Dat is de standaard waar we schema voor schema naartoe bouwen. Maar niet elke eID biedt een kant-en-klare leeftijdsvlag; sommige kunnen alleen een geverifieerde geboortedatum teruggeven. Alleen in dat terugvalgeval passeert een geboortedatum überhaupt onze dienst - en daar geldt het contract van afleiden en weggooien: de ene boolean berekenen die de handelaar nodig heeft (age_over_18, of welke drempel dan ook), dat teruggeven, en de geboortedatum nooit bewaren. In beide gevallen bewaart de handelaar een ja/nee en een tijdstempel - nooit de onderliggende identiteit.

Wees duidelijk over onze eigen rol in het midden. eIDAS Pro bewaart geen persoonlijke of gevoelige gegevens van uw klanten. Waar een schema alleen een boolean teruggeeft, bezitten wij om te beginnen niets anders. Waar een geboortedatum wél moet doorstromen, leeft die alleen in het geheugen voor het moment dat nodig is om het antwoord te berekenen - nooit weggeschreven naar een database, een log, of een back-up (onze logging strip identiteitsvelden by design). We bewaren geen namen, geen geboortedata, geen documentafbeeldingen, geen biometrische gegevens. Wat overblijft, is een minimaal, niet-identificerend verificatierecord - het resultaat en een tijdstempel - zodat u kunt aantonen dat de controle heeft plaatsgevonden. De sterkste gegevens die u nooit kunt lekken, zijn de gegevens die u ervoor koos nooit te bewaren.

En uw optionele terugvalopties veranderen daar niets aan. Wanneer u leeftijdsschatting of een documentcontrole inschakelt, wordt de selfie of het ID vastgelegd door de eigen SDK van die gespecialiseerde aanbieder en rechtstreeks naar hen verzonden - het passeert onze servers niet, en rust er ook niet op. Wij ontvangen alleen de uitkomst (een leeftijdsschatting, of een geslaagd/niet-geslaagd), nooit de afbeelding. Zelfs de meer gegevensintensieve lagen laten dus geen biometrische of documentgegevens bij ons achter.

We zijn ook eerlijk over de grens van wat vandaag mogelijk is. Voor de EU Digital Identity Wallet - de bestemming - hangt een volledig gestandaardiseerd, geboortedatumvrij bewijs nog altijd af van het age_over_18-attribuut, dat optioneel blijft in de huidige wallet-rulebooks, of van een zero-knowledge proof die op het eigen apparaat van de gebruiker wordt gegenereerd. Die zaken rijpen nog. Maar de privacy-eigenschap die ze beloven - bewijs de drempel, onthul verder niets - is er een die de beste eID-schema's vandaag al leveren. Precies daarom is eID de juiste brug: geen privacycompromis dat u tolereert tot de wallet er is, maar het eigen privacymodel van de wallet, nu al beschikbaar.

Waarom dit dezelfde weg is, geen omweg

De terechte vraag: als de wallet de bestemming is, is eID dan een afleiding die we in 2027 weggooien?

Nee - om drie concrete redenen.

Hetzelfde privacycontract, dezelfde API. Het gelaagde model, de boolean-out-interface, de regel van afleiden en weggooien - deze veranderen niet wanneer de wallet arriveert. De wallet wordt gewoon een nieuwe bron achter dezelfde verificatieoproep. Een handelaar die eID vandaag bij ons integreert, behoudt zijn integratie wanneer we het walletpad activeren.

eID is een certificeringsonafhankelijk traject. Het relying-party-pad van de EU Digital Identity Wallet hangt af van registratiecertificaten (WRPAC) die nog geen enkele lidstaat volledig operationeel heeft gemaakt. Bank-eID heeft niets van die machinerie nodig om een handelaar vandaag al te bedienen. Het stelt ons - en u - in staat om nu al omzet en echte compliance op te bouwen, zonder te wachten op een certificeringspijplijn die nog wordt opgezet.

eID is ook de oprit naar het privacy-eindstation. De identiteit die een gebruiker eenmalig bewijst via zijn bank, kan, in de architectuur die we onderzoeken, een houdbare credential zaaien op zijn eigen apparaat - waarna zero-knowledge-leeftijdsbewijzen ervoor zorgen dat de geboortedatum de telefoon nooit meer verlaat. Dat pad van eigen wallet en ZKP is echte R&D, geen leveringsbelofte. Maar het begint exact waar eID begint. De brug en de bestemming zijn dezelfde weg.

Waarom Benelux eerst

We richten ons hier eerst op Nederland en België, en de logica daarachter is bewust:

• Nederland heeft een wetgeving-gedreven, grotendeels onbediende behoefte (online alcohol) en met iDIN een schone, zelfbedienende eID-rail.
• België heeft itsme met bijna universele adoptie onder volwassenen - en omdat itsme iDIN bezit, bereikt één samenwerking beide markten.
• De Scandinavische Shopify-niche is al goed gedekt door bestaande spelers; Benelux is het open traject waar het privacy-first, gelaagde model werkelijk onderscheidend is.

Duitsland en de door de KJM gereguleerde verticalen (volwassenen, kansspelen) vormen bewust een tweede golf. Begin waar de behoefte scherp is, de rails schoon zijn, en de regelgeving beloont dat u het goed doet.

Wat dit voor u betekent

Als u een Europese handelaar of platform bent die dit jaar te maken krijgt met een leeftijdsverificatieverplichting, is de boodschap simpel: u hoeft niet te wachten op de wallet, en u hoeft ondertussen geen concessies te doen aan privacy.

• U kunt vandaag al leeftijd verifiëren via de eID die uw klanten al vertrouwen.
• U kunt het privacy-first, op uw eigen voorwaarden doen - eID standaard (een ja/nee rechtstreeks van de bank of itsme, geen geboortedatum in zicht), schatting en documentterugval opt-in per markt, fail-closed wanneer een gebruiker geen toegestane laag kan doorlopen, en in beide gevallen geen identiteitsgegevens bij ons opgeslagen.
• En u kunt het doen zonder uw integratie vast te laten lopen, want de wallet sluit, wanneer die er is, aan op dezelfde flow.

Daarom voegen we eID toe. Niet omdat we van mening zijn veranderd over de wallet - maar omdat we de brug hebben gevonden die u daar brengt zonder uw compliance, of de privacy van uw klanten, te laten wachten op een uitrol.

eIDAS Pro biedt privacy-first, eID-gebaseerde leeftijds- en identiteitsverificatie voor Europese platforms - gelaagd over nationale eID-schema's zoals itsme en iDIN, met optionele gezichtsleeftijdsschatting en documentterugval, en gebouwd om EU Digital Identity Wallet-verificatie toe te voegen zodra deze live gaat. Boek een consult →

Dit artikel is algemene informatie, geen juridisch advies. Verifieer de actuele verplichtingen voor uw markt en verticale met gekwalificeerd juridisch advies.