Carlo Koch, Gerrit Jan van t Eind, Nicole Damen (verslag)

Transcriptie

1 Programma eid eid-platform Contactpersoon Nicole Damen T nicole.damen@logius.nl Datum 27 augustus 2014 eid-platform #3 Aantal pagina's 2 Vergaderdatum en tijd 3 september 2014, uur Vergaderplaats Logius, vergaderruimte Oranje Deelnemers Andere aanwezigen vanuit het programma eid Elly Plooij-van Gorsel (voorzitter), Hankie van Baasbank (KvK), Hans Blokpoel (Belastingdienst), Leo De Boer (Verbond van Verzekeraars), Jelle Boonstra (TLN), Peter van Buijtene (PostNL), Haydar Cimen (KPN), Marlies van Elst (Equens), Erik van 't Geloof (Logius), Johan Hakkenberg (RDW), Wijnand Jongen (Thuiswinkel.org), Gé Linssen (EZ), Hedde van der Lugt (Nictiz), Piet Mallekoote (Betaalvereniging Nederland), Erik van de Poel (BKR), Jacqueline Rutjens (BZK), Paul Schumacher (Bouwend Nederland), Marcel Wendt (Digidentity), Jan- Hein Willemse (VECOZO) Carlo Koch, Gerrit Jan van t Eind, Nicole Damen (verslag) 1. Opening, mededelingen en vaststellen agenda Vaststellen van agenda en ruimte voor leden om mededelingen te doen 2. Verslag en actielijst van de vorige vergadering Verslag en actielijst van 20 mei 2014 vaststellen 3. Masterplan eid Presentatie van programmamanagers waarin zij het Masterplan toelichten dat is vastgesteld door de Stuurgroep eid 3a. Communicatie Presentatie proces naamgeving eid Stelsel 4. Pilots Bespreken aanmeldingen voor pilots 5. Resultaten Proof of Concept en Proof of Technology Toelichting op resultaten en bevindingen van werkgroepen door voorzitters van de werkgroepen Pagina 1 van 2

2 6. Stand van zaken business model Bespreken voortgang werkgroep business model 7. Toezicht Inbreng stakeholders bij project Toezicht Programma eid eid-platform Datum 27 augustus W.v.v.t.k. 9. Rondvraag 10. Sluiting Pagina 2 van 2

3 Programma eid eid-platform Contactpersoon Nicole Damen T nicole.damen@logius.nl Datum 27 augustus 2014 Naamgeving eid Stelsel Aantal pagina's 2 Agendapunt Onderwerp Status Voorstel 3a. Communicatie Naamgeving eid Stelsel Ter informatie en voor discussie over de introductie van de naam Kennisnemen van: 1. Totstandkoming nieuwe naam eid Stelsel en 2. Introductiestrategie nieuwe naam 1. Samenvatting Momenteel is de naam eid Stelsel in gebruik. De naam eid Stelsel blijkt merkenrechtelijk niet bruikbaar en bovendien werkt het communicatief niet goed. Daarom heeft het programma eid in opdracht van de Stuurgroep eid een onderzoek uitgevoerd naar een geschikte naam voor het eid Stelsel. Tijdens de vergadering van het eid-platform op 3 september a.s., zal de nieuwe naam door het Programmabureau eid worden toegelicht, evenals de wijze waarop de merknaam zal worden geïntroduceerd. 2. Naamgeving Uit het onderzoek is naar voren gekomen dat de naam eid Stelsel niet geschikt is als naam voor het stelsel om de volgende redenen: Merkenrechtelijk/juridisch eid is een veelgebruikte term. eid heeft negen identieke merkinschrijvingen. e-id heeft één merkinschrijving in het Benelux register. De.nl domeinnamen van eid en e-id zijn in gebruik in onder meer het zelfde domein als waar het programma eid zich in beweegt. Gelet op bovenstaande is de term eid is niet of nauwelijks te claimen door de overheid. 3. Communicatief De term stelsel zegt weinig over waar het eid Stelsel voor staat en wat het is. De term eid Stelsel levert weinig begrip op en de volgende reacties: lage persoonlijke relevantie, best ingewikkeld, geen duidelijke benefit, gevoelens van kwetsbaarheid en weinig vertrouwen. De conclusie is dat het positioneren van het eid Stelsel, met als naam eid Stelsel, Pagina 1 van 2

