3ULYDF\,PSDFW $VVHVVPHQW 2QWZHUS RS KRRIGOLMQHQ H,' 6WHOVHO 1/ 6WDWXV )LQDOH YHUVLH 9HUVLH MXOL

Transcriptie

1 3ULYDF\,PSDFW$VVHVVPHQW 2QWZHUSRSKRRIGOLMQHQ H,'6WHOVHO1/ 6WDWXV )LQDOHYHUVLH 9HUVLH MXOL

2 2

3 Versiegeschiedenis Versie Versiedatum Opgesteld door Samenvatting van aanpassingen J.H. Matto 1 e concept H. van der Wel Review en aanvullingen 2 e concept J.H. Matto Review 2 e concept J.H. Matto / H. van der Wel 3 e concept J.H. Matto Finale conceptversie J.H. Matto Verwerking commentaar 16 juni J.H. Matto Verwerking van commentaar nalv Reviewverslag PIA, 21 juli 2014 Afstemming en Goedkeuring Dit document is voor consultatie voorgelegd aan: Naam Handtekening Functie Datum uitgave Versie Distributie Dit document is gedistribueerd naar: Naam Betreft Verzenddatum Versie Vaststelling en ondertekening van deze rapportage Deze rapportage is vastgesteld op woensdag 23 juli Hoogachtend, M A Z A R S P A A R D E K O O P E R H O F F M A N N. V. Management Consultants J.H. Matto RE RI Partner-aandeelhouder 3

4 Inhoudsopgave 1. Inleiding Aanleiding en achtergrond PIA eid Stelsel Doelstellingen, scope en aanpak van de PIA De verdere opbouw van de PIA en leeswijzer Samenvatting bevindingen en aanbevelingen PIA Inleiding Positionering PIA bevindingen in ontwikkelproces eid Stelsel Algemeen: privacy waarborgen in het ontwerp eid Stelsel Noodzakelijkheid, proportionaliteit, subsidiariteit eid Stelsel Privacy principe Verantwoording Bevindingen Aanbevelingen Privacy Principe: Limiteren van het verzamelen van gegevens Bevindingen Aanbevelingen Privacy principe Doelbinding / Limitering gebruik gegevens Bevindingen Aanbevelingen Privacy principe Gegevenskwaliteit Bevindingen Aanbeveling Privacy principe Beveiliging van gegevens Bevindingen Aanbevelingen Privacy principe Transparantie Bevindingen Aanbevelingen Privacy principe Rechten van betrokkenen Bevindingen Aanbevelingen Beschrijving eid Stelsel Inleiding De aanleiding voor een nieuw eid Stelsel Doelstellingen van eid Stelsel Stakeholders bij het eid Stelsel Beoogde resultaten met het eid Stelsel Ontwerpeisen voor het eid Stelsel Ontkoppelen en ontzorgen van de Dienstaanbieder Waarborgen privacy Marktwerking mogelijk maken

5 3.6.4 Gebruikersgemak bevorderen Opsporing en toezicht inrichten Schets van de werking van het eid Stelsel Systeemdiagram eid Stelsel Stappen in het tot stand komen van een PseudoID Het gebruik van SectorID s Gebruik van identiteiten in een identiteitsverklaring Omvormen van pseudoniemen Fraudebestrijding: van PseudoID terug naar Stamsleutel De SectorID-dienst BSN Uitvoering PIA, bevindingen en aanbevelingen Bijlage I: Privacy Principes Bijlage II: Algemene privacy risico s

6 1. Inleiding 1.1 Aanleiding en achtergrond PIA eid Stelsel Het ontwerp voor het eid Stelsel voor Nederland bestaat uit een uniforme set van standaarden en afspraken voor geautoriseerde toegang tot digitale diensten. Het verlenen en afnemen van diensten binnen dit Stelsel gaat gepaard met het verzamelen en verder verwerken van persoonsgegevens door betrokken functionele partijen. De term eid staat voor elektronische identiteit. Deze wordt gebruikt als een persoon online gegevens over zichzelf met een organisatie deelt. Gebruik van persoonsgegevens, waaronder door de overheid, vormt in veel gevallen een inperking van het grondrecht van bescherming van de persoonlijke levenssfeer 1. Uit dit gebruik kunnen risico s voor de persoonlijke levenssfeer (privacy) van de betrokkenen voortvloeien. Onzorgvuldigheid, onbetrouwbaarheid van gegevens, verlies van gegevens (data lekken), gegevens gebruiken voor een ander doel dan waarvoor ze zijn verkregen, kunnen een negatieve impact hebben op iemands sociaal en maatschappelijk welbevinden. Informatietechnologie en grootschalige digitale gegevensverwerkingen introduceren veelal additionele (privacy) risico s die inherent zijn aan de inzet van deze technologie (de IT werkelijkheid), maar niet direct zichtbaar zijn op het niveau van eindgebruik. Het is daarom van groot belang, dat tijdens de ontwerpfase van het eid Stelsel wordt geïnventariseerd welke privacy bedreigende risico s in het geding zijn. Ook zal moeten worden vastgesteld of de met het eid Stelsel gepaard gaande verwerking van persoonsgegevens noodzakelijk is voor de te bereiken doelstellingen. Hierbij speelt zowel de vraag naar proportionaliteit (is de specifieke gegevensverwerking een bruikbaar middel om het doel te bereiken) als de subsidiariteit (zijn er geen minder privacy bedreigende alternatieven of waarborgen) van het eid Stelsel. Om deze vragen te kunnen beantwoorden heeft het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties (BZK) aan Mazars Management Consultants (MMC) verzocht om in een zo vroeg mogelijk stadium van het ontwerp van het eid Stelsel een high level Privacy Impact Assessment (PIA) uit te voeren. 1.2 Doelstellingen, scope en aanpak van de PIA Doelstellingen van de PIA Een Privacy Impact Assessment (PIA) is een hulpmiddel bij ontwikkeling van beleid, en de daarmee gepaard gaande wetgeving of bouw van ICT-systemen en aanleg van databestanden. Hiermee kunnen privacy risico s op een gestructureerde en heldere wijze in kaart worden gebracht. Een PIA is gedurende een ontwikkelproces iteratief en dynamisch van karakter. Het blijft per fase maatwerk. Door een PIA gedurende het ontwerpproces regelmatig uit te voeren, kunnen (nieuwe) risico s vroegtijdig worden ontdekt en wordt de bewustwording van risico s vergroot. Zo nodig kunnen richtinggevende aanbevelingen worden gedaan om privacy risico s te elimineren of te mitigeren. Deze PIA heeft betrekking op het ontwerp van het Nederlandse eid Stelsel versie De PIA is afgeleid van het PIA-toetsmodel dat specifiek op de Rijksdienst is gericht. Het toetsmodel is bedoeld voor toepassing op alle beleidsgebieden en binnen alle rechtsdomeinen. Het is de eerste PIA in een vroegtijdig ontwerpstadium van het eid Stelsel, dat inherent een functioneel veelzijdige en relatief complexe set aan standaarden en afspraken voor geautoriseerde toegang tot digitale diensten bevat. 1 Zie artikel 10, leden 2 en 3 Grondwet, artikel 8 EVRM, artikel 8 EU-Grondrechtenhandvest). 2 Zoals nader gespecificeerd in de van het Ministerie van BZK verkregen ontwerp documentatie. 6

7 De op basis hiervan door de deelnemers aan het eid Stelsel in te richten en te beheren ICTinfrastructuur is evenzeer inherent zeer veelzijdig en complex. Te meer omdat het eid dient aan te sluiten bij de eid ontwikkelingen op Europees niveau. Het is de bedoeling dat de PIA gedurende het ontwikkel- en realisatieproces van het eid stelsel wordt herhaald, aangescherpt en nader gedetailleerd. Deze PIA is ook een communicatiemiddel om tussen de verschillende bij het eid Stelsel betrokkenen bij het ontwikkelproces opgedane inzichten te kunnen delen, te kunnen verifiëren en zo nodig te optimaliseren. Deze High Level PIA is in beginsel bedoeld voor het ontwikkelteam van het eid, de projectverantwoordelijken en de stuurgroep. De PIA zal in een later stadium ook gebruikt kunnen worden om transparantie en draagvlak voor het eid Stelsel bij de diverse stakeholders, zoals verantwoordelijke overheden, burgers, betrokken derden en belangenorganisaties te bevorderen. Uiteindelijk is het ook het voornemen van het Ministerie van BZK en EZ, om zowel het ontwerp eid stelsel als de aan dit Stelsel inherente verwerkingen van persoonsgegevens van de deelnemers op het voldoen aan privacywet- en regelgeving te laten certificeren. De PIA dient daarom ook bij te dragen aan het ontwikkelen van een normenkader voor een auditeerbaar eid stelsel. Scope van de PIA De uitvoering van de PIA is beperkt tot de verwerking van persoonsgegevens met de ondersteunende ICT-infrastructuur zoals geschetst in de ontwerpdocumentatie van het eid Stelsel, versie Het betreft de verwerkingen van gegevens van personen binnen het kader van de doelstellingen van het eid Stelsel, zoals de eid, authenticatie-, machtiging- en vertegenwoordigingsgegevens en elektronische handtekeningen die tussen de eid Deelnemers over de gespecificeerde koppelvlakken worden uitgewisseld. Het vervolgens verwerken van persoonsgegevens in de back-office processen ten behoeve van te onderscheiden diensten door Dienstaanbieders valt buiten het bereik van de PIA. De Dienstaanbieders zijn zelfstandig verantwoordelijk voor de naleving van privacy wet- en regelgeving voor die te onderscheiden diensten. Dit neemt niet weg, dat daar waar het eid Stelsel privacy risico s in de dienstverlenende omgevingen van Dienstaanbieders genereert, hier naar vermogen aandacht aan zal worden besteed. Aanpak van de PIA De PIA is in periode januari 2014 mei 2014 door MMC conform de voorgestelde aanpak in het Model PIA Overheid uitgevoerd met ondersteuning van privacy en security experts. Tegelijkertijd zijn bij het toepassen van dit model de ervaringen met de PIA van de Nederlandse orde van IT-auditors (NOREA) in het bedrijfsleven als referentiekader meegenomen. Voorafgaand aan de uitvoering van de PIA is de relevantie van het verwerken van persoonsgegevens en de daarmee gepaard gaande privacysignificantie (privacygevoeligheid van de persoonsgegevens) binnen het eid Stelsel vastgesteld. In overleg met BZK en het Ministerie van Financiën (FIN) is de precieze scope voor de PIA bepaald. Daarbij is beslist over de in te zetten expertise, middelen en aanpak. De PIA is uitgevoerd op basis van de van BZK en FIN ontvangen ontwerpdocumentatie. Diverse malen is overleg gevoerd met projectverantwoordelijken, architecten en andere materiedeskundigen van BZK en FIN. 3 De onderhavige ontwerp documentatie van het eid Stelsel wordt nader gespecificeerd in par. 3.1 van dit rapport. 7

8 De eerste versie van het concept rapport is door BZK en FIN van commentaar voorzien. Hierna is de rapportage (versie 0.3 en 0.5) ook voorgelegd aan functionarissen van het Ministerie van Economische zaken en aan het architectenteam. Op- en aanmerken die hieruit naar voren zijn gekomen zijn hierna eveneens verwerkt. Het definitieve rapport is met inachtneming van het ontvangen commentaar vastgesteld. 1.3 De verdere opbouw van de PIA en leeswijzer Nadere toelichting opbouw van de PIA In onze aanpak van de PIA zijn twee kijkrichtingen gehanteerd voor het object van onderzoek. Allereerst is het object van onderzoek beschouwd vanuit de algemene privacy principes. Algemene privacy principes zijn ontleend aan de actuele literatuur over privacy en bescherming persoonsgegevens. Deze algemene privacy principes zijn relevant voor elke verwerking van persoonsgegegens en dus ook voor de verwerkingen binnen het eid Stelsel. In bijlage I is een nadere omschrijving van de algemene privacy principes opgenomen. Binnen de algemene privacy principes zijn de algemene privacy risico s onderkend. Ook de algemene privacy risico s zijn ontleend aan de relevante literatuur over privacy en gegevensbescherming. Het betreft risico s die relevant zijn voor alle soorten verwerkingen van persoonsgegevens en dus ook voor de verwerkingen binnen het eid Stelsel. In bijlage II zijn de privacy risico s nader omschreven. Privacy principes en risico s staan onderling tot elkaar in relatie. Zij kunnen elkaar beïnvloeden, versterken, verzwakken en vertonen strijdigheden. Ter indicatie van deze afhankelijkheden hebben wij in de inleiding van hoofdstuk 4 een tabel opgenomen van deze onderlinge afhankelijkheden. De verdere detailuitwerking van onze bevindingen is in hoofdstuk 4 per privacy principe gegeven in een uitgebreid matrixoverzicht. Per principe is daarin vervolgens een analyse gegeven van de voor dat principe relevante privacy risico s gegeven het huidige ontwerp van eid Stelsel. Hoofdstuk 4 geeft in detail een overzicht van bevindingen en aanbevelingen. Deze bevindingen en aanbevelingen zijn samengevat in hoofdstuk 2. Verdere opbouw van de PIA Deze PIA is verder als volgt opgebouwd. Hoofdstuk 2: een high level overview van de uitkomst van de PIA in de vorm van per privacy principe gesignaleerde bevindingen, risico s, de impact ervan voor betrokkenen en de verantwoordelijken voor het eid Stelsel en voor zover relevant met aanbevelingen. (Duidelijk is waar het goed gaat en op welke onderdelen het nog beter kan.) Hoofdstuk 3: een beschrijving van het eid Stelsel op hoofdlijnen, waaronder de ontwerpeisen, de uitwisseling van berichten tussen de componenten/rollen in het eid Stelsel, het tot stand komen en het omvormen van pseudoniemen en de cryptografie van het Stelsel. Hierbij wordt de werking van het eid Stelsel geïllustreerd met behulp van uit de documentatie overgenomen diagrammen en figuren. Hoofdstuk 4: een tabel met op het eid Stelsel aan privacy principes gerelateerde vragen vanuit het Model PIA Rijksoverheid met antwoorden. Waar relevant zijn privacy- of andere risico s gedetecteerd en worden aanbevelingen gedaan om deze risico s te elimineren of te mitigeren. Bijlage I: een informatief overzicht van de algemene privacy principes. Bijlage II: een informatief overzicht van relevante privacyrisico s, waarnaar eerder in de bijlage I is verwezen. 8

