De authenticatie-pooier onder de loep.

February 10, 2016

Naar aanleiding van mijn blog over de veiligheidsrisico's van federatieve identiteiten schreef mijn collega Eric Verheul een kritische reactie. Volgens hem maak ik een denkfout en hebben ook niet-federatieve vormen van authenticatie hetzelfde veiligheidsprobleem. Uit zijn reactie maak ik op dat de essentie van mijn kritiek op federatieve authenticatie niet helemaal goed is overgekomen. Bij deze een nieuwe poging.

Eric schrijft:

Allereerst is de tegenstelling tussen beide vormen van authenticatie minder groot dan wat Jaap-Henk lijkt aan te geven. Beide vormen zijn namelijk gebaseerd op een 'vertrouwde derde partij' die na zorgvuldige controle van de identiteit van de aanvrager deze het middel overhandigt.

Dat suggereert een bepaalde vorm van niet-federatieve authenticatie, die ik nadrukkelijk niet voor ogen had toen ik het artikel schreef. Het punt is juist dat er geen 'vertrouwde derde partij' moet zijn, die mijn identiteit controleert en het middel dat hij uitgeeft daarover uitspraken zou moeten laten doen.

Ik schreef:

Om dit securityprobleem op te lossen moet de gebruiker weer in de loop geplaatst worden. [...] Bijvoorbeeld door een sterke vorm van authenticatie te gebruiken die rechtstreeks plaats vindt tussen de gebruiker en de dienstverlener. Op basis van een smart card, een secure USB-token, of cryptografische sleutels op de smartphone van de gebruiker.

De kernbegrip is hier 'sterke authenticatie', gebaseerd op publieke sleutel cryptografie. Hierbij wordt gebruik gemaakt van een privé sleutel die alleen bekend is bij de gebruiker en onder zijn exclusieve controle is, en de bijbehorende publieke sleutel die bekend is bij de dienstverlener en verbonden is met de identiteit/account van de gebruiker bij die dienst. (Voor de kenners onder ons in essentie dus de manier waarop ssh gebruikers authenticeert. Ik ben ook groot voorstander van het TOFU (Trust On First Use) principe. Meestal ben ik niet geïnteresseerd in wie je nou precies bent, maar wil ik gewoon weten of je dezelfde persoon/website/etc. bent die ik de vorige keer tegen kwam.)

Omdat mensen zelf geen privé sleutels kunnen onthouden, laat staan de noodzakelijk complexe berekeningen kunnen uitvoeren, moet de authenticatie afgehandeld worden door een 'authenticatie-middel': een smart card, secure USB token, smartphone of laptop. Die moeten inderdaad door iemand gemaakt worden, en de gebruiker moet er op vertrouwen dat de privé sleutel veilig blijft en nooit het middel verlaat. In het bijzonder moet het middel zelf de cryptografische sleutels genereren - dit moet niet door de uitgever van het middel gedaan worden. Dat vertrouwen kan vergroot worden door gebruik te maken van open source en open hardware; maar de gemiddelde gebruiker zegt dit natuurlijk niet zoveel.

Het is dus expliciet niet zo dat, zoals Erik schrijft,

[...] een authenticatiedienst [...] 'zomaar' een middel [zou] kunnen uitgeven aan een fraudeur dat op andermans naam staat.

Dat werkt niet, want de naam doet er niet toe. De fraudeur moet mijn privé sleutel kennen, en die weet niemand behalve ikzelf (of, precieser gezegd, mijn middel).

De essentie is dat de toegangsbeslissing niet gemaakt moet worden op basis van een identifier (mijn naam of BSN), maar op basis van de kennis van de privé sleutel die hoort bij het account waar toegang toe gevraagd wordt. Een mooi wetenschappelijk artikel over dit onderwerp is Carl M. Ellison, "The nature of a useable PKI", Computer Networks 31 (1999), pp 823–830. (Helaas geen open access...)

En IRMA dan?