4 veel tijd en middelen zal kosten: de naam: zegt te weinig over waar het eid Stelsel voor staat. Programma eid eid-platform 4. Het proces naar een nieuwe naam Tijdens het traject zijn de doelgroepen van het eid Stelsel vastgesteld, en zijn er criteria ontwikkeld voor een nieuwe naam. De doelgroepen zijn primair de zakelijke en publieke dienstaanbieders en secundair de gebruikers, omdat bij de gebruikers vooral de middelen centraal staan en slechts op de achtergrond- het stelsel. Datum 27 augustus 2014 De criteria: De naam beklijft en straalt betrouwbaarheid en vertrouwen uit. De naam zegt iets over de werking van het eid Stelsel. De naam is uitspreekbaar, in Nederland én daarbuiten. De naam roept geen directe associatie op met ofwel de overheid, ofwel het bedrijfsleven. De naam kan fungeren als keurmerk. De naam kan merkenrechtelijk beschermd worden in de Benelux. De domeinnaam.nl, dient beschikbaar te zijn. Kwalitatief onderzoek 1 onder zakelijke dienstverleners, overheidsdienstverleners en burgers heeft een naam opgeleverd die het meest voldoet aan de criteria en de juiste associaties oproept bij alle doelgroepen.. 5. Introductie van de nieuwe naam Vooralsnog is de nieuwe naam alleen bekend bij het Programma eid en de Stuurgroep eid en zijn de ministers van EZ en BZK op de hoogte en akkoord met deze naamgeving. Het voornemen is de Tweede Kamer nog dit jaar over de naam te informeren. Het voorstel is om de naam in gebruik te nemen wanneer er daadwerkelijk dienstverlening mogelijk is via het eid Stelsel, dat wil zeggen in 2015, als er volgens de planning een eerste werkend stelsel is met de beproeving van het stelsel in de praktijk De idee is dat dienstverleners en leveranciers van eid-middelen de naam introduceren bij gebruikers, omdat zij al een band hebben met de gebruikers. 6. Discussiepunt Wat is uw beeld bij de introductie van de nieuwe naam? Alle rechten voorbehouden 2014 Ministerie van Binnenlandse Zaken en Koninkrijksrelaties, Den Haag. Er kunnen geen rechten worden ontleend aan deze publicatie. 1 Het onderzoek bestond uit gesprekken met vier groepen van elk acht personen met diverse achtergronden. Twee groepen met zakelijke en overheidsdienstverleners en twee groepen gebruikers/burgers. Onderzoek uitgevoerd door WeJane. Pagina 2 van 2

5 Programma eid eid-platform Contactpersoon Nicole Damen T nicole.damen@logius.nl Datum 27 augustus 2014 Oplegmemo bij resultaten werkgroepen POT s en POC s Aantal pagina's 3 Agendapunt Van Onderwerp Status Voorstel 5. Resultaten Proof of Concept en Proof of Technology Werkgroepen POT s en POC s Resultaten van werkgroepen POT s en POC s Ter informatie / Ter goedkeuring Het eid-platform wordt gevraagd om 1. De resultaten en bevindingen van de werkgroepen ter kennisgeving aan te nemen; 2. In te stemmen met de verwerking van de resultaten door het programma eid in het ontwerp versie Kennis te nemen van de openstaande onderwerpen binnen de werkgroepen. 4. In te stemmen met de voorgestelde vervolgstappen bij de openstaande onderwerpen. 5. In te stemmen met de inzet van de werkgroepen als klankbordgroep bij de totstandkoming van het ontwerp versie Inleiding De afgelopen vier maanden is via Proofs of Technology (POT s) en Proofs of Concept (POC s) het ontwerp van het eid Stelsel beproefd. Het doel van deze beproevingen was te borgen dat de functionaliteit, zoals beschreven in het ontwerp van het eid Stelsel 1.0, ook daadwerkelijk kan worden geïmplementeerd en op grote schaal kan worden ingezet. De uitvoering van de POT s en POC s is begeleid door een tweetal publiek-private werkgroepen. Met het voorliggende document rapporteren de werkgroepen hun bevindingen en resultaten aan het eid-platform. Deze resultaten kunnen worden verwerkt in de volgende versie van het ontwerp (versie 2.0, oplevering 1 november 2014). In het rapport worden ook de onderwerpen beschreven die niet in de werkgroepen zijn afgerond en worden de afspraken hierover weergegeven. De samenwerking binnen de werkgroepen verliep in een open en goede sfeer. Op de inhoud waren de deelnemers constructief-kritisch. Dit heeft positief bijgedragen aan de kwaliteit van de uitkomsten. Pagina 1 van 3

6 2. Algemene conclusies De werkgroepen zijn er in een positief-kritische en constructieve sfeer in geslaagd om een groot deel van de gestelde doelstellingen en opdrachten te behalen. Op grond van de uitkomsten van de beide werkgroepen is het mogelijk om tot een goed implementeerbaar ontwerp van het eid Stelsel te komen. Programma eid eid-platform Datum 27 augustus Samenvatting van resultaten In de POT-werkgroep zijn de koppelvlakspecificaties en de cryptografiebeschrijving verbeterd en aangevuld. Ook zijn deze specificaties op verschillende platforms geïmplementeerd en is gebleken dat de implementaties interoperabel zijn en naar behoren performen. In de POC-werkgroep zijn verschillende klantreizen met behulp van clickable demo s verbeterd en aangevuld. Ook zijn de functionele specificaties aan het eid Stelsel verbeterd zodat ze gebruiksvriendelijk kunnen worden geïmplementeerd. De werkgroepleden hebben de gelegenheid gehad om voor hen relevante onderwerpen in te brengen en gezamenlijk te prioriteren. Het eid-projectteam heeft elk onderwerp gepresenteerd met bijbehorende belangen en afwegingen. Dit was over het algemeen een goede voorzet voor constructieve discussies. Het is niet gelukt om alle ingebrachte onderwerpen te behandelen. Sommige onderwerpen vielen buiten de scope van de werkgroepen, en voor andere onderwerpen was te weinig tijd om ze volledig te behandelen. Enkele open onderwerpen betreffen discussies over de optimaliteit van het huidige ontwerp. Voor elk van de open onderwerpen is een voorstel gedaan voor de verdere afhandeling (zie het bijgevoegde rapport). Twee belangrijke open onderwerpen zijn een risicoanalyse op het stelsel en de (ISO-)normering. Beide waren vooraf niet gedefinieerd voor deze werkgroepen, maar staan wel gepland voor de oplevering van versie 2.0. Bij de uitwerking van deze onderwerpen wordt graag gebruik gemaakt van de aangeboden expertise van de werkgroepleden. 4. Vervolgstappen - Het projectteam ontwerp eid Afsprakenstelsel gebruikt de resultaten van de werkgroepen in versie 2.0 van het ontwerp. - Bij de totstandkoming van dit ontwerp worden de POT- en POC-werkgroep gebruikt als klankbordgroepen. - Het ontwerp 2.0 wordt dit najaar voorgelegd ter besluitvorming. Op basis daarvan kan in 2015 de realisatie van pilots plaatsvinden. 5. Voorstel De platformleden wordt gevraagd om: 1. De resultaten en bevindingen van de werkgroepen ter kennisgeving aan te nemen; 2. In te stemmen met de verwerking van de resultaten door het programma eid in het ontwerp versie 2.0; Pagina 2 van 3