9 2. Samenvatting bevindingen en aanbevelingen PIA 2.1 Inleiding De opbouw van dit hoofdstuk is als volgt. Allereerst wordt in dit hoofdstuk de positionering van de PIA in het ontwikkeldproces van het eid Stelsel besproken en voorzien van een overall conclusie (2.2) Vervolgens wordt ingegaan op de algemene privacy waarborgen die met het eid Stelsel worden beoogd. Aansluitend wordt kort ingegaan op de beginselen noodzakelijkheid, proportionaliteit en subsidiariteit in relatie met het eid Stelsel. (2.3) Tenslotte komen per privacy principe de belangrijkste bevindingen en aanbevelen uit hoofdstuk 4 van deze PIA aan de orde. Zo veel mogelijk is bij het uitvoeren van de PIA het Model Rijksoverheid gebruikt in volgorde van de op de vragen gegeven antwoorden. Een aandachtspunt bij dit model is, dat de privacy principes niet afgebakend en gestructureerd per principe kunnen worden beoordeeld. Het resultaat hiervan is, dat dit op onderdelen tot herhalingen van bevindingen en elkaar overlappende aanbevelingen leidt. Deze bevindingen en aanbevelingen zijn daarom in deze samenvatting ontdubbeld en zo veel mogelijk naar privacy principe geordend. Het hoofdstuk wordt afgesloten met een tabel die een overzicht bevat van mogelijke privacy risico s per privacy principe. 2.2 Positionering PIA bevindingen in ontwikkelproces eid Stelsel Belangrijk voor de interpretatie van de bevindingen in deze rapportage is dat het object van onderzoek, het ontwerp 1.0 van het eid Stelsel, de afsluiting is van een eerste stap in een ontwerpproces dat uiteindelijk moet leiden tot een finale beschrijving van het eid afsprakenstelsel. Het huidige ontwerp (1.0) van het eid Stelsel betreft vooral de opzet en inrichting van meer technische aspecten van het totaal te ontwikkelen afsprakenstelsel voor eid, Procedurele en juridische afspraken zijn nog geen onderdeel van het huidige ontwerp. In deze rapportage staan bevindingen en soms ook nog openstaande punten die in vervolgontwerpen nader geadresseerd of anderszins ondervangen kunnen worden. Het kan ook voorkomen dat risico s die in deze PIA zijn onderkend in het huidige Stelsel niet in de technische architectuur ondervangen (kunnen) worden, maar wel door aanvullende juridische of andere procedurele afspraken gemitigeerd kunnen worden, die nu nog niet in de stelselafspraken zijn voorzien, In deze rapportage, en eigenlijk inherent aan elk assessment, worden bevindingen gemaakt die wellicht kritisch kunnen overkomen. Deze bevindingen moeten geplaatst worden tegen het huidige stadium van het ontwerp. Onze overall conclusie is dat het eid Stelsel juist veel privacy bevorderende maatregelen in zich heeft die de doelstellingen van het eid Stelsel ondersteunen. Onze conclusie is dus positief over de aanpak en opzet van het eid Stelsel aangaande de privacyaspecten gezien het ontwerpstadium. Waarbij we de opmerking maken dat op kritische onderdelen nadere maatregelen overweging verdienen. Het doel van een PIA is juist om dat aan te duiden. 2.3 Algemeen: privacy waarborgen in het ontwerp eid Stelsel Inherent aan een eid Stelsel is, dat Dienstaanbieders onder omstandigheden waarin dit noodzakelijk is voor hun dienstverlening, de identiteit en authenticiteit van Gebruikers wensen vast te stellen. Onmiskenbaar staat in het ontwerp eid Stelsel voorop, dat de Minister van Binnenlandse Zaken en Koninkrijksrelaties en de Minister van Economische Zaken in het ontwerp van het eid Stelsel de persoonlijke levenssfeer (privacy) van Gebruikers met waarborgen wensen te omgeven. Dit blijkt uit de ontwerpeisen die bij de totstandkoming van het eid Stelsel leidend zijn: Ontkoppelen en ontzorgen van de Dienstaanbieder; Waarborgen privacy; Marktwerking mogelijk maken; Gebruikersgemak bevorderen; Toezicht en opsporing 9

10 inrichten. Dit blijkt ook, uit het in een zo vroeg mogelijk stadium van het ontwerp uitvoeren van deze PIA en de intentie om de PIA structureel in de volgende ontwerp fasen te continueren. Van begin af aan wordt in de ontwerpeisen aandacht besteed aan de privacybeginselen: dataminimalisatie en privacy by design. Er is ook aandacht voor het zelfbeschikkingsrecht van Gebruikers. Een Gebruiker wordt in staat gesteld om naar elke Dienstaanbieder een andere identiteit (pseudoniem) kenbaar te maken en kan daarmee zijn digitale privacy behouden. Een Dienstaanbieder kan alleen op basis van doelbinding autorisatie aanvragen om (sommige) gegevens te kunnen ontvangen. De gegevens worden pas verstrekt nadat de gebruiker hiervoor toestemming heeft verleend. Het uitgangspunt daarbij is dat iemand in de digitale wereld zelf moet kunnen bepalen wie welke informatie over hem krijgt en er moet voorkomen worden dat hij te maken krijgt met willekeurige of onwettige inmenging in zijn privéleven. In die zin wenst de overheid zorgvuldig om te gaan met persoonsgegevens, zoals dit ook verankerd is in de Wet bescherming persoonsgegevens (Wbp). Een PseudoID is een nummer dat de afnemer van een dienst identificeert en dat door een Authenticatiedienst aan een Dienstaanbieder wordt verstrekt. Binnen het domein van alle Authenticatiediensten is elke PseudoID uniek en is gekoppeld aan één bepaalde Dienstaanbieder. Elke Dienstaanbieder ontvangt een PseudoID dat speciaal aan hem is gericht. Hierdoor kunnen verschillende Dienstaanbieders de ontvangen PseudoID s van eenzelfde persoon niet vergelijken. Deze PseudoID s zijn persistent: iedere volgende authenticatie ten behoeve van dezelfde Dienstaanbieder levert dezelfde PseudoID op. De Dienstaanbieder zal echter in veel gevallen dat PseudoID willen koppelen aan het administratieve nummer waaronder de persoon bij de Dienstaanbieder bekend staat (het eigen interne klantnummer). De gebruiker moet daarvoor toestemming geven en zet met zijn Authenticatiemiddel een eenmalig koppelproces in gang. Een Gebruiker kan ook een non-persistente pseudo identiteit op een secure device gebruiken. Non-persistent betekent, dat een Gebruiker bij het afnemen van Diensten iedere keer een andere pseudo-identiteit aanneemt voor die gevallen waarin diens identiteit niet bij een Dienstaanbieder (meteen) bekend hoeft te worden gemaakt. Hieraan worden in het ontwerp nog bepaalde nadelen voorzien, zoals het niet bij kunnen houden van een audittrail om eventueel misbruik te kunnen aantonen. In de PIA wordt daarentegen aanbevolen om oplossingen in de richting van Life Management Platforms te verkennen. De Gebruiker zou mogelijk zelf in een eigen secure domein een audittrail kunnen bijhouden en kunnen bepalen aan wie hij de informatie in voorkomende gevallen van misbruik / identiteitsfraude verstrekt. Tenslotte kent Nederland een aantal sectoren waarin meerdere Dienstaanbieders onderling gebruik maken van hetzelfde identificerende nummer van een persoon. Binnen een dergelijke sector bestaat een register waarin het sectorale nummer van de persoon is opgenomen. In dit geval moet de authenticatie niet een Dienstaanbieder-specifieke PseudoID opleveren, maar een sector-specifieke PseudoID. Per sector wordt dan een koppelregister ingericht. Hierin wordt, na toestemming van de gebruiker, de koppeling door de sector zelf geregistreerd tussen het PseudoID en het sectorale nummer. 2.4 Noodzakelijkheid, proportionaliteit, subsidiariteit eid Stelsel Het ontwerp van het eid Stelsel kan de toets aan de eisen van de noodzakelijkheid/proportionaliteit en subsidiariteit doorstaan. De doelstellingen van het eid Stelsel in de ontwerpdocumentatie alsmede in de aan de Tweede Kamer gerichte brieven van de Ministerie van BZK onderbouwen de noodzakelijkheid. Bovendien dient Nederland als lidstaat van de EU naar verwachting binnen afzienbare tijd gevolg te geven aan de Verordening betreffende elektronische identificatie en vertrouwensdiensten voor elektronische transacties in de interne markt. Uit de ontwerp documentatie blijkt ook dat met de beginselen van proportionaliteit (is de specifieke gegevensverwerking een bruikbaar middel om het doel te bereiken) als de subsidiariteit (zijn er geen minder privacy bedreigende alternatieven of waarborgen) rekening wordt gehouden. De intentie van het ontwikkelteam is ook om die beginselen doorlopend in de volgende ontwerp fasen in het oog te houden. Ten slotte dient ook mee te worden gewogen dat in de huidige situatie zonder eid stelsel sprake is van een relatief onbeheersbare toestand met betrekking tot het gebruik van digitale 10

11 identiteiten voor Gebruikers. Het resultaat is dat er meer en meer feitenmateriaal en berichtgeving is over identiteitsfraude en privacyschendingen. Het eid Stelsel beoogd ook deze problemen te beperken. 2.5 Privacy principe Verantwoording Bevindingen In het systeemdiagram van het eid Stelsel is op hoofdlijnen en op hoog abstractieniveau te onderscheiden hoe de ICT-infrastructuur van het eid Stelsel op dit moment wordt voorzien. 4 Hierin komt ook op hoofdlijnen en in algemene termen tot uiting, welke eid Deelnemers over welke in het eid Stelsel te onderscheiden koppelvlakken berichten met persoonsgegevens met elkaar delen. In dit ontwerpstadium is nog niet bepaald wie verantwoordelijke is voor het eid stelsel als totaal. In het Stelsel worden tot dusver de volgende componenten/rollen onderscheiden: Stelselautoriteit-identificatiedienst, Authenticatiedienst, Machtigingsdienst, SectorIDdienst, Attributendienst, eid makelaar, Dienstbemiddelaar en Dienstaanbieder. De begrenzing van het eid Stelsel met daarbij de verantwoordelijkheidsvraag voor verwerkingen van persoonsgegevens door de componenten/rollen is nog niet transparant uitgewerkt. Binnen het stelsel zijn die verschillende rollen namelijk nog niet consistent vertaald naar de status van verantwoordelijke en bewerker. Zo wordt voor bepaalde rollen de status van bewerker benoemd, terwijl er ook nog de mogelijkheid bestaat om voor diezelfde rol de status van verantwoordelijke aan te nemen. Ook is het mogelijk om als eid Deelnemer / Dienstaanbieder meerdere rollen te vervullen 5. Dit kan in theorie tot combinaties van de status verantwoordelijke en bewerker bij één eid Deelnemer of Dienstaanbieder (of wellicht ook bij combinaties van eid Deelnemer en Dienstaanbieder) leiden. Bij de Dienstaanbieder en de eid makelaar zijn bijvoorbeeld volgens de ontwerp documentatie zowel de status van bewerker als verantwoordelijke mogelijk. Dit kan weer tot gevolg hebben, dat er binnen een eid Deelnemer / Dienstaanbieder sprake kan zijn van cumulatie van normaliter per rol te onderscheiden persoonsgegevens. In theorie zou dus, als gevolg van eigenschap P01, een ongebreidelde samenloop van rollen (Dienstaanbieder, Dienstbemiddelaar, eid makelaar, Authenticatiedienst, Machtigingendienst, Sector ID Dienst 6 ) bij een eid Deelnemer (conglomeraat, samenwerkingsverband, economische eenheid) kunnen ontstaan. Deze ongebreidelde samenloop van rollen, genereert een ongebreidelde cumulatie van met die rollen samenhangende persoonsgegevens, die normaliter over de afzonderlijke koppelvlakken tussen afzonderlijke eid Deelnemers worden uitgewisseld en over die eid Deelnemers wordt verdeeld. Die gegevens komen dan samen onder één eid Deelnemer (concentratie leidt tot hotspot), die (on)afhankelijk van de rol, ook nog de keuze heeft om afhankelijk van de wensen van diens klant(en) als verantwoordelijke en/of bewerker op te treden. ( Zoveel klanten, zoveel wensen, zo veel statussen ). Een bewerker is in theorie immers grotendeels afhankelijk van de eisen die een (of meerdere) verantwoordelijke(n) aan hem stel(t)(len)t. Immers, de verantwoordelijke bepaalt het doel en de middelen en heeft de zeggenschap over de verwerking. Hoe meer combinaties van rollen bij eid Deelnemers en Dienstaanbieders, hoe meer dit een tombola aan te regelen verantwoordelijkheden voor de diverse vooralsnog te onderscheiden verwerkingen tot gevolg kan hebben. 7 De begrippen eid Deelnemer en Dienstaanbieder in de Begrippenlijst eid Afsprakenstelsel worden in het document Werking van het eid Stelsel niet consistent toegepast. Dit bemoeilijkt weer het bepalen van de status van verantwoordelijke en van bewerker van de eid Deelnemers / Dienstaanbieders. In deze fase van het ontwerp eid Stelsel is in het Afspraken Stelsel is nog niet vastgelegd, welke status onder welke voorwaarden aan een component/eid Deelnemer/Dienstaanbieder 4 Zie paragraaf van dit rapport, waar dit systeemdiagram met uitleg is opgenomen. 5 Zie Werking van het eid Stelsel, ontwerpeis P01, p Een uitzondering vormt de rol van Stelselautoriteit. 7 Dit kan ook weer risico s voor het privacy principe doen ontstaan. Zie verder onder dit principe. 11