In mijn artikel rep ik met geen woord over IRMA, onze attribuut gebaseerde authenticatie technologie. Dat was met opzet, want het punt was niet om te suggereren dat IRMA beter is wat dit betreft. Dat is namenlijk ook niet (helemaal) het geval. Maar omdat Eric IRMA in zijn stuk noemt is het wel goed om hier even bij stil te staan.

Toegangsverlening binnen IRMA gebeurt op basis van attributen. Met de juiste set van attributen (naam, leeftijd, o.i.d.) krijg je toegang tot een dienst. Niemand kan zomaar valse credentials of attributen creëren. Je zou dus denken dat de volgende op IRMA gebaseerde oplossing om toegang te krijgen tot je bankrekening veilig is.

Stel je hebt een rekening bij de Rabobank. In de registratie fase geeft de Rabobank een credential uit met daarin je rekeningnummer bij de Rabobank als één van de attributen. Als je vervolgens toegang wilt hebben tot je Rabobank rekening, dan moet je dit credential met dit attribuut laten zien. In dit voorbeeld is de uitgever van het credential ook de dienstverlener die het credential verifieert.

Op deze manier toegang verlenen gaat echter nog steeds in tegen Ellison's principe: we gebruiken een identifier (het bankrekeningnummer), geen cryptografische sleutel. En die identifier is publiek. Met als gevolg dat het mij wellicht lukt om op een of andere manier (social engineering?) de Rabobank credential issuer er van te overtuigen om een credential met jou Rabobank rekeningnummer uit te geven aan mijn IRMA kaart.

Merk op dat in het Rabobank voorbeeld geen sprake is van een 'vertrouwde derde partij' die toegang kan verlenen of nemen tot jou Rabobank rekening. Toegang krijg je alleen met behulp van een door de Rabobank uitgegeven credential. En je zou kunnen zeggen dat het hierboven geschetste risico vergelijkbaar is met het risico dat een goede social engineer via de helpdesk altijd wel toegang kan krijgen tot andermans account. Als je IRMA op de hierboven geschetste manier gebruikt voor toegangsverlening is het dus echt anders dan federatieve vormen van authenticatie. Maar je kunt IRMA zeker ook federatief gebruiken. Bijvoorbeeld als Google IRMA credentials uit zou gaan geven waarin mijn Google account naam staat, waarmee ik vervolgens bij AirBnB in zou kunnen loggen.

Het onderscheid tussen federatief en niet-federatief is dus niet zo relevant voor IRMA.

Tot slot

Ik ben blij met Eric's kritische analyse. Dit soort discussies helpt om de essentiële zaken helder te krijgen. Zodat we in Nederland een veilige en privacyvriendelijke eID krijgen. En dat is in het belang van iedereen.

In case you spot any errors on this page, please notify me!
Or, leave a comment.
Huub
, 2016-02-10 17:00:37
(reply)

Wat ik tot op heden in de discussie mis, is het belang dat de authenticatiedienst dient. Bij de meeste federatieve identiteiten, dienen de authenticatiediensten het belang van de dienstaanbieder (zoals bij Facebook en Google, maar ook bij DigiD). Binnen Idensys is deze rol juist losgekoppeld. De makelaar binnen Idensys dient het belang van de dienstaanbieders, maar de authenticatiediensten dienen hun klant: de gebruiker. Hun rol is juist het beschermen van de digitale identiteit van hun klant. Technologie alleen is niet zaligmakend.

Frans de Kok
, 2016-02-15 13:50:01
(reply)

Als ik met mijn zoontje naar huis loop rent hij wel eens ineens heel snel weg en roept hij “wie het eerst de deur aanraakt…”. Als ik hem dan alsnog voorbij loop en als eerste de voordeur aanraak vervolgt hij met “…. is een zachtgekookt ei”.

De conclusie van jouw reactie is dus dat Eric’s kritiek op niet-federatieve implementaties in het algemeen terecht is. Maar dat je bij het artikel eigenlijk een hele bijzonder vorm van niet-federatief in gedachten had, TOFU (Trust On First Use). Iets dat je niet in het artikel genoemd hebt. En daardoor mist Eric’s reactie zijn doel.