7 3. Kennis te nemen van de openstaande onderwerpen binnen de werkgroepen; 4. In te stemmen met de inzet van de werkgroepen als klankbordgroep bij de totstandkoming van het ontwerp versie 2.0; 5. In te stemmen met de voorgestelde vervolgstappen bij de openstaande onderwerpen; Programma eid eid-platform Datum 27 augustus 2014 Alle rechten voorbehouden 2014 Ministerie van Binnenlandse Zaken en Koninkrijksrelaties, Den Haag. Er kunnen geen rechten worden ontleend aan deze publicatie. Pagina 3 van 3

8 Resultaten van de werkgroepen POT en POC programma eid Versie: 1.0 Datum: 26 augustus 2014 Status: Definitief Pagina 1 van 23

9

10 Colofon Programma eid Deelproject Afsprakenstelsel Bezoekadres: Herman Gorterstraat 5 6 e verdieping 3511 EW Utrecht Versie 1.0 Opdrachtgever Stuurgroep eid Aantal pagina s 23 Copyright 2014 Ministerie van Binnenlandse Zaken en Koninkrijksrelaties, Den Haag De Staat der Nederlanden (Ministerie van Binnenlandse Zaken en Koninkrijksrelaties) maakt een voorbehoud als bedoeld in artikel 15b van de Auteurswet 1912 met betrekking tot de verstrekte informatie in deze publicatie. Ingeval een derde op welke wijze dan ook zonder toestemming inbreuk maakt op het auteursrecht, kan de Staat stappen ondernemen. Pagina 3 van 23

11 Definitief Resultaten van de werkgroepen POT en POC 26 augustus 2014 Inhoud Colofon 3 Inhoud 4 Inleiding 5 1 Managementsamenvatting 6 2 Resultaten van de POT-werkgroep Aanscherping van de koppelvlakspecificaties Aanscherping van de cryptografie Beproeving door implementatie Performance 10 3 Resultaten van de POC-werkgroep Gebruik en beheer van authenticatiedienst Gebruik en beheer van attribuutdienst Gebruik en beheer machtigingen 15 4 Openstaande onderwerpen POT-werkgroep POC-werkgroep 19 Bijlage Samenstelling van de werkgroepen 21 Pagina 4 van 23

12 Inleiding In de periode mei tot en met augustus 2014 heeft de eerste ronde van de Proofs of Technology (POT s) en Proofs of Concept (POC s) voor het ontwerp van het eid Stelsel (versie 1.0) plaatsgevonden. De opdracht aan de werkgroepen was om het ontwerp 1.0 technisch en functioneel te beproeven en, waar nodig, aan te vullen. In de POT is de technische haalbaarheid van een ontwerp of specificatie getoetst en in de POC is vooral gekeken naar gebruikersgerelateerde zaken. Het doel van dit traject was te borgen dat de functionaliteit van het eid Stelsel ook daadwerkelijk kan worden geïmplementeerd en op grote schaal kan worden ingezet. De uitgangspunten van het ontwerp stonden hierbij niet ter discussie. De in dit rapport gepresenteerde resultaten uit de POT s en POC s leiden tot bijstelling van en verdieping op het ontwerp 1.0. Dit mondt uit in de ontwerpdocumenten voor de versie 2.0 (oplevering november 2014). Op basis van ontwerp 2.0 vindt in 2015 de realisatie van de pilots plaats. Werkgroepen De uitvoering van de POT s en POC s is begeleid door een tweetal publiek-private werkgroepen. De leden van deze werkgroepen zijn geworven door aankondiging op TenderNed, de eid-website en attendering hierop aan leden van het eid-platform en deelnemers van consultatierondes. Een groot aantal organisaties heeft zich aangemeld. Op basis van de vooraf gestelde criteria heeft een selectieronde plaatsgevonden en is de definitieve samenstelling van beide werkgroepen bekend gemaakt. Vier organisaties, die vertegenwoordigd zijn in het eid-platform, hebben deelgenomen aan de werkgroepen POT en/of POC. Resultaten van de beproeving Dit rapport beschrijft de belangrijkste resultaten die gedragen worden door de werkgroepen. Tevens worden de open punten beschreven waarover geen consensus bestaat in de werkgroepen. Aangegeven wordt hoe deze punten een vervolg krijgen. Aangezien de aard van de resultaten en de samenstelling van beide werkgroepen onderling van elkaar verschillen, hebben we ervoor gekozen om de uitkomsten van iedere werkgroep in aparte hoofdstukken weer te geven. Na bespreking in respectievelijk het eid-platform en stuurgroep zullen de resultaten inclusief achtergrondinformatie uit de POT s en POC s worden gepubliceerd op de eid-website. Alle resultaten worden volledig vrij van rechten beschikbaar gesteld. Dit geldt ook voor tijdens de POT s en POC s gecreëerde broncode 1. Inhoud van dit rapport Hoofdstuk 1 geeft een managementsamenvatting van de behaalde resultaten. In dit hoofdstuk worden de algemene conclusies en resultaten op beknopte wijze beschreven. Hoofdstuk 2 geeft op hoofdlijnen de resultaten uit de POT-werkgroep. Hierin komen onderwerpen aan bod als koppelvlakspecificaties, cryptografie, haalbaarheid van implementatie en een performancetest. Hoofdstuk 3 beschrijft op hoofdlijnen de resultaten uit de POC-werkgroep. Hierin is de gehanteerde werkwijze uitgelegd en komen onderwerpen aan bod als gebruik van een authenticatiemiddel, gebruikersinstellingen bij een authenticatiedienst, gebruik en beheer van attributen en gebruik en beheer van machtigingen. Hoofdstuk 4 geeft inzicht in de openstaande onderwerpen en de afspraken die hierover zijn gemaakt. 1 De exacte licentie waaronder de software wordt vrijgegeven is nog niet duidelijk. Dit is onder meer afhankelijk van de in de software gebruikte softwarecomponenten. Pagina 5 van 23