12 in het eid Stelsel kan worden toegekend, wat de inhoud van de melding van een soort verwerking behoort te zijn en hoe vervolgens de melding van een verwerking aan de relevante FG of het CBP dient te gebeuren. Er kunnen hierdoor diversiteit in statussen, in meldingen binnen het eid Stelsel en spanningen inzake het Verantwoordelijkheidsprincipe - en hierover later in het Doelbindingsprincipe ontstaan. Het is tenslotte voorstelbaar dat in de onderliggende ICT-infrastructuur van het eid Stelsel veel ICT-serviceproviders weer een diversiteit aan diensten aan eid Deelnemers zullen verlenen. Afhankelijk van de status(sen) van een eid Deelnemer verkrijgt de serviceprovider in een voorkomend geval de status van bewerker of van subbewerker. Daarbij komt dat outsourcing naar serviceproviders naar landen buitende EU/EER privacyrisico s kent ten gevolge waarvan die outsourcing aan specifieke regels of beperkingen is gebonden. Deze risico s zijn inherent aan de huidige en toekomstige ontwikkelingen in de techniek en business. De vraag is ook of deze ontwikkelingen zich al niet voordoen binnen de bestaande digitale eid toepassingen. Uit de ontwerp documentatie blijkt niet dat er al een risicoanalyse is uitgevoerd op combinaties van rollen en de mogelijke negatieve gevolgen hiervan op de persoonlijke levenssfeer van Gebruikers. Nog niet in het Afspraken Stelsel is vastgelegd, welke status onder welke voorwaarden aan een component/eid Deelnemer/Dienstaanbieder in het eid Stelsel kan worden toegekend, wat de inhoud van de melding van een soort verwerking behoort te zijn en hoe vervolgens de melding van een verwerking aan de relevante FG of het CBP dient te gebeuren. Er kunnen hierdoor diversiteit in statussen, in meldingen binnen het eid Stelsel en spanningen inzake het Verantwoordelijkheids- en Doelbindings-principe ontstaan. Deze vraagstukken over verhoudingen tussen en samenloop van rollen van verantwoordelijke en/of bewerker zullen in een vervolg ontwerpfase in procedurele en juridische afspraken nadere aandacht vereisen. In dit document komt dit vraagstuk nog op verschillende plaatsen terug Aanbevelingen 1. Stem de gehanteerde begrippen in de Begrippenlijst Afsprakenstelsel en het document Werking van het eid Stelsel goed op elkaar af; 2. Laat een risicoanalyse uitvoeren op alle mogelijke combinaties van rollen voor eid Deelnemers / Dienstaanbieders; 3. Bepaal aan de hand van een privacyrisicoanalyse welke combinaties van rollen bij een partij tot onbeheersbare privacyrisico s kunnen leiden; 4. Laat een risicoanalyse uitvoeren op de mogelijkheden van eid Deelnemers / Dienstaanbieders om zelf de status van verantwoordelijke of van bewerker of combinaties van deze statussen te kiezen; 5. Laat een risicoanalyse uitvoeren op de mogelijkheden van outsourcing van rollen en ICT-services naar partijen buiten de EU/EER; 6. Definieer per partij en per rol en per gegevensverwerking in het eid Stel de status van verantwoordelijke en van bewerker ; 7. Reguleer mogelijke combinaties van rollen en hiermee gepaard gaande verantwoordelijkheden; 8. Neem aan de hand van de uitkomst van de risicoanalyses beheersmaatregelen in het Afsprakenstelsel aangaande combinaties van rollen, de status van verantwoordelijke en bewerker en combinaties hiervan, outsourcing van rollen en ICT-services, en het hier op te houden toezicht (zoals audits of toereikende certificeringen); 9. Besteed in het Afsprakenstelsel aandacht aan de status verantwoordelijke en bewerker van een component/eid Deelnemer/Dienstaanbieder en het vervolgens melden van de hiermee verband houdende verwerking van persoonsgegevens bij de relevante FG en/of het CBP; 12

13 10. Maak afspraken c.q. geef handreikingen over de inhoud van de melding teneinde hiermee te voorkomen, dat de genoemde partijen onbewust niet aan de meldingsplicht voldoen, doelstellingen van gelijksoortige verwerking van elkaar afwijken en rechtmatigheidsvragen ontstaan; 11. Bewerkstellig hiermee dat de meldingen van de in het eid Stelsel voorkomende verwerkingen goed op elkaar worden afgestemd (convergentie-effect), waardoor spanningen in de uitwisseling en het gebruik van data binnen de keten van het eid Stelsel kunnen worden voorkomen (alignment). 2.6 Privacy Principe: Limiteren van het verzamelen van gegevens Bevindingen Een van de ontwerpeisen van het eid Stelsel, een eid-deelnemer krijgt niet meer gegevens dan strikt noodzakelijk is voor het uitvoeren van zijn taak is nauw verweven met het privacy principe doelbinding en limiteren van het gebruik van persoonsgegevens. Impliciet refereert het daarom ook aan de intentie van het eid Stelsel om te voldoen aan het privacy principe van het limiteren van het verzamelen van gegevens. In het ontwerp van het eid-stelsel wordt zo veel als maar mogelijk is bij het verwerken van (gevoelige) persoonsgegevens gebruik gemaakt van pseudo identiteiten voor Gebruikers en het versleutelen van indirect gevoelige gegevens. Welke persoonsgegevens precies tussen de componenten / rollen in het eid Stelsel worden uitgewisseld, wordt in het document Interface specifications uitgewerkt. Uit een eerste en voorlopige analyse van de gedefinieerde typen data in de berichten over de koppelvlakken tussen de te onderscheiden componenten van het eid Stelsel is vooralsnog niet komen vast te staan, dat er niet aan het beginsel van de gegevensminimalisatie wordt voldaan. De analyse kon nog niet volledig en in voldoende onderlinge samenhang worden uitgevoerd. Ten aanzien van de belangrijke koppelvlakken als K4 Dienstbemiddelaar Dienstaanbieder en K7 Authenticatiedienst - Machtigingendienst - Stelselautoriteit moeten de datasets namelijk nog worden gespecificeerd. Tevens is nog niet volledig per Partij en per koppelvlak en per combinatie van rollen aangegeven welke (meta) data in welke loggingen/audittrails worden verzameld. De effecten van het ontstaan van metadata in de onderliggende systeemlagen van betrokken ICT-providers die een rol gaan spelen bij het gebruik van het Stelsel zijn evenmin in een risicoanalyse meegenomen in het huidige ontwerp. Voor bepaalde doeleinden, bijvoorbeeld het vaststellen van de leeftijd van een Gebruiker is het voor een Dienstaanbieder niet nodig om daarbij de identiteit van de Gebruiker te vernemen. Het eid Stelsel voorziet er in zo n geval in dat kan worden volstaan met het leveren van een attribuut, dat een persoon ouder of jonger is dan een bepaalde leeftijd. Ingeval een Polymorfe PseudoID is opgeslagen op een secure device kan deze bij uitlezen door het middel zelf worden gerandomiseerd. Indien die device wordt gebruikt, is het voor de Authenticatiedienst niet meer mogelijk om de Polymorfe PseudoID te herkennen. De authenticatie kan dan worden uitgevoerd zonder dat een Dienstverlener weet over welke van zijn klanten het gaat. Dit biedt ook vanuit het principe van dataminimalisatie een extra niveau van privacybescherming. Maar er kleeft voor de Gebruiker echter wel een nadeel aan. Ingeval een secure device wordt gebruikt, is het niet meer mogelijk om precies vast te leggen welk gebruik er van een kaart (het device) wordt gemaakt. Dit verhoogt het risico voor de omkering van de bewijslast van de betrokkene ingeval van misbruik van de kaart, althans als er niet langs een andere weg een audittrail wordt bijgehouden. Uit de ontwerp documentatie blijkt niet of er voldoende is onderzocht welke reële mogelijkheden er zijn om dit nadeel te compenseren. Bijvoorbeeld door aansluitingen mogelijk te maken (via app toepassingen) op Management Life Cycle Platforms van Gebruikers. Op die Platforms hebben Gebruikers namelijk een eigen afgeschermde secure 13