Als je heel goed je best doet zijn er misschien situaties te bedenken zijn waarbij TOFU (Trust On First Use) bruikbaar is. Je digitale identiteit is bij ROFU verbonden aan een middel. En als je het middel verliest ben je je volledige digitale identiteit en bijbehorende historie kwijt. Daarnaast, als dit middel in verkeerde handen valt heeft diegene voor onbepaalde tijd toegang tot de bijbehorende digitale identiteit. En daar kan je als persoon niets tegen doen. Dat lijkt me geen fijn voor uitzicht in de meeste gevallen, zowel voor klant als voor dienstverlener.

> … In de registratie fase geeft de Rabobank een credential uit met daarin je > rekeningnummer bij de Rabobank als één van de attributen…. Maar dan moet de Dienstverlener de eerste keer toch zeker weten wie jij bent! Ik begrijp dat je hier voorstelt dan je eerst met een betrouwbare federatieve oplossing authentiseert bij een Dienstverlener en daarmee een directe relatie tussen ‘middel’ en klantID legt. Dat kan, dat is afgeleide identificatie. Dat afgeleide decentrale middel (voor het gemak IRMA) is dan nooit betrouwbaarder dan het originele federatieve middel. Misschien wel minder betrouwbaar want ik ben benieuwd hoe IRMA beschermt wordt tegen manipulatie en virussen op je PC of mobiel, hoe het intrekken bij verlies of diefstal geregeld is en hoe kostbaar het is om naast een federatieve oplossing ook nog een IRMA oplossing te hebben. Maar mogelijk zijn er maatregels om deze risico’s te beperken. En kan een federatieve Idensys oplossing een mooie synergie bereiken met IRMA..

> Merk op dat in het Rabobank voorbeeld geen sprake is van een ‘vertrouwde derde partij’ De partij die helpt om vast te stellen dat jij de eigenaar van de rekening bent is de vertrouwde derde partij. Nu zijn banken toevallig bij uitzondering wel in staat om heel betrouwbaar met een heel duur en tijdrovend proces zelf vast te stellen wie jij bent. Maar andere dienstverleners kunnen dat niet. En dat hoeft niet, dat heeft de authenticatiedienst in het federatieve stelsel al voor jou gedaan. Verder vraag ik me af of jij bekent bent met de ID-fraude met bankrekeningnummers op andermans naam en de enorme schade die dit bij het slachtoffer kan aanrichten. Zelfs een betrouwbaar proces is niet feilloos. Vandaar dat een federatief stelsel maatregels kan nemen om er voor te zorgen dat iemand anders niet ongemerkt een authenticatiemiddel in jouw naam kan hebben. Ik vind dat waardevol en geruststellend.

> Dit soort discussies helpt om de essentiële zaken helder te krijgen. > Zodat we in Nederland een veilige en privacy vriendelijke eID krijgen. > En dat is in het belang van iedereen Dan helpt het ook om niet om de discussie met gestrekt been in te gaan. Of om samen met je kameraden kwetsende kopteksten te gebruiken. Probeer elkaar te prikkelen om het gezamenlijke doel te bereiken…. DAT is in het belang van iedereen.

Oh, ja. Ik ben van de linker Twix, zie mijn commentaar bij http://fd.nl/morgen/1138342/wilt-u-af-van-de-authenticatie-pooier

admin
, 2016-02-18 09:25:08
(reply)

Er zijn juist heel veel situaties waarbij TOFU (Trust On First Use) bruikbaar is. Namelijk iedere keer als jij bij een dienst een nieuw account creëert. Je hoeft, voor het aanmaken van het account, dan namelijk niet aan te tonen wie je bent en dat jij de eigenaar bent van het account. Het account wordt aangemaakt en op hetzelfde moment aan jou privé sleutel gekoppeld (door de publieke sleutel als een soort ‘wachtwoord’ voor het account op te slaan). Misschien dat de dienst vervolgens wel je naam wil weten en je leeftijd. Als de dienst er belang bij heeft dat die informatie authentiek is, dan is er een vertrouwde derde partij nodig die hierover uitspraken kan/mag doen. Maar die derde partij is niet speelt geen enkele rol als jij wilt inloggen op je account. Dat gebeurt puur op basis van de privé sleutel.