13 Definitief Resultaten van de werkgroepen POT en POC 26 augustus Managementsamenvatting De afgelopen vier maanden hebben twee publiek-private werkgroepen het ontwerp van het eid Stelsel beproefd. Hierbij is het ontwerp met name getoetst op haalbaarheid, schaalbaarheid en gebruiksvriendelijkheid. Ook hebben de werkgroepen het ontwerp beoordeeld en waar nodig verbeterd en aangevuld. Algemene conclusies De werkgroepen zijn er, in een positief-kritische en constructieve sfeer, in geslaagd om een groot deel van de gestelde doelstellingen te behalen. Op grond van de uitkomsten van de beide werkgroepen is het mogelijk om tot een goed implementeerbaar ontwerp van het eid Stelsel te komen. Werkwijze van de werkgroepen De werkgroepleden hebben de gelegenheid gehad om voor hen relevante onderwerpen in te brengen en gezamenlijk te prioriteren. Het eid-projectteam heeft elk onderwerp gepresenteerd met bijbehorende belangen en afwegingen. Dit was over het algemeen een goede voorzet voor constructieve discussies. Het is niet gelukt om alle ingebrachte onderwerpen te behandelen. Sommige onderwerpen vielen buiten de scope van de werkgroepen, en voor andere onderwerpen was te weinig tijd om ze volledig te behandelen. Enkele open onderwerpen betreffen discussies over de optimaliteit van het huidige ontwerp. Voor elk van de open onderwerpen is een voorstel gedaan voor de verdere afhandeling. Twee belangrijke open onderwerpen zijn een risicoanalyse op het stelsel en de (ISO-)normering. Beide waren vooraf niet gedefinieerd voor deze werkgroepen, maar staan wel gepland voor de oplevering van versie 2.0. Bij de uitwerking van deze onderwerpen wordt graag gebruik gemaakt van de aangeboden expertise van de werkgroepleden. Binnen de werkgroepen werd herhaaldelijk gerefereerd aan de onderlinge afhankelijkheid tussen de onderdelen van het stelsel, zoals ontwerp, governance, businessmodel, juridica en toezicht. Het projectteam ontwerp eid Stelsel onderschrijft deze afhankelijkheid. Alle afhankelijkheden zijn geadresseerd en zijn bij de betreffende deelprojecten in het programma neergelegd. Werkgroep Proof of Technology De opdracht voor de POT-werkgroep was tweeledig. Enerzijds was dit de beoordeling en (waar nodig) aanscherping van de gepubliceerde koppelvlakspecificaties en cryptografiebeschrijving. Anderzijds was dit het aantonen dat deze technische specificaties interoperabel en op grote schaal implementeerbaar zijn. Naast de eerder genoemde discussies hebben verschillende softwareontwikkelaars implementaties gemaakt op basis van deze specificaties. De belangrijkste resultaten van de POT-werkgroep zijn: de koppelvlakspecificaties en cryptografiebeschrijving zijn beide verbeterd en aangevuld; de verbeterde specificaties zijn eenvoudiger te implementeren op verschillende platforms; de implementaties zijn interoperabel en performen naar behoren. Pagina 6 van 23

