Vergaderstukken eID-platform september 2014

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