Programma eID eID-platform
Contactpersoon Nicole Damen T 06 46 87 92 55
[email protected] Datum 27 augustus 2014
eID-platform #3
Vergaderdatum en tijd Vergaderplaats
3 september 2014, 15.00 - 17.00 uur Logius, vergaderruimte Oranje 0.031
Deelnemers
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), JanHein Willemse (VECOZO)
Andere aanwezigen vanuit het
Carlo Koch, Gerrit Jan van ’t Eind, Nicole Damen (verslag)
programma eID
Aantal pagina's 2
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. MasterplaneID Presentatie van programmamanagers waarin zij het Masterplan toelichten dat is vastgesteld door de StuurgroepeID 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
6. Stand van zaken business model Bespreken voortgang werkgroep business model
Programma eID eID-platform Datum 27 augustus 2014
7. Toezicht Inbreng stakeholders bij project Toezicht 8. W.v.v.t.k. 9. Rondvraag 10. Sluiting
Pagina 2 van 2
Programma eID eID-platform Contactpersoon Nicole Damen T 06 46 87 92 55
[email protected] Datum 27 augustus 2014
Naamgeving eID Stelsel
Agendapunt Onderwerp
3a. Communicatie Naamgeving eID Stelsel
Status
Ter informatie en voor discussie over de introductie van de naam Kennisnemen van: 1. Totstandkoming nieuwe naam eID Stelsel en 2. Introductiestrategie nieuwe naam
Voorstel
Aantal pagina's 2
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 StuurgroepeID 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
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 onderzoek1 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 StuurgroepeID 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
Programma eID eID-platform Contactpersoon Nicole Damen T 06 46 87 92 55
[email protected] Datum 27 augustus 2014 Aantal pagina's 3
Oplegmemo bij resultaten werkgroepen POT’s en POC’s
Agendapunt Van
5. Resultaten Proof of Concept en Proof of Technology Werkgroepen POT’s en POC’s
Onderwerp Status
Resultaten van werkgroepen POT’s en POC’s Ter informatie / Ter goedkeuring
Voorstel
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 2.0. 3. 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 2.0.
1. 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
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 2014
3. 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
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
Resultaten van de werkgroepen POT en POC programma eID Versie:
1.0
Datum: 26 augustus 2014 Status:
Definitief
Pagina 1 van 23
Colofon
Programma eID Deelproject Afsprakenstelsel
Bezoekadres: Herman Gorterstraat 5 | 6e 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
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—8
2.1
Aanscherping van de koppelvlakspecificaties—8
2.2
Aanscherping van de cryptografie—8
2.3
Beproeving door implementatie—9
2.4
Performance—10
3
Resultaten van de POC-werkgroep—11
3.1
Gebruik en beheer van authenticatiedienst—12
3.2
Gebruik en beheer van attribuutdienst—14
3.3
Gebruik en beheer machtigingen—15
4
Openstaande onderwerpen—18
4.1
POT-werkgroep—18
4.2
POC-werkgroep—19
Bijlage Samenstelling van de werkgroepen—21
Pagina 4 van 23
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 broncode1. 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
Definitief | Resultaten van de werkgroepen POT en POC | 26 augustus 2014
1 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
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 e meemaken (bijvoorbeeld “1 keer inloggen in nieuw account”). Pagina 7 van 23
Definitief | Resultaten van de werkgroepen POT en POC | 26 augustus 2014
2 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 2014. 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:
2.2
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. 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
Belangrijke resultaten zijn:
2.3
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. 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
Definitief | Resultaten van de werkgroepen POT en POC | 26 augustus 2014
2.4
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
3 Resultaten van de POC-werkgroep
De POC-werkgroep had tot doel om een aantal uitgewerkte klantreizen3 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 e meemaken (bijvoorbeeld “1 keer inloggen in nieuw account”). Pagina 11 van 23
Definitief | Resultaten van de werkgroepen POT en POC | 26 augustus 2014
3.1
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
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
Definitief | Resultaten van de werkgroepen POT en POC | 26 augustus 2014
3.2
Gebruik en beheer van attribuutdienst
Een dienstaanbieder wil zekerheid over de informatie die de gebruiker verstrekt bij de afname van een Digitale dienst. Om die reden maakt hij gebruik van een attribuutdienst die meer zekerheid over de kwaliteit van de informatie kan geven. Voor de gebruiker kan het makkelijk zijn dat hij wordt ondersteund bij het invullen van zijn klantgegevens op de website van de dienstaanbieder. De belangrijkste resultaten bij beheer en gebruik van authenticatiediensten gelden ook voor de attribuutdiensten. Maar aanvullend daarop zijn de volgende resultaten specifiek voor de attribuutdiensten:
Het is mogelijk om een gebruiker een weloverwogen consent beslissing te laten nemen over het vrijgeven van zijn attributen. De dienstaanbieder levert hiervoor (via zijn makelaar) de benodigde informatie aan in de dienstencatalogus en maakt daarbij onderscheid tussen 'noodzakelijke' en 'optionele' attributen.
De makelaar zorgt voor het toepassen van attribuutrichtlijnen van het stelsel. En indien noodzakelijk kan er in de toekomst een centrale controle op deze attribuutrichtlijnen plaatsvinden in dit registratieproces. Maar het eID Stelsel kent in elk geval geen centrale rol die de juistheid van deze informatie controleert.
De dienstaanbieder kan de waarde van een aangeleverd attribuut beoordelen doordat de herkomst, actualiteit en betrouwbaarheidsniveau-trustbinding4 van het attribuut wordt meegegeven. En het is aan de dienstaanbieder om een attribuut éénmalig of veelvuldig op te vragen.
In het vervolg van deze paragraaf worden de overeengekomen ontwerpvoorstellen in iets meer detail toegelicht. Controleniveau voor consent en zelfcontrole Uitgangspunt binnen het stelsel is dat gegevens alleen met instemming van de gebruiker worden verstrekt. Ontwerpvoorstellen:
Een attribuutdienst moet een mogelijkheid bieden voor een gebruiker om in te loggen en zijn eigen gegevens in te zien. Inzage omvat de attributen zelf, de bijbehorende metagegevens en de verstrekkingshistorie. De gebruiker dient altijd de mogelijkheid geboden te worden voor expliciete consent. Overslaan van de expliciete consent is alleen mogelijk via een opt-in procedure. Voor zover niet in tegenspraak met wettelijke bepalingen dient de gebruiker de mogelijkheid te hebben om zijn gegevens te verwijderen. Dit geldt zowel voor de gegevens zelf als voor de verstrekkingshistorie.
Metagegevens Metagegevens zijn gegevens die iets zeggen over het attribuut dat wordt geregistreerd. De metagegevens kunnen een belangrijke rol spelen om iets te zeggen over de kwaliteit en het daarmee ook het betrouwbaarheidsniveau van het attribuut. Ontwerpvoorstellen:
Bij een attribuut worden de volgende metagegevens geregistreerd: o o o
4
Herkomst (basisregistratie, andere overheidsregistratie, WID-document, stork-verklaring, niet-overheidsregistratie, eigen verklaring burger); Actualiteit (wanneer vastgesteld, respectievelijk ontleend aan bron); Betrouwbaarheidsniveau authenticatie, gebruikt bij vaststelling van het gegeven (voor zover van toepassing).
Trustbinding = De zekerheid dat dit attribuut bij betreffende gebruiker hoort. Meestal niveau van authenticatie. Pagina 14 van 23
Wie bepaalt welke attribuutdienst wordt gebruikt? De verwachting is dat er een groot aantal attribuutdiensten gaan ontstaan met een grote overlap in het type attributen. Denk hierbij aan basisregistraties van de overheid, registraties bij authenticatiedienst, commerciële attribuutdienst. De vraag is nu wie bepaalt welke attribuutdienst gebruikt gaat worden. Ontwerpvoorstellen:
Als de makelaar vaststelt dat er slechts één attribuutdienst het door de afnemer gevraagde attribuut kan leveren dan wordt de gebruiker automatisch doorgeleid naar deze dienst. In alle andere gevallen bepaalt de gebruiker bij welke attribuutdienst de gegevens worden opgehaald.
Welke metagegevens mogen/moeten worden verstrekt? Metagegeven die de aanvrager nodig heeft zoals betrouwbaarheidsniveau (kwaliteit van het gegeven, maar ook trustbinding naar de persoon), herkomst en actualiteit (vastgesteld op datum x). Ontwerpvoorstellen:
In verband met eenvoud en verantwoording worden altijd alle door het stelsel gedefinieerde en beschikbare metagegevens meegeleverd.
Weloverwogen beslissing De gebruiker moet een weloverwogen keuze kunnen maken of hij een attributen beschikbaar wil stellen. Ontwerpvoorstellen:
3.3
Om een beslissing te kunnen nemen of een attribuut beschikbaar te stellen heeft de gebruiker minimaal de volgende informatie nodig: o aan welke partij wordt het attribuut geleverd; o wat het doel is; o wat het gevolg is als er geen consent wordt gegeven. Bij “gevolg” worden de mogelijkheden beperkt tot “optioneel” en “noodzakelijk”.
Gebruik en beheer machtigingen
Ook bij de machtigingsdienst zijn de belangrijkste resultaten bij beheer en gebruik van authenticatiediensten van toepassing. Aanvullend daarop zijn de volgende resultaten specifiek voor het beheer en gebruik van machtigingen.
Het registratie- en beheerproces van machtigingen kan relatief laagdrempelig, eenvoudig en betrouwbaar ingericht worden. Dit geldt ook voor degene die machtigingen bij meerder machtigingsdiensten onder gebracht hebben. Hierbij is geen centrale stelsel component nodig. Ook (tijdelijk en plotseling) niet-digitaal-vaardigen kunnen bediend worden. De bevoegdheid wordt uitgedrukt in een dienst. De beschrijving hiervan is zodanig dat deze aansluit op de belevingswereld van de meeste burgers. Een ‘dienst’ kan voor bedrijven te beperkt zijn. Een relatief eenvoudige uitbreiding gebaseerd op extra beperkende attributen zou hiervoor een oplossing kunnen zijn. Dit moet nog nader onderzocht worden. Dienstaanbieders ontvangen de naam van de gemachtigde om belanghebbenden een fatsoenlijke zelfcontrolemogelijkheid te bieden. De impact op de privacy van de gemachtigde is minimaal doordat de dienstaanbieder hem niet als klant kan herkennen. Dienstaanbieders registreren alle diensten in de dienstencatalogus. Dienstaanbieders kunnen met toestemming van de eigenaar gebruik maken van gedeelde diensten. Het eID Stelsel kent daarbij geen centrale politierol die controleert of dienstaanbieders de diensten correct interpreteren. Pagina 15 van 23
Definitief | Resultaten van de werkgroepen POT en POC | 26 augustus 2014
In het vervolg van deze paragraaf worden de overeengekomen ontwerpvoorstellen in iets meer detail toegelicht. Uitdrukken van bevoegdheid met behulp van dienst Bevoegdheden in het eID Stelsel moeten worden beschreven op een manier die door machines te begrijpen is. Daardoor sluit bijvoorbeeld de vormvrije beschrijving van bevoegdheden in het handelsregister wel aan op de belevingswereld van de gebruiker, maar is deze niet 1-op-1 bruikbaar binnen het stelsel. Het ontwerp versie 2.0 zal in navolging van DigiD Machtigen het begrip “dienst” gebruiken om de bevoegdheid in een machtiging uit te drukken. ‘Dienst’ kan overigens een elementaire dienst zijn specifiek voor één dienstaanbieder, of juist bruikbaar bij meerdere dienstaanbieders. Het kan ook een verzameling van elementaire diensten zijn (dienstenset) van verschillende dienstaanbieders. Consistentie in de beschrijving van een dienst vanuit het perspectief van de gebruiker kan bereikt worden doordat een dienstaanbieder ook andermans dienst mag aanbieden. De eigenaar van de betreffende dienst moet dat dan wel toestaan. Met name bedrijfssectoren kunnen gebruik maken van dergelijke gedeelde diensten om consistentie en duidelijkheid in de sector te bereiken. Deze keuze voor ‘dienst’ heeft wel een aantal beperkingen tot gevolg. Deels kunnen die beperkingen ontweken worden door creatief gebruik te maken van het begrip dienst. Maar vooral in het bedrijvendomein kan het begrip dienst als uitdrukking van bevoegdheid tekortschieten. In de POCwerkgroep zijn voorstellen gedaan die daar een oplossing voor kunnen bieden en een relatief kleine aanpassing vergen op de huidige koppelvlakken. De ene betreft het toevoegen van extra attributen waarmee een bevoegdheid verder beperkt kan worden. De ontvangende dienstaanbieder moet deze attributen dan uiteraard wel accepteren. De andere betreft een bevoegdheid voor een specifieke transactie. Dit is echter meer van toepassing op ondertekendiensten en system to system, die beide buiten scope vallen van versie 2.0.
Ondersteuning niet-digitaal-vaardigen Niet-digitaal-vaardigen moeten bediend kunnen worden door het eID Stelsel. De overheid moet garanderen dat er mogelijkheden tot machtigen zijn voor deze doelgroep. In het uiterste geval zal de overheid zelf een machtigingsdienst als vangnet moeten inrichten. Voor private machtigingsdiensten is er vanuit het stelsel geen eis om niet-digitaal-vaardigen te ondersteunen. Tijdelijk of plotseling niet-digitaal-vaardigen met machtigingen bij een machtigingsdienst zonder ondersteuning voor niet-digitaal vaardigen, kunnen terugvallen op het vangnet. Daar kunnen zij een anderen machtigen om hun machtigingen bij de betreffende machtigingsdienst te beheren. Op deze manier kunnen hun machtigingen zo nodig verhuisd worden naar een andere machtigingsdienst.
Privacy bij gebruik van machtigingen De belangrijkste vraag wat betreft privacy bij het gebruik van machtigingen is of er wel of geen comfortgegevens over de gemachtigde met de bevoegdheidsverklaring mee gaan naar de dienstaanbieder. Daarbij moet een afweging worden gemaakt tussen zelfcontrole en privacy. Ten behoeve van zelfcontrole zal een dienstaanbieder aan een belanghebbende moeten laten zien wie namens hem diensten heeft afgenomen. Ten behoeve van privacy krijgt de dienstaanbieder de naam van een gemachtigde, terwijl zijn naam, vanwege privacy, niet meekomt als hij voor zichzelf inlogt bij dezelfde dienstaanbieder. De oplossing hiervoor is dat de dienstaanbieder de naam van de gemachtigde ontvangt om zijn belanghebbende een fatsoenlijke zelfcontrolemogelijkheid te bieden. Maar door een relatief eenvoudige maatregel kan de dienstaanbieder deze naam niet koppelen aan dezelfde persoon (gemachtigde) indien hij voor zichzelf authentiseert bij dezelfde dienstaanbieder. Pagina 16 van 23
Totaaloverzicht machtigingen Een machtigingsverlener en een gemachtigde besluiten samen bij welke machtigingendienst hun machtiging ondergebracht wordt. Hierdoor kan het voorkomen dat de machtigingen van één belanghebbende bij meerdere machtigingsdiensten ondergebracht zijn. Zeker na verloop van tijd kan het heel lastig zijn voor een gebruiker om overzicht te houden over zijn machtigingen. Binnen het huidige ontwerp zijn mogelijkheden aanwezig om een gebruiker overzicht te laten behouden over zijn machtigingen, zelfs als die bij verschillende machtigingsdiensten zijn geregistreerd. Machtigingsdiensten moeten daarvoor een relatief eenvoudige maatregel nemen. Machtigingsdiensten (of andere partijen) kunnen daarmee heel laagdrempelig dit overzicht bieden.
Machtigingsscenario’s Het huidige ontwerp kan op dit moment drie verschillende scenario’s bedienen. 1. Dienstaanbieders die nog niets weten van de gebruiker en deze via een makelaar routeert naar de gekozen machtigingsdienst. 2. Dienstaanbieders die al weten welke machtigingsdienst de gebruiker heeft en deze direct routeert naar deze dienst. 3. Dienstaanbieders die een portaal hebben met klantbeeld/dossieroverzicht en aan de gemachtigde willen tonen voor welke diensten hij bevoegd is (om alleen dat deel te tonen).
Pagina 17 van 23
Definitief | Resultaten van de werkgroepen POT en POC | 26 augustus 2014
4 Openstaande onderwerpen
4.1
POT-werkgroep
Onderstaande punten staan nog open en moeten in een later stadium worden geadresseerd.
Risicoanalyse / fraudeanalyse Een dergelijke analyse brengt risico’s, maatregelen en geaccepteerde restrisico’s in kaart. Afspraak: Deze analyses zijn nodig voor versie 2.0 van het ontwerp van het afsprakenstelsel en moeten daarom op korte termijn worden ingepland.
Fraudedetectie De eisen aan het proactief opsporen van fraude zijn nog niet beschreven. Afspraak: Deze eisen zijn nodig voor versie 2.0 van het ontwerp van het afsprakenstelsel en daarom moeten op korte termijn deze eisen in kaart worden gebracht.
Mobiel gebruik met behulp van apps Tijdens de bijeenkomsten van de werkgroep en tijdens de ontwerpfase van versie 1.0 zijn de contouren van dit onderwerp verkend. Het is echter niet nodig om dit op korte termijn verder uit te werken. Afspraak: Mobiel gebruik komt in een volgende versie van het ontwerp. Voor de betreffende versie zal besloten gaan worden of er op dit onderwerp een POT of POC gaat plaatsvinden.
System to system communicatie Tijdens de bijeenkomsten van de werkgroep en tijdens de ontwerpfase van versie 1.0 zijn de contouren van dit onderwerp verkend. Het is echter niet nodig om dit op korte termijn verder uit te werken. Afspraak: System to system komt in een volgende versie van het ontwerp. Voor de betreffende versie zal besloten gaan worden of er op dit onderwerp een POT of POC gaat plaatsvinden.
Single Sign On / Sign Out Tijdens de bijeenkomsten van de werkgroep en tijdens de ontwerpfase van versie 1.0 zijn de contouren van dit onderwerp verkend. Het is echter niet nodig om dit op korte termijn verder uit te werken. Afspraak: Single Sign On / Sign Out komt in een volgende versie van het ontwerp. Voor de betreffende versie zal besloten gaan worden of er op dit onderwerp een POT of POC gaat plaatsvinden.
Pagina 18 van 23
Ondertekendienst Tijdens de bijeenkomsten van de werkgroep en tijdens de ontwerpfase van versie 1.0 zijn de contouren van dit onderwerp verkend. Het is echter niet nodig om dit op korte termijn verder uit te werken. Afspraak: Ondertekendienst komt in een volgende versie van het ontwerp. Voor de betreffende versie zal besloten gaan worden of er op dit onderwerp een POT of POC gaat plaatsvinden.
Dienstbemiddelaars / portalen Tijdens de bijeenkomsten van de werkgroep en tijdens de ontwerpfase van versie 1.0 zijn de contouren van dit onderwerp verkend. Het is echter niet nodig om dit op korte termijn verder uit te werken. Afspraak: Dienstbemiddelaars / portalen komt in een volgende versie van het ontwerp. Voor de betreffende versie zal besloten gaan worden of er op dit onderwerp een POT of POC gaat plaatsvinden.
4.2
POC-werkgroep
Nut en noodzaak van de (Polymorfe) PseudoID Volgens een aantal deelnemers aan de werkgroep maakt de (Polymorfe) PseudoID het stelsel wellicht erg ingewikkeld. Zij betwijfelen of deze complexiteit opweegt tegen de belangen op het gebied van vertrouwelijkheid. Afspraak: Dit is geen onderwerp voor de POC werkgroep. De discussie over (Polymorfe) PseudoID wordt buiten de werkgroep onder verantwoordelijkheid van het programmamanagement eID gevoerd. Geïnteresseerde leden van de werkgroep kunnen aan deze discussie meedoen.
Normenkader Het opstellen van een normenkader valt niet binnen de scope van de werkgroep. Voor de implementatie van de pilots in 2015 is het wel van belang dat dit normenkader is opgesteld. Afspraak: Het normenkader wordt in een aparte werkgroep opgesteld. Geïnteresseerde deelnemers van de werkgroepen kunnen zitting nemen in deze werkgroep.
Machine to machine invulling Het huidige ontwerp richt zich op digitale diensten die via webportalen van dienstaanbieders worden aangeboden. De eID diensten moeten ook aangeboden kunnen worden in het machine to machine kanaal. Afspraak: Dit onderwerp behoort niet tot deze eerste ronde van POT’s en POC’s. Uitwerking van eID in het M2Mkanaal zal in een volgende versie van het ontwerp van het stelsel worden meegenomen. Voorafgaand aan de betreffende versie zal besloten gaan worden of er op dit onderwerp een POT of POC gaat plaatsvinden.
Pagina 19 van 23
Definitief | Resultaten van de werkgroepen POT en POC | 26 augustus 2014
Ondertekenen eID kan ook ondersteuning geven aan het ondertekenen van documenten. Dit is echter nog niet opgenomen in het huidige ontwerp van het stelsel. Afspraak: Ondertekenen komt in een volgende versie van het ontwerp. Voor de betreffende versie zal besloten gaan worden of er op dit onderwerp een POT of POC gaat plaatsvinden.
Dienstbemiddelaar Het kan ook voorkomen dat niet de dienstaanbieder zelf de gebruiker ondersteunt bij het afnemen van digitale diensten, maar dat een andere partij dit namens de dienstaanbieder doet. In dit geval is er sprake van een dienstbemiddelaar. (Denk hierbij aan de situatie dat Kluwer digitale diensten aanbiedt om de aangifte voor de Belastingdienst in te vullen, te ondertekenen en in te zenden.) Afspraak Dienstbemiddelaar zal in een volgende versie van het ontwerp van het stelsel worden meegenomen. Voor de betreffende versie zal besloten gaan worden of er op dit onderwerp een POT of POC gaat plaatsvinden.
Werken met verschillende personages door gebruiker Het ontwerp van het eID stelsel maakt het mogelijk dat de gebruiker verschillende personages kan aannemen. Denk hierbij aan: een personage om overheidsdiensten af te nemen en een personage om commerciële diensten af te nemen, een personage om de rol van gemachtigde in te vullen, etc. Afspraak Personages zal in een volgende versie van het ontwerp van het stelsel worden meegenomen. Voor de betreffende versie zal besloten gaan worden of er op dit onderwerp een POT of POC gaat plaatsvinden.
Ketenmachtigingen Het is ook mogelijk dat een gemachtigde weer gebruik maakt van een andere partij om hem te ondersteunen bij het afnemen van een dienst. Er is dan sprake van ketenmachtigingen. Afspraak: Ketenmachtiging zal in een volgende versie van het ontwerp van het stelsel worden meegenomen. Voor de betreffende versie zal besloten gaan worden of er op dit onderwerp een POT of POC gaat plaatsvinden.
Invulling bij apps door dienstaanbieders Het huidige ontwerp richt zich op digitale diensten die via webportalen van dienstaanbieders worden aangeboden. De eID-diensten moeten ook aangeboden kunnen worden op mobiele devices ter ondersteuning van bijvoorbeeld apps. Afspraak: eID op mobiele devices zal in een volgende versie van het ontwerp van het stelsel worden meegenomen. Voor de betreffende versie zal besloten gaan worden of er op dit onderwerp een POT of POC gaat plaatsvinden.
Pagina 20 van 23
Kunnen attributen op één plek beheerd worden? De verwachting is dat in de toekomst een groot aantal attribuutdiensten binnen het stelsel actief zullen zijn. Dit kan een enorme beheerlast voor de gebruikers gaan betekenen. Daarom is het voorstel gedaan om een voorziening te creëren waarmee, vanaf één plek, de gebruiker alle attributen kan beheren. Afspraak: Deze wens wordt binnen het project eID nader onderzocht.
eID-brede omgeving waar gebruikers overzicht hebben van al hun eID-gebruik De verwachting is dat in de toekomst een gebruiker bij verschillende authenticatiediensten een middel heeft afgenomen, in verschillende registers machtigingen heeft geregistreerd en bij verschillende attribuutdiensten gegevens heeft geregistreerd. Het gevaar bestaat dat deze gebruiker op deze manier onvoldoende inzicht heeft wat er is vastgelegd en wat wordt gebruikt. Daarom is het voorstel gedaan om een voorziening te creëren waarmee, vanaf één plek de gebruiker inzicht heeft in registratie en gebruik van al zijn gegevens binnen het stelsel. Afspraak: Deze wens wordt binnen het project eID nader onderzocht.
Pagina 21 van 23
Definitief | Resultaten van de werkgroepen POT en POC | 26 augustus 2014
Bijlage
Samenstelling van de werkgroepen
Hieronder wordt de initiële5 samenstelling van de POT- en POC-werkgroep weergegeven.
POT-werkgroep
Organisatie
Naam
Rol
eID
Vincent Jansen
Voorzitter
eID
Jolien Franken
Secretaris
eID
Michiel Dollenkamp
SAMLkoppelvlakkenexpert
eID
Eric Verheul
Encryptieëxpert
eID
Frans de Kok
Stelselarchitect
Geen
Remco Schaar
Java-ontwikkelaar
Geen
Rutger Storm
.Net-ontwikkelaar
Geen
Martin van Es
PHP-ontwikkelaar
Geen
Thijs van Dalen
Crypto-ontwikkelaar
A.E.T.
Jan Rochat
Algemeen lid
CreAim
Rogier Pafort
Algemeen lid
Digidentity
Jornt van der Wiel
Algemeen lid
Enable-U
Heiko Hudig
Algemeen lid
Entrust
Mike Dobson
Algemeen lid
Equens
Jurjen Bos
Algemeen lid
Equens
Tim Binsted
Algemeen lid
Gemalto
Michael Webster
Algemeen lid
iWelcome
Johander Jansen
Algemeen lid
KPN
René Bonte
Algemeen lid
Logius
Wim Geurts
Algemeen lid
Microsoft
Ton Koenraadt
Algemeen lid
Nouzelle
Auke Zaaiman
Algemeen lid
SURFnet
Joost van Dijk
Algemeen lid
Verizon
Chris Adriaensen
Algemeen lid
5
Enkele werkgroepleden zijn om uiteenlopende redenen slechts enkele keren aanwezig geweest. Pagina 22 van 23
POC-werkgroep Organisatie
Naam
Rol
eID
Noortje Verheij
Voorzitter
eID
Roel Niessen
Secretaris
eID
Marco Eikenaar
Stelselarchitect
eID
Frans de Kok
Stelselarchitect
eID
Vincent Jansen
Stelselarchitect
eID
Wim Kegel
Stelselarchitect
eID
Hans-Rob de Reus
Programma-architect
eID
Rosalie Schuurman
Communicatieadviseur
Geen
Cheyenne Vermeulen
Interaction designer
A.E.T.
Jan Rochat
Algemeen lid
Achmea
Peter Hoogendoorn
Algemeen lid
Aegon
Leon Jansen
Algemeen lid
Connectis
Martijn Kaag
Algemeen lid
CreAim
Mark Baas
Algemeen lid
Digidentity
Maaike Liesting
Algemeen lid
Dynalogic
Christoph Roubben
Algemeen lid
Equens
Francis de Groot
Algemeen lid
ESG
Will Kamminga
Algemeen lid
Gemalto
Pierino van de Burg
Algemeen lid
iWelcome
Maurice Luizink
Algemeen lid
KPN
Sander Steenbergen
Algemeen lid
PKIpartners
Wilbert van der Kruk
Algemeen lid
Post NL
Niels Mulder
Algemeen lid
Rijkswaterstaat
Edwin Tijdeman
Algemeen lid
Sivi
Florus van der Linden
Algemeen lid
Van Brug / Dataplaza
Robert Heinen
Algemeen lid
VGZ
Erwin Kersten
Algemeen lid
Verizon
Harm Jan Arendshorst
Algemeen lid
ZET solutions
Jacob Bosma
Algemeen lid
Pagina 23 van 23
Programma eID eID-platform Contactpersoon Nicole Damen T 06 46 87 92 55
[email protected] Datum 27 augustus 2014 Aantal pagina's 3
Stand van zaken business model
Agendapunt Onderwerp
6. Business model Stand van zaken business model
Status Voorstel
Ter informatie en ter bespreking De leden van het eID-platform worden gevraagd om: in te stemmen met de richting van het voorgestelde business model. In te stemmen met de uitwerkingsvragen en waar nodig aanvullingen te doen. In te stemmen met de verdere uitwerking van de expertgroep. Het business model wordt dan op juridisch,technisch, commercieel vlak verder uitgewerkt en getoetst op haalbaarheid.
1. Inleiding Op vrijdag 25 juli 2014 is de tussentijdse voortgang met betrekking tot het business model eID naar de eID-platformleden gestuurd. Dit voorstel is tot stand gekomen na diverse besprekingen en consultaties met publieke en private partijen. Het is gebaseerd op het model dat in de gesprekken op het meeste draagvlak lijkt te kunnen rekenen, maar is nog in een pril stadium. Aan de hand van de eerder meegestuurde notitie (thans nogmaals bijgevoegd ter informatie) wordt getoetst of de expertgroep de juiste oplossingsrichting heeft gekozen en de juiste uitwerkingsvragen heeft gedefinieerd. 2. Doelstelling van het business model Zolang gebruikers niet breed over een eID-middel beschikken, is het voor dienstaanbieders niet interessant om aan te sluiten op het eID Stelsel. Het business model biedt de mogelijkheid hier een doorbraak in de brengen, totdat de betaalbereidheid van gebruikers vergroot kan worden (of geen factor meer is). Hierdoor kan de adoptie van eID middelen en diensten versneld worden en kan er positieve groeispiraal ontstaan. Het business model moet een bijdrage leveren in de opstartfase zodat: eID-middelen snel breed beschikbaar komen er een stijging komt in het betrouwbaarheidsniveau van beschikbare middelen
Pagina 1 van 3
eID-middelen snel bij verschillende dienstaanbieders gebruikt kunnen worden
3. Voorgesteld business model De betaalbereidheid van de dienstaanbieder is hoger. Die ervaart een toegevoegde waarde van transacties via het eID Stelsel, doordat ze zelf geen voorziening hoeven te onderhouden om in te loggen, een hogere betrouwbaarheid over de identiteit krijgen of door attributen die verstrekt worden (zoals leeftijd verificatie). Voor het realiseren van de doelstelling, zal er daarom een financiële stroom vanuit de dienstaanbieder richting de authenticatieleverancier (leverancier van authenticatiemiddelen) op gang moeten komen, waardoor de authenticatieleverancier gratis of goedkoop middelen kan verstrekken aan de gebruiker. De prijs van een middel moet hierdoor gelijk of lager zijn dan de betaalbereidheid van de gebruiker. Die financieringsstroom moet de authenticatieleverancier in staat stellen de voorinvestering voor de uitgifte van middelen te realiseren en kunnen ondersteunen met een positieve business case. Daarvoor wordt in het voorgestelde model een prijs betaald door de dienstaanbieder, via de makelaar, aan de authenticatieleverancier.
Programma eID eID-platform Datum 27 augustus 2014
Het voorgestelde business model ziet er als volgt uit: dienstaanbieders sluiten een contract met een makelaar. In dat contract maken ze, naast de makelaarsdiensten, ook afspraken over het afnemen van eID-transacties (authenticaties, machtigingen, attributen, handtekeningen e.d.). ze kunnen hierin opnemen of ze per transactie betalen, een bundel afnemen, een fixed price, staffels, per klant per jaar of iets dergelijks. De mogelijkheden en prijzen worden bepaald door marktwerking. de makelaars kopen de transacties in bij onder andere de authenticatieleveranciers. De prijzen zijn ook afhankelijk van marktwerking. de makelaars zijn, inherent aan de werking van het stelsel, verplicht om met alle authenticatieleveranciers een contract te sluiten. Hierdoor wordt geborgd dat met alle eID-middelen bij alle dienstaanbieders kan worden ingelogd. Hierdoor is de onderhandelingspositie van de makelaars zwakker. Als gevolg hiervan is het voorstel om een maximumprijs vast te stellen voor transacties. Bekeken moet worden hoe die prijs bepaald moet gaan worden. Op basis van indicaties uit de Scandinavische landen, lijkt (bij grotere volumes) een bedrag van €0,05 tot €0,10 cent per transactie een redelijke indicatie. 4. Verdere uitwerking en stappen Er zijn nog zaken die uitgewerkt moeten worden,zoals: Gedurende welke periode is het noodzakelijk om verrekening binnen het stelsel te laten plaatsvinden? Dus hoe lang is die opstartfase? En op welke manier kan het worden afgebouwd?
Op welke manier moet de maximum prijs worden bepaald? Wie kan die vaststellen?
Is dit model voor zowel eindgebruikers, dienstaanbieders en deelnemers in het stelsel werkbaar?
Pagina 2 van 3
Wat zijn transacties c.q. de basis voor de verrekening? Wie betaald wat bij single sign on?
Hoe wordt de benodigde informatie voor het business model vastgesteld en wie houdt dit bij? Kan dit gecontroleerd worden?
Moet en kan er een onderscheid gemaakt worden tussen B2B, B2G, C2B, C2G?
Welke juridische aandachtspunten zijn er ten aanzien van dit voorstel?
Hoe werkt het business model bij internationale transacties (zoals onder de eIDAS verordening)?
Wat betekent het voor partijen die reeds zijn aangesloten of gebruikers die reeds een middel hebben gekocht?
Programma eID eID-platform Datum 27 augustus 2014
Uiteindelijk zal het uitgewerkte voorstel voor het business model onderdeel worden van het afsprakenstelsel eID en de daaraan verbonden besluitvormingsprocedure doorlopen. Dat betekent dat na het eID-platform (27 oktober 2014), de publieke stuurgroep eID (6 november 2014) en de ministers van BZK en EZ (december 2014) hierover een besluit moeten nemen.
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
Programma eID eID-platform Contactpersoon Nicole Damen T 06 46 87 92 55
[email protected] Datum 24 juli 2014 Aantal pagina's 5
Eerste voorstel businessmodel eID Stelsel
Onderwerp Status Voorstel
Eerste voorstel businessmodel eID Stelsel Ter informatie en ter bespreking 3 september
Kan het eID-platform zich vinden in de richting van het voorgestelde businessmodel? Op basis hiervan wordt het businessmodel verder uitgewerkt en getoetst op haalbaarheid (juridisch, technisch, commercieel, draagvlak, e.d.). Deze notitie wordt ook op de website van het eID Stelsel gepubliceerd en actief beschikbaar gesteld aan alle organisaties die hun interesse in het businessmodel kenbaar hebben gemaakt. Doel is om de totstandkoming van het businessmodel zo transparant mogelijk te laten zijn en zoveel mogelijk draagvlak ervoor te creëren.
Inleiding In de bijeenkomst van het eID-platform van 20 mei 2014 is gevraagd om vóór de zomer een voorstel voor de uitwerking van het businessmodel te ontvangen. Dit voorstel treft u hierbij aan. In deze notitie is een voorstel opgenomen voor het businessmodel voor de opstartfase van het eID Stelsel. Dit voorstel is tot stand gekomen na diverse besprekingen en consultaties met publieke en private partijen. Als bijlage is de presentatie van 9 juli 2014 over het businessmodel en het verslag daarvan toegevoegd. Het voorstel is gebaseerd op het model dat in de gesprekken op het meeste draagvlak lijkt te kunnen rekenen. Het voorstel is echter nog in een pril stadium. Aan de hand van deze notitie wordt getoetst of we de juiste oplossingsrichting kiezen en we de juiste uitwerkingsvragen hebben. Doelstelling van het businessmodel Het eID Stelsel is gebaseerd op een afsprakenstelsel. In het afsprakenstelsel worden de gezamenlijke afspraken vastgelegd tussen de partijen die deelnemen in of aan het stelsel. Een van de onderdelen van het afsprakenstelsel is het businessmodel.
Pagina 1 van 5
De waarde van (aansluiting op c.q. gebruik maken van) het eID Stelsel neemt toe met het aantal partijen dat er gebruik van maken; en daarmee de terugverdienmogelijkheid voor de investeringen die ermee gemoeid zijn. Uit de consultatie is naar voren gekomen dat de meeste partijen waarde hechten aan een snel en breed gebruik van het eID Stelsel. Als belangrijkste belemmerende factor daarbij wordt de beschikbaarheid van eID-middelen voor eindgebruikers (burgers en bedrijven) aangegeven.
Programma eID eID-platform Datum 24 juli 2014
In het onderdeel businessmodel wordt beschreven of en op welke wijze er specifieke financiële verrekeningen binnen het stelsel (c.q. tussen actoren in het stelsel) plaatsvinden. Er kan gekozen worden om geen gezamenlijke afspraken in het afsprakenstelsel hierover op te nemen (zoals bij eHerkenning het geval is voor b2b gebruik). Alles wordt in dat geval aan de markt overgelaten. In deze notitie wordt een voorstel uitgewerkt waarin er wel sprake is van verrekening binnen het stelsel. Zonder die invulling lijkt een succesvolle start van het eID Stelsel niet mogelijk, vooral in het consumentdomein waar de betaalbereidheid van consumenten laag is. De betaalbereidheid voor gebruikers is laag, doordat: Gebruikers nu meestal niet voor inlogmiddelen hoeven te betalen (perceptie van gratis) Gebruikers in de opstartfase nog maar beperkt bekend zijn met het eID Stelsel Gebruikers in de opstartfase nog maar beperkte voordelen zien van een eID-middel (aantal dienstaanbieders dat zijn diensten ermee ontsluit moet nog groeien) Dit zorgt voor het klassieke kip-ei probleem. Zolang gebruikers niet breed over een eID-middel beschikken, is het voor dienstaanbieders niet interessant om aan te sluiten op het eID Stelsel. Het businessmodel biedt de mogelijkheid hier een doorbraak in de brengen, totdat de betaalbereid van gebruikers vergroot kan worden (of geen factor meer is). Hierdoor kan de adoptie van eID middelen en diensten versneld worden en kan er positieve groeispiraal ontstaan. Het businessmodel moet een bijdrage leveren in de opstartfase zodat: eID-middelen snel breed beschikbaar komen er een stijging komt in het betrouwbaarheidsniveau van beschikbare middelen eID-middelen snel bij verschillende dienstaanbieders gebruikt kunnen worden Daarnaast zijn er een hoeveelheid diensten die nog niet ontsloten worden of kunnen worden omdat gebruikers niet over een middel van voldoende betrouwbaarheid beschikken. Deze middelen zijn duurder en er zijn minder diensten waarvoor die middelen te gebruiken zijn.
Pagina 2 van 5
Voorgesteld businessmodel De betaalbereidheid van de dienstaanbieder is hoger. Die ervaart een toegevoegde waarde van transacties via het eID Stelsel, doordat ze zelf geen voorziening hoeven te onderhouden om in te loggen, een hogere betrouwbaarheid over de identiteit krijgen of door attributen die verstrekt worden (zoals leeftijd verificatie). Voor het realiseren van de doelstelling, zal er daarom een financiële stroom vanuit de dienstaanbieder richting de authenticatieleverancier (leverancier van authenticatiemiddelen) op gang moeten komen, waardoor de authenticatieleverancier gratis of goedkoop middelen kan verstrekken aan de gebruiker. De prijs van een middel moet hierdoor gelijk of lager zijn dan de betaalbereidheid van de gebruiker.
Programma eID eID-platform Datum 24 juli 2014
Die financieringsstroom moet de authenticatieleverancier in staat stellen de voorinvestering voor de uitgifte van middelen te realiseren en kunnen ondersteunen met een positieve business case. Daarvoor wordt in het voorgestelde model een prijs betaald door de dienstaanbieder, via de makelaar, aan de authenticatieleverancier. Het voorgestelde businessmodel ziet er als volgt uit: dienstaanbieders sluiten een contract met een makelaar. In dat contract maken ze, naast de makelaarsdiensten, ook afspraken over het afnemen van eID-transacties (authenticaties, machtigingen, attributen, handtekeningen e.d.) ze kunnen hierin opnemen of ze per transactie betalen, een bundel afnemen, een fixed price, staffels, per klant per jaar of iets dergelijks. De mogelijkheden en prijzen worden bepaald door marktwerking de makelaars kopen de transacties in bij onder andere de authenticatieleveranciers. De prijzen zijn ook afhankelijk van marktwerking de makelaars zijn, inherent aan de werking van het stelsel, verplicht om met alle authenticatieleveranciers een contract te sluiten. Hierdoor wordt geborgd dat met alle eID-middelen bij alle dienstaanbieders kan worden ingelogd. Hierdoor is de onderhandelingspositie van de makelaars zwakker. Als gevolg hiervan is het voorstel om een maximumprijs vast te stellen voor transacties1 Bekeken moet worden hoe die prijs bepaald moet gaan worden. Op basis van indicaties uit de Scandinavische landen, lijkt (bij grotere volumes) een bedrag van €0,05 tot €0,10 cent per transactie een redelijke indicatie
1
Vergelijkbaar bij het voorstel van de Europese Unie voor transacties met creditcard maatschappijen. Pagina 3 van 5
Schematisch ziet dat er als volgt g uit.
Programma eID eID-platform Datum 24 juli 2014
Met dit model, wordt getracht enerzijds het gestelde doel te realiseren en tegelijkertijd zoveel mogelijk ruimte te laten aan de markt om tot een innovatief businessmodel te komen. Getoetst moet worden of dit model voldoende is, om het doel te realiseren. Cruciaal is de ‘aansluitbereidheid’ van dienstaanbieders in de komende 18-24 maanden, want alleen dan zal er voldoende vertrouwen zijn bij authenticatieleveranciers om de benodigde investeringen te doen. Alternatief kan zijn om, buiten het stelsel, met een fonds of garantstelling te werken om authenticatieleveranciers in staat stellen de voorinvesteringsrisico’s te dragen. Omdat dit complexer is en tot een ongelijke verdeling van risico leidt tussen dienstaanbieders, is dit model nu verder niet uitgewerkt. Uitwerking Er zijn nog veel zaken die uitgewerkt moeten worden. Hieronder worden er alvast een aantal aangegeven: - Gedurende welke periode is het noodzakelijk om verrekening binnen het stelsel te lasten plaats vinden? Dus hoe lang is die opstartfase? En op welke manier kan het worden afgebouwd? - Op welke manier moet de maximum prijs worden bepaald? Wie kan die vaststellen? - Is dit model voor zowel eindgebruikers, dienstaanbieders en deelnemers in het stelsel werkbaar? - Wat zijn transacties c.q. de basis voor de verrekening? Wie betaald wat bij single sign on?
Pagina 4 van 5
-
Hoe wordt de benodigde informatie voor het businessmodel vastgesteld en wie houdt dit bij? Kan dit gecontroleerd worden? Moet en kan er een onderscheid gemaakt worden tussen B2B, B2G, C2B, C2G? Welke juridische aandachtspunten zijn er ten aanzien van dit voorstel? Hoe werkt het businessmodel bij internationale transacties (zoals onder de eIDAS verordening)? Wat betekent het voor partijen die reeds zijn aangesloten of gebruikers die reeds een middel hebben gekocht?
Programma eID eID-platform Datum 24 juli 2014
Vervolgtraject Op 3 september zal dit voorstel worden besproken in het eID-platform. Parallel daaraan wordt in de periode augustus tot september het voorstel verder uitwerkt en besproken met publieke en private dienstaanbieders. Ook zullen de eerste verkennende gesprekken omtrent de juridische en technische consequenties worden gevoerd. Op basis van de bespreking in het eID-platform en de feedback die van andere partijen wordt ontvangen, zal er een uitgewerkt voorstel worden opgesteld. Dit zal in een vervolgbijeenkomst van de werkgroep businessmodel begin oktober worden besproken alvorens deze wordt voorgelegd aan het eID-platform. Uiteindelijk zal het voorstel voor het businessmodel onderdeel worden van het afsprakenstelsel eID en de daaraan verbonden besluitvormingsprocedure doorlopen. Dat betekent dat na het eID-platform (27 oktober 2014), de publieke stuurgroep eID (6 november 2014) en de ministers van BZK en EZ (december 2014) hierover een besluit moeten nemen.
Alle rechten voorbehouden © 2014 Ministerie van Binnenlandse Zaken en Koninkrijksrelaties, Den Haag. Er kunnen geen rechten worden ontleend aan deze publicatie.
Pagina 5 van 5
Programma eID eID-platform Contactpersoon Mirjam Gerritsen T 06 225 26 406
[email protected] Datum 26 augustus 2014 Aantal pagina's 3
Toezicht
Agendapunt Onderwerp
7. Toezicht Voorstel voor betrekken van belanghebbenden bij het inrichten van het toezicht op het eID Stelsel.
Status Voorstel
Ter besluitvorming 1. Instemmen met inrichten werkgroep en expertgroep 2. Minimaal drie leden aandragen voor de expertgroep; liefst zowel van de aanbiedende marktpartijen als de dienstaanbieders of gebruikers.
1. Inleiding Nu eID meer vorm begint te krijgen, komt ook het borgen van het vertrouwen in het stelsel nadrukkelijker naar voren. In de StuurgroepeID van 10 juli is een nota met richtinggevende voorstellen voor het inrichten van het toezicht besproken. De gekozen richting is:
Er komt een publieke toezichthouder op het eID Stelsel; BZK en EZ gaan samen de instelling van deze toezichthouder wettelijk vormgeven, richtend op eID, maar rekening houdend met eventuele uitbreiding naar andere onderdelen van de vitale digitale infrastructuur.
Deze contouren vormen de basis voor de verdere inrichting de komende tijd. eID integreert het bedrijvendomein met het burgerdomein en dat vraagt om een geïntegreerd toezicht op het moment dat de pilots medio 2015 van start gaan. Omdat de marktpartijen die actief zijn binnen eID met dit toezicht te maken zullen krijgen, is het noodzakelijk dat de inrichting van dat toezicht tijdens de ontwikkelfase ook met hen wordt besproken. Deze nota geeft aan op welke manier wordt voorgesteld om dat in te vullen.
2. Toelichting Toezicht op basis van bestaande toezichtarrangementen Het project “inrichting geïntegreerd toezicht” gaat voorstellen doen voor het toezicht op de korte termijn op basis van de bestaande toezichtsarrangementen voor DigiD, PKIoverheid en eHerkenning. Bij deze integratie zal ook gekeken worden naar de mogelijkheden om de lasten voor de deelnemende marktpartijen zoveel mogelijk te beperken. De inrichting voor de korte termijn zal plaatsvinden
Pagina 1 van 3
op basis van het nu bestaande toezicht op DigiD, PKI-o en eHerkenning en zal zich in eerste instantie richten op het toezicht op de deelnemende marktpartijen en het stelsel. Integratie eHerkenning is een afsprakenstelsel met rollen vergelijkbaar met die binnen het eID Stelsel. De verwachting is dat de inrichting van het toezicht op eHerkenning herbruikbare elementen bevat voor het eID Stelsel. Bij de inrichting van het toezicht op het eID Stelsel wordt daarom uitgegaan van de basis van eHerkenning, waarbij gekeken wordt naar de elementen van het toezicht op PKIoverheid en DigID die hier aan kunnen worden toegevoegd.
Programma eID eID-platform Datum 26 augustus 2014
PKIoverheid is een publiekprivate samenwerking net als eHerkenning en er is overlap in deelnemende marktpartijen. De manier waarop het toezicht op PKIoverheid nu is georganiseerd, kan mogelijk integreren met eHerkenning. Het burgerdomein (DigiD) wordt onderdeel van het stelsel en dat impliceert dat de huidige normenkaders en het Informatiebeveiligingsplan van DigiD herbruikbare elementen bevatten voor eID. eHerkenning is oorspronkelijk ontworpen voor het bedrijvendomein. Een werknemer kan met een eHerkenningsmiddel diensten afnemen bij de overheid en bedrijven namens zijn werkgever. De werkgever heeft een grote verantwoordelijkheid bij het juist registreren van zijn werknemers bij de deelnemende marktpartijen. De risicoanalyse van eHerkenning is gemaakt op deze basis. Risico’s op het gebied van privacy en fraude worden anders gewogen als ook het burgerdomein betrokken wordt. Daar waar bij bedrijven deskundig personeel wordt ingezet om zaken digitaal af te handelen, is er bij burgers een veel grotere diversiteit en mate van bekwaamheid in het omgaan met digitale wegen. Dat verhoogt bij burgers in een aantal gevallen de risico’s. Dit heeft direct consequenties voor de inrichting van het toezicht en voor de normenkaders Informatiebeveiliging en het informatiebeveiligingsplan. Een integratie waarbij naar bruikbare elementen van beide wordt gekeken is nodig om tot een voorstel voor toezicht op en een normenkader Informatiebeveiliging voor het eID Stelsel te komen.
3. Vervolgproces Het project Toezicht wil graag in de eID-platformbijeenkomst van december een adviesnota voorleggen met voorstellen: x
hoe het toezicht voor de korte termijn kan worden ingericht; Pagina 2 van 3
op basis waarvan toezicht gehouden zou moeten worden (normenkader informatiebeveiliging); en hoe de naleving vorm kan krijgen.
Programma eID eID-platform Datum 26 augustus 2014
Na bespreking in het eID-platform zal deze nota ook worden ingebracht in de Stuurgroep eID. Om te komen tot een afgewogen adviesnota in december, wil het project Toezicht graag een publiekprivate werkgroep raadplegen. Ter voorbereiding van de werkgroep zal een expertgroep bijeenkomen. Eenmaal begin oktober en eenmaal in november. Voor deelname in de expertgroep wordt gedacht aan: auditors securitymanagers of IB specialisten. Affiniteit met het onderwerp en enige kennis van eHerkenning en / of DigiD is nodig om een zinvolle bijdrage te kunnen leveren. De leden van het eID-platform worden gevraagd om deelnemers voor de werkgroep voor te dragen. Aanmelding voor de expertgroep kan via de secretaris van het eID-platform.
4.Voorstel De leden van het eID-platform worden gevraagd om: In te stemmen met het instellen van een publiekprivate werkgroep (met een open uitnodiging) voor de uitwerking van het toezicht, die onder het platform wordt gepositioneerd. In te stemmen met het op korte termijn inrichten van een expertgroep als onder 3 beschreven, met als doel mee te denken over de voorstellen en de werkgroep voor te bereiden. Minimaal drie leden voor te dragen voor de expertgroep; liefst zowel van de aanbiedende marktpartijen als van de dienstaanbieders of gebruikers.
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