14 Werkgroep Proof of Concept De opdracht voor de POC-werkgroep was ook tweeledig. Enerzijds was dit de verbetering en aanvulling van een aantal uitgewerkte klantreizen. 2 Anderzijds was dit het aantonen dat de functionele specificaties op een gebruiksvriendelijke manier kunnen worden geïmplementeerd. Een interactieontwerper heeft de verschillende klantreizen uitgewerkt tot clickable demo s. Echter door het uitvallen van deze interactieontwerper zijn niet alle gewenste klantreizen uitgewerkt. De belangrijkste resultaten van de POC-werkgroep zijn: de klantreizen zijn met behulp van clickable demo s verbeterd en aangevuld; de functionele specificaties zijn verbeterd en aangevuld om te zorgen dat ze gebruikersvriendelijk kunnen worden geïmplementeerd. 2 Een klantreis is een verhalende omschrijving van een specifieke sessie die een gebruiker van het eid Stelsel kan meemaken (bijvoorbeeld 1 e keer inloggen in nieuw account ). Pagina 7 van 23

15 Definitief Resultaten van de werkgroepen POT en POC 26 augustus Resultaten van de POT-werkgroep De POT-werkgroep had tot doel de koppelvlakspecificaties versie 1.0 en de cryptografie (t.b.v. privacybescherming en pseudoniemen) versie 0.88 (20 mei 2014) te beoordelen en waar nodig aan te vullen en aan te scherpen. Daarnaast was een doel om de implementeerbaarheid, interoperabiliteit en performance op verschillende platforms aan te tonen door POT software op te leveren voor de belangrijkste rollen en koppelvlakken en de beschreven cryptografie. In het algemeen kan, kijkend naar deze doelstellingen, worden gesteld dat het POT-traject succesvol is verlopen. Vanaf de start was duidelijk dat we er in geslaagd zijn afgevaardigden samen te brengen met een positief-kritische houding, de juiste inhoudelijke kennis en de wil om bij te dragen. Met elkaar zijn we er in goede sfeer in geslaagd de basis te leggen voor betere, completere specificaties die eenvoudiger te implementeren zijn, waarvan de belangrijkste zaken zijn beproefd in implementaties en waarbij is vastgesteld dat deze naar behoren kunnen performen. In de volgende paragrafen worden resultaten in meer detail beschreven. 2.1 Aanscherping van de koppelvlakspecificaties Uitgangspunt voor de POT waren de in januari gepubliceerde versie 1.0 van de koppelvlakspecificaties, aangevuld met de cryptospecificaties d.d. 20 mei Tijdens de werkgroepen is naast een review van de specificaties gewerkt aan het verdiepen en aanscherpen van een aantal onderwerpen. Hierbij stonden het verbeteren van de interoperabiliteit en het implementatiegemak, met name voor aansluitende dienstaanbieders, centraal. Belangrijke resultaten zijn: Vereenvoudigen van het koppelvlak van de dienstaanbieder met de makelaar. Het stelsel kent door de rijke scope ook complexe structuren om alle relevante gegevens te verzamelen en te communiceren. Door in het domein van de eid-makelaar een samenvatting van deze structuren aan te bieden, wordt het voor dienstaanbieders mogelijk om eenvoudig en volledig SAMLcompliant aan te sluiten op het stelsel. Alleen de dienstaanbieder die behoefte heeft aan de complexere structuren kan deze ook ontvangen. Toevoegen van attributen. Er is beschreven hoe wordt omgegaan met attributen, hoe deze kunnen worden opgevraagd en verstrekt en welke metagegevens over attributen worden vastgelegd. Beschrijven van de beveiliging van het berichtenverkeer. De mechanismen voor de beveiliging van het berichtenverkeer en de daarbij benodigde sleutels en algoritmen zijn in detail beschreven. Hierbij is geborgd dat de beveiliging voldoende toekomstvast is. Toevoegen van beschrijvingen voor metadata. Hierin wordt vastgelegd welke entiteiten en systemen actief zijn binnen het stelsel, welke rol of rollen ze mogen vervullen, welke gegevens ze mogen leveren en op welk betrouwbaarheidsniveau ze mogen acteren. Toevoegen van een beschrijving voor de dienstencatalogus. Hierin wordt vastgelegd welke diensten en dienstensets bestaan in het stelsel, welk betrouwbaarheidsniveau en welke identiteitstype en eventuele attributen vereist zijn en wie het recht heeft verklaringen op te vragen voor deze diensten. 2.2 Aanscherping van de cryptografie Voor het generen van pseudoniemen binnen het stelsel golden als uitgangspunt voor de POT de cryptospecificaties versie 0.88 (20 mei 2014). Tijdens de werkgroepen is naast een review van de specificaties gewerkt aan het verdiepen en aanscherpen van een aantal onderwerpen. Hierbij is o.a. aandacht uitgegaan naar implementatiegemak, zowel voor aansluitende dienstaanbieders als voor mogelijke HSM-leveranciers, en het faciliteren van verschillende migratiescenario s. Pagina 8 van 23