Voor bestaande accounts is de situatie anders. Daar zul je op één of andere manier aan moeten tonen dat jij de account houder bent. Frans legt mij een oplossing in de mond:
Ik begrijp dat je hier voorstelt dan je eerst met een betrouwbare federatieve oplossing authentiseert bij een Dienstverlener en daarmee een directe relatie tussen ‘middel’ en klantID legt.

Dat is dus niet wat ik bedoel. In plaats hiervoor gebruik te maken van de omslachtige suggestie van Frans, kun je natuurlijkgewoon je bestaande vorm van authenticatie bij de dienst (bijvoorbeeld username/wachtwoord) gebruiken om aan te tonen wie je bent! Vervolgens koppel je je privé sleutel aan je account (en schakel je username/wachtwoord authenticatie uit). Dit is ook hoe SSH werkt: je logt in met je wachtwoord en kopieert je publieke sleutel naar je account (om zo je privé sleutel aan je account te binden).

Blijft over wat er gebeurt als je je privé sleutel (in Frans’ termen het authenticatiemiddel) kwijt raakt. In dat geval (en dat geval probeer je natuurlijk zoveel mogelijk te voorkomen, bijvoorbeeld door goede en veilige backups van je privé sleutel te maken) is iedere vorm van authenticatie die een beetje extra zekerheid kan geven of jij de eigenaar bent van het account welkom. Vertrouwde derde partijen kunnen daar zeker een rol in spelen.

Voor de duidelijkheid, ik claim dus niet dat TOFU de enige goede manier is om in te loggen. Zoals ik in mijn oorspronkelijke stuk al schreef bestaan er twee soorten accounts: diensten waar je een abonnement op hebt, en diensten die toegang geven tot iets wat exclusief je eigendom is. Eigenlijk is het een onderscheid, in economische termen, tussen diensten met uitputbare en niet uitputbare goederen. Voor diensten met onuitputbare goederen waar jij een abonnement hebt, en waar je dus geen schade lijdt als anderen gebruik maken van je abonnement, is TOFU voor jou als gebruiker niet zo relevant. Anders wel.

En ook voor de duidelijkheid: ik schrijf hier specifiek over een privé sleutel als middel om op een veilige manier toegang te krijgen tot je accounts. Wat ik daarmee niet noodzakelijkerwijs bedoel is dat we één sleutel voor al onze accounts moeten hebben. (Hoeveel wel is een interessante vraag!) Ook is niet de bedoeling dat alle dienstverleners dezelfde publieke sleutel voor mij registereren, dit om te voorkomen dat dienstverleners al mijn accounts bij hun kunnen linken. Idensys heeft dit risico onderkent en voorkomt deze vorm van linken door dienst specifieke pseudoniemen te gebruiken.

Hugo Leisink
, 2016-02-16 14:40:58
(reply)

Een reactie op een opmerking van Eric Verheul:

“Met andere woorden, bij zowel de federatieve als de niet-federatieve opzet speelt de authenticatiedienst een fundamentele betrouwbaarheidsrol.”

Wat er nodig is om een niet-federatieve opzet mogelijk te maken, biedt de mogelijkheid om misbruik vanuit de derde partij in te dammen. Neem een PKI. Ik genereer zelf mijn prive-sleutel en gebruik de derde partij voor ondertekening van mijn publieke sleutel. Deze publieke sleutel laat ik door de bank (eventueel via de derde partij) hard aan mijn account koppelen.

De derde partijk kan nu alleen nog frauderen door een nieuwe publieke sleutel aan de bank te geven en deze aan mijn account te koppelen. Natuurlijk merk ik dit zelf omdat vanaf dan mijn login niet meer werkt. En omdat dit een bijzondere handeling is, is dit de mogelijkheid voor extra controles. Bijvoorbeeld door een belletje naar de klant zelf ter bevestiging.