14 domein, waarin zij hun persoonsgegevens kunnen opslaan en verder verwerken. Hierin kunnen zij mogelijk zelf loggegevens verzamelen en beheren. In geval van misbruik van hun gegevens of in het kader van bewijsvoering kunnen Gebruikers dan zelf bepalen in welke gevallen zij aan welke instanties toegang tot de loggingen / audittrails geven Aanbevelingen 1. Ga door met het aanvullen van de specificaties van de typen data die nodig zijn voor het berichtenverkeer over de koppelvlakken K4 en K7 en waar nodig nog voor audittrails en loggingen. 2. Onderzoek de mogelijkheden voor het bijhouden van audittrails over het gebruik van een secure device, bijvoorbeeld om aan te sluiten op ecosystemen zoals Life Management Platforms. Onderzoek daarbij of een Gebruiker in een dergelijke omgeving de mogelijkheid heeft om (bijvoorbeeld met een app op een mobile device audittrails in een eigen secure omgeving op te slaan. De Gebruiker kan dan zelf bepalen aan wie hij deze gegevens ter beschikking wil stellen. 3. Laat op de noodzaak voor het verzamelen van het BSN bij de relevante SectorIDdiensten een aanvullende risicoanalyse uitvoeren en daarbij ook de eventuele noodzaak tot aanvullende BSN-regelgeving vaststellen. 4. Bepaal de impact van effecten van metadata die ontstaat op onderliggende systeemlagen als gevolg van het gebruik van IT middelen 2.7 Privacy principe Doelbinding / Limitering gebruik gegevens Bevindingen Het doel van het eid Stelsel is: 1. het creëren van een toekomstbestendige en betrouwbare elektronische identiteitsinfrastructuur die gebruikt kan worden door zowel publieke als private Dienstaanbieders en die publiek-privaat beheerd en doorontwikkeld wordt. 2. Mogelijk maken dat publieke Dienstaanbieders de toegang en afhandeling van online dienstverlening vanaf 2015 via het eid Stelsel kunnen inrichten waardoor zij de doelstelling Digitaal 2017 uit het regeerakkoord kunnen realiseren: Bedrijven en burgers kunnen in 2017 zaken met de overheid digitaal afhandelen. Het eid Stelsel moet de volgende diensten mogelijk maken: 1. Authenticatie 9 met hoog betrouwbaarheidsniveau; 2. Verificatie van aanvullende gegevens (attributen) zoals leeftijd; 3. Ondersteuning (wettelijke) vertegenwoordiging; 4. Een betrouwbare, praktisch handzame en bruikbare elektronische handtekening. In het Stelsel worden hiertoe tot dusver de volgende componenten/rollen onderscheiden: Stelselautoriteit-identificatiedienst, Authenticatiedienst, Machtigingsdienst, SectorIDdienst, Attributendienst, eid makelaar, Dienstbemiddelaar en Dienstaanbieder. Ten aanzien van het privacy principe Verantwoordelijkheid zijn in het eid Stelsel risico s ten aanzien van combinaties van componenten/rollen en de daarmee samenhangende status van verantwoordelijke en/of bewerker gesignaleerd. Die risico s werken onherroepelijk door in het privacy principe Doelbinding. 10 Op hoofdlijnen zijn de doelstellingen van het eid Stelsel en van eid Deelnemers in de onderliggende ontwerpdocumentatie vermeld. Per eid Deelnemer zijn afhankelijk van hun status als verantwoordelijke en/of bewerker in abstracto doelstellingen geformuleerd. Maar dit 8 Vanzelfsprekend zal daarin betrokken moeten worden, wat de integriteitswaarde is van de data in die omgevingen met het oog op eventuele mogelijkheden voor manipulatie door Gebruikers. Ook de eventuele risico s voor het ontstaan of bevorderen van identiteitsfraude via die Gebruikersomgevingen. 9 Het bewijzen en controleren van de geclaimde identiteit van een Handelende Persoon via een (set van) authenticatiemiddel(len) op een bepaald betrouwbaarheidsniveau. 10 In principe raakt dit ook het privacy principe limitering van verzamelen van gegevens. 14

15 zijn nog geen toereikende concrete doelstellingen in samenhang met de specifieke dienstverlening en daarmee verband houdende verwerkingen van persoonsgegevens. De typen datasets die evenwel in de berichten over de koppelvlakken tussen de eid Deelnemers worden uitgewisseld, zijn al wel gespecificeerd in het document Interface Specifications. Ten aanzien van die specificaties kan onder voorbehoud van de eerder gesignaleerde risico s worden opgemerkt, dat de samenstelling van de datasets over de koppelvlakken tussen de te onderscheiden eid Deelnemers niet op voorhand aanleiding geeft tot de veronderstelling dat deze datasets niet in overeenstemming zijn met het privacy principe Doelbinding. Met andere woorden; niet op voorhand is kunnen blijken, dat de specificaties van de datasets voor de gegevensuitwisseling over de koppelvlaken niet nodig zijn voor de taken op hoofdlijnen van de te onderscheiden componenten/rollen. Hierop aansluitend wordt het voorbehoud geplaatst, dat nadere detaillering van het ontwerp op de koppelvlakken K4 Dienstbemiddelaar Dienstaanbieder en K7 Authenticatiedienstmachtigingendienst en Stelselautoriteit nog nodig is om uiteindelijk in onderlinge samenhang vast te stellen welke persoonsgegevens precies tussen de in het eid Stelsel te onderscheiden eid Deelnemers (per rol) en Dienstaanbieders (per rol) worden uitgewisseld. Naar verwachting zullen ook door de eid Stelsel ICT-infrastructuur directe en indirecte persoonsgegevens ontstaan in koppelvlakken, de loggingen/audittrails op de koppelvlakken en de loggingen/audittrails op de Dienstaanbieders. Deze zijn in de ontwerp documentatie nog niet inzichtelijk. Dit impliceert dat er ook nog geen concrete doelstelling voor zijn. In de audittrails van eid Deelnemers kunnen uit de inloggegevens van publieke en private Dienstaanbieders, hoewel hier niet voor bedoeld, ook indirect gegevens over de financiële of economische situatie van betrokkenen, of andere gegevens die kunnen leiden tot stigmatisering of uitsluiting, worden gedistilleerd. Dit risico neemt toe naarmate eid Deelnemers / Dienstaanbieders meerdere rollen kunnen vervullen. De doelstelling van het eid Stelsel leidt bij grootschalig gebruik onvermijdelijk tot het ontstaan van enorme dataverzamelingen bij de te onderscheiden eid Deelnemers en Dienstaanbieders, die tot op de identiteit van Gebruikers en andere betrokkenen zijn te herleiden. Het verwerken van uniek identificerende gegevens is immers noodzakelijk in het kader van de doelstellingen van het eid Stelsel (behoudens die gevallen waarbij bijvoorbeeld met een attribuut aangaande de leeftijd bij een Dienstaanbieder kan worden volstaan). Hoewel het verwerken van uniek identificerende gegevens, zoals biometrische gegevens, en de hierbij te gebruiken middelen nog niet expliciet als mogelijkheid binnen het eid Stelsel worden genoemd, is dit op basis van de ontwerpeisen van het Stelsel al wel mogelijk. Of voor een of meer van de betrokken eid Deelnemers of Dienstaanbieders een beperking geldt van de mogelijkheid om persoonsgegevens te verwerken als gevolg van geheimhoudingsverplichtingen (in verband met functie/wet) komt niet expliciet aan de orde in de ontvangen ontwerp documentatie. Maar niet op voorhand uit te sluiten is, dat dit bijvoorbeeld binnen de sectorale toepassingen (bijvoorbeeld bij zorginstellingen) wel het geval zou kunnen zijn. De ontwerpeisen van het eid Stelsel bevatten (indicaties voor) (nadere) controles op het gebruik van (nieuwe) persoonsgegevens binnen de kaders van het eid Stelsel. De controles zijn nog niet op alle hiervoor in aanmerking komende verwerkingen van persoonsgegevens in beeld gebracht. In de ontwerpdocumentatie is nog geen aandacht besteed aan een eventuele overdracht van persoonsgegevens door de Stelselautoriteit en eid Deelnemers naar een (overheids)instantie buiten de EU/EER, en als dat zo mocht zijn, hoe dan dient te worden gehandeld ingeval dit een land betreft dat geen passend privacy beschermingsniveau heeft. Zie in dat verband ook de risico s die ten aanzien van ICT-(sub)bewerkers in bij de handeling van het privacy principe Verantwoording aan de orde kwamen. 15

16 Uit de ontwerpdocumentatie blijkt ook, dat dat alle ontwikkelingen op het gebied van (elektronische) identiteit, authenticatie en machtigen van burgers mogelijke impact hebben op de privacy. Bij toegang tot persoonsgegevens (zoals BSN, adres en leeftijd), al dan niet via diensten, dient grote zorgvuldigheid in acht genomen te worden. Het eid-programma betrekt er daarom belangen- en maatschappelijke organisaties en toonaangevende media bij. Ideeën en denkbeelden, maar ook voorgestelde (deel)oplossingen, worden zo in een vroegtijdig stadium vanuit verschillende gezichtspunten gedeeld en besproken. Verder worden deze organisaties in het vervolg van het ontwikkelproject eid betrokken bij Privacy Impact Analyses en geconsulteerd in het kader van het wetgevingstraject. Waarmee in de ontwerpdocumentatie aangetoond wordt, dat de ontwerpers de privacy van de Gebruikers hoog in het vaandel hebben staan Aanbevelingen 1. Specificeer alle persoonsgegevens die tussen de in het eid Stelsel te onderscheiden eid Deelnemers (per rol) en Dienstaanbieders (per rol) over de koppelvlakken worden uitgewisseld. 2. Specificeer daarbij ook de directe en indirecte persoonsgegevens die in de eid Stelsel ICT-infrastructuur over de koppelvlakken in de loggingen/audittrails van de eid Deelnemers/Dienstaanbieders worden opgeslagen. 3. Specificeer per verwerking per component/rol in het eid Stelsel wat het specifieke doel van een verwerking is. 4. Beoordeel tenslotte per component/rol of combinaties van componenten/rollen de doeleinden voor die verwerkingen en of de hiervoor te verwerken persoonsgegevens binnen die doelstellingen passen. 5. Hou bij de mogelijkheden van meerdere rollen bij eid Deelnemers rekening met ongewenste cumulatie van data in de audittrails die de genoemde risico s doen toenemen. 6. Denk tijdens de ontwerpfase tijdig na over de noodzaak/wenselijkheid van het verwerken van biometrische gegevens ten behoeve van de doelstellingen van het Stelsel. 7. Laat aanvullend onderzoek uitvoeren naar mogelijke verwerkingen van persoonsgegevens door eid Deelnemers en Dienstaanbieders binnen het eid Stelsel waaraan vanwege (sectorale of specifieke) geheimhoudingsverplichtingen in verband met functie/wet beperkingen voor het gebruik zijn verbonden. 8. Neem zonodig in de ontwerpeisen mee of er sprake kan zijn van overdracht van persoonsgegevens naar een (overheids)instantie buiten de EU/EER. 9. Stel nadere eisen / geef handreikingen in het Afsprakenstelsel op alle doelstellingen en uit te voeren controles op het gebruik van persoonsgegevens in de te onderscheiden ICT-omgevingen/ componenten van het eid Stelsel en laat hieraan voorafgaand een specifieke risicoanalyse uitvoeren. 10. Neem in het Afsprakenstelsel toereikende voorwaarden voor doelbinding en toezicht op om de gesignaleerde risico s te elimineren. 11. Dwing dit zonodig met specifieke wetgeving af. 2.8 Privacy principe Gegevenskwaliteit Bevindingen Uit de bevindingen aangaande het Doelbindingsprincipe, kan worden afgeleid, dat in de ontwerpeisen van het eid Stelsel aanzetten zijn gegeven voor controles om de juistheid, nauwkeurigheid en actualiteit (kwaliteit) van de in het eid Stelsel verwerkte persoonsgegevens na te gaan. In de periodiciteit en specifieke inrichting van deze controles moet nog worden voorzien. In het verlengde van ontwerpeisen in relatie tot toezicht en opsporing is naar onze mening hier sprake van een bijzondere situatie. Belangrijk onderdeel van de algemene privacy principes is het borgen van de datakwaliteit (zie bijlage 1). Ook binnen het eid Stelsel waarbij het gaat om digitale identiteiten dienen kwaliteit borgende maatregelen te worden getroffen. Maatregelen voor het controleren van de betrouwbaarheid van digitale identiteiten en het 16

17 detecteren van inconsistenties in identificerende gegevens dienen een normaal onderdeel te zijn van het systeem en de verwerkingsprocessen. Over het algemeen is een mix van preventieve en repressieve maatregelen nodig om de kwaliteit van gegevensverwerkende processen te borgen. Deze maatregelen, die deels ook het karakter zullen hebben van maatregelen voor het beperken en detecteren van identiteitsfraude, moeten niet verward worden met activiteiten van eventuele opsporingsinstanties. Het doel van het Stelsel is het verwerken van betrouwbare digitale identiteiten en daaraan gerelateerde data. Controle van de kwaliteit van data hoort daar onlosmakelijk bij. En uiteraard staat controle meestal op gespannen voet met het vertrouwelijkheidsaspect van privacy Aanbeveling 1. Definieer in de volgende ontwikkelingsfase in het Afsprakenstelsel op elkaar aansluitende incidentele en periodieke controles op de kwaliteit van de verwerkte persoonsgegevens door de te onderscheiden componenten in het eid Stelsel. 2.9 Privacy principe Beveiliging van gegevens (Privacy by Design en Privacy Enhancing Technologies) Bevindingen In de ontwerp-documentatie is nog niet voorzien in het opstellen, implementeren en handhaven van beleid met betrekking tot de gegevensbeveiliging bij de eid Deelnemers. Het risico hiervan is, dat het niveau van de beveiliging van persoonsgegevens door de eid Deelnemers binnen het eid Stelsel kan variëren en tot zwaktes in de eid-keten kan leiden. Voor het geval dat een eid Deelnemer voor diens rol in het eid Stelsel en de daarmee gegaard gaande verwerking van persoonsgegevens de status van bewerker zal aannemen, is in de ontwerp documentatie nog niet voorzien hoe verantwoordelijken in het eid Stelsel zorg dienen te dragen voor de gegevensbeveiliging en het toezicht hierop bij hun bewerkers. In de ontwerp documentatie is al wel, zij het op onderdelen wat gefragmenteerd, aandacht besteed aan technische en organisatorische beveiligingsmaatregelen die zijn getroffen ter voorkoming van niet-geautoriseerde of onrechtmatige verwerking/misbruik van persoonsgegevens in het eid Stelsel. Deze maatregelen liggen vooral nog op het niveau van het gebruik van (Polymorfe) PseudoID s en de versleuteling van data gedurende de communicatie tussen de eid Deelnemers onderling en de Dienstaanbieders. Het gebruik van (Polymorfe) PseudoID s is de kern van het eid Stelsel, waarmee invulling wordt gegeven aan belangrijke privacy principes als dataminimalisatie. Tevens kunnen deze maatregelen onder de noemer gebruik van privacy enhancing technologies en het toepassen van privacy by design worden gebracht. Ook is op belangrijke componenten/koppelvlakken het berichtenverkeer encrypted. Voor een tweetal componenten dient dit nog te worden ingevuld. In de technische en organisatorische beveiligingsmaatregelen, dan wel de hiervoor te hanteren beveiligingsstandaarden door eid Deelnemers en Dienstaanbieders in hun respectievelijke backoffice systemen is nog niet voorzien. Hierbij valt bijvoorbeeld ook te denken aan de beveiliging en het beheer van de geheime sleutels van eid Deelnemers en Dienstaanbieders. Dit geldt ook voor de Stelselautoriteit. In de ontwerp documentatie is tenslotte nog niet voorzien in procedures in geval van inbreuken op beveiligingsvoorschriften, en voor het detecteren ervan. Dit geldt ook voor calamiteitenplannen met het oog op de gevolgen van een onvoorziene gebeurtenis waarbij persoonsgegevens worden verloren of worden blootgesteld aan onrechtmatige verwerking. De ontwerp documentatie bevat nog geen concrete informatie over de bewaar en vernietigingstermijnen voor de te onderscheiden verwerkingen van persoonsgegevens door de Stelselautoriteit, de eid Deelnemers en de Dienstaanbieders. Dit geldt ook voor het eventueel onderhevig zijn aan wettelijke sectorale eisen met betrekking tot bewaring. 17

18 2.9.2 Aanbevelingen 1. Voorzie in het Afsprakenstelsel in normen / standaarden voor het beveiligen van persoonsgegevens voor de Stelselautoriteit, eid Deelnemers en Dienstaanbieders, waarmee convergentie in de beveiligingsaanpak wordt bewerkstelligd. 2. Neem daarin op, dat eid Deelnemers en Dienstaanbieders (en hun bewerkers) jaarlijks dienen te worden onderwerpen aan een beveiligingsaudit door hiertoe erkende gekwalificeerde onafhankelijke instellingen en dat iedere Partij jaarlijks het auditrapport (of Third Party Memorandum) aan de Stelselautoriteit dient te overleggen. 3. Neem in het Afsprakenstelsel een voorziening op voor het melden van beveiligingsincidenten en datalekken binnen de eid infrastructuur en de eid Deelnemers bij de Stelselautoriteit en andere relevante toezichthouders, zoals het CBP. 4. Zorg in het Afsprakenstelsel voor op elkaar afstemde richtlijnen over het bewaren van persoonsgegevens voor de Stelselautoriteit, de eid Deelnemers en de Dienstaanbieders. 5. Hou daarbij rekening met mogelijke gedifferentieerde bewaartermijnen per type verzamelde persoonsgegevens. 6. Betrek daar daarbij ook de relevante wettelijke/sectorale eisen met betrekking tot de bewaring van bepaalde typen van persoonsgegevens. 7. Zorg in ieder geval dat inzichtelijk wordt op basis van welke beleidsmatige en technische gronden bewaartermijnen voor bepaalde typen van persoonsgegevens binnen het eid Stelsel zijn vereist. 8. Zorg dat in het Afsprakenstelsel ook maatregelen zijn voorzien om de persoonsgegevens na afloop van de bewaartermijn te vernietigen. Hierbij dient ook aandacht te worden besteed aan gegevens in loggingen en audittrails. 9. Zorg er tenslotte voor dat de bewaartermijnen en de vernietiging van persoonsgegevens onderdeel uitmaken van de scope van certificeringsaudits Privacy principe Transparantie Bevindingen Burgers die reeds gebruik maken van bestaande authenticatievoorzieningen als DigiD en e- Herkenning kunnen in zekere zin bekend zijn met de identificatie en authenticatiedoeleinden voor dat deel van het toekomstige eid Stelsel. Zowel aan de kant van de overheid als van marktpartijen zijn er immers verschillende bestaande ICT-voorzieningen die, na migratie, zullen worden opgenomen in het eid Stelsel. Denk hierbij aan: DigiD, DigiD Machtigen, eherkenning en PKIoverheid. Maar in de ontwerp documentatie is ook aangegeven dat de werking van het eid Stelsel complex is. Dit betekent dat niet op voorhand mag worden aangenomen, dat de werking van het nieuwe eid Stelsel voor de Gebruiker, alsmede het gebruik van diens gegevens door relevante eid Deelnemers en Dienstaanbieders transparant is. Nu het eid Stelsel als publieke-privaat stelsel voor electronische identificatie, authenticatie en autorisatie met bestaande, maar ook met nieuwe partijen samenwerkt, is het noodzakelijk dat de betrokkenen vooraf worden geïnformeerd over het bestendigen of aanvullen van het doel van het verwerken van hun persoonsgegevens binnen het eid Stelsel. Dus ook met welke specifieke wijzingen en aanvullingen het eid Stelsel gepaard gaat. Hierbij dient in aanmerking te worden genomen, dat zich binnen het eid Stelsel, afhankelijk van de rol/combinatie van rollen die een component / eid Deelnemer binnen dit Stelsel vervult, bij de betrokkene kenbaar moet zijn of aan de betrokkene kenbaar moet worden gemaakt, voor welk specifiek doel zijn gegevens bij welke component voorwelke rollen worden verzameld en verder verwerkt. Afhankelijk van het gebruik dat een betrokkene (Gebruiker/Belanghebbende) van het eid Stelsel maakt, zal de informatie hier op toegespitst moeten zijn. Hoewel er van mag worden uitgegaan, dat de Gebruiker over de diensten in het eid Stelsel zal worden geïnformeerd, zal hier volledigheidshalve in het Afsprakenstelsel aandacht aan moeten worden besteed. Dit nu is in die samenhang nog niet voorzien in de ontwerp documentatie van het eid Stelsel. In het voorgaande is reeds aan de orde gekomen, dat in ontwerpdocumentatie nog niet alle stappen van de verwerking in de zin van soorten gegevens en uitwisselingen, volledig in kaart 18

19 zijn gebracht, althans niet zodanig dat daardoor voor de betrokkenen inzichtelijk is bij wie, waarom en hoe de persoonsgegevens worden verwerkt. Aangezien het ontwerp nog verder wordt uitgewerkt, zullen aanvullende stappen in de verwerkingen en in gegevensuitwisseling in de volgende ontwerpversies worden toegevoegd. Er is in ieder geval geen aanleiding om te veronderstellen dat de beoogde gegevensuitwisselingen niet inzichtelijk in kaart kunnen worden gebracht en vervolgens ook transparant voor de Gebruikers kunnen worden gemaakt Aanbevelingen 1. Neem in de ontwerpeisen van het eid Stelsel op, dat in het Afsprakenstelsel geregeld wordt dat aan Gebruikers kenbaar wordt gemaakt welke eid Deelnemers op welke momenten voor welke doeleinden hun persoonsgegevens verwerken. 2. Bewerkstellig hiermee een convergente en met elkaar samenhangende toepassing van het transparantiebeginsel bij alle eid Deelnemers binnen het eid Stelsel. 3. Ga door met het in kaart brengen van alle stappen van de verwerking in de zin van soorten gegevens en uitwisselingen, zodanig dat daardoor voor de betrokkenen inzichtelijk is bij wie, waarom en hoe de persoonsgegevens worden verwerkt. 4. Besteed daarbij ook aandacht aan metadata die binnen het eid Stelsel in systeemloggingen/audittrails wordt verwerkt. 5. Stem, in de veronderstelling, dat er mediacampagnes over de werking van het eid Stelsel zullen komen, de uitvoering van de voorgaande aanbevelingen hier op af Privacy principe Rechten van betrokkenen Bevindingen Het is nog niet te overzien of er in de ontwerp-documentatie voldoende aandacht is besteed aan de principes van opt-in / opt-out voor Gebruikers van het eid Stelsel en welke attributen die nu precies betreft. In de ontwerp documentatie is nog niet met zoveel worden geregeld via welke procedure betrokkenen de mogelijkheid hebben zich tot de verantwoordelijken in het eid Stelsel te wenden met het verzoek hen mede te delen of hun persoonsgegevens worden verwerkt. Dit geldt ook ten aanzien van derden, die mogelijk bedenkingen hebben tegen een dergelijke mededeling, en in de gelegenheid moeten worden gesteld om hun zienswijze te geven. Evenzeer voor het regelen van de wijze waarop een verzoek van een betrokkene tot verbetering, aanvulling, verwijdering of afscherming van persoonsgegevens in behandeling moet worden genomen. Wel zijn er op onderdelen impliciet aanzetten tot het inzagerecht van betrokkenen. In dit stadium van de ontwerpeisen van het eid Stelsel kan zodoende in de ontwerp documentatie ten aanzien van (andere) eid Deelnemers (zoals de SectorID Dienst die in feite Attributendienst is, de Attributendienst, de Machtigingendienst, de eid-makelaar) nog niet worden gesproken van op elkaar afgestemde concrete inzage procedures voor betrokkenen (Gebruikers). Althans niet met zoveel woorden waar de norm op doelt. Ook niet hoe eventuele derden, die mogelijk bedenkingen zou kunnen hebben tegen een dergelijke mededeling, in de gelegenheid gesteld kunnen worden om hun zienswijze te geven. Dit geldt evenzeer voor concrete en formele procedures voor het in behandeling nemen van verzoeken van een betrokkenen tot verbetering, aanvulling, verwijdering of afscherming van persoonsgegevens. Een Dienstbemiddelaar kan optreden als bewerker namens een of meerdere Dienstaanbieders of op eigen titel als verantwoordelijke (P22) Naast Dienstaanbieder en Dienstbemiddelaar wordt in het stelsel ook het begrip Diensteigenaar gebruikt. De Diensteigenaar is de partij die beslist over de indeling en naamgeving van de diensten en over alle beleidsmatige aspecten die gelden voor de betreffende dienst, zoals het vereiste Betrouwbaarheidsniveau (P23). 11 Voor diensten waarvoor in het stelsel maar één Dienstaanbieder is, is de Dienstaanbieder tevens Diensteigenaar. Als de dienst door meerdere partijen wordt aangeboden fungeert een overkoepelend orgaan als Diensteigenaar. 11 Zie Werking van het eid Stelsel, de ontwerpeisen P22 en P23. 19

20 Deelnemers aan het eid Stelsel die tot op personen te herleiden gegevens verwerken zijn ieder voor zich, voor wat hun aandeel in de verwerking betreft, verantwoordelijk voor het naleven van privacy- wet en regelgeving. Gezien de data interactie tussen de Stelselautoriteit en de meerdere te onderscheiden eid Deelnemers in een identificatie/authenticatie/machtigings/vertegenwoordigingsproces, is het voorstelbaar dat een betrokkene, wil hij zijn rechten effectueren, door de bomen het bos niet meer ziet en mogelijk van het kastje naar de muur wordt gestuurd. Dit zou het inzagerecht voor wat betreft het eid Stelsel tot een fictie kunnen maken Aanbevelingen 1. Besteed in de volgende ontwerp fasen aandacht aan opt-in / op-out mogelijkheden voor Gebruikers bij de daarvoor in aanmerking komen diensten / attributen en neem dit indien relevant in het Afsprakenstelsel mee. 2. Besteed in het Afsprakenstelsel aandacht aan procedures voor de eid Deelnemers / Dienstaanbieders voor het effectueren van rechten van betrokkenen (Gebruikers). 3. Geef daarbij handreikingen om convergentie in de afhandeling ervan bij de Stelselautoriteit, eid Deelnemers en Dienstaanbieders te bewerkstelligen. 4. Geef ook handreikingen voor een efficiënte en effectieve routing van de afhandeling van deze verzoeken van Gebruikers ingeval de afhandeling ertoe moeten leiden dat meerdere eid Deelnemers zich hiermee moeten gaan bezig houden. Bedenk daarbij ook, dat er omstandigheden kunnen zijn, waarin derden, die mogelijk bedenkingen hebben tegen een dergelijke mededelingen, in de gelegenheid moeten worden gesteld om hun zienswijze te geven. 5. Zorg er ook voor dat het voor de Gebruiker transparant is tot wie welk verzoek inzake welk recht (het beste) kan worden gericht Neem de voorzieningen voor de rechten van betrokkenen mee in de het Afsprakenstelsel over de verplichte en periodiek uit te voeren certificeringsaudit voor de eid Deelnemers. 12 Wellicht kan worden nagedacht over de instelling van een onafhankelijke partij als de eid Ombudsman. 20

21 3. Beschrijving eid Stelsel. 3.1 Inleiding Als object van onderzoek zijn door BZK de volgende ontwerpdocumenten, versie 1.0, d.d. 21 januari 2014, status concept; van het Programma eid aan MMC ter beschikking gesteld: 1. Voorwoord eid Afsprakenstelsel, waarin tot uiting komt dat deze ontwerpversie uit 5 aparte secties bestaat. Elke sectie heeft een apart document en kan uit meerdere hoofdstukken bestaan; 2. Introductie op het eid Stelsel. Hierin wordt de huidige situatie rondom authenticatie en autorisatie uitgelegd en de invloed van het eid Stelsel en de werking ervan aan de hand van de belangrijkste ontwerpeisen beschreven. Tot slot een eenvoudige uitleg van het inlogproces binnen het eid Stelsel; 3. Stakeholders, belangen en ontwerpeisen. Na de beschrijving van de stakeholders en de bijbehorende belangen volgen in detail de aan het eid Stelsel te stellen ontwerpeisen; 4. Werking van het eid Stelsel. Deze sectie bevat het volledige ontwerp van het stelsel met alle componenten en hun interacties; 5. Interface specifications. In het Engels zijn de technische specificaties voor de koppelvlakken in het stelsel beschreven. Ook hoe de verklaringen als SAML-bericht verzonden moeten worden; 6. Begrippenlijst eid Afsprakenstelsel. Het huidige ontwerp van het eid Stelsel is, zoals gezegd, nog in een ontwikkelingsfase. De hierboven genoemde ontwerp versie is het vervolg op het document eid Afsprakenstelsel 0.7 van oktober 2013 en heeft tot doel om de werking en het ontwerp technologisch en procesmatig te beproeven. Deze beproeving gebeurt in een publiek-private samenwerking. Het gaat hierbij uitdrukkelijk om proeven en nog niet om pilots. Dit traject van POT s (Proofs of Technology) en POC s (Proofs of Concept) is op het moment van publicatie van dit document in voorbereiding. Publieke en private organisaties die digitale diensten aanbieden kunnen (met BZK) aan de hand van deze versie de implementatiemogelijkheden toetsen. Daarnaast is deze versie input voor andere onderdelen van het eid Stelsel zoals wetgeving, toezicht, beheer, testomgevingen, privacy- en risicoanalyses, usability, etc. Het document is tevens input voor impactanalyses op bestaande diensten en voorzieningen zowel aan de kant van de dienstaanbieders als aan de kant van potentiele deelnemers aan het eid Stelsel. In dit kader vindt nu een toetsing en nadere uitwerking voor het M2M-kanaal plaats en zullen op korte termijn de bijzondere machtigingssituaties worden beschreven. Uitkomsten van deze acties zullen input zijn voor de volgende versies van het ontwerp van het eid Stelsel, waarvan de 2.0-versie is gepland voor oktober In dit hoofdstuk wordt ten behoeve van de uitvoering van de PIA op basis van de hierboven verantwoorde ontwerp documentatie achtereenvolgens inzicht verschaft in: De aanleiding voor het eid Stelsel; Doelstellingen van het eid Stelsel; De stakeholders bij het eid Stelsel Beoogde resultaten met het eid Stelsel; Ontwerpeisen voor het eid Stelsel; Schets van de werking van het eid Stelsel. Dit gebeurt aan de hand van uit de ontwerp documentatie overgenomen teksten, diagrammen, modellen, en figuren. Dit wordt zo getrouw mogelijk gedaan, maar er is hierbij geen volledigheid nagestreefd. Voor de precieze werking van het eid Stelsel wordt naar de inhoud van de aangehaalde documenten verwezen. Wij hebben per tekstdeel aangegeven uit welk document het tekstdeel is overgenomen.. Voor de toelichting van gehanteerde begrippen en definities is het oog op de toegankelijkheid van de teksten zo veel mogelijk gekozen voor verwijzingen naar de noten onderaan een pagina. 21

22 3.2 De aanleiding voor een nieuw eid Stelsel [Samengevat uit document: Introductie op het eid Stelsel, ] De maatschappij wordt in hoog tempo gedigitaliseerd, zowel in de private als in de publieke sector. De overheid biedt steeds meer digitale diensten aan de burgers via internet. Naast slimme ICT toepassingen en goed georganiseerde processen vereist de elektronische dienstverlening vooral een hoge betrouwbaarheid en een betrouwbare authenticatie (wie ben je?) en autorisatie (wat mag je?). Anders gezegd, in de digitale wereld is het wenselijk dat identificering, autorisatie en ook het verstrekken van machtigingen (wat mag je, namens wie?) op een zelfde betrouwbaarheidsniveau en met een zelfde gemak kan plaatsvinden als in de reële wereld. De Nederlandse overheid, in casu het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties (BZK), verschaft burgers een administratieve identiteit. Op basis daarvan geeft BZK fysieke identiteitsbewijzen uit, die burgers in het maatschappelijk verkeer kunnen gebruiken. De overheid voert het beheer over die voorziening. Nederland heeft behoefte aan een sterk elektronisch identiteitensysteem (eid). Het huidige systeem is voor verbetering vatbaar zoals blijkt uit de diverse soorten incidenten die met enige regelmaat in de media komen. Voorts zijn in 2013 een aantal onderzoeken door de rijksoverheid gepubliceerd over omvangrijke identiteitsfraude in Nederland en andere vormen van computercriminaliteit die eveneens aanleiding geven tot optimalisatie van het huidige digitale identiteitenstelsel. De sterk digitaliserende maatschappij vereist, nogmaals benadrukt, een elektronisch identiteitensysteem met een hoge betrouwbaarheid en dat vertrouwd kan worden. Daarbij wil de overheid naar een maximale serviceverlening aan de burger en aan bedrijven via digitale kanalen. Hierbij wil zij zowel het publieke als het private domein faciliteren. Overleg met private sectoren over het nieuwe identiteitenstelsel is onderhanden. In het bijzonder worden daarbij de volgende sectoren genoemd: financiële sector, banken, verzekeringsmaatschappijen, zorgsector, maar ook geregistreerde beroepen, zoals: notariaat, advocaten, accountants et cetera. Het doel is het ontwikkelen van één stelsel waarbinnen middelen gebruikt worden voor zowel het publieke als het private domein. 13 Het beoogde eid stelsel bevat voor een aantal publieke en private deelnemers 14 koppelvlakken waarover gegevens van identificeerbare personen worden uitgewisseld. Deze verwerkingen van persoonsgegevens zullen aan toereikende veiligheids- en privacynormen moeten voldoen. Het beoogde stelsel maakt gebruik van meerdere soorten ICT-middelen teneinde de afhankelijkheid van één middel te vermijden en om fallback scenario s in geval van calamiteiten mogelijk te maken. Verder wordt geopteerd voor de mogelijkheid om, afhankelijk van de aard van de gevraagde dienstverlening en de gevoeligheid van het beoogde eid middel, gebruik te maken van verschillende betrouwbaarheidsniveaus (STORK levels 2 t/m 4). 13 BZK werkt hier aan het ontwikkelen van een eid Stelsel waaraan qua aanleiding en doelstellingen een zwaar wegend algemeen maatschappelijk belang ten grondslag ligt. De argumenten waarom BZK het eid Stelsel ontwikkeld zijn hiervoor toereikend. Dit is ook de grondslag voor het voldoen aan het noodzakelijkheidsbeginsel. Het ontwerp van het Stelsel, zoals dit in de ontwerp documentatie wordt geschetst voldoet overwegend aan de beginselen van de proportionaliteit en subsidiariteit. In dat verband wordt ook verwezen naar de relevante behandeling van deze onderwerpen in hoofdstuk 4 van dit rapport. 14 eid Deelnemer: Een eid-deelnemer is een organisatie die specifieke diensten binnen het eid Stelsel aanbiedt. Elke eid-deelnemer treedt officieel toe tot het eid Stelsel en is daarmee gebonden aan de standaarden en afspraken zoals beschreven in het eid Afsprakenstelsel. Tevens is elke eid-deelnemer onderhavig aan toezicht en handhaving. Voorbeelden van eid-deelnemers zijn een Authenticatiedienst, een Attribuutdienst en een eid-makelaar. 22

23 Het eid stelsel NL dient geschikt te zijn om bestaande voorzieningen te kunnen blijven gebruiken, zoals: eherkenning 15, PKI-overheid en DigiD. Dit geldt ook voor het gebruik van al bestaande authenticatiemiddelen. Eventueel zal migratie moeten kunnen plaatsvinden naar nieuwe afsprakenstelsels. Nieuwe voorzieningen moeten uiteraard direct aan de nieuwe afsprakenstelsels voldoen. Denk hierbij aan het erijbewijs, de enik en private middelen. Het stelsel dient uiteindelijk ook internationale (op Europees niveau) ontwikkelingen aan te haken teneinde zich open te stellen voor de interne markt en hiermee grensoverschrijdende services te ondersteunen (internationale operabiliteit). De overheid wil dat het ontwerp van het nieuwe eid stelsel eind 2014 gereed is voor realisatie en volledig operationeel is in Doelstellingen van eid Stelsel [Tekst uit document: Stakeholders, belangen en ontwerpeisen, ] Het doel van het eid Stelsel NL is: 1. het creëren van een toekomstbestendige en betrouwbare elektronische identiteitsinfrastructuur die gebruikt kan worden door zowel publieke als private Dienstaanbieders 16 en die publiek-privaat beheerd en doorontwikkeld wordt. 2. Mogelijk maken dat publieke Dienstaanbieders de toegang en afhandeling van online dienstverlening vanaf 2015 via het eid Stelsel kunnen inrichten waardoor zij de doelstelling Digitaal 2017 uit het regeerakkoord kunnen realiseren: Bedrijven en burgers kunnen in 2017 zaken met de overheid digitaal afhandelen. 17 Het eid Stelsel moet de volgende diensten mogelijk maken: Authenticatie 19 met hoog betrouwbaarheidsniveau; 2. Verificatie van aanvullende gegevens (attributen) zoals leeftijd; 3. Ondersteuning (wettelijke) vertegenwoordiging; 4. Een betrouwbare, praktisch handzame en bruikbare elektronische handtekening. In de doelstellingen worden ook de belangen van de stakeholders van het eid Stelsel meegenomen. De belangen van de stakeholders die direct gevolgen hebben voor het ontwerp zijn: Verhogen beveiliging en betrouwbaarheidsniveau; 2. Verhogen vertrouwelijkheid en zorgvuldige omgang met privacygevoelige informatie; 3. Gebruikersgemak en toegankelijkheid; 4. Participatie private partijen (level playing field in stand houden). Invulling: privaat wat kan, publiek (alleen) wat moet; 5. Verbetering continuïteit digitale dienstverlening; 6. Toekomstvastheid (uitbreidbaar); 7. Beperken kosten. 15 eherkenning is het publiek-private stelsel dat regelt dat bedrijven zich digitaal kunnen authentiseren en autoriseren wanneer ze online zaken regelen met de overheid en met private partijen. 16 Dienstaanbieder: Een Dienstaanbieder is een persoon (natuurlijk of niet-natuurlijk) die kenbaar heeft gemaakt dat het elektronisch bereikbaar is voor burgers en bedrijven, zodat zij als Handelende Persoon in staat worden gesteld om digitale transacties in het kader van een dienst te kunnen uitvoeren. 17 Bron: Stakeholders, belangen en ontwerpeisen, par Bron: Stakeholders, belangen en ontwerpeisen, par Het bewijzen en controleren van de geclaimde identiteit van een Handelende Persoon via een (set van) authenticatiemiddel(len) op een bepaald betrouwbaarheidsniveau. 20 Bron: Stakeholders, belangen en ontwerpeisen, par

24 3.4 Stakeholders bij het eid Stelsel [Tekst uit document: Stakeholders, belangen en ontwerpeisen, ] Belangrijke stakeholders bij het eid Stelsel zijn: 21 Beleidsverantwoordelijke ministeries Ministerie van Binnenlandse Zaken en Koninkrijksrelaties (Min BZK) Ministerie van Economische Zaken (Min EZ DG Uitvoering) Belanghebbende organisaties Belangenorganisaties College Bescherming Persoonsgegevens (CBP), de Consumentenbond, Bits of Freedom, de Autoriteit Consument en Markt (ACM) en toonaangevende media. Wetenschappers en experts Manifestgroep Publieke eid Deelnemers Logius Gemeenten Private eid-deelnemers Leveranciers eherkenning (ICT) Leveranciers Publieke dienstaanbieders Ministerie van Veiligheid en Justitie Ministerie van Volksgezondheid, Welzijn en Sport Vereniging van Nederlandse Gemeenten (VNG) en Nederlandse Vereniging Voor Burgerzaken (NVVB) Belastingdienst Rijksdienst voor het Wegverkeer (RDW) Uitvoeringsinstituut Werknemersverzekeringen (UWV) Sociale Verzekeringsbank (SVB) Private Dienstaanbieders Financiële Dienstaanbieders Webwinkels 3.5 Beoogde resultaten met het eid Stelsel [Tekst uit document: Introductie op het eid Stelsel, ] Met het ontwerp eid Stelsel worden de volgende resultaten beoogd: Een gestandaardiseerde manier om de authenticatie en bevoegdheid voor het afnemen van alle digitale diensten vast te stellen. 2. Het gaat hierbij om persoonsgebonden digitale diensten. Dat hoeft niet altijd te betekenen dat de identiteit eenduidig vastgesteld moet worden. Het kan ook gaan om andere kenmerken van een persoon, bijvoorbeeld of de persoon ouder dan 18 jaar is, of juist kunnen aantonen dat de persoon jonger is dan 12 jaar. 3. Een technologie-onafhankelijk ontwerp. Hierdoor kunnen zowel bestaande als nieuwe manieren voor het vaststellen van de authenticatie en de bevoegdheid worden ingezet. 21 Bron: Stakeholders, belangen en ontwerpeisen, par Zie Introductie op het eid Stelsel, p.5. 24

25 4. Voor natuurlijke en niet-natuurlijke personen gelden dezelfde standaarden, met als resultaat dat het vaststellen van de authenticatie en de bevoegdheid in het burger- en het bedrijvendomein uitwisselbaar is. 5. De verantwoordelijkheden van de verschillende partijen die betrokken zijn bij de levering van een digitale dienst en het vaststellen van de authenticatie en bevoegdheid van de persoon die deze dienst afneemt, zijn duidelijk beschreven. Hierbij zijn maatregelen genomen die ervoor zorgen dat de privacy gewaarborgd wordt. 3.6 Ontwerpeisen voor het eid Stelsel [Tekst uit document: Introductie op het eid Stelsel, ] In de sectie Werking van het stelsel is beschreven op welke wijze de ontwerpeisen zijn verwerkt in het ontwerp van het eid Stelsel. De ontwerpeisen voor het eid Stelsel zijn als volgt geclusterd: Ontkoppelen en ontzorgen van de Dienstaanbieder 2. Waarborgen van de privacy 3. Marktwerking mogelijk maken 4. Gebruikersgemak bevorderen 5. Toezicht en opsporing inrichten Ontkoppelen en ontzorgen van de Dienstaanbieder Beoogde effect: Dienstaanbieder is ontkoppeld van (technologisch) aanbod van leveranciers van Authenticatiemiddelen. 24 Het inlogproces wordt door de Dienstaanbieder als dienst afgenomen van een eidmakelaar (vergelijkbaar met een ideal-betaling) 25. Dezelfde standaarden voor zowel portaaldiensten als machine-to-machinediensten Nevenstaande figuur illustreert de ontkoppeling van het eid-middel van de Dienstaanbieder. De Dienstaanbieder kiest de eid-makelaar waarmee de gebruiker kan inloggen. Een eid-makelaar is een aparte dienst die onder andere inlogprocessen aanbiedt. Deze eid-makelaar laat de eid-middelen zien waarmee de gebruiker kan inloggen. De gebruiker kan vervolgens zelf het eid-middel selecteren waarmee hij wil inloggen. Op deze wijze kan hij met hetzelfde middel terecht bij meerdere Dienstaanbieders. Via gestandaardiseerde verklaringen weet de Dienstaanbieder met wie hij te maken heeft (via een Identiteitsverklaring) en wat deze gebruiker mag (via een Bevoegdheidsverklaring). Vervolgens bepaalt de Dienstaanbieder of de gebruiker de gewenste handeling mag uitvoeren. Dit is het autorisatiebesluit. 23 Stakeholders, belangen en ontwerpeisen, par Dit is een set van attributen op basis waarvan een Gebruiker zich kan laten authentiseren. Het Authenticatiemiddel kan verschillende verschijningsvormen hebben, bijvoorbeeld een combinatie van gebruikersnaam en wachtwoord zijn of een in software, op een smartcard of in andere specifieke hardware opgeslagen certificaat. Een Authenticatiemiddel wordt ook wel eid-middel genoemd. 25 De eid-makelaar is een eid-deelnemer die namens een Dienstaanbieder aan de Handelende Persoon de keuze voor de gewenste Authenticatiedienst en eventueel Machtigingsdienst voorlegt. Deze partij controleert ook of alle benodigde verklaringen voor het afnemen van de gevraagde dienst beschikbaar zijn (de bevoegdheidsketen) en levert via een gestandaardiseerd koppelvlak de resultaten terug aan de Dienstbemiddelaar. 25

26

27

28 Zolang de gebruiker hetzelfde Authenticatiemiddel gebruikt, wordt steeds dezelfde PseudoID gebruikt en blijft de koppeling met het klantnummer van de Dienstaanbieder in het koppelregister in tact. In de praktijk zullen echter veel gebruikssituaties voorkomen waarbij de gebruiker een ander Authenticatiemiddel gaat gebruiken. Bijvoorbeeld: Mijn middel is verlopen, ik krijg een nieuwe. Dan wil ik met mijn nieuwe middel nog steeds bij mijn bestaande klantaccount kunnen inloggen. Ik wil met een tweede middel kunnen inloggen bij een bestaand klantaccount. Ik stap over naar een andere Authenticatiedienst en krijg daar een nieuw middel. Met dat nieuwe middel wil ik nog steeds kunnen inloggen bij een bestaand klantaccount. Bovenstaande is als beeld te vergelijken met het nummerbehoud bij abonnementen van mobiele telefoons. De houder kan ervoor kiezen om bij wijziging van provider het mobiele nummer te behouden. Dezelfde werkwijze wordt ook ondersteund in het eid Stelsel. De houder van een middel moet zelf de keuze kunnen maken om aan een Authenticatiedienst te verzoeken dat een nieuw middel dezelfde PseudoID s genereert. De PseudoID s zijn dan niet afhankelijk van het specifieke middel, maar zijn persistent gemaakt op persoonsniveau. Het voordeel hierbij is dat bij een nieuw middel de bestaande koppelingen bij diverse Dienstaanbieders intact blijven. Om persoonlijke redenen (bijvoorbeeld privacy) kan een gebruiker ervoor kiezen om bij een nieuw Authenticatiemiddel juist wel nieuwe PseudoID s te genereren. Om zijn bestaande klantaccount bij een Dienstaanbieder dan te behouden, zal er wel een nieuwe koppeling tot stand moeten komen. De onderstaande figuur illustreert nogmaals de keuzevrijheid. 28

29

30 3.7.1 Systeemdiagram eid Stelsel [Tekst uit document: Werking van het eid Stelsel, hoofdstuk 1, ] Onderstaand diagram toont de verschillende componenten van het stelsel en de belangrijkste koppelvlakken. De hier geschetste componenten zijn rollen. Er zijn eid-deelnemers die gecertificeerd zijn en hun diensten aanbieden aan andere partijen of aan Gebruikers. eid-deelnemers kunnen zich specialiseren en bijvoorbeeld alleen een makelaarsdienst aanbieden, maar ze kunnen ook kiezen om meerdere rollen in te vullen en daarmee een compleet scala aan eid-diensten aan te bieden. Deze keuzevrijheid geldt voor alle partijen. Zo kan een Dienstaanbieder ervoor kiezen om zelf op te treden als Dienstbemiddelaar; voor veel kleinschalige diensten zal dit zelfs een voor de hand liggende invulling zijn. Een ander voorbeeld is een bedrijf dat zelf Bevoegdheidsverklaringen afgeeft voor zijn eigen werknemers en dus optreedt als Machtigingsdienst. Figuur 1: Systeemdiagram eid Stelsel 30

31 3.7.2 Stappen in het tot stand komen van een PseudoID [Tekst uit document: Werking van het eid Stelsel, hoofdstuk 3, paragraaf 3.2, ] De eerste stap wordt gezet op het moment dat de Gebruiker zich meldt als (nieuwe) klant van een Authenticatiedienst. De Authenticatiedienst vraagt voor de nieuwe klant een zogenaamde Polymorfe PseudoID 29 aan bij de Stelsel Autoriteit. Deze Polymorfe PseudoID is de kern van de encryptie van het stelsel. De Polymorfe PseudoID is voor iedere Authenticatiedienst verschillend. Als een Authenticatiedienst voor dezelfde persoon de aanvraag opnieuw indient, zal het resultaat een andere Polymorfe PseudoID zijn. Toch leveren al deze verschijningsvormen na twee transformaties (de eerste bij de Authenticatiedienst, de tweede bij de Dienstaanbieder) steeds dezelfde PseudoID op. [Tekst uit document: Werking van het eid Stelsel, hoofdstuk 3, paragraaf 3.3, ] Een Polymorfe PseudoID wordt berekend en uitgereikt door een vertrouwde centrale partij binnen het stelsel: de Stelselautoriteit/pseudoniemen. De Polymorfe PseudoID wordt aangevraagd door een Authenticatiedienst op het moment dat een Gebruiker zich daar registreert. De Stelselautoriteit controleert de Stamsleutel bij de beheervoorziening BSN en in een eigen administratie. Daarmee voorkomt de Stelselautoriteit dubbele inschrijvingen en signaleert hij niet-unieke Stamsleutels. Een Polymorf PseudoID is randomiseerbaar (aangegeven met een dubbele lijn in Figuur 2). Dat houdt in dat er extra gegevens aan de Polymorfe PseudoID kunnen worden toegevoegd zonder dat dit invloed heeft op de PseudoID s die van het Polymorfe PseudoID worden afgeleid. Als twee Authenticatiediensten hun aanvraag voor een Polymorfe PseudoID baseren op dezelfde Stamsleutel, zullen ze bij één en dezelfde Dienstaanbieder dezelfde PseudoID opleveren. [Tekst uit document: Werking van het eid Stelsel, hoofdstuk 3, paragraaf 3.4, ] De Authenticatiedienst slaat de ontvangen Polymorfe PseudoID op. Als de Authenticatiedienst gebruik maakt van een secure device 30 (bijvoorbeeld een geavanceerde smartcard) als Authenticatiemiddel, dan kan de Polymorfe PseudoID op het middel zelf worden opgeslagen. Authenticatiediensten die gebruik maken van middelen die dit niet ondersteunen (zoals gebruikersnaam/wachtwoord of een eenvoudigere vorm van smartcard ) slaan de Polymorfe PseudoID s op in de eigen administratie. Hiermee wordt de oplossing bruikbaar voor een breed scala aan Authenticatiemiddelen. Een Polymorfe PseudoID die is opgeslagen op een secure device kan bij uitlezen door het middel zelf worden gerandomiseerd. Dat betekent dat de Authenticatiedienst de Polymorfe PseudoID niet meer zal herkennen en dus de authenticatie kan uitvoeren zonder te weten over welke van zijn klanten het gaat. Dit biedt een extra niveau van privacybescherming. Het gaat evenwel ten koste van de volledigheid van de informatie in de audit trail: het is niet meer mogelijk om precies vast te leggen welk gebruik er van een kaart wordt gemaakt. De keuze is hier aan de Gebruiker Een identificerend kenmerk van de Gebruiker dat wordt berekend en uitgereikt door de Stelselautoriteit/pseudoniemen aan een Authenticatiedienst of Machtigingsdienst. Deze wordt aangevraagd door een Authenticatie- of Machtigingsdienst op het moment dat een Gebruiker zich daar registreert. Een Polymorfe PseudoID wordt afgeleid van de Stamsleutel van een Gebruiker. De gegevens waaruit de Stamsleutel wordt opgebouwd zijn: geslachtsnaam, eerste voornaam, overige voorletters, geboortedatum en geboorteplaats. Een Polymorfe PseudoID wordt berekend door: een hash te berekenen over de combinatie van Stamsleutel, Personage en volgnummer; deze hash te versleutelen met een geheime sleutel van de Stelselautoriteit. De sleutel van de Stelselautoriteit geldt voor het hele stelsel en dient zwaar beveiligd te worden. Opslag in een HSM (Hardware Security Module) is hierbij een vereiste. Het polymorfe karakter van de gegenereerde pseudoniemen (het feit dat ze zich in verschillende gedaanten kunnen manifesteren) maakt ze tot een gevoelig punt, te vergelijken met een encryptiesleutel. Authenticatiediensten dienen daarom Polymorfe PseudoID s te bewaren in een HSM. 30 Het eid Stelsel zal nader definiëren aan welke voorwaarden een secure device moet voldoen. 31 Niet onderzocht is of met een app toepassing die informatie naar een Life Management Platform van een Gebruiker kan worden getransporteerd. Die Gebruiker houdt dan zelf die gegevens bij. Niet uitgewerkt is hoe andere secure devices kunnen worden gebruikt in de vorm van apps op mobile devices. Zie in dat verband het rapport van Kuppingercole : Qiy Independent Trust Framework inzake Life Management Platforms. 31

32 Als de Gebruiker zich door tussenkomst van de Authenticatiedienst ergens wil authentiseren, berekent de Authenticatiedienst uit de Polymorfe PseudoID een Versleutelde PseudoID. Een Authenticatiedienst ontvangt van de Stelselautoriteit/sleutelbeheer een geheime sleutel ten behoeve van het berekenen van Versleutelde PseudoID s. Deze sleutel (in Figuur 2 aangeduid als Metamorfosesleutel, omdat hij de verschijningsvorm van de Polymorfe PseudoID bepaalt) wordt op een zeer specifiek wijze (aangeduid als CT2) afgeleid van de identiteit van de Authenticatiedienst. De Versleutelde PseudoID wordt berekend op basis van de Polymorfe PseudoID van de Gebruiker, het Personage dat de Gebruiker heeft gekozen 32, en de identiteit van de Ontvangende Partij. Deze omzetting is aangeduid als CT3. Een Versleutelde PseudoID heeft de volgende eigenschappen. 1. Een Versleutelde PseudoID is randomiseerbaar; 2. Een Versleutelde PseudoID is alleen leesbaar voor de Ontvangende Partij. [Tekst uit document: Werking van het eid Stelsel, hoofdstuk 3, paragraaf 3.5, ] De laatste stap in het aanmaken van de PseudoID wordt uitgevoerd door de Ontvangende Partij. Deze heeft hiertoe van de Stelselautoriteit/sleutelbeheer een eigen geheime sleutel ontvangen. Door deze toe te passen op het ontvangen Versleuteld PseudoID berekent hij het feitelijk te gebruiken pseudoniem (PseudoID) dat het resultaat is van de authenticatie. Een PseudoID is persistent, uniek voor de Ontvangende Partij en alleen afhankelijk van de Stamsleutel van de Gebruiker en het gekozen Personage. Anders gezegd, het geheel van de transformaties CT1, CT2, CT3 en CT4 is zodanig dat het eindresultaat onafhankelijk is van de Authenticatiedienst die de authenticatie uitvoert en van het toevoegen van random informatie aan de Polymorfe PseudoID en de Versleutelde PseudoID. Deze eigenschap is cruciaal; hij zorgt ervoor dat de oplossing tegelijkertijd voldoet aan alle eisen van keuzevrijheid van de Gebruiker, privacybescherming en onafhankelijkheid van toegepaste middelen. 32 Er is nog niet vastgesteld hoe de Gebruiker deze keuze kenbaar maakt. Een mogelijke invulling is dat het Personage wordt gekoppeld aan het middel; dat zou inhouden dat de Gebruiker voor ieder Personage een apart middel moet aanschaffen. Implementaties die koppelen van meerdere Personages aan één middel mogelijk maken zijn ook denkbaar. Intern in het stelsel wordt een Personage gepresenteerd door een getal met een nader te bepalen bereik. 32

33 Figuur 2: Genereren van PseudoID's Het gebruik van SectorID s [Tekst uit document: Werking van het eid Stelsel, hoofdstuk 3, paragraaf 3.6, ] Het bekendste voorbeeld van een SectorID is het BSN. Om dit gebruik mogelijk te maken is het noodzakelijk dat er een verband word gelegd tussen Personage en een SectorID. Dit is de taak van een SectorID-dienst 33. Daarvoor wordt niet rechtstreeks gebruik gemaakt van de Polymorfe PseudoID; die is daarvoor door zijn steeds wisselende verschijningsvorm niet geschikt. In plaats daarvan wordt er gebruik gemaakt van een PseudoID. In feite gedraagt een SectorID-dienst zich op dit punt als een gewone Attributendienst. Deze oplossing zorgt ervoor dat een SectorID gebruikt kan worden in combinatie met een willekeurig Authenticatiemiddel van een willekeurige Authenticatiedienst. 33 De SectorID-Dienst zorgt ervoor dat op basis van een PseudoID de bijbehorende SectorID van een persoon wordt opgeleverd. Dit gebeurt in de vorm van een Attribuutverklaring en daarom is desectorid-dienst ook een Attributendienst. 33

34 Het authenticatieproces verloopt in deze situatie als volgt (zie Figuur 3). 1. De Authenticatiedienst gebruikt in CT3 niet de identiteit van de Dienstaanbieder, maar de identiteit van de SectorID-dienst. 2. Het resultaat is een Versleutelde PseudoID, behorend bij het gebruikte Personage. Deze Versleutelde PseudoID kan alleen door de SectorID-dienst worden gelezen. 3. De SectorID-Dienst past op deze Versleutelde PseudoID zijn eigen geheime sleutel toe en verkrijgt zo de PseudoID waaronder de Gebruiker bij hem bekend is. 4. DeSectorID-Dienst zoekt de bijbehorende SectorID op. Deze SectorID wordt in een Attribuutverklaring opgenomen. De oorspronkelijke Identiteitsverklaring 34 wordt aan de Attribuutverklaring gehecht in een identiteitsketen 35. Het geheel wordt vervolgens teruggegeven aan de aanvrager (de eid-makelaar) Gebruik van identiteiten in een identiteitsverklaring [Tekst uit document: Werking van het eid Stelsel, hoofdstuk 3, paragraaf 3.7, ] Iedere Identiteitsverklaring bevat tenminste één Versleutelde PseudoID. Als hij geadresseerd is aan meerdere Ontvangende Partijen, dan bevat hij even zoveel Versleutelde PseudoID s. Afhankelijk van de context waarin de Identiteitsverklaring gebruikt moet worden kan hij als zelfstandige verklaring voorkomen, kan hij gehecht zijn aan een Attribuutverklaring of aan een Bevoegdheidsverklaring. Zowel attributen als identiteiten zijn kenmerken van een persoon. Een identiteit legt een eenduidig verband tussen een persoon en een verzameling gegevens over meerdere personen, zoals een klantenbestand of een registratie van beroepsbeoefenaren. Daarmee geeft de identiteit het door de Handelende Persoon beoogde gebruik van de keten van verklaringen aan. Neem als voorbeeld een advocaat die zowel een BSN als een advocatennummer (BAR-nummer) heeft. Hij zal zijn BSN gebruiken als hij als burger zaken doet met de overheid en zijn advocatennummer wanneer hij als advocaat handelt. Daarom geldt de volgende regel. Een identiteitsketen kan per Ontvangende Partij slechts één identiteit (PseudoID of SectorID) bevatten. Aan een Attribuutverklaring is altijd een Identiteitsverklaring gehecht. In de meeste gevallen zal dat een Identiteitsverklaring zijn met twee geadresseerden: de Attributendienst zelf en de Ontvangende Partij van de Attribuutverklaring. Er zijn echter ook situaties waarin de Attributendienst de enige geadresseerde is. Immers, PseudoID's zoals hier gebruikt zijn persistent (i.e. bij ieder gebruik hetzelfde). Een persistent gegeven, hoe betekenisloos ook, stelt de ontvanger in staat om een historie op te bouwen van het gebruik van de Handelende Persoon van het stelsel. 36 Dat is niet nodig in de situatie dat bijvoorbeeld alleen een specifiek eigenschap van de Handelende Persoon (bijvoorbeeld ouder dan 18? ) vereist wordt. In dat geval bevat de Identiteitsverklaring alleen de Versleutelde PseudoID voor de Attributendienst. Dat is voor de Ontvangende Partij verder niet leesbaar. Hij kan uit de ontvangen keten afleiden dat de identiteit deugdelijk is vastgesteld, dat de persoon in kwestie inderdaad ouder dan 18, maar niet over wie het gaat. Daarmee bevat de keten precies voldoende informatie voor de Ontvangende Partij. 34 Iedere Identiteitsverklaring bevat tenminste één Versleutelde PseudoID. Als hij geadresseerd is aan meerdere Ontvangende Partijen, dan bevat hij even zoveel Versleutelde PseudoID s. Afhankelijk van de context waarin de Identiteitsverklaring gebruikt moet worden kan hij als zelfstandige verklaring voorkomen, kan hij gehecht zijn aan een Attribuutverklaring of aan een Bevoegdheidsverklaring. 35 Een identiteitsketen kan per Ontvangende Partij slechts één identiteit (PseudoID of SectorID) bevatten. 36 Een belangrijke vraag is nu: welke ontvangers in het eid Stelsel, zowel eid Deelnemers als Dienstaanbieders, kunnen de identiteit van de Gebruiker herleiden, dan wel wat zijn de reële mogelijkheden om een databestand met dergelijke gegevens met welke partijen te herleiden en wat is daar dan voor nodig. Hier is nog geen risicoanalyse op uit gevoerd. Althans dit blijkt niet uit de ontwerp-documentatie. 34

35 Figuur 3: Pseudoniemen en sectorale nummers 35

36 Omvormen van pseudoniemen [Tekst uit document: Werking van het eid Stelsel, hoofdstuk 4, paragraaf 4.1, ] Er is een aantal situaties waarin een specifiek pseudoniem moet worden omgevormd in een ander pseudoniem om bruikbaar te zijn. Gebruik van PseudoID bij Machtigingsdienst Een Gebruiker kan bij een Machtigingsdienst meerdere machtigingen voor verschillende Dienstaanbieders vastleggen. De eis van transparantie houdt dan het volgende in. Een Gebruiker moet kunnen inloggen bij een Machtigingsdienst en al zijn machtigingen zien en beheren 37 (zowel de machtigingen waarin hij als Vertegenwoordigde voorkomt als die waarin hij als Gemachtigde voorkomt). In deze situatie ligt het voor de hand om de Machtigingsdienst te beschouwen als een Dienstaanbieder die de dienst Beheer Machtigingen verleent aan de Gebruiker. De Gebruiker wordt geauthentiseerd aan de hand van een PseudoID die specifiek is voor de Machtigingsdienst. Op het moment dat op basis van de geregistreerde machtiging een Bevoegdheidsverklaring moet worden gemaakt, dient deze persoon echter te worden aangeduid op de manier waarop de Ontvangende Partij deze persoon kent, dus met de PseudoID voor de Ontvangende Partij. Het mag voor de Ontvangende Partij immers geen verschil maken of de Vertegenwoordigde zélf inlogt of dat iemand anders dat namens hem of haar doet op basis van een machtiging. Dat kan binnen de cryptografie van het stelsel alleen als de Bevoegdheidsverklaring de Versleutelde PseudoID van de Vertegenwoordigde en de Gemachtigde bevat. Een Bevoegdheidsverklaring bevat de Dienstaanbieder-specifieke Versleutelde PseudoID van de Gemachtigde en de Vertegenwoordigde. Voor de laatste Gemachtigde in een keten kan dat worden gerealiseerd door de Authenticatiedienst. Een Authenticatiedienst levert op verzoek zowel een Versleutelde PseudoID voor de Dienstaanbieder als voor de Machtigingsdienst. Voor de overige Gemachtigden in een keten en voor de Vertegenwoordigde dient de Machtigingsdienst te kunnen beschikken over Polymorfe PseudoID s van de betrokken personen. Deze worden door de Machtigingsdienst aangevraagd bij de Stelselautoriteit/pseudoniemen als onderdeel van het registratieproces van een machtiging zie figuur 4. Dit hoeft alleen de eerste keer dat de Gebruiker een machtiging registreert; de Machtigingsdienst zal de ontvangen Polymorfe PseudoID opslaan en bij een volgende gelegenheid hergebruiken. Er zijn meerdere varianten van het aanvraagproces mogelijk, maar als onderdeel van het proces dienen de hier beschreven stappen zowel voor de Vertegenwoordigde als voor de Gemachtigde te worden doorlopen. Het proces begint ermee dat bijvoorbeeld de Vertegenwoordigde inlogt bij de Machtigingsdienst om een aanvraag voor een machtiging in te dienen. In deze context is de Machtigingsdienst de Dienstaanbieder, dus de Authenticatiedienst genereert een Versleutelde PseudoID (CT3) die alleen gelezen kan worden door de Machtigingsdienst. Deze ontcijfert de Versleutelde PseudoID en verkrijgt op die manier de PseudoID van de Vertegenwoordigde voor zijn eigen administratie. Als onderdeel van de authenticatie vraagt de Machtigingsdienst om de attributen waaruit de Stamsleutel van de Gebruiker is opgebouwd. Deze worden als aanvullende attributen meegeleverd in de Identiteitsverklaring. Uit hoofde van zijn rol zal de Machtigingsdienst daarvoor bij toetreding tot het stelsel autorisatie voor hebben gekregen. 37 De vraag is wat hier beheer betekent. Machtigingen kunnen worden ingetrokken. Is hier al goed nagedacht over de hiermee gepaard gaande rechtsgevolgen? Kan hij machtigingen aanpassen, manipuleren, verwijderen? Wat zijn de consequenties van rechtswege als hij dat doet voor afgegeven machtigingen? Bestaat die mogelijkheid? Aanstaan en bewaartermijn van loggingen op mutaties? Wie kan daarbij? 36

37 De Machtigingsdienst gebruikt vervolgens deze gegevens om een eigen aanvraag voor een Polymorfe PseudoID in te dienen bij de Stelselautoriteit/pseudoniemen. Omdat deze gegevens al een keer eerder zijn gebruikt om een Polymorfe PseudoID aan te vragen, zijn daarbij geen complicaties zoals een niet-unieke Stamsleutel te verwachten. De Stelselautoriteit/pseudoniemen berekent een nieuwe Polymorfe PseudoID ten behoeve van de Machtigingsdienst die als onderdeel van de machtigingstriple 38 wordt opgeslagen. Een Machtigingsdienst vraagt voor het genereren van PseudoID s een eigen Polymorfe PseudoID aan bij de Stelselautoriteit/pseudoniemen. Op het moment dat de Polymorfe PseudoID is ontvangen kan de Machtigingsdienst de voor het samenstellen van de Stamsleutel verkregen attributen verwijderen, voor zover ze niet als comfortinformatie deel uitmaken van de machtiging. In de praktijk zal dit betekenen dat de geboorteplaats en eventuele aanvullende gegevens geschrapt kunnen worden. De Machtigingsdienst beschikt net als een Authenticatiedienst over een Metamorfosesleutel. Als de machtiging wordt opgevraagd, gebruikt de Machtigingsdienst deze om uit de Polymorfe PseudoID een Versleutelde PseudoID ten behoeve van de Dienstaanbieder te genereren. De Dienstaanbieder haalt bij binnenkomst van de Bevoegdheidsverklaring zijn private sleutel over de Versleutelde PseudoID en verkrijgt zo de PseudoID van de Gebruiker. Op basis van de algemene eigenschappen van de cryptografie weten we dan dat dit dezelfde PseudoID is als de Authenticatiedienst voor de Vertegenwoordigde genereert wanneer de Vertegenwoordigde zelf zou inloggen bij de Dienstaanbieder. Wanneer de machtiging tot stand komt via een balieproces verloopt het feitelijk op dezelfde wijze, alleen wordt de Stamsleutel van de Vertegenwoordigde dan afgeleid van de gegevens op het WID. Deze vormt dan de basis voor de aanvraag van de Polymorfe PseudoID. De gegevens voor het aanvragen van een Polymorfe PseudoID verkrijgt de Machtigingsdienst uit een Identiteitsverklaring of uit een eigen registratieproces. Figuur 4: Pseudoniemen bij een Machtigingsdienst 38 Met de machtigingstriple worden de Vertegenwoordigde, de Gemachtigde en de betrokken dienst bedoeld. 37