16 Belangrijke resultaten zijn: Vereenvoudiging van een aantal cryptografische bewerkingen om pseudoniemen te genereren om zo de implementatie in de HSM te vereenvoudigen. Toevoegen van beschrijvingen van de zogenaamde PPCA, een implementatie op een smartcard die direct herleiden van identiteiten in het domein van de authenticatiedienst onmogelijk maakt zonder compatibiliteit met het stelsel te verliezen. Alleen op deze manier is volledige privacy te waarborgen. Voorheen waren de methoden (U-Prove, Idemix, Duitse eid) die een dergelijke anonimiteit mogelijk maken lastig SAML-compliant te gebruiken omdat zij verplichten dat de dienstaanbieder (in plaats van de authenticatiedienst) een smartcard van de gebruiker met daarop een (U-Prove, Idemix) applicatie moet benaderen. Het unieke aan PPCA is dat het anonimiteit mogelijk maakt in een SAML-context waarbij de authenticatiedienst het uitlezen van de smartcard voor zijn rekening neemt. Door de compatibiliteit met het stelsel is met PPCA daarbij sommige problematiek, waaronder revocatie, ook eenvoudiger te adresseren dan bij vergelijkbare methoden. Vanuit de POT is aangegeven dat implementatie op basis van PPCA in een smartcardomgeving (met name Javacard) wordt bemoeilijkt doordat in deze omgeving geen elementaire cryptografische operaties mogelijk zijn (elliptische-kromme-puntoptellingen). Als gevolg hiervan is een aanvullende methode ontwikkeld en toegevoegd aan de specificaties ( Affine PPCA ) die dergelijke elementaire operaties vermijdt. Toevoegen van faciliteiten in het kader van opsporing. Onder strikte voorwaarden is het mogelijk een afgegeven pseudoniem terug te herleiden naar een algemeen bruikbare identiteit. Ook is het onder strikte voorwaarden mogelijk voor een identiteit in onderzoek pseudoniemen voor verschillende dienstaanbieders te genereren die kunnen worden gebruikt om mogelijk frauduleuze activiteiten op te sporen. Het mogelijk maken om voor dienstaanbieders een statisch versleuteld pseudoniem te genereren, waardoor een toekomstvaste migratieoplossing beschikbaar komt die volledig SAMLcompliant in het koppelvlak kan worden getransporteerd. Dit is een uitbreiding ten opzichte van de eerdere oplossing die alleen maar gerandomiseerde versleutelde pseudoniemen opleverde. Omdat het hier een migratieoplossing betreft dient te worden voorzien in voldoende prikkels voor dienstaanbieders en deelnemers om zo de gewenste uitfasering ook daadwerkelijk te laten plaatsvinden. Indien nodig zal hiervoor te zijner tijd een uiterste migratiedatum moeten worden vastgesteld. Door de toevoeging van zowel de genoemde migratieoplossing als PPCA kan het stelsel een wijd spectrum van privacybescherming ondersteunen zodat ook op het terrein van de privacy een toekomstvast stelsel ontstaat. 2.3 Beproeving door implementatie Zowel de koppelvlakken en de cryptografie zijn beproefd door middel van implementaties. De koppelvlakken zijn voor de interactie tussen dienstaanbieder, makelaar, authenticatiedienst en machtigingendienst geïmplementeerd in zowel Java,.Net als PHP. In Java zijn ook gedeelten van een attribuutdienst en SectorID-dienst en hun koppelvlakken met de makelaar geïmplementeerd. De implementaties zijn op juistheid en interoperabiliteit getoetst door ketentesten in verschillende configuraties (telkens twee verschillende implementaties) uit te voeren. Voor de cryptografie ten behoeve van pseudoniemen is een implementatie uitgevoerd in Java. De ontwikkelaars hebben steeds als klankbord gefungeerd voor de leden van de werkgroep en hebben ook actief bijgedragen tijdens de werkgroepbijeenkomsten. Tijdens de implementatie zijn ook verschillende bevindingen gedaan die hebben bijgedragen aan de aanscherping van de verschillende specificaties. Als resultaat van de POT-werkgroep zal de ontwikkelde broncode beschikbaar worden gesteld. Door de focus op ondersteunen van het specificatietraject zijn deze implementaties niet in alle gevallen compleet of compleet conform de laatste versie van de specificaties. De broncode wordt as-is, zonder garanties en uitsluitend ter inspiratie opgeleverd. Pagina 9 van 23

17 Definitief Resultaten van de werkgroepen POT en POC 26 augustus Performance De implementaties zijn met name op het gebied van de implementatie van zowel de cryptografie die ten behoeve van de pseudoniemen wordt gebruikt, als de cryptografie die ten behoeve van de algemene beveiliging van verbindingen en berichtenverkeer wordt gebruikt, beoordeeld op performance. Volgens de eerste bevindingen (onder voorbehoud van meer representatievere tests) lijkt de cryptografie geen bottleneck in de performance te vormen. In verhouding met de overige verwerkingsstappen, zoals het processen van de berichten zelf, is de belasting door de cryptografie niet significant zwaar. Hierbij dient nog te worden opgemerkt dat geen gebruikt gemaakt is van een representatieve omgeving. Zo is er bijvoorbeeld geen HSM gebruikt (zou negatief kunnen doorwerken op de resultaten door communicatieoverhead), maar ook geen high performance servers, maar een ontwikkelomgeving op een gewone laptop (zou juist positief kunnen doorwerken op de resultaten). Pagina 10 van 23