Het voordeel van een niet-federatieve opzet is dus dat de inzet, en dus de mogelijkheid tot fouten (bewust en onbewust), minder aanwezig is dan bij een federatieve opzet. Uiteraard, mits het proces vanuit de dienst en de afnemen daarop ingericht is. Het is, om het zomaar te zeggen, een schakel uit het proces voor een groot deel wegnemen.

Hugo Leisink
, 2016-02-16 14:45:53
(reply)

Ter verbetering in mijn vorige post:

Het voordeel van een niet-federatieve opzet is dus dat de inzet

moet zijn:

Het voordeel van een niet-federatieve opzet is dus dat de inzet van de derde partij

Eric Verheul
, 2016-02-18 13:12:12
(reply)

Ik neem met enige tegenzin deel aan deze discussie omdat het onderwerp gewoon te complex is om in een discussiegroep aan de hand van algemeenheden en niet volledig uitgewerkte voorbeelden te voeren. Maar goed, er worden eigenlijk drie varianten besproken: 1. federatief met vertrouwde derde partij (TTP) bij middeluitgifte EN gebruik, 2. niet-federatief met TTP bij middeluitgifte maar NIET bij gebruik 3. niet-federatief zonder TTPs

Voorbeelden van 1 zijn DigD, de Surfnet federatie, iDIN (iDEAL) en Idensys. Voorbeelden van 2 zijn de meeste EU eID kaarten zoals bij onze buren Duitsland en België. Voorbeeld van 3: is FIDO (https://fidoalliance.org/)

IRMA kan zowel als Type 2 als Type 3 worden geïmplementeerd (en zelfs lees mijn reactie als Type 1).

Eigenlijk is Type 3 een contradictio in terminis omdat je als gebruiker toch wel het middel moet vertrouwen en ik denk dat de meeste burgers niet hun eigen middel willen/kunnen maken. Bij een Type 3 is het lastig voor een dienstverlener om betrouwbare globale attributen van de gebruiker te krijgen zoals BSN (publieke dienstverleners) of voor- en achternaam. Immers, omdat er geen TTPs zijn, zal de gebruiker op een of andere manier zelf de dienstverlener moeten overtuigen van deze attributen. De EU eIDAS betrouwbaarheidseisen vereisen dan in feite dat een burger zelf fysiek langs elke dienstverlener moet. Niet alleen bij elke publieke dienstverlener (belastingdienst, UWV, etc.) maar ook langs bijvoorbeeld elke bank waar je gebruik van wilt maken als klant. Het voorbeeld van Rabobank die een credential uitgeeft met daarin je rekeningnummer klinkt heel aardig tot je realiseert dat Rabobank vanuit wettelijke eisen (o.m. WWFT, http://wetten.overheid.nl/BWBR0024282/2015-01-01) dat pas mag doen als hij je identiteit (BSN en voor- en achternamen) heeft gevalideerd tegen een WID document of via een andere bank (afgeleide identificatie).

Type 3 werkt dus misschien best aardig zolang je maar geen globale attributen wilt hebben want dan wordt het m.i. onwerkbaar. Maar dat is geen invulling van de eID behoefte die er bestaat. Daarbij is het namelijk wel noodzakelijk dat een interactie ook globale attributen verstrekt aan de dienstverlener. Een belangrijke use-case van Idensys is bijvoorbeeld aanloggen bij de overheid en daar moet altijd een BSN worden opgeleverd richting de overheid. Natuurlijk kun je dat ter discussie stellen maar dat is echt een hele andere discussie. Verlies, diefstal of kapotgaan van een Type 3 middel is daarbij ook lastig. Want hoe blokkeer je middel en hoe kom je dan weer in je account? Daar kun je vast hele mooie technische oplossingen voor bedenken maar in de werkelijkheid zullen die gebruikersonvriendelijk zijn en kostbaar voor de dienstverleners. De meeste mensen zullen m.i. verlies, diefstal of kapotgaan willen kunnen oplossen (zeker als uiterste redmiddel) door zich te identificeren met een WID document, i.e. met globale attributen. FIDO heeft revocatie van middelen expliciet buiten de standaarden geplaatst; dat moet je dus zelf maar oplossen. Overigens ben ik bezig met een (privacy vriendelijke) revocatie techniek voor o.m. FIDO te ontwikkelen op basis van pairing based cryptografie.

Type 2 middelen zijn technisch realiseerbaar maar worden gehinderd doordat het o.m. complicerend is voor een dienstverlener zoals ik beschreef in mijn reactie https://www.cs.ru.nl/E.Verheul/presentations/Reactie_column_FD.pdf. Ik heb er geen wetenschappelijk onderzoek naar gedaan maar dit lijkt ook de reden dat de Duitse en Belgische eID kaarten niet erg succesvol zijn. En in die situatie is er nog maar één niet-federatief middel; de situatie waarin er meer dan één zijn lijkt me dan al helemaal niet glansrijk. De belangrijkste stelling in mijn reactie is dat de betrouwbaarheid en privacy eigenschappen van Type 1 en Type 2 niet voor elkaar hoeven onder te doen. Type 3 noem ik daar niet omdat die m.i. geen realistisch antwoord geeft op de vraag.

Frans de Kok
, 2016-02-19 16:07:10
(reply)

Een tijdje terug kwam een Zuid-Europese bank er achter dat hun bankkaarten relatief eenvoudig onherkenbaar gedupliceerd konden worden en dat dit op grote schaal gebeurde. Daarop besloot de bank een nieuwe hele veilige bankkaart in te voeren. De klanten konden hun veilige nieuwe kaart ophalen uitsluitend op vertoon van hun oude kaart. De bestedingslimiet van de oude kaart was nog redelijk beperkt. Maar omdat de nieuwe kaart zo veilig was, werd bestedingslimiet vastgesteld op ongelimiteerd…. De bank bestaat inmiddels niet meer.

> … kun je natuurlijk gewoon je bestaande vorm van authenticatie > bij de dienst (bijvoorbeeld username/wachtwoord) gebruiken om aan > te tonen wie je bent! Vervolgens koppel je je privé sleutel aan > je account (en schakel je username/wachtwoord authenticatie uit). De betrouwbaarheid van het initiële koppelproces bepaald (mede) de betrouwbaarheid alle daarvan afgeleide authenticatiepogingen. Hoe geweldig het middel ook is dat je daarbij gebruikt. In dit geval stelt JaapHenk voor om een veilig middel via een username/wachtwoord te koppelen aan een account. De overheid (en de rest van Nederland) heeft iets betrouwbaarders nodig dan een veilig middel dat is uitgereikt op basis van een username/wachtwoord. Volgens de Europese eIDAS standaarden voldoet dit proces niet eens aan de betrouwbaarheids eisen van het laagste betrouwbaarheidsniveau.

Uiteraard kan een Dienstaanbieder zelf een betrouwbaarder proces inrichten. En laten we de europeese eIDAS richtlijnen daarbij als uitgangspunt nemen. Zoals Eric al schrijft zal een Dienstverlener dan voor het vaststellen van een identiteit of persoonsgegeven een proces in moeten richten inclusief een balie contact met WID controle. Als elke Dienstverlener dit zelf zou moeten doen wordt dat heel inefficiënt, kostbaar en heel onvriendelijk voor gebruikers. Ook zitten hier privacy risico’s aan omdat er waarschijnlijk meer WID persoonsgegevens bij de Dienstverlener terecht komen dan strikt noodzakelijk. Net als het kopietje WID dat autoverhuurbedrijven maken.

De Dienstverlener kan dit hele registratie proces beter uitbesteden aan een vertrouwde derde partij (TTP) die daarbij ook meteen de (privacy) belangen van de gebruiker behartigd. Deze TTP kan dit zodanig doen dat een Dienstverlener alleen de gegevens krijgt die hij nodig heeft voor zijn dienst. En de TTP kan er voor zorgen dat de Gebruiker de regie over eigen identiteit en attributen houdt. Onderdeel daarvan is dat een gebruiker bij het verstrekken van identiteit en persoonsgegevens waarschijnlijk weinig inzicht heeft in eventuele risico’s en dat de individuele gebruiker een ongunstige onderhandelingspositie heeft ten opzichte van een grote Dienstverlener.

> Blijft over wat er gebeurt als je je privé sleutel (in Frans’ termen het authenticatiemiddel) > kwijt raakt. In dat geval (en dat geval probeer je natuurlijk zoveel mogelijk te voorkomen, > bijvoorbeeld door goede en veilige backups van je privé sleutel te maken) is iedere vorm > van authenticatie die een beetje extra zekerheid kan geven of jij de eigenaar bent van > het account welkom. Onderschat niet hoe lastig dit op een gebruikersvriendelijke, betrouwbare en veilige manier te regelen. Voor je het weet introduceer je weer een nieuw zwakke plek. Verder leert de ervaring dat de meeste mensen slecht risico’s kunnen afwegen en/of lui zijn. Ik zou maar niet te zwaar leunen op de gebruiker om zelf initiatief te nemen. Misschien kan een vertrouwde derde partij hier een rol spelen?

Fraude bestrijding en privacy

Het uniek identificeren van een persoon hoeft overigens niet te betekenen dat de digitale identiteit ook direct te herleiden is tot een persoon in de echte wereld. Veel dienstverleners hebben niet meer nodig dan een digitale identiteit die betrouwbaar gekoppeld moet kunnen worden aan een bestaande klant. In toenemende mate zullen dienstverleners (en zeker volledig digitale dienstverleners) hun klanten niet noodzakelijk in de echte wereld hoeven te herkennen. Aan de andere kant, als er bijvoorbeeld sprake is van fraude, dan is die noodzaak er vaak wel. De uitdaging is om er voor te zorgen dat de privacy van de vele bonafide gebruikers zo goed mogelijk gewaarborgd wordt. En dat slechts de identiteit van een malafide gebruiker opgeheven kan worden via een zorgvuldige procedure (vastgesteld door de politiek).

Een nationale toegangs oplossing zal naast privacy ook tegemoet kunnen komen aan het belang voor fraudebestrijding. Vooral ID-Fraude kan desastreuze gevolgen hebben voor slachtoffers en hun familie. Geen enkel proces ongeacht de waarborgen kan ID-Fraude volledig voorkomen. Het is daarom van belang om er voor te zorgen dat er voldoende mogelijkheden zijn om ID-fraude in een vroeg stadium op te merken. En dat kan het meest efficiënt en effectief gebeuren door de betrokkene zelf. ID-Fraude kan zijn verwoestende werk vooral doen zolang het slachtoffer daar geen weet van heeft. Een tweede voorwaarde is dat een slachtoffer de ID-fraude kan laten stoppen als hij dit opgemerkt heeft (of een vermoeden heeft).

Meetlat

Een nationale oplossing voor digitale toegang zal eisen tbv (ID-) fraudebestrijding en privacy moeten bedienen. Een federatieve inrichting die in kleine stapjes voortbouwt op bestaande investeringen kan tegemoet komen aan eisen van fraudebestrijding en privacy. En ook aan eisen voor marktwerking, keuzevrijheid, beschikbaarheid, betrouwbaarheid, gebruikersgemak, eenvoud van aansluiten (voor Dienstverleners). Misschien geldt dat ook voor de type 2 (zie Erics reactie) oplossing. Om daar iets zinnigs over te zeggen zou het handig zijn om duidelijke transparante eisen vast te leggen voor zo’n nationale oplossing. Dat kan dan een meetlat zijn waarmee alternatieven en aanvullende maatregels beoordeeld kunnen worden. Idensys heeft dat gedaan. Maar waarschijnlijk is dit onvoldoende afgestemd. Dergelijke hulp is in elk geval zinniger dan om aan de hand van een over versimpeld verhaal en weinig onderbouwing de andere Twix te diskwalificeren. Misschien kunnen we nog een poging doen om een gezamenlijke privacy en fraudebestrijdings meetlat samen te stellen.