18 3 Resultaten van de POC-werkgroep De POC-werkgroep had tot doel om een aantal uitgewerkte klantreizen 3 te verbeteren en aan te vullen door middel van het maken van clickable demo s. Daarnaast was een doel om aan te tonen dat de functionele specificaties op een gebruiksvriendelijke manier kunnen worden geïmplementeerd. In het algemeen kan worden gesteld dat een groot deel van deze doelen zijn behaald. Veel klantreizen zijn door clickable demo s verder uitgewerkt en aangescherpt. Helaas is het niet gelukt om alle klantreizen door te ontwikkelen, doordat de interaction designer van de werkgroep vanaf juli wegens fysieke beperkingen niet langer kon deelnemen. Verder heeft de werkgroep een aantal ontwerpvoorstellen gedaan ter verbetering en aanvulling van het voorgelegen ontwerp van het eid Stelsel. Deze voorstellen worden meegenomen in ontwikkeling van het ontwerp 2.0 van het eid Stelsel. Hiermee kan het stelsel uiteindelijk gebruiksvriendelijker worden geïmplementeerd. Verderop in dit hoofdstuk worden de belangrijkste resultaten en ontwerpvoorstellen van de werkgroep beschreven. Allereerst wordt hieronder kort de werkwijze van de werkgroep toegelicht. Werkwijze De eerste bijeenkomst op 16 mei 2014 bestond uit de introductie van het vastgestelde ontwerp 1.0 voor het eid Stelsel, inclusief uitgangspunten. Gedurende alle bijeenkomsten kregen werkgroepleden de gelegenheid om voor hen belangrijke discussiepunten in te brengen. Het eid-projectteam heeft deze punten thematisch geordend en heeft gedurende het traject geprobeerd om zoveel mogelijk discussiepunten te behandelen. De werkwijze die hierbij werd gehanteerd, bestond uit twee fases. In de eerste fase gaf het eid-projectteam een introducerende presentatie inclusief mogelijke afwegingen. Hierbij werden ook zogenaamde klantreizen gebruikt, waarin via klikbare schermen mogelijke scenario s die een gebruiker van het eid Stelsel zou kunnen doorlopen zichtbaar werden gemaakt. Bij deze presentaties hadden werkgroepleden de gelegenheid om hun belangen en afwegingen te delen met de rest van de werkgroep. In de tweede fase schreef het eidprojectteam een ontwerpvoorstel op basis van de gevoerde discussies en de genoemde afwegingen. Deze ontwerpvoorstellen werden vervolgens aan de werkgroep gepresenteerd met de vraag of dit voorstel de juiste conclusies op basis van de gevoerde discussies weergaf. Na bespreking in de werkgroep werd het ontwerpvoorstel aangepast met als uiteindelijke doel om consensus te bereiken binnen de werkgroep. Gedurende de laatste twee Figuur 1: Uitbeelding van de gefaseerde werkwijze. maanden van het gehele traject werden documenten en argumenten met elkaar uitgewisseld via de online omgeving Confluence. Hierdoor kon ook buiten de geplande bijeenkomsten voortgang gemaakt blijven worden. 3 Een klantreis is een verhalende omschrijving van een specifieke sessie die een gebruiker van het eid Stelsel kan meemaken (bijvoorbeeld 1 e keer inloggen in nieuw account ). Pagina 11 van 23

19 Definitief Resultaten van de werkgroepen POT en POC 26 augustus Gebruik en beheer van authenticatiedienst Het ontwerp van het eid Stelsel stelt strenge eisen aan de gebruikersinteractie. Ook als een gebruiker zich heel eenvoudig wil authentiseren voor een (website van een) dienstaanbieder. Zo moet de gebruiker vanuit elke dienstaanbieder (bij de makelaar) kunnen kiezen uit meerdere authenticatiediensten. De authenticatiedienst moet de gebruiker ondersteunen met mogelijkheden op zelfcontrole en consent. Verder moet er een bepaalde mate van consistentie zijn tussen authenticatiediensten terwijl er ook nog voldoende ruimte moet overblijven voor deze partijen om zich in de markt te onderscheiden. Voor de gebruiker moet de gehele gebruikersinteractie laagdrempelig, eenvoudig en duidelijk zijn. Ook iemand die gewend is aan een relatief simpele authenticatie zoals bijvoorbeeld bij de Belastingdienst met DigiD. Tegelijkertijd moet ook de privacy en veiligheid van de gebruiker gewaarborgd worden. Bij deze afweging zullen sommige gebruikers een onbezorgde en andere weer een kritische houding hebben. De belangrijkste resultaten van de POC is dat het waarschijnlijk mogelijk is om aan de eisen van het eid Stelsel te voldoen zonder dat dit ten koste gaat van het gebruikersgemak. Een onbezorgde gebruiker hoeft nauwelijks extra keuzes te maken voor het beheer van zijn authenticatiemiddel. De voorkeur voor een authenticatiedienst kan worden vastgelegd. Deze voorkeur kan een volgende keer weer worden gebruikt. Zelfcontrole en consent kunnen hierbij voor een onbezorgde gebruiker alleen als dat er echt toe doet worden aangeboden. Dit vereist overigens wel een inspanning van de authenticatiedienst. Een kritische gebruiker kan ook adequaat ondersteund worden door hem een strengere interpretatie aan te bieden van: als het er toe doet. In het vervolg van deze paragraaf worden de overeengekomen ontwerpvoorstellen in iets meer detail toegelicht. Controleniveau voor consent en zelfcontrole Het controleniveau is een gebruikersinstelling bij de authenticatiedienst. Het geeft de mate aan waarin een gebruiker consent moet geven en inzicht krijgt in zijn contacthistorie ten behoeve van zelfcontrole. Ontwerpvoorstellen: Alleen consent vragen en zelfcontrole bieden wanneer het ertoe doet. De gebruiker kiest daarbij zijn eigen controleniveau dat meeweegt bij de bepaling van wanneer wat ertoe doet (de risicoanalyse). Het controleniveau wordt initieel ingesteld op een basisniveau. Dit niveau biedt de gebruiker alle mogelijkheden voor zelfcontrole en zal veiligheid boven gebruiksgemak stellen. Voor dit basisniveau worden de eisen beschreven. Andere niveaus, waarin de gebruiker minder zelfcontrole kan doen, staan open ter invulling. Hierover worden wel eisen gesteld aan inzage en controle. Afwijking van het basisniveau kan alleen in samenspraak met de gebruiker en kan uitsluitend via opt-in procedures (i.e. met expliciete toestemming van de gebruiker) worden gekozen. Comfortinformatie Comfortinformatie betreft informatie over de gebruiker die functioneel niet nodig is maar de gebruikersbeleving positief kan beïnvloeden. Een voorbeeld daarvan is een aanspreeknaam van de gebruiker. Ontwerpvoorstellen: De afweging van belangen leidt op dit moment tot het voorstel om de authenticatiedienst geen comfortinformatie aan de dienstaanbieders door te laten geven. Elke dienstaanbieder is zelf verantwoordelijk voor de presentatie van een acceptabele aanspreeknaam. Pagina 12 van 23

20 Optimaliseren van de gebruikersinteractie Gebruikersgemak is één van de belangrijke ontwerpeisen voor het eid stelsel. De gebruikersinteractie is hier een belangrijk aspect van. Het streven van het ontwerp is het minimaliseren van het aantal klikken en het aantal zichtbare partijen die een rol spelen in de authenticatie. Gebruikersvoorkeuren spelen hierbij een belangrijke rol. Ontwerpvoorstellen: De gebruiker krijgt de mogelijkheid om zijn voorkeur voor een authenticatiedienst en/of machtigingendienst vast te leggen bij de makelaar. De makelaar kan de gebruiker vervolgens direct routeren naar de betreffende authenticatiedienst en/of machtigingendienst. Deze diensten moeten wel de mogelijkheid bieden om de gebruiker weer terug te leiden naar de makelaar om toch een andere dienst te kiezen. De makelaar kan ervoor kiezen om de stijl van zijn pagina's aan te passen aan de stijl van de dienstaanbieder. Voor de integratie van de makelaar in de website van de dienstaanbieder zullen richtlijnen en best practices komen. Die moeten voor enige consistentie tussen dienstaanbieders (en makelaars) zorgen. De makelaar kan ook (voor een deel van zijn klanten) voor een eigen stijl kiezen. Ook in dit geval zijn er voorschriften om te komen tot consistentie voor de gebruiker. Voor de authenticatiediensten geldt juist weer dat deze zich herkenbaar en consistent tonen aan hun klanten. Elke suggestie op samenwerking tussen authenticatiedienst en dienstaanbieder moet voorkomen worden. Enige consistentie tussen authenticatiediensten is gewenst. Maar voorschriften zullen ruimte laten voor de authenticatiediensten om zich te onderscheiden. In het algemeen dient elke partij zich als onderdeel van een gezamenlijke gebruikersflow te gedragen en niet als geschakelde individuele stapjes. Hierdoor is het voor alle partijen verplicht om bijvoorbeeld de mogelijkheid te bieden om een stap terug te gaan in het inlogproces. De lijst met authenticatiediensten bij de makelaar is op alfabetische volgorde geordend. Zelfcontrole bij de dienstaanbieder Onder zelfcontrole wordt verstaan: het bieden van een mogelijkheid aan de gebruiker om inzage te krijgen in zijn eigen gegevens en zijn eigen contacthistorie, en zo zelf de controle uit te voeren op de juistheid en volledigheid van zijn gegevens. Ontwerpvoorstellen: De gebruiker moet zelfcontrole kunnen uitvoeren. Om dit te kunnen doen is het voor de dienstaanbieders dwingend voorgeschreven om de gebruiker te tonen wanneer voor het laatst is ingelogd ( uw laatste bezoek was ). De gebruiker moet bij de dienstaanbieder ook zijn contacthistorie kunnen opvragen. De gebruiker kan daaruit misbruik van zijn identiteit (middelen) of machtigingen opmerken. Er komt een aanbeveling om gebeurtenissen te signaleren die het urgent maken dat de gebruiker zijn gegevens controleert (afwijkingen van het normale gebruikerspatroon). Exception flows Transacties in het eid Stelsel lopen over meerdere schijven. Dat betekent dat ook de foutafhandeling over meerdere partijen wordt verdeeld. Per rol in het eid Stelsel zal worden beschreven (in de vorm van "exception flows") wat er fout kan gaan in het authenticatieproces en op welke wijze deze fout moet worden afgehandeld. Ontwerpvoorstellen: Als een gebruiker wordt doorgestuurd naar een website die niet beschikbaar is dan is het voor de eid-deelnemers verplicht om een pagina foutafhandeling te tonen. Voor de dienstaanbieder is dit optioneel. Binnen het eid Stelsel worden afspraken gemaakt over de codes die worden gebruikt in het geval er een fout wordt geconstateerd. Pagina 13 van 23