Datum 1 3 JAN Betreft verzoek medewerking onderzoek gebruik autencicatiemiddelen van banken

Document 1

Ministerie van Financiën

Retouradres Postbus 20201 2500 EE Den Haag

Directoraat-Generaal Belastingdienst Korte voarbout 7 2511 CW Den Haag Postbus 20201 2500 EE Den Haag www.minfin.n1 inlichtinaen

Datum 1 3 JAN. 2012 Betreft verzoek medewerking onderzoek gebruik autencicatiemiddelen van banken

Ons kenmerk DGB/2012/208 Uw brie Bijlagen

Geachte

Voor de Belastingdienst is het verder ontwikkelen van dienstverlening via het internet een belangrijk speerpunt. Een onderdeel daarvan is de ontwikkeling van een portaal op Internet, genaamd MijnBelastingdienst.nl. Naar verwachting wordt dat portaal In 2014 op grote schaaf geintroduceerd Belastingplichtigen - in eerste instantie burgers en later ook bedrijven - kunnen dan via Internet inloggen in dit portaal, waarin zij een overzicht aantreffen van hun dossier. Aangezien dit portaal privacygevoelige gegevens ontsluit, is een hoog betrouwbare authenticatie van de gebruiker vereist. In lijn met de adviezen van de A3 Commissie' wil de Belastingdienst onderzoeken welke mogelijkheden er zijn om vanaf 2014 te beschikken over hoog betrouwbare authenticatiemiddelen voor burgers en bedrijven. En van de te onderzoeken mogelijkheden is het gebruik van de door . banken aan hun klanten verstrekte authenticatienniddelen . In dat kader zijn recent verkennende gesprekken gevoerd met vertegenwoordigers van een viertal banken2. Op basis van die gesprekken is gezamenlijk geconstateerd dat een bank als'authenticatiedienst voor een overheidsdienstaanbteder (in ieder geval de Belastingdienst) een aantrekkelijke optie lijkt. Of dit ook daadwerkelijk realiseerbaar Is, vergt nader onderzoek. Dit nader onderzoek moet zodanige informatie opleveren dat er een gefundeerde uitspraak over de haalbaarheid kan worden gedaan en daarbij een advies over de te maken keuzes. Voor het beoordelen van de haalbaarheid zal in ieder geval op de volgende onderwerpen een nader onderzoek plaatsvinden:

http://www.djksoverbe1tnlidocumentbn-ert-publkatles/rapporte0/2011/11/17/adviescommissle-authenticatieen-autorisatie-bedrilve_n.html Het betreft vertegenwoordiging van

.4

t

«sis

't1361 .ri

a. Architectuurontwerp, zoals berichtspecificatie en technische koppelvlakken b. Technische vereisten en standaarden c. Globale invulling serviceniveau-overeenkomst d. Juridische aansprakelijkheid en reputatierisico bij samenwerking .e. Beleidsmatige en juridische issues zoals gebruik van het BSN en het raadplegen van GBA-gegevens f. Tijdshorizon g. Business case en financiering h. Veiligheid, waaronder betrouwbaarheidsniveaus en bevetligingsprocessen I. Internationale inbedding j. Governance Ik wil graag voorstellen om dat nadere onderzoek in gezamenlijkheid uit te voeren, met in eerste instantie de vier genoemde banken en tevens In nauwe samenwerking met de Ministeries van B2K en EL&I. Mij is aangegeven dat dit onderzoek in een doorlooptijd van plusminus twee tot drie maanden voldoende resultaten zal opleveren. Ik verzoek u hierbij om vanaf begin februari expertise uit uw organisatie beschikbaar te stellen, zodat we inderdaad met elkaar ultimo april de haalbaarheid kunnen vaststellen.

Hoogachtend, de Directeur-generaal Belastingdienst,

P.W.A, Veld

Directoraat-Generaat Belastingdienst Ons kenmerk

DGB/2012-208

Document 2


> Retouradres Postbus 20201 2500 EE Den Haag

Directoraat-Generaal Belastingdienst Korte Voorhout 7 2511 CW Den Haag Postbus 20201 2500 EE Den Haag www.rijksoverheld.n1 Inlichtingen

Datum Betreft Onderzoek gebruik authenticatiemfddelen van banken

Ons kenmerk 068/2012/6435 Uw brief (kenmerk)

Bijlagen

Geachte Op 13 januari 2012 zond ik u en uw collega's bij een brief met het verzoek om mee te werken aan een haalbaarheidsonderzoek naar inzet van authenticatiemiddelen door klanten van uw bank voor hun communicatie met de Belastingdienst. Bij brief van 6 februari 2012 ontving ik van u een positieve reactie op dit verzoek, Augustus jongstleden Is de rapportage over dit haalbaarheidsonderzoek aan mij uitgebracht. Zoals afgesproken met de vertegenwoordigers van de banken in dit traject, geef ik deze maand mijn reactie op de bevindingen zoals beschreven in het onderzoeksrapport. Inmiddels heb ik begrepen dat het in deze fase het voor nlnder zinvol is om gebruik van haar authenticatiedlenst voor verkeer met de Belastingdienst mogelijk te maken. Dit omdat de populatie aan particuliere klanten van - de beoogde doelgroep van de Belastingdienst - nog niet voldoende omvang heeft. Mocht in de toekomst alsnog willen aanhaken in dit traject, dan is zij daartoe uiteraard van harte uitgenodigd. Voor nu wil ik u hartelijk danken voor de deskundige inbreng van de heer in de werkgroep die het haalbaarheidsonderzoek heeft uitgevoerd. Met vriendelijke groet, De Directeur-generaal Belastingdienst,

P.W.A. Veld

Ministerie van Financiën Document 3

> Retouradres Postbus 20201 2500 EE Den Haag

Directoraat-Generaal Belastingdienst Korte Voorkant 7 2511 ON Den Haag Postbus 20201 2500 EE Den Haag www.rijksoverheld.nf Inlichtingen

Datum Betreft Onderzoek gebruik authenticatiemiddelen van banken

•

Ons kenmerk DGB/2012/6435 Uw brief (kenmerk)

Bijlagen

Geachte Op 13 januari 2012 zond Ik u en uw collega's bij een brief met het verzoek om mee te werken aan een haalbaarheidsonderzoek naar inzet van authenticatiemiddelen door klanten van uw bank voor hun communicatie met de Belastingdienst. Bij brief van 20 januari 2012 ontving ik een positieve reactie op dit verzoek.' Augustus jongstleden is de rapportage over dit haalbaarheidsonderzoek aan mij uitgebracht. Zoals afgesproken met de vertegenwoordigers van de banken in dit traject, geef Ik u hierbij mijn reactie op de bevindingen zoals beschreven in het onderzoeksrapport. Ik ben verheugd dat we gezamenlijk hebben kunnen vaststellen dat het haalbaar is om klanten van genoemde banken in staat te steilen hun authenticatiemiddelen voor internetbankieren te gebruiken voor verkeer met de Belastingdienst. Inmiddels heb ik begrepen dat de voorkeur van de banken uitgaat naar een driejarige samenwerkingsovereenkomst met de Belastingdienst afs basis voor dit gebruik, met een wederzijdse intentie tot voorzetting van de samenwerking na die periode. Een driejarige samenwerkingsovereenkomst is voor de Belastingdienst goed werkbaar. Een beslissing omtrent voortzetting zal moeten worden genomen op basis van een evaluatie, waarbij naast de ervaringen met de samenwerking ook de verdere ontwikkelingen rond beschikbaarheid van betrouwbare authenticatiediensten voor overheidsdienstverlening worden meegenomen. Zoals het onderzoeksrapport aangeeft, Is de wijze van financieren nog een openstaand punt. Inmiddels zijn door de banken eerste ruwe inschattingen gemaakt van de kosten van het gebruik van authenticatiemiddelen voor verkeer met de Belastingdienst. De Belastingdienst is bereid onder gezamenlijk vast te stellen voorwaarden een zekere compensatie te geven voor de kosten van het gebruik van bankmiddelen. Een dergelijke kostencompensatie moet zakelijk onderbouwd en politiek verantwoord kunnen worden. De. nu beschikbare inschattingen zijn daarvoor in mijn optiek nog niet voldoende robuust..

Ik nodig de banken dan ook graag uit om op korte termijn de kostencomponent verder te objectiveren en in gezamenlijk overleg tot Invulling van voorwaarden voor monitoring daarvan te komen. In de oplossing voor gebruik van bankmiddelen zoals die in het onderzoeksrapport wordt beschreven, wordt aangehaakt bij de bestaande DigiD-voorziening. Dat betekent dat Loglus als beheerder van DiglD - feitelijk het voortouw zal hebben bij het samen met de banken realiseren van deze oplossing. De Belastingdienst zal in de operationele samenwerking tussen Loglus en banken een regierol vervullen. Het is van belang de rollen van Loglus als 'uitvoerder' en van de Belastingdienst als 'regisseur' goed uit te werken In de samenwerkingsovereenkomst. Om de samenwerking per 2014 te kunnen realiseren, Is het van belang om dé genoemde aspecten op korte termijn te concretiseren. Graag nodig ik u uit om op korte termijn in overleg te treden over de wijze waarop we onze samenwerking de komende periode verder vorm geven. Met vriendelijke groet, De Directeur-generaal Belastingdienst,

P.W.A. Veld

Directoraat-Generaal Detastingclienst Ons kenmerk DGEV2012/5435

Document 4


Agenda Overleg HAB Datum: Tijdstip: Plaats: •

8 februari 2012 10.00 - 12.00 Belastingdienst Vergadercentrum De Wereld, zaal Colombia 20 etage Herman Gorterstraat 55 Utrecht

Directoraat-Generaat Belastingdienst Inlichtinuen

Datum 6 februari 2012 Notitienummer DGEW1.0 Rubriek E-overheld

Project: Haalbaarheidsonderzoek HAB (Hergebruik Authenticatiemiddelen Banken)

Agenda I. Opening en vaststellen agenda 2. Brief Peter Veld en reacties van de aangeschreven banken 3. Proces in vogelvlucht en betrokkenheid bestuurders 4. Inhoudelijke verkenning: `flow van kosten' en aansprakelijkheid Bijlage: SNO van DigiD 5. Inventarisatie en prioritering onderzoeksvragen

6. Werkvorm en organisatie van onderzoek

7. Rondvraag en sluiting

Document 5

Ministerie van Financiën tWs'S'

Verslag Overleg HAB Datum: Tijdstip: Plaats:

Directoraat-Generaal Belastingdienst

8 februari 2012 10.00 — 12.00 Belastingdienst Vergadercentrum De Wereld, zaal Colombia 2e etage Herman Gorterstraat 55 Utrecht

Inlichtingen

Datum 10 februari 2012 Notitienummer

Overleg: Haalbaarheidsonderzoek authenticatiemiddelen banken (HAB)

Rubriek E-overheid

Aanwezig:

Volgend overleg: Dinsdag 21 februari 2012 15.00 — 17.00 uur, te Utrecht (uitnodiging volgt)

Acties en afspraken: Afspraak 1. Bijeenkomst met bestuurders

Actie datum vastleggen half april

1 Wie

Wanneer Week 7

namen genodigden doorgeven en email adres van secretariaat 2. Mededingingsrechtelijke aspecten

in kaart brengen

Week 8

afstemmen met EL&I/Nma 3. Communicatie 4. Eerste prioriteit heeft onderzoek naar specificatie vraagkant BD en invulling aansprakelijkheid S. Eisen vraagkant BD cq. kostenvaria beien

terughoudende opstelling lopende het onderzoek, aanspreekpunt is MinFin Zolang er geen voldoende voortgang is op deze twee onderwerpen, worden er geen andere onderwerpen onderzocht, Beoordelen voortgang in volgend overleg uitwerken

nvt Week 8

Week 8

banken: B5N meeleveren, Stork 3-4, SNO, volume/samenstelling (incl. aansluitpunten) 6. Aansprakelijkheid 7. Inrichting juridische werkgroep 8. Mogelijkheid gebruik B5N door banken als authenticatiedienst voor een overheidsdienstaanbieder . 9. Invulling bankmiddelen en overheid in andere landen

aspecten, vragen in kaart brengen en uitwerken uitwerken opzet en samenstelling

juridische werkgroep

Nog bepalen Week 7

eerste inventarisatie belemmeringen en mogelijkheden

Week 8

Week 8

•

korte beschrijving per land van het gebruiksmodel en de financiering van het gebruik van bankmfddelen voor overheidsdiensten. In ieder geval de volgende landen meenemen: - Noorwegen • Denemarken • Zweden • Finland • Estonia • Oostenrijk

10.0rganisatiestructuur

beschrijven

Week 7

11.Volgen de bijeenkomst

allen ' -

21 februari 2012, 15.00 — 17.00 uur, Utrecht

Document 6

Functionele uitwerking authenticatie ten behoeve van Haalbaarheidsonderzoek gebruik authenticatiemiddelen banken (HAB) (versie 0.9, 24 februari 2012) I. Inleiding De DC Belastingdienst heeft in februari 2012 vier banken, te weten uitgenodigd voor een haalbaarheidsonderzoek naar het gebruik van hun authenticatiemiddelen - via opneming in het stelsel eHerkenning - voor elektronisch verkeer tussen burgers en bedrijven en portalen van de Belastingdienst. De Ministeries van BZK en EL&I nemen deel aan dit onderzoek vanuit hun beleidsverantwoordelijkheid voor elektronische dienstverlening aan burgers en bedrijven en met het oog op het breder inzetten van bankmiddelen voor verkeer tussen burgers, bedrijven en overheid. Het onderzoek wordt uitgevoerd door een coördinatiegroep bestaande uit vertegenwoordigers van de vier banken, DC Belastingdienst en de Ministeries van BZK en EL&I. Het onderzoek moet zodanige informatie opleveren dat een gefundeerde uitspraak over de haalbaarheid van dit gebruik kan worden gedaan en dat een advies kan worden gegeven over de te maken keuzes. Het onderzoek zal een aantal onderwerpen omvatten, waaronder architectuur, technische standaarden, beleidsmatige en juridische Issues en governance. Van de zijde van de banken is aangegeven dat over twee onderwerpen in elk geval duidelijkheid verkregen moet worden voor aan de andere te onderzoeken aspecten toegekomen kan worden. Deze betreffen het kostenmodel en de (beperking van) aansprakelijkheid bij inzet van authenticatiemiddelen bij browsercommunicatie met de Belastingdienst. In deze notitie wordt beschreven vanuit welke context het haalbaarheidsonderzoek wordt uitgevoerd en welke invulling van authenticatie wordt gevraagd, zodat meer zicht op de kostenstructuur wordt verkregen. Het vraagstuk met betrekking tot de aansprakelijkheid wordt door een juridische werkgroep aangepakt.

2. Context van het onderzoek DE Belastingdienst heeft opdracht gegeven om een visie en migratiestrategie te ontwikkelen voor het thema authenticatie en autorisatie voor digitale dienstverlening via internet. Onderdeel van deze visie is de ontwikkeling van een uniform stelsel van authenticatieen autorisatievoorzieningen voor burgers en bedrijven. Deze ontwikkeling wordt in nauwe samenwerking met Ministeries van BZK en EL&I uitgevoerd. De resultaten van het haalbaarheidsonderzoek moeten passen in deze ontwikkeling. n onderstaande figuur Is het basisschema voor authenticatie en autorisatie weergegeven. In de beschrijving wordt de Belastingdienst als voorbeeld gehanteerd, maar het schema is van toepassing op elke overherdsdienstaanbieder. Contexteagram Dienstafnemer Zelfaangever », Gemachtigde 0 Famille, kennis o Maatschap. Interm. o riscateDienstverl. 0 Douane Dienstverl

radilterentrePaytti (front end)

Publieke Portaal

7-4WilWil

BilastIngdienst . Portaal •• MginliD,MljniSi. 0P D.Ondernerner

Dlenstaanbleder (back end) gelasfinedienst

4

Transactliservices 1

I

Zelfaangever > Gemachtigde El Fiscale Olenstvert Cl Douane Dlenstverr

Private Parfa Software Pakkethortaal

le

Mentteitsvedlon-ng 'igje bent

Authentkatie dienst

ir Bevoegdh vedajing 3wtje mor

In de figuur is weergegeven dat een dienstafnemer (de gebruiker) via drie kanalen een digitale dienst bij de Belastingdienst kan afnemen: a. Via het internetportaal van de Belastingdienst. b. Bij een balie op een kantoor van de Belastingdienst. De medewerker van de Belastingdienst maakt daarbij gebruik van hetzelfde internetportaal als bij a. c. Het derde kanaal betreft het gebruik van private partijen die intermediaire voorzieningen aanbieden aan de dlenstafnemer. Dit kunnen softwarepakketten zijn, maar ook portaal voorzieningen op Internet. In de architectuur maakt de Belastingdienst een onderscheid in ICT-voorzieningen die rechtstreeks In contact staan met de dienstafnemer (front end) en de transactieservices die vanuit de back end van de Belastingdienst worden aangeboden. Kenmerkend voor deze architectuur is dat de transactieservices van de back end onafhankelijk zijn van de front end voorziening. Op deze wijze kunnen de front end voorzieningen van de Belastingdienst en die van de private partijen op een zelfde manier gebruik maken van de transactieservices van de back end. En daarmee wordt voor de transactieservices In de back end ook de invulling van authenticatie en autorisatie gestandaardiseerd. Dm gebruik te kunnen maken van persoonsgebonden transactieservIces moet worden vastgesteld of de dienstafnemer dit mag. Het antwoord op deze vraag wordt geleverd door middel van twee gestandaardiseerde verklaringen: - Een identiteitsverklaring: deze verklaring wordt opgemaakt door een vertrouwde authenticatiedienst. De authenticatiedienst verklaart welke identiteit van de dienstafnemer is vastgesteld en met welke betrouwbaarheid. - Indien de dienstafnemer namens een andere persoon een transactie wil afnemen, moet beoordeeld worden of die dlenstafnemer dat mag. Hiervoor wordt door een machtigingsregister een verklaring verstrekt Waarin een uitspraak over de bevoegdheid is opgenomen. Voor de uitvoering van het haalbaarheidsonderzoek kan de context vooralsnog worden vereenvoudigd: - In deze fase van het onderzoek wordt uitgegaan van het gebruik van de portaal voorzieningen van de Belastingdienst zelf. Later zal de uitbreiding naar gebruik door private partijen worden onderzocht. Daarmee is het architectuur onderscheid in front en back end voorzieningen voor een authenticatiedienst niet relevant. - In het verkeer tussen belastingplichtige en Belastingdienst kunnen ook machtigingsrelaties aan de orde zijn. Dit aspect wordt vooralsnog buiten de scope van het onderzoek gehouden. In een latere fase van het haalbaarheidsonderzoek zal dit aan de orde (moeten) komen. Op basis van die vereenvoudiging is in onderstaande figuur de context van een authenticatiedienst weergegeven. Context van een authenticatiedienst bestuursrechtelijke relatie

I

Publieke Portaal

çt

Dienstafnemer Zelfaangever

ene

- - ▪ -• - - - - - - - - Dienstaanbieder Belastingdienst

1:IMijnBD, MijnTSL Cl PO Ondernemers

pi

Identlteitsverklaring 'Wiep bene'

r Aiith.entirátié‘ e dienst -7

Uitgangspunt voor het onderzoek zijn de relaties die ontstaan tussen een dienstaanbieder (Belastingdienst), authenticatiedienst (Bank) en dienstafnemer (gebruiker). Op basis van een bestuursrechtelijke relatie (aanvragen beschikking, doen van aangifte etc.) vindt digitaal berichtenverkeer plaats tussen dienstafnemer eh dienstaanbieder. 3. Gevraagde invulling van authenticatle Als eerste wordt een beschrijving gegeven van de casus dat een dienstafnemer wil inloggen bij het portaal van de dienstaanbieder Belastingdienst. Dit wordt aangeduid als het interactiepatroon "inloggen".

Interaelleparroon winloggenn

Dienstaanhiede Belastingdienst

Cl MIJ riBD, MijnT5t. oPD Ondernemers

0 É:renten,verklaring Kr op en= Authentleatledienst

Bij het inloggen worden de volgende stappen gezet. 1. Contact maken met dienstaanbieder De dienstafnemer (gebruiker) neemt het initiatief om een dienst bij een dienstaanbieder af te nemen en navigeert naar de website van die dienstaanbieder. Op de website geeft de gebruiker aan dat deze naar de persoonlijke omgeving wil (drukt op de button `inloggen'). 2. Inloggen 2a. De website routeert vervolgens de gebruiker naar de herkenningsmakelaar. De herkenningsmakelaar toont een scherm met mogelijke authenticatlediensten, waarop de gebruiker vervolgens de authenticatiedienst van zijn keuze selecteert. 2b. De herkenningsmakelaar routeert de gebruiker naar de desbetreffende authenticatiedienst. 2c. De authenticatiedienst voert, met behulp van het bijbehorende authenticatlemiddel, het authenticatieproces met de gebruiker uit. Op basis van eerder geregistreerde gegevens wordt de identiteit (identificerend kenmerk) door de authenticattedienst vastgesteld. 2d. De authenticatiedienst registreert de vastgestelde identiteit In een identiteitsverklaring en verstuurt deze naar de herkennIngsmakeiaar; de gebruiker wordt weer terug gerouteerd naar de herkenningsmakelaar van de dienstaanbieder. 2e. De herkenningsmakelaar constateert dat de authenticatie succesvol is verlopen en stuurt de ontvangen Identiteitsverkiaring naar de website. Op basis van de ontvangen identiteitsverklaring besluit de website om de gebruiker al dan niet toegang te verlenen tot de persoonlijke omgeving.

3. Gebruikersondersteuning Indien de gebruiker problemen ondervindt tijdens het inloggen, kan de gebruiker contact opnemen met de helpdesk van de desbetreffende authenticatiedienst.

Voor het uitvoeren van het haalbaarheidsonderzoek met betrekking tot de gewenste invulling, worden afzonderlijke onderwerpen benoemd. Elk onderwerp wordt In de vervolgstappen nader uitgewerkt.

Onderwerp 1: Gevraagd betrouwbaarheidsniveau van authenticatie In dit onderzoek wordt ervan uitgegaan dat de Belastingdienst voor alle diensten minimaal STORK-3 vraagt. Door de Belastingdienst wordt rekening gehouden dat op de middellange termijn (<5 jaar) het minimale niveau naar STORK-4 zal gaan. Onderwerp 2: Kostenvergoeding uitgevoerde authenticatie Voor elke uitgevoerde authenticatie (in dé vorm van een geleverde identiteitsverklaring aan de herkennIngsmakelaar), zal de Belastingdienst een vergoeding verstrekken aan de authenticatiedienst Daarbij hebben de volgende variabelen een invloed op de omvang van de vergoeding: • Een authenticatie uitgevoerd op STORK-4 is van meer waarde dan STORK-3. • Gerealiseerde jaarvolumes. De herkenningsmakelaar registreert welke identiteitsverklaringen van welke authenticatiedienst zijn ontvangen.

Onderwerp 3: Servicentveau overeenkomst (SNO), De eerste invulling van het SNO is gebaseerd op de huidige invulling van DigiD. De aanname is dat deze invulling van toepassing is op elke authenticatiedienst. Beschikbaarheid Authenticatiedienst: • Norm: de productieomgeving is 7*24 uur beschikbaar, alle dagen van het jaar • Minimaal: 99,5% beschikbaar • Servicewindow ondersteuning: • l e lijn voor Dienstafnemer: werkdagen van 8.00 uur tot 22.00 uur • le lijn voor Dienstaanbieder: 24 uur per dag Prestatie-eisen: Performance indicator voor capaciteit en performance Authenticatiedienst

Soort afspraak

Norm

Verwerkingstijd bij authenticatie

Verwerking authenticatie gemiddeld afgehandeld binnen 0,15 sec.

Verwerkingstijd bij maximale concurrent sessies

Daar waar 900 concurrent sessies worden gestart, is de verwerkingstijd van minimaal 95% van deze 900 sessies korter dan3Oseconden.

Minimaal te realiseren

100 %.

Kentallen met betrekking tot capaciteit en performance Authenticatiedienst Soort afspraak

Norm

Minimaal te realiseren

Capaciteit authenticaties

Het aantal authenticatles wordt gegarandeerd voor 300.000 authenticatles per uur (gedurende 24 uur per dag).

Geen.

' Onderwerp 4: Koppeling met en leverino van BSN door authenticatledienst

Een groot deel van de populatie dienstafnemers bij de Belastingdienst zijn burgers. De administratie van de Belastingdienst is ingericht op het BSN als identificerend kenmerk van een burger. Dat betekent dat voor de Belasting dienst in een identiteitsverklaring aangaande een burger het BSN moet zijn opgenomen. Of en via welke verschillende scenario's dit realiseerbaar is, Is een onderzoek op zich. Dit onderwerp wordt in hoofdstuk 4 apart uitgewerkt.

4. BSN problematiek Conform de vigerende BSN-weteving mag een private partij als authenticatiedienst niet het 85N verwerken en dus ook niet verstrekken in de identiteitsverklaring. Of dit ook van tóepassing Is voor een bank als authenticatiedienst is nog onzeker. Vanuit andere wetgeving heeft een bank namelijk een wettelijke verplichting om het BSN op te nemen In de administratie van de bank. Om dit onderwerp nader te onderzoeken worden verschillende scenario's uitgewerkt. Scenario 1: Bank maa BSN verwerken als authenticatiedienst In dit scenario wordt er van uitgegaan dat een bank het BSN mag koppelen aan de rekeninghouder ten behoeven van authenticatie aan een overheidsdlenstaanbieder. Uitgezocht moet worden onder welke voorwaarden dit mag en welke eventuele aanpassingen aan wet- of regelgeving•noodzakelijk zijn.

De volgende scenario's gaan ervan uit dat een bank geen BSN mag leveren als authenticatiedienst. Dat betekent dat er dan binnen de overheid een zogenaamde omnummervoorziening nodig is. Deze voorziening registreert de koppeling van het identificerende kenmerk van een rekeninghouder van een bank met het BSN van die rekeninghouder. Het interactiepatroon Inloggen wijzigt daardoor. interactiepatroon inloggen en koppeling met 135N"

Olenstaanbleder Belastingdienst Catvliin8D, MkinTSL 1 PO Ondernemers

• g

autbédtkatre PtpQe.s,. CD kle entiteitsverklaring

•

Omnummervoorziening• Overheid

I

4—

AuthentIcatledienst

De wijzigingen zijn: 2. Inloggen 2a. tot en met 2c. zijn ongewijzigd. 2d. De authenticatiedienst registreert de vastgestelde Identiteit met het identificerende kenmerk van de bank in een identiteitsverklaring en verstuurt deze naar de herkenningsmakelaar; de gebruiker wordt weer terug gerouteerd naar de herkenningsmakelaar van de dienstaanbieder. 2e. De herkenningsmakelaar constateert dat de authenticatie succesvol Is verlopen en dat het BSN voor de dienstaanbleder nodig is. De herkenningsmakelaar roept de omnummervoorziening aan en verstrekt het identificerende kenmerk volgens de bank. 2f. De omnummervoorziening zoekt het bijbehorende BSN op en geeft deze retour aan de herkenningsmakelaar. 2g. De herkenningsmakelaar voegt het BSN toe aan de Identiteitsveridaring (er ontstaat dan een nieuwe identiteitsverklaring) en stuurt deze identiteitsverklaring naar de webSite. Op basis van de ontvangen identiteitsverklaring besluit de website Om de gebruiker al dan niet toegang te verlenen tot de persoonlijke omgeving.

Om de werking van de.omnummervoorziening mogelijk te maken zal eenmalig de koppeling geregistreerd moeten van elke rekeninghouder die de bank als authenticatiedienst wil gebruiken. Voor de wijze waarop deze koppeling registratie wordt uitgevoerd zijn meerdere scenario's denkbaar. Elk scenario wordt op haalbaarheid nader onderzocht Scenario-2: Via de bank wordt de koppeling aangemeld De bank registreert in de eigen administratie het BSN van elke rekeninghouder (natuurlijke Personen). Tijdens die registratie is een 'face-to-face' controle aan de hand van een geldig identiteltsdocument uitgevoerd. In dit scenario moet worden onderzocht welke wettelijke belemmeringen er zijn om eenmalig per rekeninghouder de koppeling aan de omnummer voorziening te melden. De aanname is dat dit scenario minder BSN-wetgeving belemmering heeft dan scenario-1.

Scenario-3: Via een "overheidsbalie" wordt de koppeling aangemeld Een rekeninghouder van een bank die ervoor kiest om zijn bank-authenticatiemiddelen ook te gebruiken voor overheidsdiensten, zal dan zelf fysiek naar een overheidsbalie moeten. Bij die balie wordt dan een `face-to-face' controle aan de hand van een geldig identiteitsdocument uitgevoerd. Vervolgens wordt aan de balie een bank-authenticatie uitgevoerd, zodat het identificerende kenmerk van de bank wordt gekoppeld aan het BSN. Dit wordt doorgegeven aan de omnummer voorziening. Dit is een behoorlijk ingrijpend scenario, vooral het inrichten van nieuwe werkzaamheden bij gen overheidsbalie en de daarvoor benodigde ICT-voorziening.

Scenario-4: De Belastingdienst meldt koppeling aan de hand van de bestaande bank renseignering ' Conform huidige wetgeving Is een bank jaarlijks verplicht om financiële gegevens te renseigneren aan de Belastingdienst. In die renseignering is voor natuurlijke personen het I3SN opgenomen. In dit scenario wordt deze informatiestroom gebruikt om de koppeling tussen rekeninghouder en BSN aan te melden bij de omnummervoorzlening. Ook hier zal beoordeeld moeten worden of dit past binnen vigerende wet-en regelgeving. Tevens moet dan worden ingericht op welke wijze een rekeninghouder hiervoor toestemming verleent en moet ook het identificerende kenmerk volgens de bank in de informatiestroom beschikbaar zijn.

Document 7 USECASE I: Een consument gebruikt zijn banktoken voor identificatie bij de Belastingdienst

Consument

Belastingdienst

Herkenningsmakelaar

Bank

Een consument bezoekt de site van de Betastingdienst Selectie van een onderwerp waarbij identificatie nodig is

De BD toont het keuzerepertoire

De ED stuurt het ID verzoek door naar de makelaar De makelaar toont de beschikbare middelen

De consument selecteert bank"

Vastlegging tbv afrekening en doorsturen naar bank

De consument gebruikt het bank token

DoorgeleidIng van JA naar de BD Op basis van JA levert de BD de gevraagde dienst De consument ontvangt de gevraagde dienst

De Belastingdienst weet Met met welke middel de consument ziel Identificeert

De bank presenteert het identificatie menu

bank venverkt de aanvraag en zegt JA of NEE

Ingeval van NEE actie tbd

De makelaar weet niet voor welke dienst identificatie wordt gevraagd

De makelaar geeft zijn antwoord in het gewenste massage formaat

De bank weet niet voor welke dienst Identificatie wordt gevraagd

Document 8 USECASE 3: Een consument wit zijn bankmiddel activeren bij DigiD

Consument

DigiD

1-lerkenningsmakelaar •

Bank

Consument wil bankmiddel activeren en gaat naar DigiD DigiD toont keuzemogelijkheden Consument selecteert . activeren bankmiddel DigiD presenteert inlogscherm Consument logt in met DigiD Midden DigiD toont keuze mogelijkheid aangesloten banken Consument selecteert bank DigiD stuurt door naa r gekozen bank De bank presenteert activeringspagina Consument gebruikt bankmktdel

Consument ontvangt melding activering geslaagd

Op basis van JA wordt SIN gekoppeld aan BSN

De bank verwerkt de activering en zegt JA of NEE

Logius t1M"."11 Ministerie van Binnenlandse Zaken en

Document 9

Koninlaijksrela des

Logies Tactisch Beheer • Bezoekadres: Wilhelmina v Pruisenweg 52 2595 AN Den Haag 96810 25093E Den Haag wwvitiogius.ni Inlichtingen bij

notitie

Vergelijken BSN zonder uitwisselen Datum 6 junl 2012

Inleiding In het kade ván de verkenning van de inzet van bankmiddelen voor authenticatie binnen de e-Overheid wordt onderzocht in hoeverre daarvoor gebruik gemaakt kan worden van het bij BSN wat bij de banken al bekend is. Het knelpunt in juridisch opzicht is dat de wetgeving op grond waarvan de banken over het BSN beschikken een andere Is dan het authenticeren van een burger in een willekeurige transactie met de e-Overheid. Gebruik van het BSN in de eigenlijken authenticatie kan vermeden worden door gebruik te maken van een pseudoniem. Dit pseudoniem (in eerdere notities aangeduid als UP, Uniek Persoonsnummer) is bekend bij de bank en bij DígiD1en bij de bank. DigiD omvat in deze onzet een omnummervoorziening, die het BSN behorend bij het UP opzoekt. Dit BSN wordt vervolgens doorgegeven als resultaat van de authenticatie aan de dienst die de authenticatie heeft geïnitieerd. Dit roept wel de vraag op hoe de omnummertabei wordt gevuld. Het is onvermijdelijk om daarvoor gebruik te maken van het BSN waar de banken al over beschikken. Immers, alleen op die manier kan een verband tussen gelegd tussen de identiteitscontrole die de bank aan de balie heeft uitgevoerd en de identiteit van de burger binnen de e-Overheid, die is opgehangen aan het BSN. Dit is noodzakelijk om een authenticatie uit te voeren op STORK niveau 3 of 4. Tegelijkertijd is het wenselijk om het gebruik van het BSN tot het absolute minimum.te beperken. Dit memo beschrijft een methode om de koppeling tot stand te brengen zonder het BSN feitelijk uit te wisselen.

Vergelijken zonder uitwisselen Kern van de oplossing is de constatering dat aan het begin van de transactie beide partijen de beschikking hebben over het BSN van de burger. De bank heeft het op grond van de Wwft (Wet ter voorkoming van witwassen en financiering van 1In deze notitie wordt OigiD gebruikt als aanduiding voor de centrale authenticabe-

voorziening voor burgers voor de e-Overheid. Het huidige DIgID bevat in aanleg een groot deel van de componenten die nodig zijn voor de rol die hier wordt geschetst. Aanpassingen en uitbreidingen zullen evenwel noodzakelijk zijn voor een volledige Implementatie.

terrorisme) en zijn voorganger de WID (Wet identificatie bij dienstverlening). DigiD beschikt over het BSN doordat de burger op de bestaande wijze een DigiD op betrouwbaarheidsniveau Basis of Midden heeft verkregen. Wat dus nodig is, is een manier om vast te stellen dat beide beschikken over hetzelfde BSN. Dit kan als volgt worden gerealiseerd:

Dat bij deze transactie geen kennis wordt uitgewisseld blijkt door te analyseren wat er gebeurt als In stap 7 blijkt dat belde BSN's niet gelijk zijn. De bank weet dan niets meer dan voor de transactie: niet wat het BSN is dat bij DigiD bekend is en niet wat het resultaat van de vergelijking is. DigiD weet dat de BSN's verschillen maar niet wat het BSN is wat bij de bank bekend is (al zou DigiD daar door een brute-force aanval wel weer achter kunnen komen). Het ongelijk zijn van de BSN's kan binnen de beheerorganisatie gebruikt worden om in samenwerking met de bank een onderzoek te starten. Immers, het lijkt waarschijnlijk dat of bij de bank, of bij DigiD, een poging wordt gedaan tot identiteitsfraude.

Conclusies 1. De beschreven transactie voldoet aan het principe dat er geen BSN's worden uitgewisseld, en ook overigens alleen de minimaal noodzakelijke 2 Bij symmetrische encryptie wordt dezelfde sleutel gebruikt voor versleutelen en ontsieutelen. 3 Er zijn variaties op het beschreven scenario mogelijk, die ook een brute-force aanval onmogelijk maken - ten koste van wat extra rekencapaciteit.

Logius Tactisch Beheer Datum 6 junl 2012

kennis. 2. Fris wel sprake van bewerken van het BSN omdat het BSN gebruikt wordt in de sleutelberekeningen een beide zijden. 3. De transactie gebeurt eenmalig, en op uitdrukkelijk verzoek van de burger zelf. 4. Na voltooien van de transactie voldoet het uitgifte proces voor het DigiD account aan de eisen voor Stork zekerheidsniveau 3 en 4. De sterkte van de authenticaties met dit account hangt dan alleen nog af van de sterkte van het gebruikte authenticatiemiddel. Er dient nog worden vastgesteld of de beschreven transactie valt binnen de marges van de wet op het BSN. Naar mijn mening is wellicht niet voldaan aan de letter van de wet, maar zeker wel aan de doelstelling van de wetgever:

Loglus Tactisch Beheer Datum 6 juni 2012

Document 10

Opdracht Juridische werkgroep Haalbaarheidsonderzoek gebruik authentIcatlemIddefen banken (HAB) (versie 0.9, 17 februari 2012) 1. Inleiding De DC Belástingdienst heeft En februari 2012 vier banken, te weten uitgenodigd voor een haalbaarheidsonderzoek naar het gebruik van hun authenticatlemIddelen - via opneming In het stelsel eHerkenning - voor elektronisch verkeer tussen burgers en bedrijven en portalen van de Belastingdienst. De Ministeries van BZK en EL&I nemen deel aan dit onderzoek vanuit hun beleidsverantwoordelijkheid voor elektronische dienstverlening aan burgers en bedrijven en met het oog op het breder Inzetten van bankmiddelen voor verkeer tussen burgers, bedrijven en overheid. Het onderzoek wordt uitgevoerd door een coiirclinatiegroep bestaande uit vertegenwoordigers van de vier banken, DC Belastingdienst en de Ministeries van BZK en EL&I. Het onderzoek moet zodanige informatie opleveren dat een gefundeerde uitspraak over de haalbaarheid van dit gebruik kan worden gedaan en dat een advies kan worden gegeven over de te maken keuzes. Het onderzoek zal een aantal onderwerpen omvatten, waaronder architectuur, technische standaarden, beleidsmatige en juridische issues en govemance. Van de zijde van de banken is aangegeven dat over twee onderwerpen in eik geval duidelijkheid verkregen moet warden voor aan de andere te onderzoeken aspecten toegekomen kan worden. Deze betreffen het kostenmodel en de (beperking van) aansprakelijkheid bij Inzet van authenticatiemIddelen bij browsercommunicatie met de Belastingdienst. Deze notitie behelst het tweede onderwerp, de (beperking van de) aansprakelijkheid. Dit onderwerp zal bij voorrang door een juridische werkgroep warden aangepakt. Onderstaand worden de relevante vragen en de werkwijze van de werkgroep uitgewerkt. Uitgangspunt voor de werkgroep is de hieronder geschetste weergave van de relaties tussen overheldsdlenstverlener (dienstaanbieder), authenticatledienst (bank) en gebruiker (dienstafnemer). In het verkeer tussen belastingplichtige en Belastingdienst kunnen ook rnachtigingsrelaties aan de orde zijn. Dit aspect is vooralsnog echter buiten scope van de opdraait van de juridische werkgroep gelaten. In een latere fase van het haalbaarheidsonderzoek zal dit aan de orde (moeten) komen. interactiepatroon Authenticatieprooes Bestuursrechtelijke relatie

Op basis van een bestuursrechtelijke relatie (aanvragen beschikking, doen van aangifte etc.) vindt elektronisch berichtenverkeer plaats tussen clienstafnemer en dienstaanbieder. Hierbij worden de volgende stappen gezet. 1. Contact maken met dienstaanbieder De dienstafnemer neemt het Initiatief om een dienst bij een dienstaanbieder af te nemen en navigeert naar de website van die dienstaanbieder. Op de website geeft de gebruiker aan dat deze naar de persoonlijke omgeving wil (drukt op de button 'Inloggen'). 2. Inloggen 2a. De website routeert vervolgens de gebruiker naar de herkenningsmakelaar. De herkenningsmakelaar toont een scherm met mogelijke authenticatiediensten, waarop de gebruiker vervolgens de authenticatiedienst van zijn keuze selecteert. 2b. De herkenningsmakelaar routeert de gebruiker naar de desbetreffende authenticatiedienst. 2c. De authenticatiedienst voert het authenticatieproces met de gebruiker uit, met behulp van het bijbehorende authenticatiemiddel. Op basis van eerder geregistreerde gegevens wordt de identiteit (identificerend kenmerk) door de authenticatiedienst vastgesteld. 2d. De authenticatiedienst registreert de vastgestelde identiteit Ineen identiteitsverklaring en verstuurt deze naar de herkenningsmakelaar; de gebruiker wordt weer terug gerouteerd naar de website van de dienstaanbieder (al dan niet via de herkenningsmakelaar). 2e. De herkenningsmakelaar constateert dat de authenticatie succesvol is verlopen en stuurt de ontvangen identiteitsverklaring naar de webslté. Op basis van de ontvangen identiteitsverklaring besluit de website om de gebruiker al dan niet toegang te verlenen tot de persoonlijke omgeving. • 3. Gebruikersondersteuning Indien de gebruiker problemen ondervindt tijdens het inloggen, kan de gebruiker contact opnemen met de helpdesk van de desbetreffende authenticatiedienst. Aan het interactiepatroon liggen de volgende juridische relaties ten grondslag:

• • •

Dienstafnemer-dlenstaanbieder: bestuursrechtelijk, gereguleerd door wetgeving uit het desbetreffende domein (bv. fiscaliteit, toeslagen). Dienstafnemer-authenticatiedienst: civielrechtelijk, op basis van (bij gebruik bankmiddelen) contractuele relatie met bant4 Dienstaanbieder-authenticatiqdienst: civielrechtelijk, op basis van afsprakenstelsel. Dienstaanbieder-herkenningstnakelaar: civielrechtelijk, op basis van afsprakenstelsel.

2. Vragen De te beantwoorden vragen zijn: 1. Is het overzicht van de geschetste relaties tussen betrokken partijen bij een authenticatiedienst cq. de afname van diensten bij de overheid volledig? Zo nee, welke relaties ontbreken? 2. Welke wettelijke kaders zijn van toepassing op de verschillende relaties? 3. Welke verantwoordelijkheden en, in het verlengde daarvan, aansprakelijkheden vloeien voort uit deze relaties?. 4. Hoe kunnen deze aansprakelijkheden worden gemitigeerd, zodat voor zowel banken als overheid de risico's van medegebruik van authenticatiemiddelen aanvaardbaar zijn? 3. Werkwijze Beantwoording van de vragen gebeurt in een werkgroep bestaande uit juristen van de betrokken banken, DGBelastingdienst en de Ministeries van BZK en EL&I. Voor de eerste bijeenkomst van de werkgroep leveren de banken een 'top 5' aan van de voor hen belangrijkste aansprakelijkheidsissues, met als doel om - mede gelet op de korte doorlooptijd van het onderzoek - direct de focus te kunnen bepalen. Bij de beantwoording van de vragen wordt gebruik gemaakt van documentatie (aansluitvoorwaarden, gebruiksvoorwaarden, SNO's) in het kader van de publieke

authenticatiedienst DigiD, de afsprakenstelsels eHerkenning en PKIoverheid, alsmede van algemene bankvoorwaarden en voorwaarden voor internetbankieren. Daarnaast wordt geput uit de ervaringen met gedeeld gebruik door banken van de infrastructuur voor a uthenticatie in het kader van iDEAL en uit verslagen en notities ten behoeve van eerder overleg tussen banken en elierkenning over dit onderwerp. De werkgroep levert uiterlijk aan het einde van week 11 (12-16 maart) een eindrapport op aan de kerngroep.

Document 11 Kort verslag juridisch overleg HAB d.d. 23 maart 2012 Aanwezig

1. Opening en kennismaking Bij dit punt wordt kort stilgestaan bij de scope van het traject en daarmee van de werkgroep. Van de zijde van de banken wordt aangegeven dat alleen gekeken wordt naar hergebruik van hun middelen door de Belastingdienst, hergebruik binnen het stelsel eHerkenning is nu niet aan de orde. geeft aan dat de Belastingdienst hierbij wel in het oog houdt wat de gewenste ontwikkelingen in het stelsel zijn om de behoefte aan authenticatieen autorisatiediensten van de Belastingdienst op langere termijn in te vullen. Ook wordt van bankenzijde aangegeven dat het beoogde business model ook van groot belang is bij de beoordeling van de juridische aspecten. De uitgangspunten voor het business model zoals besproken in de startvergadering van 21 februari j1 (bedrijf heeft/betaalt middel, Belastingdienst betaalt gebruik) worden toegelicht. Deze worden ook voor de juridische analyse als uitgangspunt genomen. 2. Inventarisatie juridische kwesties Aan de hand van de illustratie in de opdrachtnotitie worden de relaties tussen partijen (gebruiker, bank (als authenticatiedienst), Belastingdienst) doorgenomen. Dit leidt tot de volgende aandachtspunten: • De Belastingdienst moet de afspraken met de belastingplichtige over gebruik van het authenticatiemiddel vastleggen. Vergelijk de gebruiksvoorwaarden voor DigiD, • • Het feit dat een bankmiddel gebruikt kan worden, kan worden opgenomen in een openstellingsbesluit voor elektronisch verkeer met de Belastingdienst (op grond van artikel 2.15 Awb). De BD heeft nu al zo'n openstellingsbesluit, dat behoeft sowieso actualisering. • Daarnaast zal nodig zijn om het gebruik van de pas voor andere doeleinden dan betalingstransacties ook in de bankvoorwaarden vast te leggen. Actie BD: nadere analyse deugdelijkheid gebruiksvoorwaarden DigiD en wijze waarop destijds (verplicht) gebruik van DigiD voor de aangifte is geregeld. Actie banken: analyse modaliteiten voor aanpassen bankvoorwaarden. • • Hoe wordt omgegaan met vertegenwoordigingssituaties (varianten: meer passen bij één rekening, en/of rekening, gemachtigde pas) en eventuele beperkingen in de bevoegdheid van de pashouder (bv. alleen OB-, geen Vpb-aangifte)? • Deze kwestie speelt ten algemene bij de BD. In het kader van uitwerking van een

autorisatiesystematiek komt dit ook aan de orde. Het lijkt wenselijk om op pasniveau af te spreken welke wel en niet gebruikt kunnen worden. Dit zou vastgelegd kunnen worden in een machtigingen- en dienstenregister (vgl. uitwerking van dezelfde troblernatiek in eH). De verantwoordelijkheid voor uitiverkinWrealisexing hiervan ligt bij de BD. Actie BD: nagaan op welk niveau en op welke wijze koppeling tussen bevoegdheden en middel gerealiseerd kan worden. • Hoe wordt omgegaan met misbruik van de pas bij-gebruik in verkeer met de BD? Ook hier kan worden aangesloten bij de DigiD-voorwaarden: het middels is strikt persoonlijk, er is een verplichting tot het geheimhouden van je wachtwoord, zorgvuldig gebruik etc. Eventueel misbruik zal de banken niet worden tegengeworpen. De BD heeft uiteindelijk via de Awr mogelijkheden om onjuiste of frauduleuze aangiftes aan te pakken.

• Daarnaast kan het voorkomen dat een pas op bancaire gronden geblokkeerd wordt (overschrijcrmg kredietlimieten ed.). Die blokkering moet niet doorwerken in het gebruik van de pas voor verkeer met de BD (het middel zelf is immer wel in orde). • Ander belangrijk punt betreft de vraag wat de consequentie is van hef uit de lucht zijn van de authenticatiedienst van de bank betekent voor het tijdig doen van aangiftes. Uitgangspunt moet zijn dat de Belastingdienst dit oplost in het licht van de • bestuursrechtelijke relatie met de belastingplichtige (relevant is kader rond verzenden en ontvangen in de Awb en evt. specifieke regels in de Awr). Ook bij gebruik van DigiD werkt dit zo (geen claims jegens Logius). • Naar aanleiding van de discussie over deze aspecten wordt geconcludeerd dat het wenselijk is om hergebruik aanvankelijk te beperken tot heffen, en daarbinnen eventueel tot het domein ondernemers. Als dat goed werkt, kan eea. verder worden uitgebreid. Bij Toeslagen (waar direct betalingen worden verricht op basis van opgegeven gegevens) spelen deze risico's des te sterker.

Actie BD: uitwerken voorzieningen/beleid bij blokkeren passen en anderszins uit de lucht zijn van de authenticatiedienst. • Stilgestaan wordt bij het onderscheid tussen authenticatie bij toegang en • ondertekening van de aangifte. Bij gebruik van DigiD wordt nu ook geen onderscheid gemaakt tussen deze twee functies. De wilsuiting (onderdeel van de ondertekening) is ingericht via een verklaring aan het slot van de aangifte (ik verklaar ... duidelijk, stellig en zonder voorbehoud...) Actie BD: bezien hoe ondertekening moet worden ingericht (in verlengde van huidige werkwijze met DigiD). • De relatie bank-Belastingdienst moet geregeld worden door een overeenkomst, met daarbij een SLA. Daarvoor bestaan verschillende modaliteiten: de banken contracteren afzonderlijk, één bank contracteert (een soort makeIaatfunctie, vgl. betalingsacceptant) en maakt afspraken met andere banken (vgl. iDeal). De vraag is of ook gebruik gemaakt zal (of kan) warden van het iDeal netwerk. In dat geval komt ook Currence als betrokken partij in beeld. • Vooralsnog is het zinvol uit te gaan van een relatie tussen BD en banken, wel geschoeid op de leest van iDeal, maar specifiek ingericht. Dat voorkomt complicerende govemance-kwesties. • Punten waarvoor de banken in elk geval de aansprakelijkheid willen uitsluiten/beperken zijn: onjuist gebruik/misbruik van de pas, niet-functioneren van het systeem. Overigens hangt de mate van beperking ook af van de vergoeding voor het hergebruik. • De Belastingdienst accepteert het uitgifteproces van bankmiddelen als adequaat. Eventueel kan de BD dit wel (laten) auditen (voor eigen rekening). Actie banken: uitwerken contractuele relatie en aansprakelijkheidsbeperkingen conform bovenstaande lijn.

Document 12

Rapportage haalbaarheidsonderzoek gebruik authenticatiemiddelen van banken door de Belastingdienst

Augustus 2012

Versie 1.0

Inhoudsopgave

1.

Inleiding

1

2.

Conclusie

3

3.

Schets van de oplossingsrichting

4

4.

H aa I baa rh eidsvraagstu kke n

6

41.

Betrouwbaarheidsniveau authenticatie en gebruik van BSN

6

4.2. Regelgeving voor een bank als authenticatiedienstverlener

6

4.3. Juridische onderwerpen

7

4.4. Impact op de ICT-portfolio

8

Bijlage 1: Overzicht van betrokken personen in de uitvoering van het onderzoek

10

Bijlage 2: Lijst van uitgangspunten geformuleerd tijdens het onderzoek

11

1.

Inleiding

Voor de Belastingdienst is het verder ontwikkelen van dienstverlening via het internet een belangrijk speerpunt In 2012 is het internetportaal MijnToeslagen.nlgeïntroduceerd, waarop burgers online de status van hun lopende toeslagen kunnen inzien en aanvragen kunnen indienen. Een ander initiatief is de ontwikkeling van een internetportaal MijnBelastingdienst.nl. De bedoeling is om dat portaal in 2014 te introduceren. Belastingplichtigen - in eerste instantie burgers en later ook bedrijven - kunnen dan via Internet inloggen in dit portaal, waarin zij een overzicht aantreffen van hun dossier. Vanaf datzelfde jaar zouden ze ook aangifte moeten kunnen doen via het portaal. Aangekien Mijnbelastingdienst.n1 privacygevoelige gegevens ontsluit en verwerkt (bijvoorbeeld gegevens voor de VIA, de vooraf ingevulde aangifte), Is een authenticatie van de gebruiker met een hoge mate van zekerheid vereist. Conform de handreiking "Betrouwbaarheidsniveaus voor authenticatie bij elektronische overheldsdiensten"1 is voor de portaaldiensten van de Belastingdienst een authenticatie van minimaal STORK1 niveau 3 gewenst In lijn met de adviezen van de A3 Commissie3 wil de Belastingdienst onderzoeken welke mogelijkheden er zijn om vanaf 2014 te beschikken over authenticatiemiddelen voor burgers en bedrijven die de nodige mate van zekerheid kunnen leveren (STORK niveau 3 of hoger). Eén van de te onderzoeken mogelijkheden is het kunnen gebruiken van de door banken aan hun klanten verstrekte authenticatiemiddelen. In dat kader zijn eind 2011 verkennende gesprekken gevoerd met vertegenwoordigers van vier banken 4. Op basis van die gesprekken is geconstateerd dat het inzetten van een bank als authenticatiedienstverlener voor de Belastingdienst een aantrekkelijke optie lijkt. Of dit ook daadwerkelijk realiseerbaar is, vergt nader onderzoek. Dit nader onderzoek moet zodanige informatie opleveren dat er een gefundeerde uitspraak over de haalbaarheid kan warden gedaan en een advies over de te maken keuzes kan worden gegeven. In januari 2012 heeft DG Belastingdienst aan de Raden van Bestuur van de betrokken banken verzocht om medewerking te verlenen aan het haalbaarheidsonderzoek. Deze hebben hier positief op gereageerd, ofschoon door de banken wel het voorbehoud gemaakt is dat aan positieve bevindingen van het haalbaarheidsonderzoek geen conclusies kunnen worden verbonden over eventuele deelname aan een implementatie; dit blijft te allen tijde een afweging die elke bank individueel zal maken. Tijdens de uitvoering van het onderzoek is tevens afgestemd met de beleidsafdelingen van de Ministeries van BZK (beleidsverantwoordelijk voor autorisatie en authenticatie van burgers) en EL&I (be leidsverantwoordelijk voor autorisatie en authenticatie van bedrijven). Dit rapport beschrijft het resultaat van het uitgevoerde onderzoek. Aanvankelijk was de ambitie om de resultaten ultimo april 2012 op te leveren, echter dit is niet haalbaar gebleken. Het proces van afstemmen en toetsen van de inzichten binnen de overheid vergde meer tijd dan gepland. Het rapport is opgesteld door de Belastingdienst; de vier betrokken banken hebben gezamenlijk reviewcommentaar op dit rapport aangeleverd dat in deze versie is verwerkt. De conclusies en de gehanteerde uitgangspunten (bijlage 2) zijn in gemeenichappelijkheid vastgesteld en zijn door alle betrokken partijen geaccordeerd.

1 http://www.forumstandaardisatie.nlketueel/itemnitel/nieuwe-publiealie-handreiking-hetrouwhaarheidsniveaus-heschikhar/ 2

STORK is het referentiekader zie Inins://nnvw.eid-stork.euf

3

http ://wv.nv. rijksaverheid.nlidaeumenten-en-publieaties/rapporten/2011/11/17/adviesconunissie-authenticatieen-autorisatie•hedrijven.html.

'Het betreft

1

De opbouw van dit rapport is als volgt: - Hoofdstuk 2 beschrijft de conclusie. - Hoofdstuk 3 geeft een indruk van de oplossingsrichting van het authenticatieproces (het inloggen). Hoofdstuk 4 beschrijft de afzonderlijke vraagstukken die voor de haalbaarheid van belang zijn. Per vraagstuk wordt aangegeven wat de oplossingsrichting is, zodat het vraagstuk de haalbaarheid niet in de weg staat. Als achtergrondinformatie zijn de volgende bijlagen toegevoegd: - Bijlage 1: Overzicht van personen die in de uitvoering van het onderzoek hebben deelgenomen. - Bijlage 2: Lijst van uitgangspunten geformuleerd tijdens het onderzoek.

2

2.

Conclusie

Over een aantal essentiële aspecten van het gebruik van authenticatiediensten van banken in de context van overheidsdienstverlening bestaat binnen de coördinatiegroep overeenstemming. Het gaat hierbij om het volgende: a. De wijze waarop een bank als authenticatiedienstverlener een unieke identificatie kan leveren voor natuurlijke personen, Indien deze gebruik maken van het aan hen door de bank ter beschikking gestelde authenticatiemiddel. Er wordt door de Belastingdienst een koppeling aangebracht tussen deze unieke persoonsaanduiding (UP) van de persoon bij een bank en het BSN van die persoon. b. De vereiste kwaliteitsborging van een bank als authenticatiedienstverlener (de zekerheid en de betrouwbaarheid van de dienstverlening). De bestaande regelgeving rond elektronisch betalingsverkeer en toezicht op de banken biedt voor de Belastingdienst voldoende zekerheden. c. Beperking van de aansprakelijkheid van banken bij uitval van de authenticatiedienst: de Belastingdienst legt geen claims bij de banken, consequenties voor de burger (bijvoorbeeld niet tijdige indiening aangifte) worden door de Belastingdienst zelf opgevangen via coulance. In het verlengde hiervan heeft de burger geen verhaalsrecht op de banken voor eventuele uitval van dé authenticatiedienst. d. Als uitgangspunt is gehanteerd om zoveel mogelijk gebruik te maken van de bestaande ICT-inrichting bij de banken. Oogmerk van dit uitgangspunt is de vereiste ICT-aanpassingen bij de banken zoveel als mogelijk beperkt te houden. Benodigd is o.m. de.creatie van het bericht "Identiteitsverklaring" en serveraansluitingen op de herkenningsmakelaar van de Belastingdienst e. Tegen de achtergrond van de opgestelde uitgangspunten zijn geen juridisch showstoppers geïdentificeerd Wel is vastgesteld dat over een aantal aspecten die. in de productie overeenkomst thuishoren, in dit stadium nog geen oordeel kan worden gevormd. Daarom wordt geadviseerd de uiteindelijk beoogde productie situatie te laten voorafgaan door een pilot, die de benodigde informatie over deze zaken zal moeten opleveren. Op één punt kon nog geen overeenstemming worden bereikt, namelijk de invulling van de financiële Vergoeding door de Belastingdienst voor het gebruik van de authenticatiediensten van de banken. De • mogelijke invulling van de pilot speelt hierbij een rol. Dit verschil van inzicht leidt tot het afronden van het onderzoek zonder financiële conclusie. .De banken hebben aangegeven hierdoor niet in staat te zijn een uitspraak te doen over de haalbaarheid. Geadviseerd wordt over dit aspect nader bilateraal (Belastingdienst met elke bank individueel) overleg te plegen, dan wel dit onderwerp op bestuurlijk hoger niveau te adresseren.

3

3.

Schets van de oplossingsrichting

Het concept om gebruik te maken van de authenticatiemiddelen van de banken ten behoeve van overheidsdienstverlening is voor de Belastingdienst geen autonome ontwikkeling. De strategische koers van de Belastingdienst zet in op de ontwikkeling van een "elD Stelsel NL". Aanbieders van authenticatiediensten hanteren binnen een dergelijk stelsel dezelfde standaarden. Er is vanuit de Europese Commissie regelgeving op dit onderwerp in voorbereiding. Het zal nog even duren voordat deze regelgeving van kracht wordt. Met de invulling zoals die nu met de banken wordt voorzien, sorteert de Belastingdienst voor op deze koers. De banken doen in dit stadium mede in verband met de komende Europese regelgeving nog geen uitspraak over hun participatie in het "elD Stelsel NL". In onderstaand schema is een schets van de oplossingsrichting gegeven, zoals die in het elf> Stelsel wordt voorzien. De banken zijn in onderstaand schema indicatief weergegeven. De in dit rapport beschreven oplossingsrichting met de banken maakt gebruik van dezelfde componenten.

Authenticattediensten NL

Omnummer voorziening

DigID Dlenstaanbieder

Herkennings makelaar

eH erkenning identiteitsverklaring

174P'Zi identiteitsverklaring

Belastingdienst Mijn Toeslagen MijnBelastingdienst

Banken

4

elD Stelsel NL

Gebruiker

"HandelendePartij"

Authenticatiediensten Een authenticatiedienst stelt 'op afstand' de identiteit van een persoon als eigenaar van het gebruikte authenticatiemiddel (de gebruiker) vast. Ter ondersteuning van het identificatieproces stelt de authenticatiedienst aan de gebruiker dit persoonsgebonden authenticatiemiddel beschikbaar. Voor de invulling van het authenticatiemiddel kan een authenticatiedienst eigen technologie inzetten, bijvoorbeeld sma rtcardtechnologie of het gebruik van mobiele telefoons. Ook de specifieke invulling van de authenticatie dialoog

4

met de gebruiker wordt door de authenticatiedienst bepaald. De authenticatiedienst hanteert in de communicatie voor elke individuele gebruiker een bestendige unieke persoonsaanduiding (UP), die geen logische overeenkomst vertoont met de gebruikte authenticatiemiddelen. Dit UP wordt door de overheidsdienstaanbieder gebruikt als basis voor het beheer van zijn relatie met de gebruiker.

Identiteitsverklaring

Een overheidsdienstaanbieder (bijvoorbeeld de Belastingdienst) wil niet afhankelijk zijn van de specifieke technologieën van de verschillende authenticatiediensten. Om dit te bereiken wordt het resultaat van een authenticatie door middel van een gestandaardiseerde identiteitsverklaring in de vorm van een elektronisch bericht aan de overheidsdienstaanbieder verstrekt. In dit bericht wordt door de authenticatiedienst verklaard welke unieke persoonsaanduiding (UP) bij het gebruik is vastgesteld.

Herken ningsmakelaar

De herkenningsmakelaar is het "single point of entry" voor een overheidsdienstaanbieder (in dit geval de Belastingdienst) naar authenticatiedien sten. Vanuit de authenticatiedienstverleners gezien is de herkenningsmakelaar het koppelpunt naar de overheidsdienstaanbieder. De herkenningsmakelaar presenteert aan de gebruiker het keuzemenu voor het selecteren van de gewenste authenticatiedienstverlener en regelt na de keuze het doorgeleide n van de gebruiker naar de geselecteerde partij. (Deze dialoog is vergelijkbaar met het keuzemenu van banken in het iDeal model om te kunnen afrekenen bij een webwinkel). De herkenningsmakelaar registreert en archiveert de van de authenticatiedienstverlener ontvangen identiteitsverklaring. Het aangeleverde UP in de identiteitsverklaring wordt doorgestuurd naar de z.g. omnummervoorziening. De omnummervoorziening levert als resultaat een tweede identiteitsverklaring, aanvullend op de eerste, waarin het BSN is opgenomen. Op die manier beschikt bijvoorbeeld de Belastingdienst over het BSN van de eigenaar van het authenticatiemiddel die zich via een private authenticatiedienstverlener heeft geïdentificeerd. De specificaties van de aansluiting aan de Herkenningsmakelaar zullen op het Internet warden gepubliceerd en op die manier ter beschikking warden gesteld van ah partijen die in de toekomst als authentieatiedienstverlener willen gaan acteren. De specificatie zijn gebaseerd op internationale standaarden én worden in samenwerking met de betrokken partijen beheerd.

Omnummervoorziening

Een overheidsdienstaanbieder als de Belastingdienst werkt voor natuurlijke personen, met het BSN als identificerende kenmerk van de belastingplichtige. Voor de Belastingdienst moet het resultaat van het identificatieproces dan het BSN zijn. Echter vanwege BSN-wetgeving mag of zal niet iedere a uth enticatiedienstverlener het BSN verstrekken. Als oplossing wordt een door de overheid beheerde omnummervoorziening ingericht. In deze voorziening wordt de koppeling tussen het UP van een authenticatiedienst en het 85N geregistreerd. Voor elke nieuwe UP zal eenmalig deze koppeling worden vastgelegd. De kwalitatieve invulling van dat registratieproces en de gebruikte authenticatiemiddelen bepalen het betrouwbaarheidsniveau van de koppeling (vergelijkbaar met de STORK-normering).

5

4.

Haalbaarheidsvraagstukken

4.1. Betrouwbaarheidsniveau authenticatie en gebruik van BSN Vanwege het toenemend aantal beveiligingsincidenten op internet hecht de Belastingdienst veel belang aan een hoog zekerheldsniveau van authenticatie. Als normering voor het indelen van authenticatiemiddelen wordt het STORK-model gehanteerd. In de beleidsplannen van de Belastingdienst is opgenomen het voornemen om voor zijn diensten minimaal 'STORK niveau 3 authenticatie' te verlangen. De Belastingdienst accepteert dat de door de banken gebruikte middelen en authenticatieprocessen voor veilig elektronisch betalingsverkeer eveneens voldoende zijn voor een betrouwbare toegang tot de digitale diensten van de Belastingdienst, aangezien deze middelen en processen onder toezicht staan van de Nederlandse autoriteiten (bijvoorbeeld toezicht door de Nederlandse Bank). Het haalbaarheidsonderzoek heeft zich gericht op een alternatief voor DigiD, dus de identificatie van natuurlijke personen op een hoger STORK niveau dan dat van het huidig beschikbare DigiD. Voor de Belastingdienst moet de identificatie van een natuurlijke persoon het BSN opleveren. Financiële instellingen zijn verplicht het BSN van rekeninghouders te administreren en bij de renséignering door te geven aan de Belastingdienst. Echter door de huidige regelgeving rondom het gebruik van het BSN, is het voor banken niet toegestaan het BSN te gebruiken anders dan voor renseignering naar de Belastingdienst. BZK heeft dit bevestigd en ziet zonder aanpassing van regelgeving geen mogelijkheden voor het toestaan van ruimer gebruik van het BSN. Het is niet voorzien dat het doorvoeren van regelgeving mogelijk is binnen de termijnen waarin het Belastingdienstportaal moet worden opgeleverd. Voor het beoordelen van de haalbaarheid is derhalve uitgegaan van ongewijzigde regelgeving, zijn de consequentiess aanvaard en is gezocht naar een andere oplossing. Als oplossing wordt een zogenoemde omnumniervoorziening voorzien (zie hoofdstuk 3).

4.2. Regelgeving voor een bank als authentIcatledienstveriener Voor het verkrijgen van toegang tot persoonsgebonden e-diensten bij de Belastingdienst is de vaststelling van de juiste identiteit van degene Wiens authenticatiemiddel wordt gebruikt om de toegang te verzoeken van primair belang. Voor deze vaststelling is de Belastingdienst — in het geval van gebruik van een door een bank verstrekt authenticatiemidel - afhankelijk van die bank als authenticatiedienstverlener en is inzicht nodig op welke wijze die afhankelijkheid op een betrouwbare en zekere wijze wordt ingevuld. Allereerst is het belangrijk om vast te stellen dat het voor een bank ook van primair belang is om de juiste Identiteit vast te stellen. In die zin komen de belangen van de Belastingdienst en de banken overeen. Specifiek voor Nederlandse banken wordt het benodigde vertrouwen aanvullend geregeld via de volgende maatregelen: a. De bedrijfsvoering staat onder toezicht van DNB, dit betreft ook de eisen aan veilig elektronisch betalingsverkeer. b. In 2008 is de Wet ter voorkoming van witwassen en financieren van terrorisme (Wwft) ingevoerd. Op basis hiervan dient een bank een controle uit te voeren op de identiteit van een rekeninghouder, aan de hand van documenten zoals paspoort, identiteitskaart of rijbewijs. c. De Nederlandse Vereniging van Banken (NVB) heeft richtlijnen voor minimum beveiligingseisen voor persoonlijke authenticatieen signeerapparatuur opgesteld 6. De betrokken banken hebben deze richtlijn geïmplementeerd.

S m.n. ontwerp, implementatie, operatie en beheer van de omnummervoorziening 6 Richtlijn NVB LC594

6

d. Banken hebben zich geconformeerd aan (internationale) normen voor informatiebeveiliging, bijvoorbeeld NEN 27001.

4.3. Juridische onderwerpen Aansprakelijkheid Een authenticatiedienstverlening berust in het algemeen op een overeenkomst tussen Authenticatiedienstverlener en Gebruiker (burger, ondernemer). In geval van gebruik van door een bank geleverde producten en diensten is dit de overeenkomst tussen bank en rekeninghouder, uitgewerkt in algemene bankvoorwaarden. De standaardvoorwaarden van de Nederlandse banken bevatten afdoende waarborgen die betrouwbaar en zeker gebruik van deze bancaire middelen voor authenticatiedoeleiriden als in dit onderzoek bedoeld, zoals verplichtingen tot strikt persoonlijk gebruik, tot geheimhouding van het wachtwoord, etc, mogelijk maken. Met het oog op gebruik voor diensten van de Belastingdienst, kan een bank overwegen om desgewenst de reeds bestaande voorwaarden aan te vullen. De gebruiker zal deze moeten accepteren alvorens gebruik gemaakt kan worden van zijn authenticatiemid del voor verkeer met de Belastingdienst Eventueel misbruik van het authenticatiemid del in het verkeer met de Belastingdienst is het risico van de Belastingdienst De Belastingdienst heeft uiteindelijk via de Awr mogelijkheden om onjuiste of frauduleuze aangiftes te corrigeren. In de situatie waarin een rekeninghouder slachtoffer is geworden van identiteitsfraude (pas of inloggegevens gestolen, geskimd, etc.), dan warden door de banken blokkerende maatregelen genomen conform de bij de betreffende bank geldende procedures. In gevallen dat de authenticatiedienst onverhoopt niet beschikbaar is voor diensten van de Belastingdienst heeft de gebruiker geen verhaalsrecht op de authenticatiedienstverlener, in casu de bank. Uitgangspunt hierbij is dat de Belastingdienst dit oplost in het licht van de bestuursrechtelijke relatie met de belastingplichtige, bijvoorbeeld door het betrachten van enige coulance rond ontvangst van berichten. Relevant is hierbij het kader rond verzenden en ontvangen in de Awb en eventuele specifieke regels in de Awr.

Mededingings- en aanbestedingsrechtelijke. aspecten De vraag is of de samenwerking met banken op mededingingsrechtelijke bezwaren stuit. Met het oog hierop is de NMa geconsulteerd. De NMa gaf aan dat indien transparante en non-discriminatoire criteria voor de samenwerking worden geborgd, inhoudende dat ook andere banken op een equivalente manier deel kunnen gaan uitmaken van de dienstverlening, en indien de samenwerking wordt gebaseerd op bilaterale overeenkomsten tussen enerzijds Belastingdienst en anderzijds de verschillende individuele authenticatiedienstverleners, deze samenwerking past binnen de kaders van de mededingingswetgeving en er voor de NMA geen aanleiding zal zijn tot het nemen van maatregelen . Voorts is in samenspraak met een deskundige bij het Ministerie van EL&I geanalyseerd hoe de samenwerking met de banken in aanbestedingsrechtelijke zin moet worden gekwalificeerd. Het aa nbestedingsrecht heeft primair tot doel om concurrentie te verkrijgen en om alle geïnteresseerde partijen een gelijke kans te geven de opdracht te verkrijgen. In het onderhavige geval is dat in principe aan de orde: het uiteindelijke doel is dat authenticatiediensten van banken in den brede beschikbaar komen voor transacties met de Belastingdienst Met het oog daarop is van belang dat eventuele afspraken en specificaties die dat vergt, openbaar zijn, zodat deze bekend kunnen zijn bij andere partijen die interesse hebben om authenticatiedienstverlener te warden.

7

Er is in het geval er authenticatiediensten -voor gebruik hij door de Belastingdienst geleverde diensten - van een bank zouden worden afgenomen geen sprake van een opdracht waarop het aan bestedingsrecht van toepassing is: niet de Belastingdienst is de afnemer van authenticatiediensten van de banken, doch de klant (de rekeninghouder) van de bank. Dit heeft tot gevolg dat niet alle potentiële in het leveren van authenticatiedienstverlening geintereiseerde partijen in het haalbaarheidspnderzoek behoeven te worden betrokken. Uit oogpunt van het belang dat de Belastingdienst heeft bij laagdrempelige toegang tot hoogwaardige authenticatiediensten als door de banken geleverd, zou een vergoeding voor het gebruik betaald kunnen warden aan de banken. Deze dient dan gebaseerd te worden op de (meer)kosten die de bank maakt bij het faciliteren van gebruik van hun authenticatiemiddelen door burgers in het verkeer met de Belastingdienst Zou worden besloten tot het uitvoeren van een productiepilot dan kan - los van bovenstaande- een proefen pilotfase worden gekwalificeerd als een onderzoekstraject dat buiten de aanbestedingsregels valt. Voorwaarde hierbij is dat de uitkomsten van proef of productiepilot breed gedeeld worden. Dat Is, met het oog op verdere verbreding van het gebruik van authenticatiediensten van banken, ook uitdrukkelijk de bedoeling. Een proef of productiepilot zou overigens ook kunnen worden benut voor het uitwerken van de Juridische kaders voor de samenwerking, het verkrijgen van inzicht in performance en piekbelasting, alsook voor de (implicaties van de) transacties die binnen de pilot zijn uitgevoerd.

4.4. impact op de ICT-portfolio Impact op de functionaliteit Aan het einde van bijlage 2 Is de use case 'inloggen met een authenticatiemiddel van een bank voor de Belastingdienst in schemavorm toegelicht Deze invulling lijkt op het iDeal-model en is realiseerbaar in het huidige ICT-landschap van de banken. De belangrijkste door te voeren aanpassingen zijn: Functionaliteit om UP's toe te kennen en te beheren, danwel deze —indien ze uit bestaande systemen of processen zijn verkegen ten behoeve van authenticatie - te koppelen aan het binnenkomende verzoek tot identificatie. Registratie, beheer en controle toegestane diensten per authenticatiemiddel. Het aanpassen van de authenticatie functionaliteit, zodat het resultaat van een uitgevoerde authenticatie als een identiteitsverklaring in een elektronisch bericht volgens gestandaardiseerd formaat aan de Belastingdienst wordt verzonden. Het inrichten van beveiligde communicatie verbindingen tussen elke bank en de herkenningsmakelaar van de Belastingdienst. Voor de Belastingdienst en Logius (DigiD) zijn-de volgende aanpassingen noodzakelijk: Het kunnen verwerken van de identiteitsverklaring. - Het inrichten, exploiteren en beheren van een herkenningsmakelaar. Het ondersteunen van de gebruiker bij het aanmelden en activeren van het door de bankten behoeve van authenticatie verstrekte a uthenticatiemiddel voor gebruik bij de Belastingdienst - Het inrichten, exploiteren en beheren van de omnummenroorziening om de koppeling BSN met UP te administreren. Vastgesteld is dat bovenstaande aanpassingen maakbaar zijn. Echter vanwege de schaarse ruimte in de ICTportfolio van de betrokken organisaties, zijn de benodigde aanpassingen niet bij alle partijen realiseerbaar voor 2014. Om de aanpassingen in 2014 te realiseren, moeten hiervoor nog in 2012 realisatie opdrachten worden verstrekt.

8

Impact op performance In 2011 zijn door DigiD ongeveer 53 mln. authenticaties uitgevoerd, het aandeel voor de Belastingdienst was 17 mln. De jaarlijkse piek treedt op in de maand maart en bedraagt in die maand ongeveer 13 mln. uitgevoerde authenticaties. De voorziening DigiD is ontworpen voor maximaal 300:000 authenticaties per uur, in de praktijk ligt de piek op 60% hiervan. De banken voeren dagelijks elk ongeveer 1 mln. authenticaties uit.

Impact op operationele processen en ondersteuning Zowel bij de Belastingdienst als bij deelnemende banken zullen processen moeten worden ingericht ter ondersteuning van gebruikers die problemen ondervinden met de authenticatiedienst dan wel daar vragen over hebben. Uitgangspunt hierbij is dat het primaire aanspreekpunt bij problemen met de authenticatiedienst de betreffende bank is, die daarvoor haar contactpunten zal moeten instrueren. Onderzocht moet worden hoe eventuele issues op het raakvlak tussen de systemen zullen worden behandeld; de banken zullen geen uitspraken doen over acties die hun klant op de website van de Belastingdienst doet, en de Belastingdienst zal geen uitspraken kunnen doen over acties binnen het bancaire identificatiedomein. Daarnaast kunnen de banken aanpassingen doorvoeren In hun algemene voorwaarden omtrent het gebruik van bancaire authenticatiemiddelen voor verkeer met de Belastingdienst Het streven hierbij is dat dit kan worden gedaan zonder dat daarvoor individuele goedkeuring per klant noodzakelijk is. Ten slotte zal er een voorlichtingscampagne moeten komen waarbij de banken en de Belastingdienst gezamenlijk de burgers informeren over de aanvullende nieuwe mogelijkheden tot authenticeren; hierbij kan het van pas komen dat voor deze aanpak — door de Belastingdienst in overleg met de banken - een aparte merknaam (zoals IDEAL") wordt geintroduceerd.

9

Bijlage 1: Overzicht van betrokken personen in de uitvoering van het onderzoek. Het haalbaarheidsonderzoek is uitgevoerd met de betrokkenheid van onderstaande organisaties en personen. Organisatie Ministerie van Financiën Ministerie van BZK Ministerie van EL&

Medewerker

Rot Coördinatiegroep Juridische werkgroep Beleidsmedewerker Juridisch medewerker Beleidsmedewerker Coördinatiegroep (tot 1 juhi) Coördinatiegroep (vanaf 1 juni) Juridische werkgroep Coördinatiegroep Juridische werkgroep Coördinatiegroep Juridische werkgroep Coördinatiegroep Juridische werkgroep

10

Bijlage 2: Lijst van uitgangspunten geformuleerd tijdens het onderzoek

1.

De Belastingdienst is een onderzoek gestart naar de haalbaarheid van het gebruik van bancaire authenticatiemiddelen bij zijn dienstverlening en heeft de banken uitgenodigd aan dit onderzoek deel te nemen. De uitvoering van het vooronderzoek mag geen belemmeringen vormen voor toekomstige authenticatiedienstverleners, waaronder andere banken (geen beperking van de mededinging). De specifieke scope van dit vooronderzoek betreft het hergebruik van de op dit moment beschikbare bancaire middelen voor authenticatie en doet geen uitspraken over niet-bancaire middelen.

2.

De Belastingdienst verhoogt het zekerheidsniveau voor zijn e-diensten de komende jaren naar minimaal een "two-factor» authenticatie-ondersteuning, vergelijkbaar met Stork-niveau 3. Er wordt vanuit gegaan dat de door de banken gebruikte middelen en authenticatieprocessen voor veilig elektronisch- ' betalingsverkeer eveneens voldoende zijn voor een voldoende geauthenticeerde en betrouwbare toegang tot de digitale diensten van de Belastingdienst, aangezien deze middelen en processen onder toezicht staan van de Nederlandse autoriteiten (bijvoorbeeld toezicht door de Nederlandse Bank).

3.

De Belastingdienst gaat ervan uit dat de komende 5 jaar de huidige beschikbare "two-factor" bancaire authenticatiemiddelen voldoende veilig zijn. Wanneer er zich ontwikkelingen voordoen die aanleiding zijn voor één of meerdere banken om zwaardere middelen toe te gaan passen dan zal opnieuw overlegd gevoerd worden met de Belastingdienst. De Belastingdienst volgt ook in de toekomst het beleid van de toezichthouders met betrekking tot veiligheid van betalingsverkeer.

4.

De Belastingdienst hecht aan veilige, maar laagdrempelige' authenticatiemiddelen voor burgers en ondernemers. In dat licht is hij bereid een compensatie te verlenen aan een Authenticatiedienstverlener voor het gebruik van middelen/diensten voor transacties met de Belastingdienst. Deze compensatie wordt vastgelegd in een bilaterale samenwerkingsovereenkomst tussen Authenticatiedienstverlener en Belastingdienst

5.

De herkenningsma kaar is de verantwoordelijkheid van de Belastingdienst De h erkenningsmakelaar registreert welke identiteitsverklaringen aan welke Authenticatiedienstverlener zijn gevraagd.

6.

Als richtlijn voor de beschikbaarheid worden de huidige richtlijnen van DigiD overgenomen: - Norm: de productieomgeving is 7*24 uur beschikbaar, alle dagen van het jaar, met uitzondering van geplande onderhoudsmomenten. - Minimaal: 99,5% beschikbaar.

7.

Als richtlijn voor de beschikbaarheid voor het Servicewindow voor ondersteuning wordt de huidige beschikbaarheid van DigiD overgenomen: - r lijn voor Dienstafnemer: werkdagen van 8.00 uur tot 22.00 uur. - llijn voor Dienstaanbieder (Belastingdienst): 24 uur per dag- Indien er problemen met inloggen zijn, dan neemt de Dienstafnemer contact op met de servicedesk van de Authenticatiedienstverlener. Indien de website van de Belastingdienst niet beschikbaar is, dan neemt de Dienstafnemer contact op met de servicedesk van de Belastingdienst.

8.

De herkenningsmakelaar roept de a uthenticatiedienst aan. In deze aanroep wordt meegegeven van welke Dienstaanbieder (Belastingdienst) de aanroep afkomstig is en met welk minimale Stork-niveau de authenticatie moet worden uitgevoerd. De authenticatiedienst krijgt geen informatie met betrekking tot welke Dienst (transactie) de authenticatie benodigd Is.

11

9.

Conform de vigerende weten regelgeving is het niet toegestaan dat een private Authenticatiedienstverlener het BSN op enigerlei wijze gebruikt. Ook banken in de rol van Authenticatiedienstverlener mogen het BSN niet gebruiken. Dit impliceert dat het BSN niet als resultaat van authenticatie in de identiteitsverklaring afkomstig van een private Authenticatiedienstverlener mag worden opgenomen.

10. Het resultaat van een uitgevoerde authenticatie dient een persoonsgebonden identificatie te zijn. Daartoe kent een Authenticatiedienstverlener aan elke persoon een persistent uniek identificerend nummer toe, aangeduid als een Unieke Persoonsaanduiding, afgekort UP. Deze UP wordt bij een succesvolle authenticatie in het antwoord naar de herkenningsmakelaar opgenomen. Een toegekende UP is uniek per Authenticatiedienstverlener, omdat deze een unieke identifier voor elke bank bevat, waardoor de, combinatie bank-identiffer en UP samen uniek is over alle systemen heen. Deze UP is een contextloos nummer, slechts bedoeld voor koppeldoeleinden. Het verbindt de administratie van de Authenticatiedienstverlener met die van de overheid (de BSN-administratie). Het schept de mogelijkheid om aan beide zijden gegevens te veranderen zonder impact op de koppeling uit te oefenen. Voorbeeld: de bank kan het bankrekeningnummer of pasnummer veranderen zonder impact voor de authenticatiedienst 11. Een Authenticatiedienstverlener levert alleen een verklaring omtrent de vastgestelde UP van een persoon. Geen enkele Authenticatiedienstverlener levert informatie over de mogelijke bevoegdheden van deze persoon. 12. Er wordt vooralsnog geen onderscheid gemaakt in een authenticatieverzoek in het kader van 'inloggen' in een overheidsportaal en een authenticatieverzoek in het kader van het ondertekenen van transacties. Bijvoorbeeld bij het gebruik van DigiD wordt nu ook geen onderscheid gemaakt tussen deze twee functies. De wilsuiting (onderdeel van de ondertekening) is ingericht via een verklaring aan het slot van de aangifte (ik verklaar ... duidelijk, stellig en zonder voo rbehoud.„). 13. De overheid is verantwoordelijk voor een juiste en betrouwbare koppeling van het UP met het BSN van de betreffende persoon. De bank is verantwoordelijk voor een juiste en betrouwbare koppeling van het UP aan de bancaire administratie van de betreffende persoon. 14. Een gebruiker neemt zelf het initiatief om zijn ter beschikking gestelde' private authenticatiemiddel (bankmiddel) tevens te gebruiken voor overheidsdiensten via internet (in casu Belastingdienst-portaal). Om dit te realiseren zal de gebruiker voorwaarden moeten accepteren: - De Overheid (Belastingdienst) kan voorwaarden voor het gebruik van digitale diensten van de Overheid ter acceptatie aanbieden. - De Authenticatiedienstverlener kan voorwaarden ter acceptatie aanbieden. 15. Een Authenticatiedienstverlener heeft de bevoegdheid om een a uthenticatiemiddel van een individuele gebruiker buiten werking te stellen. 16. Overwegingen bij misbruik van het authenticatiemiddel bij gebruik in verkeer met de Belastingdienst - De standaardvoorwaarden van de Nederlandse banken bevatten afdoende dekking voor het gebruik van de bancaire middelen, zoals het strikt persoonlijke gebruik, verplichting tot geheimhouding van het wachtwoord. - Eventueel misbruik in de fiscale sfeer is het risico van de Belastingdienst De Belastingdienst heeft uiteindelijk via de Awr mogelijkheden om onjuiste of frauduleuze aangiftes te corrigeren. - In de situatie waarin een rekeninghouder slachtoffer is geworden van identiteitsfraude (pas, inloggegevens, etc.), dan worden blokkerende maatregelen genomen.

12

17. In het geval van het niet beschikbaar zijn van een authenticatiedienst, heeft de gebruiker aangaande diensten van de Belastingdienst geen verhaalsrecht op de Authenticatiedienstverlener. Uitgangspunt hierbij is dat de Belastingdienst problemen als gevolg van het niet beschikbaar zijn oplost In het licht van de bestuursrechtelijke relatie met de belastingplichtige (relevant is kader rond verzenden en ontvangen in de Awb en eventueel specifieke regels in de Awr). 18. De authenticatiedienstverlening berust op een overeenkomst tussen Authenticatiedienstverlener en gebruiker (burger, ondernemer). In geval van een bank is dit de overeenkomst tussen bank en rekeninghouder, uitgewerkt in algemene voorwaarden voor internetban kieren. De bank kan besluiten aanvullende voorwaarden stellen aan hergebruik van het authenticatiemiddel door de rekeninghouder voor verkeer met de Belastingdienst De gebruiker zal daarme moeten instemmen. 19. De werking van een regulier authenticatieverzoek is in onderstaand schema beschreven.

13

Use case 'inloggen met een authenticatiemiddel van een bank voor de Befastingdiense

Dienstafnemer

Belaslingdrenst

Herkenningsmakelaar

Authenticatiackenst Bank

Gebruiker bezoekt de site van de Belastingdienst De BD toont de website Selectie van eed < onderwerp waarbij identificatie nodig is

De BD stuurt het D verzoek door naar de makelaar De makelaar toont de beschikbare middelen

De gebruiker selecteert "Bank» Vasttegging tbv afrekening en doorsturen naar Bank

De gebruiker gebruikt het Bankmiddel

De gebruiker ontvangt de gevraagde dienst

Op basis Auth.resultaat levert de BD de gevraagde dienst

Doorgeleiding van Auth.resultaat naar de BD

Gewenste minimale1 Stork-niveau De Bank presenteert het Identificatie menu

UP

De Bank verwerkt authenticafie

14

Document 13 Memo voor de DG Belastingdienst Peter Veld Van: 1. Inleiding Het Forum Standaardisatie en College Standaardisatie hebben geconcludeerd dat authenticatie van burgers en bedrijven een belangrijke infrastructurele voorziening is voor de verdere ontwikkeling is van de dienstverlening. Op verzoek van de DG Belastingdienst hebben diverse gesprekken gehad met de belangrijke stakeholders bij de overheid en bij de banken voor een door de DG Belastingen te organiseren Ronde Tafel met de bestuurders van de overheid (DG Bestuur en Konirikrijksrelaties, DG Bedrijfsleven en Innovatie, DG Belastingdienst en de Hoofddirectie SVB) en de banken inclusief de NVB) om zo tot een doorbraak te komen voor het gebruik van de authenticatie middelen van de banken voor de dienstverlening van de overheid (en voor e-commerce). De Ronde Tafel is beoogd om op bestuurlijk niveau te komen tot een commitment voor de start van een samenwerking om met de bestaande authenticatie middelen van de (drie) banken e-government en e-commerce diensten eenvoudiger en beter toegankelijk te maken voor burgers (consumenten) en zzp-ers. 2. Conclusie Zowel dei bestuurders van de overheid als van de banken onderkennen het strategische belang van het gebruik van de authenticatie middelen van banken voor e-government . / dienstenen e-commerce diensten. Deze bestuuraers erkennen allemaal ook dat het om diverse redenen het tot op heden niet mogelijk was om tot een gezamenlijke aanpak te komen dit ten voordele van de burgers (consumenten) en bedrijven zoals dit wel is gebeurd is in diverse andere landen van de Europese Unie. Wij concluderen dat er via een Ronde Tafel met de bestuurders van de overheid en de banken een doorbraak gerealiseerd kan worden voor het authenticatie vraagstuk mits de bestuurders van beide zijden bereid zijn om de uitgangspunten (de "wat vraag") en de randvoorwaarden (de "hoe vraag") met een gezamenlijk authenticatie programma te ondersteunen. Wij concluderen tevens dat de realisatie van zo'n programma uitdrukkelijk zal voorzien in de behoefte van burgers (consumenten) en zzp-ers en van de dienstverleners van egovernment en e-commerce diensten. De realisatie van zo'n programma zal bijdragen aan de efficiency verbetering bij zowel de overheid als het bedrijfsleven. Het vormt tevens een cbncrete invulling van het Massaal Digitaal programma en van het elD stelsel programma van de overheid en van het Shopping 2020 programma van het bedrijfsleven.

•De realisatie van zo'n programma zal bijdragen aan de waardering van de toegevoegde bijdrage van de banken aan een voor hun klanten belangrijke behoefte. 3. Gesprekken De conclusie voor het houden van een Ronde Tafel voor een doorbraak van het authenticatie dossier is gebaseerd op gesprekken met de bestuurders van overheid hebben plaats gevonden met • DG Belastingdienst: Peter Veld • DG Bestuur en Koninkrijksrelaties: Gert Jan Buitendijk • DG Bedrijfsleven en Innovatie: Bernard Leeftink De gesprekken met de bestuurders van de banken hebben, na een brief van de DG Belastingdienst naar de Raad van Bestuur van deze banken, plaats gevonden met • •

Tevens heeft er een gesprek plaats gevonden met Nederlandse Vereniging van Banken en is , geinformeerd over de ontwikkelingen. Daarnaast hebben veel aanvullende gesprekken plaats gevonden met managers en medewerkers bij de overheid, de banken sector en de e-commerce sector die allen het belang van een doorbraak voor het authenticatie dossier bevestigen. 4. De uitgangspunten: de WAT vraag Het is van groot belaná dat bij de start van een samenwerking van de banken en de overheid de scope zeer duidelijk afgebakend is. Een programma scope dat de drie banken hun bestaande authenticatie middelen voor hun particuliere en zzp klanten na circa twee jaar na de Ronde Tafel voor e-government services in zullen zetten is haalbaar mits aan de onderstaande randvoorwaarden voldaan wordt. De overige banken die willen deelnemen aan het programma worden daarbij ten principale ook in de gelegenheid gesteld door de drie banken zodat in beginsel 100 procent van de authenticatie services beschikbaar kan komen voor de egovernment dienstverlening met de keuzevrijheid voor de burger (consument) en zzper welke dienstverlener hij/zij prefereert. Voor het halen van deze termijn is focus onontbeerlijk De drie rechtstreeks betrokken banken kunnen in deze fase niet tegelijkertijd support geven om tevens hun bestaande authenticatie middelen voor bedrijven voor e-government services aan te bieden. De banken constateren dat deze services al door veel administratie kantoren en gespecialiseerde dienstverleners aangeboden worden.

De drie banken zien niet de noodzaak om via dit samenwerkingsprogramma met de Belastingdienst (namens de overheid) tevens de authenticatie voor e-commerce in de project scope te hebben ook al omdat ze via de Betaalvereniging al een programma voor authenticatie voor e-commerce opgestart hebben als bijdrage aan het Shopping 2020 programma. 5. De randvoorwaarden: de HOE vraag a. Programma Governance Voor de banken is het van essentieel belang dat de DG Belastingdienst namens de overheid het aanspreekpunt (rijksoverheid en mede-overheden) is en zal blijven tijdens dit programma voor alle overheidsdienstverleners tijdens de uitvoering van dit programma. Zowel de DG Bestuur en Koninkrijksrelaties als de DG Bedrijfsleven en Innovatie hebben bevestigd dat zij dit principe ondersteunen en hieraan medewerking zullen geven. De drie banken zijn bereid om op Stuurgroep niveau en werkgroep (medewerkers) niveau deskundige managers en medewerkers in te zetten met de veronderstelling dat ook DG Belastingen dat zal doen. ) De drie banken zien het gezamenlijke authenticatie programma als een project met de beoogde afgebakende scope. De Betaalvereniging Nederland neemt namens de banken- deel aan het Platform e-ID Stelsel dat een adviesrol heeft met een bredere scope. De banken willen hun beperkte resources primair in zetten op de het beoogde project De drie banken veronderstellen dat er een gemeenschappelijk project bureau ingericht zal worden. b. Authenticatie schema De drie banken zijn bereid om via hun bestuurlijke en operationele rollen in de Betaalvereniging Nederland een kopie van het iDeal model beschikbaar te maken rekening houdend met sommige aspecten van het eID stelsel. Zowel de bestuurders van de geconsulteerde drie banken als van de overheid gaan er van uit dat de bestaande authenticatie middelen van de banken hergebruikt moeten kunnen blijven worden. De drie banken zijn bereid de governance van het e-Authenticatie 'Deal schema zodanig vorm te geven dat zowel de overheid als de banken op gelijkwaardige

wijze aan deel nemen. De Betaalvereniging Nederland heeft thans al ervaring met de vraag hoe de governance van multi-stakeholders schema's het best vorm kan krijgen. De Betaalvereniging Nederland werkt in het kader van het Shopping 2020 programma aan een schema voor authenticatie voor e-commerce. De Betaalvereniging Nederland is -met instemming van de drie banken- werkt op verzoek van de Belastingdienst een POC (Proof of Concept uit) die tijdens de voorgenomen Ronde Tafel gepresenteerd kan worden

c. Vergoeding structuur De ontwikkelingen in andere landen in de Europese Unie hebben aangetoond dat een succesvolle authenticatie service voor e-government en/of e-commerce diensten alleen gerealiseerd wordt als een helder bekostigingsmodel (zowel voor operationele kosten als voor investeringskosten) een integraal onderdeel is voor deze services. In deze modellen dragen de dienstverleners van e-government als van de e-commerce services bij aan de kosten van de authenticatie service provider. Uit de gesprekken met de bestuurders met de overheid is duidelijk dat er ten principale de bereidheid aanwezig is dat overheidsdienstverleners daadwerkelijk hun deel van deze kosten voor het gebruik van de authenticatie middelen van de banken voor e-government diensten te dragen. De drie banken kunnen gelet op de concurrentie wetgeving geen uniforme afspraken maken met de dienstverleners van de overheid over één tarief structuur voor alle overheidsdienstverleners. De drie banken vragen zich af of de DG Belastingen voor dit probleem -evenals in andere landen van de Europese Unie- een adequate oplossing gevonden kan worden met instemming van de Autoriteit Consument ez Markt. De banken hebben uitgebreide ervaring hoe deze problematiek via een intefchange model opgelost kan worden. De authenticatie serviceprovider van de overheidsdienstverlener moet in staat zijn ook de authenticaties met authenticatie middelen van concurrenten te kunnen verwerken. d. Communicatie Zowel de bestuurders van de banken als van de overheid hebben aangeven dat het gebruik van de authenticatie middelen van de banken voor e-government gepaard moet gaan met de juiste communicatie. De vormgeving van de communicatie moet deel van het programma zijn.


Document 14

Aan Taskforce en werkgroepleden Voorbereiding rondetafel BankID

DIrectoraat-Generaal Belastingdienst Inlichtingen

Datum 15 mei 2015

notitie

Status concept

Plannfng en documenten 1.h.k.v. de rondetafel BankID

Inleiding In deze notitie wordt een overzicht gegeven van de documenten, welke afgestemd dienen te zijn met alle betrokken ten behoeve van de beoogde ronde tafel-bijeenkomst met vertegenwoordigers van de overheid en banken. De betrokkenen zijn benoemd in de bijlage bij deze notitie. De ambitie is om de ronde tafel-bijeenkomst te doen plaatsvinden op of rondom de datum van het Congres Toekomst Betalingsverkeer van 16 juni a.s. (weeknr. 25). Oplevering, inclusief voorafgaande afstemming, van de desbetreffende documenten dient dan ook uiterlijk in de eerste week van juni gerealiseerd te zijn (weeknr. 23). De (operationele) activiteitenplanning per document is als volgt: Nr. 1

2

3

4

Documenten

Actor

Intentieverklaring Banken en overheid Versie 0.86 opleveren en ter bespreking versturen aan Bd BvN en andere overheidspartijen Bespreken versie 0.86 met resp. BvN en MinEZ BvN / Bd / EZ Finaliseren versie 1.0 Bd Samenwerkingsovereenkomst Bank en Belastingdienst Versie 0.86 opleveren en ter bespreking versturen aan Bd BvN Bespreken versie 0.86 met BvN BvN / Bd Finaliseren versie 1.0 Bd Uitgangspunten Pilot Belastingdienst met BankID Versie 0.86 opleveren en ter bespreking versturen aan Bd BvN en andere overheidspartijen Bespreken versie 0.86 met BvN en MinEZ BvN / Bd / EZ Finaliseren versie 1.0 Bd Bijlage 1. Normenkader authenticatie invulling Werksessie op 19/5 BvN / Bd

Deadline eind weeknr. 20; 15-05-15 21; 22-05-15 22; 27-05-15 20; 15-05-15 21; 22-05-15 22; 27-05-15 2015-05-i5 21; 22-05-15 22; 27-05-15 21; 22-05-15 Pagina 1 van 4

5

6

7

8 9

10 11

12

Uitwerking en vervolg Finaliseren verste 1.0 Bijlage 2. Beschrijving verificatieproces aanmelding BSN-k Oplevering vanuit programma elD Verspreiden versie 1.0 Bijlage 3. Bewerkerovereenkomst gebruik BSN Bepalen publieke beleidsrichting gebruik BSN Bepalen publieke beleidsrichting gebruik BSN Opstellen versie 10 Bijlage 4. Beschrijving Customer joumey input aanleveren vanuit Bd Uitwerken demoschermen Opleveren demoschermen versie 1.0 Bijlage 5. Koppelvia k beschrijving aanmelding BSN-k Versie 1.0 opleveren en versturen aan BvN Bijlage 6. Architectuurschets pilotiandschap Technische workshop Uitwerking en vervolg_ • Finaliseren versie 10 Bijlage 7. KoppelvlakbeschrlbAng authenticatiesessie Versie 1.0 opleveren en versturen aan BvN Bijlage 8. Contouren Pliotp la n Versie 0.3 opleveren en ter bespreking versturen aan BvN Bespreken verSié 0.3 met BvN Bespreken versie 0.8 met BvN Finaliseren versie 1.0 Bijlage 9. Gezamenlijke communicatielijn Bepalen hoofdlijnen Afstemmen wederzijds intern Vaststellen versie 1.0

BvN / Bd Bd

Bd Bd

Bd Bd Bd Bd BvN / Bd BvN/Bd

22; 27-05-15 22-05 HRdR via FdK 20; 15-05-15 21; 22-05-15 22-05 ML?? Afh BSN besluit 21; 22-05-15 22; 27-05-15 Offirala a. 22-05 HRdR 20;15-05-15 21; 22-05-15 22; 27-05-15 22-05 HRdR

Bd Bd BvN /Bd Bd

21; 22-05-15 22; 27-05-1.5 a

Bd Bd

20;15-05-15

Bd Bd Bd

21; 22-05-15 22; 27-05-15

BvN / Bd BvN / Bd BvN / Bd

CK check 1K en PW 21; 22-05-15 22; 27-05-15 -Pin S --

Pagina 2 Var/ 4

•

Bijlage Betrokken vertegenwoordigers ronde tafel-bijeenkomst Bankt() Aanwezigen ronde tafel-bijeenkomst: Naam Functie

Organisatie

Beta a fve reniging Nederland Ministerie van Binnenlandse Zaken en Koninkrijksrelaties Ministerie van Economische Zaken Belastingdienst Digicommissaris Taskforce. voorbereiding: Naam

Functie

Organisatie

Betaalvereniging Nederland 7

Ministerie van Binnenlandse Zaken en Koninkrijksrelaties

_

Ministerie van Economische Zaken Belastingdienst

Werkgroe leden voorbereidin • Naam Functie/rol

Organisatie

_

Betaalvereniging Nederland

_

Belastingdienst

_ _

Belastingdienst Ministerie van Economische

_

Zaken Ministerie van Economische Zaken Pagina 3 van 4

Projectleider Pilot Banken


Projectleider Pilot Belastingdienst

Belastingdienst

Pagina 4 van 4

Agenda Document 15

1. Opening en vaststellen agenda 2. Brief Peter Veld en reacties van de aangeschreven banken 3. Proces in vogelvlucht en betrokkenheid bestuurders 4. Inhoudelijke verkenning: 'flow van kosten' en aansprakelijk 5. Inventarisatie en prioritering onderzoeksvragen 6. Werkvorm en organisatie van onderzoek 7. Rondvraag en sluiting

Context van een Authentica iedienst

Dienstafnemer »1./4 Zelfaangever > Gemachtigde O Familie, kennis U Maatschap. lnterrn. U Fiscale Dienstverl. U Douane Dienstverl.

• Zelfaangever > Gemachtigde 12 Fiscale Dienstverl, Cl Douane Dienstverl.

Front end .POblieke POrtaal

Belastingdienst Portaal - MiJnaD, MiJnTSL - Pl) Ondernemers

•

Private Partij SOftware Pakket/portaal

a Verklaring Igij "wie je bene'

dienst . .

Verklaring "watfe maf

Kostencomponenten voor een Authenticatiedienst

/___ 0 N\ ,

, blOittifnékcrlè'i' ":,

_

K

Authenticatiedienst

i

-"

I

ti tc:trge ci drtt

1

i

i

I

a

4iittrentfcatle

COnSti rfight

•

I i I

I i

"at

Dienstaai

Herkennin makelaa °0

•

1.

Het verstrekken van een authentIcatlemiddel • Aanschaf is verantwoordelijkheid Dienstafnemer • Afspraak tussen Dlenstafnemer en Authenticatiedienst

2.

Het leveren van een Identiteitsverklaring • Vergoeding door Dlenstaanbieder per bericht • Volume afspraken • Wel of geen BSN-conversie

3.

Exploitatie Herkenningsmakelaar • Is verantwoordelijkheid DIenstaanbleder • Kosten geheel voor rekening Dienstaa nbie der • Geen vergoeding door Authenticatiedlenst • FacturerIngsfunctie ror ontvangen identiteitsverklaringen.

4. Ondersteuning Dienstafnemer • Verantwoordelijkheid Authenticatiedienst • Doorberekenen gebruikskosten is afspraak tussen Dienstafnemer en Authenticatiedienst

5.

Service Nivo Overeen' • Beschikbaarheid infrasi • Beschikbaarheid help& • Contractvoorwaarden • Voorkeur uniforme SN • Per Dienstaanbieder/0 • Kosten verdisconteerd

6.

Eenmalige opstartkost • Stimulering • Voorlichting

Deskresearch Kostenniodei en Contractueel

1. Hoe is het in andere voorbeeld landen geregeld • Noorwegen • Denemarken es Zweden • Finland • Estonia • Oostenrijk

2. Voorbeeld invullingen van huidige contracten • DigiD • PKI-0 leveranciers

Voorbeeld Autherdicatiedienst DigiD

1. ;:

1...• .

titétisiateakriërt ,c;.::..

,' Ij.:

.

1

a"

Authenticatiedienst

;...,..t.......,t,;,...? s.)7,,;.,5,!;r42;-,..:, ., 1

:1

:"./

3, .'7.:.; '..-.., -- '....:,.. 7 •:::::::., i: 1

i.

Logius

Gebruiksvoorwaarden

Aansluitvoorwaarden

Dl

Aansluit- en Gebruiksvoorwaarden

SNO

Artikel 2 gebruik en diensten

Beschikbaarheid van DigiD • Norm: de productieomgeving van DigiD is 7*2 • Minimaal: 99,5% beschikbaar

2.2 Alvorens de Gebruiker gebruik kan maken van DigiD dient hij de Gebruiksvoorwaarden Digit:, te accepteren. Artikel 3 Inspanningsverplicfrting Logius zal zich naar beste vermogens inspannen de Diensten beschikbaar te houden.

Servicewindow ondersteuning le lijn voor burgers: werkdagen van 8.00 uur to. 1.13 lijn voor klanten: 24 uur per dag Performance !Performance Indicator voor capaciteit en performance DMID Soort afspraak

Artikel 9 Aansprakelijkheid In het kader van aansprakelijkheid gelden de algemene regels van het Nederlands recht ten aanzien van de Inhoud en omvang van de wettelijke verplichting tot schadevergoeding.

Norm

VenverkIngstild van DigiD bij iVerweddng authenticatie gemIddeli &Oentje-abt

I

Verwerkingstijd bij maximale Daar waar 900 concurrent sessies 1 concurrent sessies verwerkingstijd van minimaal 95% I

dan 30 seconden.

Kentallen met betrekking tot capaciteit en performance Soort afspraak

Capaciteit eutientIcalles

JNorm

Het aantal authenkates wordt gos authenticalies per uur (gedurende ;

Bijlage: achtergrond sheets thema Authenti

Wat is het? •

Authenticatie: ben je, die je zegt te zijn? - Bijvoorbeeld met je DigiD, maar ook pincode, wacht etc. - Betrouwbaarheid verschilt.

Twee manieren van authenticeren...

Onhandig, kostbaar, complex, onveilig. Voor ieder proces een eigen a uthenticatiemiddel %Mai !Ei -1~ aa a

ar

a

a

al

Ook een goed idee is ... Authenticatie ontkoppelen van Dienstaanbieder

Naar een uniform stelsel in NL

'

Een stelsel heeft nodig: • Standaards • Toezicht • Acceptatie • Internationale aansluiting

Betrouwbare authenticatie • • • • •

Wens: naar hoog niveau Zo mogelijk parallel: elD, banken, eRijbewijs, PKI Maatschappelijke acceptatie, breed gebruik Redelijk kostenniveau The race never ends.

1.1,4gdrenweik

Document 16


Actielijst Betaalvereniging — Belastingdienst t.b.v. voorbereiding ronde tafel-bijeenkomst: Nr. 1 2 3

4 5

Actie Aanpassen intentieverklaring met gedeeld 'eindbeeld' Bevestigen dat alle banken in gelegenheid zijn gesteld om te participeren in de pilots Agendareservering (laten) maken voor ronde tafeldeelnemers aan beide zijden op / rondom 16 juni

Navragen of Samenwerkingsovereenkomst getekend wordt per individuele bank of door BvN Navragen intern overheid of notitie 'Gelijk speelveld' ook als zinvol wordt gezien voor ronde tafel-bijeenkomst (n b banken geven aan van niet)

Actor Bd / CK

Deadline 15-05 22-05

Loopt

Bd / CK ism BvN JAK

22-05

Loopt

ByN /AK

22-05

Bd / CK

15-05

BvN LAK

6

Navragen datum periodiek overleg Depotstelsel als optie voor bijeenkomst met itaskforce, w.o. directeuren Betalingsverkeer

Bd/CK

15-05

7

Uitzoeken of initiele koppeling aan EiSN-k in batch kan of dat dat individueel moet Aanpassen notities Uitgangspunten en Gelijk speelveld

Bd /1-112cIR

15-05

Bd / HRdR Bd / HRdR ism BvN/ AK BvN / R5

15-05 15-05

22-05

Bd / HRdR

15-06

Bd / CK Bd/ME Bd / CK

15-05 08-05 22-05

Bd / CK

26-05

BvN JAK

26-05

8 9

Organiseren werksessie Normenkader

10

Organiseren vervoigsessie Pilots. Initiatief bij R5 om vrijdag 22-05 met Wi om tafel te gaan

11

Organiseren technische werksessie tbv koppelvlakken en conversie SAM L 'dialecten';

12 13 14 15

16 17 18

Opstellen planning met producten en mijlpalen Opstellen nieuwe vërsie Customer journey Nav 4: CK zal Samenwerkingsovereenkomst nogmaals voorleggen aan de juriste van de Belastingdienst. Nav 6: Plannen inhoudelijke goedkeuring op tactisch 'niveau aan overheidskant (vergelijkbaar met interne stuurgroep banken 10/6) Nav 6: Aangeven of nog aanwezigheid is gewenst vanuit Belastingdienst bij interne stuurgroep banken 10/6 Nav 13: Verder (laten) uitwerken van de demo Customer Journey o.b.v. de screenshots van de Bd Aanpassen / intern bespreken Intentieverklaring op aantal artikelen g. en h. 4- twee extra artikelen. • Vastleggen in versie 0.87 .

BvN / AK

Status

Loopt

Loopt

Bd / CK

22-05

19

Aanpassen Intentieverklaring artikel i. en tekstvoorstel aan CK sturen

ByN / AK

20-05

20

Aanpassen Notitie Uitgangspunten op keuze om bijlagen

Bd / CK

22-05 Pagina 1 Van 3

21 22 23

24

25

niet mee te sturen naar de ronde tafel in versie 0.87 Terugkoppeling geven over gebruik BSN, dan wel fallback scenario's Terugkoppeling geven over (proces) van keuze makelaar Nay 14: Stukken (statuten oid) overleggen die relatie Betaalvereniging— banken aangeven mbt tekenen van Samenwerkingsovereenkomst Nay 14: Navragen of SamenwerkingsOvereenkomst bedoeld is als geldend voor de hele pilotperiode of dat er nog een soort nader contract volgt. Nay 6: Checken hoe tactisch 'voor-akkoord' kan worden gehaald op ronde tafel-stukken. AK/RJW checkt wensen Stuurgroep; CK checkt (eventuele) aanwezigheid daarbij vanuit Bd.

Bd/CK

29-05

Bd / CK BvN /AK .

29-05 04-06

Bd / CK

. 04-06

BvN / AK of RJW Bd / CK

04-06

26 .

Bewaken dat Customer journey voor 10/6 gereed is (presentatie Stuurgroep)

BvN / AK

08-06

27

Aanpassen llitgangspuntendocument 0.87 aan gemaakte opmerkingen in sessie 28/5 en opmerkingen EZ in een versie 028

Bd / CK

04-06

28

Voorstel voor tekst communicatielijn rondom bankenpilot aanleveren aan Bd tbv afstemming

04-06

29

Checken in hoeverre een (actief) persberichtgewenst is vanuit respectievelijk de Bd en de banken

BvN /AK of RJW Bd / CK BvN / RJW

30

Navragen bij BZK of gebruik van BSN-koppelregister ook mogelijk is voor bankenpilot met zorgverzekeraars Zodra PIA elD stelsel gereed is (medio juni) afspraak arrangeren tussen . . . AK en HRdR Aanleveren concept beschrijving verificatieproces aanmelding BSN-koppelregister

31 32

04-06

Bd/CK

04-06

Bd / HRdR

Medio juni 04-06

Bd / HRdR .

Toelichting: (*2) 19/5: AK geeft aan via mail een 'verklaring' te zullen sturen dat BvN alle banken in de gelegenheid heeft gesteld om deel te nemen aan de pilot (*3) Aan de kant van de overheid is het nu niet opportuun om 'zonder meer' een agendareservering in te schieten bij de betrokken DG's. Volgende week is daar waarschijnlijk wel . groen licht voor te krijgen. 19/5: CK streeft ernaar nog deze week duidelijkheid te krijgen. 28/5 Afgesproken dat contactpersonen uit beider secretariaten worden gekoppeld om een agenda reservering te maken voor de 4e week juni. 2/6 CK contactpersoon doorgegeven. (*4) Belastingdienst geeft aan de Samenwerkingsovereenkomst met de individuele banken te willen stuiten. BvN geeft aart de voorkeur te hebben om dat met en via de BvN te doen. (*5) De notitie Gelijk Speelveld is inderdaad uitsluitend relevant voor (in eerste instantie) de overheidspartijen. Deze zal dan ook geen onderdeel vormen van de set documenten voor de ronde tafel-bijeenkomst.

Pagina 2 van 3

(*6) Datum Depotstelsel is nog niet vastgesteld, maar inschatting is dat het alsnog inplannen daarvan niet lukt binnen de gestelde termijn. Voorstel BvN is dan ook om aan de bankenkant de interne stuurgroepsessie (van 10/6) te benutten om inhoudelijk akkoord te krijgen op tactisch niveau. CK zal een vergelijkbaar moment plannen aan de overheidskant. 28/5: CK zal vertegenwoordiger Bd vragen om bij de Stuurgroep aanwezig te zijn op 10/6. AK / FOW checkt wensen bij Stuurgroep. (*7) Dat kan via een geautomatiseerd proces, waarbij Individueel, herhaald, wordt aangeroepen. (*9) Nieuwe versie Normenkader op 26/5 van Bd naar BvN en op 1/6 weer nieuwere versie retour. Finale versie beoogd voor 5/6. (*11) 19/5: Bijlage Architectuurschets pilotlandschap is losgekoppeld van de ronde tafel-sessie. Vormt dan ook geen bijlage meer in de lijst. Werksessie zal over zo'n 3 weken plaatsvinden. (*14) 28/5: Indien formele relatie Betaalvereniging — banken eenduidig aangeeft dat ondertekening door Betaalvereniging kan, is dat voor de Bd geen probleem. (*21) 28/5: Uitgangspunt Is en blijft dat BSN gebruikt kan worden bij initiele registratie. Binnen programma eID lijkt dat nu ook de overheersende lijn. (*24) 4/6: Samenwerkingsovereenkomst is bedoeld voor gehele pilotperiode. Er volgt niet nog eens een contract. De samenwerkingsovereenkomst is eigenlijk een convenant, waarin we afspraken vastleggen over een gezamenlijk te bereiken beleidsdoel en de daarbij geldende voorwaarden. (*29) 4/6: Belastingdienst geeft er de voorkeur aan om geen actief persbericht te verspreiden. Een gedeelde 'passieve' communiCatielljn Is wel noodzakelijk. (*30) 4/6: Besproken met BZK. Men ziet de logica om organisaties die nu 'Eigin-gebruik gerechtigd' zijn, toegang te geven tot het BSN-k. Wat de implicaties zijn van een bankenpilot nu met die organisaties wil men eerst nader overdenken.

Pagina 3 van 3

Document 17

20-7-2015

Bilaactisdna

Re

eb. j iele ~Ven,

telg Sereiiits Deen. vileetre • IJL/Smid n

Otos nar

acts Pan

AnnOtreditte Aanyte sun over 25)L4. 154emp neát rtn re• time, we-

InIterstenbelaulrip ha 4:44 nett4enbetsla0. Sattn3 bies teerel, e tk5•514.5,H.11:e5t....••••.

Itedanoo

Stakfallgele 15 Lol. Reu, LIT utik ta•trto ta •clanlat et, Mr 25:p.getedne."

19.• HP. POC6 b/. fine~r, Mit; rl, P.Incrop~tg, inte5p.a to. alp. lbo am% maip. •

Me

vaiveit

Ettalt-ticilltatzasad

Volnradde Traan om.) a.mits Mto ra tee

JntrdcnaI mtge unelesep. Vb54•r. •-no45•55.. wm,sk• •Isalt recesc•• ~sena. zweet—

KNMI ta 'aerlie. SdleStr; 1rwint

-

.

Paneren, Aller klelettlellee daal cmWarmeed

ron:non onármernon

1.161~ a etrais4pacaptC.31Cc CP 14 en (p..?..)ir.c.f. a bh] la.cl vat; ~mennen> S15 lEe; 5 belanonilr &e at ah uonat tenec 'stbl ;en vet, niukan (5.4-2 el: I ras) Reet-

Vcrstating•n tinerrt.t.:~•~SC "Rad' ..ctrant:t et ~esa 15, til

.

I ee

CaPiPPI YUP IP.P4tia

belik

ten adAttede eng

Nemo • nege• Mina 5 peccranclez anfixtrulkcan Precha.ct cm kut. . a lict.ohPace 5 V.-.69.6.1•Pf. war. Prodrr• :,-traorto

In

~20 We» ka:Ito. >Si epen. Olnintbetkierinru 0.~..advutclatton. • trceallriiPlahpitd. Mor—

noenen &aHl4iØ titij tugx,wCgns MOP 3.4.21n.. R•val oer vy. et,

ft Pa

biloouon oP

%new atif«.47441'14 n Zr. et tt n:J

Inloggen op Mijn Belastingdlenst • Ltt Vief 3134 the:Neemt is ra penntfre ~te tl deed~radisag vaan sint ne bodekeicirec le :c prt1.1.1 3.td iw•I • • • •

in ~sipste kin% tor tetS liárnitn..440111 n en-anten Met nteetebo ~I na =1301 afl. teel e zee* eens. ms eteinellef »Ude

TIJD» le wbeithawdit (.53art •,5 fo• kei Hall at en inn t•• cue went. am d • de t• erre•i, ta• bri mrstreron e• red weef e n+ Men mee telg kOma lie ir br ho en,. r•••• bot ne. anus Imer• tyantatitcliae gia witt.44 envie tbaele et~ S n be tere. boreel.14* aaaaa • leer eetnt• ani 4 bargoense.« pclatcce•

C

s ee• " litlekel.e... )

azogat doen conor-20/ 4

II let 5545 2 meet ene tae... serre tbelero om SDU els •

1

20-7-2015

ggen op Mijn Belestlngdlenst •65...5..st 6 ma sci.55.46. Pon bij 6115€1.0kleJt.0. 0 lno rish

Men na pele~ ale».> 6er.iht o lasnxteMent: fl410 1100,00,10t. 'nal» aband wralnin.,..er....1

•555MC.15•655.~ Jan 6~4 K dár en.fl.iD.OWMktrJ u de telt-

vt.• kar.g lStrft k.I. Ir int«. 1.42.1 wam:cru

345n Cleil~diant 5 B.5502.2 n»- erna.. ween II" tiwed OGDO Meg deze tal aan ez won...1.1J.V.195184.5 Inpent N ef mie." rendre) Sertdebaidt0,

0.45allepatisl

Inloggen met Dign

1-J•nr....*C4Z5 0•0060400

ntUUtbecn 021 fl1 0". 0v ani. Tnia: Pat d...e. rTp*t dem njj. Plat11.11~~1e0

u hal iita, lawast1.0,0,0* >0 0 ~br i0000.40. immt

wrOliel J. .S.*flln.mWbD.

0.0..I.nracesmaja CePe van ~d ~n Sr. vis harst rocknO te; tf..~ conus rlipti4.MMi.0 dim. J. n.6/ 66op...

ror.cloato

bij vw ate.cnii brast

al

Dat na ~é pag? Don

2

20-7-2015

Inlogirn Pilot ItStweedn uitgelogd wordtcht ~denim pllotdoetwaarb b•prodcrwonit ca In ta ;mem« **onder enkkldio Aan* presides* mond banken als partij« Wropp.art

lolatuegal

Min Be I e gingaretat

Inloggen pilot

~nekt [tekrt with Szakird~ dat 11.4011~~ pist doet ~rh beproefd wort en In bloem MI andu mktior den US Aan de proef cbin zaagbanken di paan Edgar:tikt et}

t idensys 61V loleinole« BenkID

Bank/D

3

20-7-2015

Inloggen op Mijn Belastingdfenst Mol eniorslort. don rne ~dong Uw ~IQ. Om de ~te Wou~nenlokyorantrin ~te C~bbCiMor.

lon BankID Wip *n runtr~

t •2I

AMRO ASN FUdllt DUI0 'MC X 'rib kabaiunk : Risjorpeel Stit Bijt : Vod= Bui.

en

Wrat

DEMO BANK

p-L

C.i.f.. •

GletimkerMaare

J }.): ot.y.1,

riolne

I I riRmail:

T04~

4

20-7-2015

gr

BANK ; DEMO . na•

atr. .7 ra

L1 ar AI:vd,gl idntme C". IJ: CM vr I.,•2! nannind ta stat:. rni.V: •

~1.•111141

1191 j 371 9

4.9

101'..r.ha

Atb elibidi,•3

Mijn Eiliestingdlanst . ..._

•

.

tt/YAAPA Lneling LE dolima •• . •

Welkom Dit oe penotirt• "oho lijdt lidastatient. U re ten fr 2~41.03 t.. or.Oh fraltja.ellmea• 31100 eng c.v. bleu<

• 9.9 OlteZo, Ol u oio. nr hebt bdst-n 0,03.2:013 or HM uur.

unloar. .1.0 ~urn

r Mar antedblebrrle.-.

wrt .nunatalvx .al

IS lacter Curneraildeork9 On • ••••q•

091vo4er

(slim

nujArtc n.ntell•cicu•Mt

Demin24Iern1

ra-O-Zuts

Veabsbkte napea » •or I a drawear warmte 4VIC bart~ “rls •• Oir e oija.cci uni> >

.1 n, g onourjr, V pool rOrrerur

5

Document 18 sSIL


Aan: Bestuurders betrokken bij pilot BankID

DIrectoraat-Generaa I Belastingdienst Inlichtingen

Datum 22 juni 2015 Notitienummer DGB/cluster IV

notitie

Inhoudelijke uitgangspunten pilot Belastingdienst met BankID

Rubriek IV Beleid Auteur

Van Kopie aan Bijlagen

Inleiding In deze notitie wordt een samenvatting gegeven van de inhoudelijke uitgangspunten die van toepassing zijn op de pilot van de Belastingdienst met gebruikmaking van BankID. Een aantal uitgangspunten is nader uitgewerkt in documenten die zijn geaccordeerd door vertegenwoordigers van zowel de banken als de Belastingdienst. Deze documenten zijn benoemd aan het einde van deze notitie.

Uitgangspunten 1.

De doelgroep wordt afgebakend tot natuurlijke personen die als ingezetene (duurzaam woonachtig in Nederland) zijn ingeschreven in de BRP (basisregistratie personen) en een BSN bezitten. Het moet mogelijk worden dat deze doelgroep met behulp van een bankmiddel kan inloggen in het 85N-domein. Het 85N-domein is breder dan alleen publieke dienstaanbieders en omvat bijvoorbeeld ook pensioen- en zorgverzekeraars. Met andere woorden, het bankmiddel biedt een alternatief voor die organisaties die op dit moment DigiD mogen gebruiken. Deze notitie heeft echter betrekking op het formuleren van uitgangspunten voor de eerste toepassing van het bankmiddel in het BSN-domein, namelijk een pilot met de Belastingdienst. De verwachting is dat voor de overige dienstaanbieders in het BSN-domein de uitgangspunten ook van toepassing zijn.

2.

De introductie van BankID voor gebruik bij de Belastingdienst zal via een beheerste groei moeten verlopen. De eerste fase is het uitvoeren van een productie-pilot bij een aantal webportalen van de Belastingdienst, zodat naast DigiD ook kan worden ingelogd met BankID. De Belastingdienst wenst grip te kunnen houden op de omvang van de doelgroep die gebruik Pagina 1 van 4

maakt van de pilot. In een nadere uitwerking moet worden vastgesteld welke beheersmaatregelen aan de kant van de Belastingdienst mogelijk zijn en welke aan de kant van de banken. 3.

Voor een publieke dienstaanbieder in het BSN-domein moet het resultaat van elke authenticatiesessie het BSN opleveren.

4.

Op grond van de Wet bescherming persoonsgegevens en de Wet algemene bepalingen burgerservicenummer is het niet toegestaan dat het BSN door een bank bij iedere authenticatiesessie wordt aangeleverd aan de Belastingdienst.

5.

Op basis van punt 4 wordt geconcludeerd dat een bank als resultaat van elke authenticatiesessie een ander identificerend kenmerk van de persoon (eID-kenmerk) dan het BSN moet aanleveren. Een vaste set aan persoonsgegevens (bijvoorbeeld naam, geboortedatum, geboorteplaats) levert onvoldoende garantie van uniciteit. Daarom is het nodig dat elke bank als elD-kenmerk een uniek identificerend nummer aan elke persoon toekent. Dit unieke elD-kenmerk wordt aangeduid met de term BankID. In technische zin genereert elke bank een unieke persistente BankID voor elke gebruiker. Deze BankID is specifiek voor het gehele BSN-domein en specifiek per bank. De koppeling van een BankID met het BSN van de desbetreffende persoon wordt in het overheidsdomein vastgelegd in een generieke publieke voorziening, het BSN-koppelregister (BSNk).

6.

De overheid en de banken stellen hoge betrouwbaarheidseisen aan de wijze waarop de initiële koppeling van een BankID met het BSN tot stand komt. Een belangrijk aspect hierbij is de wijze waarop de identiteit van de persoon wordt vastgesteld aan de hand van een geldig identiteitsdocument. Banken hebben hiervoor processen ingericht die in het wettelijk kader van de Wet ter voorkoming van witwassen en financieren van terrorisme (Wwft) onder toezicht van DNB vallen. Aanvullend hierop hanteren de banken eisen die de kwaliteit en betrouwbaarheid van de identiteitsvaststelling en de gegevens moeten borgen. Voor het elD Stelsel wordt hiervoor een normenkader opgesteld. Het voldoen aan het normenkader zal worden vastgesteld via gangbare assessment procedures, zoals die ook gelden voor bijvoorbeeld iDEAL of AcceptGiro, waarin de Betaalvereniging zal valideren dat de banken voldoen aan de gestelde eisen.

7.

Voor elke BankID moet een eenmalig koppelproces met het BSN warden doorlopen. Hiervoor levert de bank eenmalig een set aan persoonsgegevens aan bij het BSNk. De gegevensset bestaat uit: a. Voor- en achternaam, en geboortedatum van de persoon b. BankID van de persoon c. Ter verificatie het BSN van de persoon Het BSNk voert een verificatieproces uit en beoordeelt de match tussen de aangeleverde gegevens en de registratie in de BRP. De beschrijving van het aanmelden verificatieproces, zowel het goed- als het foutpad zijn opgenomen in document B. In dat document is tevens opgenomen op welke wijze het aanmeldproces wordt geïnitieerd.

8.

Voor het eenmalig aanleveren van het BSN zal BZK een bewerkerovereenkomst BSN met de bank sluiten. In document C is deze overeenkomst opgenomen.

9.

Nadat de initiële koppeling tussen BankID en BSN succesvol in het BSNk is geregistreerd, is het BSN voor het regulier inloggen bij de publieke dienstaanbieder niet meer nodig. Voor het inloggen wordt door de bank elke keer het BankID van de persoon aangeleverd.

Pagina 2 van 4

10. De Belastingdienst is voornemens om naast de pilot met BankID tevens een pilot via het elD Stelsel te realiseren. De pilots via het elD Stelsel zullen onder de naam Idensys worden gecommuniceerd. Binnen de termijn waarop de pilots gaan starten zijn de banken niet toegetreden tot het elD Stelsel. Dat betekent dat de pilot van de banken niet onder de naamgeving Idensys mag vallen, maar onder een eigen naam worden gecommuniceerd. In het portaal van de Belastingdienst komt een neutrale verwijzing naar de inlogmogelijkheid voor de pilot-deelnemers. De visualisatie hiervan is in document D Customer journey opgenomen. 11. In document D is de Customer journey opgenomen. Hierin is als voorbeeld uitgewerkt het inloggen met BankID in het portaal van de Belastingdienst. Tevens is uitgewerkt het ondertekenen van de aangifte door middel van het nogmaals uitvoeren van een authenticatie. 12. De technische invulling van het koppelvlak voor de initiële aanmelding bij het BSNk wordt door de overheid opgesteld en zal worden uitgevoerd als een synchrone webservicebevraging. Het koppelvlak is in document E opgenomen. 13. In het ontwerp van het elD Stelsel worden authenticatiediensten via de rol Makelaar aangesloten. Voor de pilot zullen de banken en de Belastingdienst in principe gebruik maken van de diensten van de leverancier die nu al soortgelijke diensten levert aan de banken in het kader van hun gezamenlijke elektronische betalingsdiensten. Hiermee wordt niet vooruitgelopen op vervulling van de rol van Makelaar bij eventuele voortzetting van de samenwerking na de pilot 14. Het uitgangspunt van de Belastingdienst is dat er één uniform koppelvlak wordt gehanteerd tussen de Makelaar en de authenticatiedienst. Dat maakt het echter nog steeds mogelijk dat er binnen de infrastructuur van BankID een eigen protocol wordt gehanteerd. Het voorstel van de Belastingdienst is dat het uniforme koppelvlak wordt uitgevoerd als een SAML Query door middel van een bevraging van een SOAP-webservice. Het koppelvlak is in document F opgenomen. 15. De deelnemende banken zorgen voor het met goed gevolg doorlopen van een conformiteitstest bij de beheerorganisatie van het Afsprakenstelsel elektronische toegangsdiensten voor de implementatie van de koppelvlakken van de documenten Een F. 16. Gedurende de pilotperiode wordt voor de aansturing van de uitvoering van de pilot een gemeenschappelijke besturing tussen de banken en de Belastingdienst ingericht. Aan de kant van de banken verzorgt de Betaalvereniging de coördinatie. Deze besturing is opgenomen in document G. 17. Omwille van een afgestemde, eenduidige communicatie over de BankID pilot is in document H de communicatielijn opgenomen, welke door zowel de banken als de Belastingdienst zal worden gehanteerd. 18. Een nadere uitwerking van deze uitgangspunten is vastgelegd in de volgende documenten, die gezamenlijk zijn vastgesteld door vertegenwoordigers van zowel de banken als de Belastingdienst: A. Normenkader authenticatie invulling, versie a.a, dd. xx B. Beschrijving verificatieproces aanmelding bij BSNk, versie a.a, dd >cc C. Bewerkerovereenkomst gebruik BSN, versie a.a, dd. xx D. Customer journey, versie a.a, dd. xx E. Koppelvlakbeschrijving aanmelding bij BSNk, versie 1.0, dd. )oc Pagina 3 van 4

F. Koppelvlakbeschdjving authenticatiesessie, versie 1.0, dd. xx • G. Contouren Pilotplan, versie a.a, dd. xx H. Communicatielijn BankID pilot, versie 1.0, dd. xx

Pagina 4 van 4

Document 19 • Intentieverklaring tussen Banken en Belastingdienst voor samenwerking op het gebied van authentIcatie bij elektronische dienstverlening

In de periode 2014-2015 hebben bestuurders van de Belastin die bestuurders van de (verder te noemen: Banken) en de Betaalvereniging Nederland,

de mogelijkheden verkend voor samenwerking op het gebied van authenticatie bij elektronische dienstverlening van de Belastingdienst. Zij hebben overeenstemming bereikt over een aantal uitgangspunten en randvoorwaarden voor samenwerking, die zij vastleggen in deze Intentieverklaring. Context Belastingdienst: a) Het kabinet Rutte II heeft In het regeerakkoord doelstellingen opgenomen voor het realiseren van een recht op elektronisch zaken doen voor burgers en bedrijven in hun contacten met de overheid, onder de noemer Digitaal 2017. De Ministers van Binnenlandse Zaken en Koninkrijksrelaties en van Economische Zaken hebben deze doelstelling uitgewerkt in een vislebrief Digitaal 2017 en een Digitale Agenda voor ondernemers. Daarnaast heeft het kabinet de Digicommissarls benoemd voor het voeren van regie op de realisatie van de voor Digitaal 2017 benodigde generleke digitale infrastructuur (GDI). De Digicommissaris heeft hiertoe een Digiprogramma opgesteld. t;) De Belastingdienst zet - mede in het licht van de doelstellingen voor Digitaal 2017 - de komende jaren in op uitbouw van elektronische dienstverlening aan bedrijven en burgers. Daarvoor is brede beschikbaarheid van betrouwbare authenticatiediensten nodig. c) De Belastingdienst draagt ten behoeve van de realisering daarvan intensief bij aan de ontwikkeling van een Afsprakenstelsel elektronische toegangsdiensten, als onderdeel van de GDI. Dit Afsprakenstelsel is onder meer gericht op de inzet van private authenticatiediensten voor elektronische dienstverlening van organisaties In het publieke domein. d) De Belastingdienst ziet meerwaarde in het hergebruik van de authenticatiedlensten van de Banken voor elektronische transacties met burgers en bedrijven.

Context Banken: e) De Banken hebben de afgelopen jaren geïnvesteerd in betrouwbare authenticatiediensten ten behoeve van elektronische bancaire dienstverlening en betalingsverkeer met hun klanten. f)

De Banken hebben het voornemen pilots te starten waarbij zij deze authenticatiedlensten ten behoeve van gebrUik bij derden (bedrijven en overheden) ter beschikking stellen. De banken ontwikkelen in dat kader tevens de afspraken en techniek voor bancaire

authenticatlediensten, waaraan deze derden bij gebruik hiervan moeten gaan voldoen. g) Hiermee beogen de Banken onder meer de veiligheid van elektronisch zakendoen voor Nederlandse consumenten en bedrijven te verbeteren en geven zij opvolging aan wensen vanuit de markt.

Context samenwerking Belastingdienst en Banken: h) De Belastingdienst en Banken willen de inzet van de bancaire authenticatiediensten beproeven in een pilot. I) Bij de vormgeving van de pilot sluiten de Belastingdienst en de Banken aan op de technische specificaties en het normenkader voor betrouwbaarheidsniveaus van het Afsprakenstelsel elektronische toegangsdiensten. j)

De Banken kunnen bij de pilot gebruik maken van de onder verantwoordelijkheid van de Minister van Binnenlandse Zaken en Koninkrijksrelaties ressorterende generieke publieke voorziening, genaamd BSN Koppelregister, die gebruik van private authenticatiemiddelen

zoals bankpassen, bij het afnemen van diensten in het publieke domein mogelijk maakt. k) In het licht van de doorontwikkeling en evaluatie van het Afsprakenstelsel en de communicatie over de evaluatie van de pilot zal de Betaalvereniging gedurende de pilot namens de Banken als toehoorder participeren in de besturingsstructuur van het Afsprakenstelsel elektronische toegangsdiensten. I)

De Banken en de Belastingdienst voeren de pilot ieder voor eigen rekening en risico uit. Met deze afspraak over het wederzijds dragen van de kosten lopen zij op generlei wijze

vooruit op een kostenverdeling bij voortzetting van de samenwerking na de pilot. m) Dp grond van deze uitgangspunten en randvoorwaarden zullen de Belastingdienst en Banken een overeenkomst sluiten voor inrichting van de pilot voor hergebruik van Authenticatiediensten van de Banken bij elektronische dienstverlening van de Belastingdienst. n) De streefdatum voor de start van de pilot is 1 december 2015. o) De Banken en de Overheidspartijen onderschrijven het streven naar één Afsprakenstelsel voor elektronische toegangsdiensten. De Banken en de Belastingdienst beogen met deze pilot, onder voorbehoud van een wederzijds positieve evaluatie, de basis te leggen voor een structurele invulling van de inzet van de authenticatiedHensten van de Banken binnen de kaders van het Afsprakenstelsel elektronische toegangsdiensten. Een eventueel vervolg op de pilot en daarmee samenhangende aspecten, zoals een opschaling in aantallen gebruikers, zijn onderhevig aan politieke besluitvorming.

Aldus in zesvoud opgemaakt te 's-Gravenhage en ondertekend op ... 2015.

Namens de Belastingdienst,

P.W.A. Veld

Namens de Betaalvereniging Nederland,

(naam)

(naam)

(naam)

(naam)

(naam)

Document 20 Concept Samenwerkingsovereenkomst tussen de ... (naam bank) en de Belastingdienst inzake het gebruik van authenticatiediensten van de ... (naam bank) voor elektronische transacties tussen particuliere belastingplichtigen en toeslaggerechtigden en de Belastingdienst Partijen

1.

De Staat der Nederlanden (Ministerie van Financiën), van wie de zetel is gevestigd te Den Haag, hierna te noemen: de Staat, te dezen rechtsgeldig vertegenwoordigd door: de Directeur-Generaal Belastingdienst, P.W.A. Veld;

2.

gevestigd te, hierna te noemen: de Bank, te dezen rechtsgeldig vertegenwoordigd door: ...

Overwegende a.

Partijen hebben in de Intentieverklaring tussen Banken en overheid voor samenwerking op het gebied van authenticatie bij overheidsdienstverlening uitgangspunten en randvoorwaarden voor het gebruik van authenticatiediensten van de Banken bij elektronische dienstverlening van de Belastingdienst vastgelegd.

b. Partijen wensen ter invulling daarvan afspraken te maken over een pilot voor het gebruik van authenticatlediensten van de Banken, met name wat betreft de kaders voor de pilot, de governance, de naleving en de wederzijdse aansprakelijkheid.

Zijn als volgt overeengekomen

Artikel 1 Voorwerp van de overeenkomst 1. De Bank stelt in het kader van de pilot zijn particuliere klanten voor de periode van ... tot en met ... in staat om aan hen voor transacties in het kader van elektronische betaalverkeer verstrekte Authenticatiemiddelen te gebruiken voor elektronische transacties met de Belastingdienst op het terrein van belastingen en toeslagen. 2. Partijen zullen daarbij aansluiten op de kaders voor de pilots die gedurende 2015 en 2016 worden uitgevoerd in het kader van het Afsprakenstelsel elektronische toegangsdiensten. 3. De concretisering van deze kaders voor de pilot bij de Banken is vastgelegd in de Notitie Uitgangspunten BankID v1.0, die als bijlage bij deze overeenkomst is gevoegd.

Samengevat houdt deze in dat de banken voldoen aan het Normenkader betrouwbaarheidsniveaus en de standaarden voor informatiebeveiliging, genoemd in het Afsprakenstelsel elektronische toegangsdiensten. 4. Bij voortzetting van de samenwerking tussen Partijen op grond van wederzijds positieve evaluatie van de pilot, zal de Belastingdienst in een aanbestedingsprocedure een herkenningsmakelaar selecteren die voldoet aan alle ter zake relevante eisen in het eID Stelsel, zodat verzekerd is dat via die makelaar alle authenticatiediensten, inclusief die van de Bank, ontsloten kunnen worden.

Artikel 2 Naleving 1. De Bank toont het voldoen aan de in artikel 1, tweede en derde lid, bedoelde kaders aan door middel van een verklaring van een onafhankelijke auditor en door middel van een verklaring over het met goed gevolg doorlopen van een conformiteitstest bij de beheerorganisatie van het Afsprakenstelsel elektronische toegangsdiensten. 2. Indien gedurende de pilot blijkt dat de Bank niet meer voldoet aan de in artikel 1, tweede en derde lid, bedoelde kaders, zal de Belastingdienst de afname van Authenticatiediensten van de Bank beëindigen door middel van een opdracht aan de herkenningsmakelaar om deze diensten af te sluiten. De Belastingdienst zal de afname van Authenticatiediensten van de Bank hervatten zodra deze weer aantoonbaar voldoet aan de in artikel 1, tweede en derde lid, bedoelde kaders. Artikel 3 Aansprakelijkheid De Belastingdienst en de banken voeren de pilot ieder voor eigen rekening en risico uit en spreken voorts de volgende aansprakelijkheidsverdeling af: a. De Belastingdienst zal misbruik van Authenticatiemiddelen door klanten niet aan de Bank tegenwerpen. De Belastingdienst draagt de schade die uit eventueel misbruik voorvloeit. b. De Belastingdienst zal niet-beschikbaarheid van de Authenticatiedienst niet aan de Bank tegenwerpen en zal de Bank vrijwaren voor claims van klanten als gevolg van nietbeschikbaarheid van diensten van de Belastingdienst die voortvloeit uit nietbeschikbaarheid van de Authenticatiedienst

Artikel 4 Overleg en onvoorziene omstandigheden 1. De Bank zal als toehoorder participeren in de besturingsstructuur van het Afsprakenstelsel elektronische toegangsdiensten, zodat hij zijn kennis en ervaring op basis van de uitgevoerde pilot kan inbrengen bij de doorontwikkeling van het Afsprakenstelsel. Dit mede met het oog op het eventueel structureel inzetten van Authenticatiediensten van de Banken binnen het Afsprakenstelsel elektronische toegangsdiensten, doch zonder op enige beslissing ter zake van de Bank vooruit te lopen. 2. Onverminderd het eerste lid, voeren de Belastingdienst en de Bank gedurende de pilot regelmatig overleg over de voortgang en resultaten van de pilot 3. Indien de Belastingdienst-of de Bank onvoorziene omstandigheden signaleert die van wezenlijke invloed zijn op de uitvoering van de pilot, doet hij hiervan onverwijld

mededeling aan de andere partij. Partijen treden in dat geval in overleg over de ontstane situatie en de gevolgen die deze heeft voor het al dan niet gewijzigd voortzetten of het beëindigen van de pilot.

Artikel 5 Looptijd Deze overeenkomst treedt in werking op de dag van ondertekening en eindigt op ...

Aldus in tweevoud opgemaakt te 's-Gravenhage en ondertekend op .... De Staat,

De Bank

Voor deze,

Voordeze,

P.W.A. Veld

(naam)

Bijlage Notitie Uitgangspunten BankID v_1.0

Gehanteerde uitgangspunten HAB:

versie: 5 juni 2012

1. De Belastingdienst heeft een onderzoek gestart naar de haalbaarheid van het gebruik van bancaire authenticatierniddellen bij haar dienstverlening en heeft de banken uitgenodigd aan dit onderzoek deel te nemen. De• uitvoering van het vooronderzoek mag geen belemmeringen vormen voor toekomstige authenticatiedienstverleners, waaronder andere banken (geen beperking van de mededinging). De specifieke scope van dit vooronderzoek betreft het hergebruik van de op dit moment beschikbare bancaire middelen voor a uthenticatie en doet geen uitspraken over niet-bantai re middelen. 2. De Belastingdienst vraagt voor alle diensten minimaal een "two-fa ctor" authenticatie ondersteuning, vergelijkbaar met Stork niveau 3. Hierbij wordt ervan uitgegaan dat de door de banken gebruikte middelen en authenticatieprocessen voor veilig elektronisch betalingsverkeer eveneens voldoende zijn-voor een betrouwbare toegang tot de digitale diensten van de Belastingdienst, aangezien deze middelen en processen onder toezicht staan van de Nederlandse autoriteiten (bijvoorbeeld toezicht door de Nederlandse Bank). 3. De Belastingdienst gaat ervan uit dat de komende 5 jaar de huidige beschikbare "two-factor* bancaire authenticatiemiddelen voldoende veilig zijn. Wanneer er zich ontwikkelingen voordoen die aanleiding zijn voor één of meerdere banken dm zwaardere middelen toe te gaan passen dan zal opnieuw overlegd gevoerd worden met de Belastingdienst. De Belastingdienst volgt ook in de toekomst het beleid van de toezichthouders met betrekking tot veiligheid van betalingsverkeer. 4. De Belastingdienst hecht aan veilige, maar laagdrempelige authenticatiemiddelen voor burgers en ondernemers. In dat licht is zij bereid een compensatie te verlenen aan een Authenticatiedienstverlener voor het hergebruik van middelen/diensten voor transacties met de Belastingdienst. Deze compensatie wordt vastgelegd in een bilaterale samenwerkingsovereenkomst tussen Authenticatiedienstverlener en Belastingdienst. 5. De herkenningsmakelaar is de verantwoordelijkheid van de Belastingdienst. De herkenningsma kelaar registreert welke identiteitsverklaringen aan welke Authenticatiedienstverlener zijn gevraagd. 6. De gevraagde beschikbaarheid van elke authenticatiedienst is: - Norm: de productieomgeving is 7*24 uur beschikbaar, alle dagen Vali het jaar, met uitzondering van geplande onderhoudsmomenten. - Minimaal: 99,5% beschikbaar. - <nog toevoegen wat de huidige piek bij DigiD is> 7. Het gevraagde Servicewindow voor ondersteuning is: - le lijn voor Dienstafnemer: werkdagen van 8.00 uur tot 22.00 uur. - le lijn voor Dienstaanbieder (Belastingdienst): 24 uur per dag. - Indien er problemen met inloggen zijn, dan neemt de Dienstafnemer contact op met de servicedesk van dé Authenticatiedienstverlener. Indien de website van de Belastingdienst niet beschikbaar is, dan neemt de Dienstafnemer contact op met de servicedesk van de Belastingdienst.

8. De herkenningsmakelaar roept de authenticatiedienst aan. In deze aanroep wordt meegegeven van welke Dienstaanbieder (Belastingdienst) de aanroep afkomstig is en met welk minimale Stork-niveau de authenticatie moet worden uitgevoerd. De authenticatiedienst krijgt geen informatie met betrekking tot welke Dienst (transactie) de authenticatie benodigd is. 9. Conform de vigerende wet-en regelgeving is het niet toegestaan dat een private Authenticatiedienstverlener het BSN op enigerlei wijze gebruikt. Ook banken in de rol van Authenticatiedienstverlener mogen het BSN niet gebruiken. Dit impliceert dat het BSN niet als resultaat van authenticatie in de identiteitsverklaring afkomstig van een private Authenticatiedienstverlener mag worden opgenomen. 10. Het resultaat van een uitgevoerde authenticatie door een authenticatiedienst dient een persoonsgebonden identificatie op te leveren. Daartoe kent een Authenticatiedienstverlener aan elke persoon een persistent uniek identificerend nummer toe, aangeduid als een Unieke Persoonsaanduiding, afgekort UP. Deze UP wordt bij een succesvolle authenticatie in het antwoord 'naar de herkenningsmakelaar opgenomen. Een toegekende UP is uniek over alle Authentica . tiedienstverleners heen. Deze UP is een contextloos nummer, slechts bedoeld voor koppeldoeleinden. Het verbindt de bankadministratie met die van de overheid (de BSNadministratie). Het schept de mogelijkheid om aan beide zijden gegevens te veranderen zonder impact op de koppeling uit te oefenen. Voorbeeld: de bank kan het bankrekeningnummer of pasnummer veranderen zonder impact voor de authenticatiedienst. • 11. Een Authenticatiedienstverlener levert alleen een verklaring omtrent de vastgestelde UP van een persoon. Geen enkele Authenticatiedienstverlener levert informatie over de mogelijke bevoegdheden van deze persoon. 12. Er wordt vooralsnog geen onderscheid gemaakt in een authenticatieverzoek in het kader van 'inloggen' in een overheidsportaal en een authenticatieverzoek in het kadervan het ondertekenen van een transacties. Bijvoorbeeld bij het gebruik van DigiD wordt nu ook geen onderscheid gemaakt tussen deze twee functies. De wilsuiting (onderdeel van de ondertekening) is ingericht via een verklaring aan het slot van de aangifte (ik verklaar ... duidelijk, stellig en zonder voorbehoud...). 13. De overheid is verantwoordelijk voor een juiste en betrouwbare koppeling van het UP met het 135N van de betreffende persoon. De bank is verantwoordelijk voor een juiste en betrouwbare koppeling van het UP aan de bancaire administratie van de betreffende persoon. 14. Een gebruiker neemt zelf het initiatief om zijn ter beschikking gestelde private authenticatiemiddel (ban kmiddel) tevens te gebruiken voor overheidsdiensten via internet (in casu Belastingdienst-portaal). Om dit te realiseren zal de gebruiker voorwaarden moeten accepteren: - De Overheid (Belastingdienst) kan voorwaarden voor het gebruik van digitale diensten van de Overheid ter acceptatie aanbieden. - De Authenticatiedienstverlener kan voorwaarden ter acceptatie aanbieden.

15. Een Authenticatiedienstveriener heeft de bevoegdheid om een authenticatiemiddel van een individuele gebruiker buitenwerking te stellen. 16. Overwegingen bij misbruik van het authenticatierniddel bij gebruik in verkeer met de Belastingdienst: - De standaardvoorwaarden van de Nederlandse banken bevatten afdoende dekking voor het gebruik van de bancalre middelen, zoals het strikt persoonlijke gebruik, verplichting tot geheimhouding van het wachtwoord. - Eventueel misbruik komt volledig voor het risico van de Belastingdienst. De Belastingdienst heeft uiteindelijk via de Awr mogelijkheden om onjuiste of frauduleuze aangiftes te corrigeren. - In de situatie waarin een rekeninghouder slachtoffer is geworden van identiteitsfraude (pias, in loggegevens etc.), dan worden blokkerende maatregelen genomen. 17. In het geval van het niet beschikbaar zijn van een authenticatiedienst, heeft de gebruiker aangaande diensten van de Be lastingdienst geen verhaalsrecht op de Authenticatiedienstverlener. Uitgangspunt hierbij is dat de Belastingdienst dit oplost in het licht van de bestuursrechtelijke relatie met de belastingplichtige (relevant is kader rond verzenden en ontvangen in de Awb en evt. specifieke regels in de Awr). 18. De authenticatiedienstverlening berust op een overeenkomst tussen Authenticatiedienstverlener en gebruiker (burger, ondernemer). In geval van een bank is dit de overeenkomst tussen bank en rekeninghouder, uitgewerkt in algemene voorwaarden voor internetbankieren. De gebruiker zal eenmalig moeten instemmen met het gebruik van de middelen voor andere doeleinden dan oorspronkelijk bedoeld en krijgt in dit kader wellicht aanvullende voorwaarden voorgelegd. 19. De werking van een regulier authenticatieverzoek is beschreven in bijlage 1.

Bijlage 1. Flow van een authentkatieverzoek

USECASE 1: Een dienstafnemer gebruikt zijn bankmiddel voor identificatie bij de Belasting dienst Dienstafnemer

Belasfingdienst

Herkenningsmakelaar

Authenticatiedienst Bank

Gebruiker bezoekt de site van de Belastingdienst De BD toont de website Selectie van een ondexwerp waarbij identificatie nodig Is

De BD stuurt het D verzoek door naar de makelaar De makelaar toont de beschikbare middelen

1 De gebruiker selecteert °Bank

Vastlegging tbv afrekening en doorsturen naar Bank

Gewenste minimale Stork-niveau

De gebruiker gebruikt het Bankmiddel

De gebruiker ontvangt de gevraagde dienst

Op basis Aulhaesultaat levert de BD de gevraagde dienst

Doorgeleiding van Auth.resultaat naar de BD

UP

De Bank presenteert het identificatie menu

De Bank verwerkt authenticatie

Document 21

Interface specitcations AD-KR 1.9 This page describes the Inteface between en Authenficatiedienst (AD) and BSN koppelregister (KR), used to (de-)provision a nem AD-KR sequence cifagrams ... . . Aal hprarillkvSears1 2,

E

ESMK;ppelrrgifirt irr_z

1:AssocfacelISNRequest

I p

1 Assor lareRSNRespriwie •

•g,

utheinittnikdieng

il

II5N Koppefreggier

1:DeassociareaSNRequest IOcassodaece5NRtiotnse

To allow the use of the social security number (BSN), AD's can register the pseudonyms they've allocated to ussr to be (de)associated at the BSN Koppeiregister. After association, a user can be authenticated for services requiring the BSN via the BSN Koppeiregister, see Interface specifications HM-MR 1.9. The interface descdbed in this document is used to impiement the use case °AUC6 Registreren BSN' (register BSN) and MUST be implemented by every AD that services the domein Web service The interface for (de-)associating a user differs from the general specifications. No SAML Is used here, only a web service is used in thls interface specitication. Non-SAML requirements from the generaf specifications (eg, Secure connection) apply, unless specified otherwise. In the interface described here, the use case AUC6 Registreren BSN therefor consists of an eHarkenning-specific web service using a AssociateBSNRequest and AssociateBSNResponse (and DeassociateBSNRequest en DeassociateBSNResponse for deregistration). The BSN Koppelregister MUST expose one web service containing these two operations and MUST publish the corresponding WSDL document: r--

I WSDL BSN-koppelregister associate

Expand

source <wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soalcr xmlns:bsnkr=hurn:etoegang:1.9:bsn-koppelregister" xmlns:wsdl="http://schemas.xmlsoap.org/wsdlr' xmlns:xsd=nhttp://www.w3.org/2001/XMLSchema " name="BSNKR Association" targetNamespace=urn:etoegang:1.9:bsn-koppelregisteru> I i

-

<wsdl:types> <xsd:schese targetNamespace=d urn:etoegang:1.9:bsn-koppelregister" attributeFormDeault=?unqualifiedd elementFormDefault=ngualifiedu> <xsd:element name="AssociateBSNRegnest" tyne="bsnkr:AssociateBSNRegueetTypeu> I 1 <xsd:annotation> <xed:documentation>Request message to associate a BSN

(Dutch social security number) to a specific pseudonym, for future use via the BSN attribute queries. The 'BSN Noppelregister will associate the provided specific pseudonym with the subjects BSN after checking the authoritative sources (GBA, applicable document registry). <xsd:complexType name="AssociateBSNRequestTypen> <xsd:complexoontent> <xsd:extension base="benkr:BSNAssocationRequestBasetype"› <xsd:sequence> <xsd:element name="SpecificPseudonym" type="bsnkr:PseudonymType" 1> <xsd:element name="BSN" type="lenkr:BSNType" 1> <xsd:element name="DocumentType" type="bsnkr:DocumentTypeType" minOccurs="0" 1> • <xSd:element name="DocumentID" type="benkr:DocumentIDType" minOccurs="0" />. <xsd:element name="GivenNames" type="bsnkr:GivenNamesType" minOccurs="0" /> <xsd:element name="SurName" type="bsnkr:surNameType" minOccurs="0" /> <xsd:element name="DateOfBirth" type="bsnkr:BirthDateType" minOccurs="0" /> <xsd:element name="PlaceOfBirth" type="bsnkr:PlaceOfBirthType" minOccurs="0" /> <7xsd:complexContent> <xsd:complexType name="BSNAssocationPequestBasetype" abstract="truen> <xsd:sequence> <xsd:element name="SpecificPseudonym" type="bsnkr:PseudonymType"

t> <xsd:attribute name="DateTime" type="xsd:dateTime" use="required" 1> <xsd:simpleType name"PseudonymTypeo> <xsd:restriction base="xsd:string"> <xsd:length value="255" /> <xsd:simpleType name="BSNType"> <xsd:annotation> <xsd:documentation>In case a BSN consists of a number of oply.8 digits, the BSN shall be padded with a preceding '0' (digit zero). <xsd:restriction base="xsd:string"› <xsd:length value="9" /> <xsd:simpleType name="DocumentIDTypeg> <xsd:annotation> <xsd:documentation>Document ID as appearing on the Identity Document referenced

• <xsd:restriction base="xsd:string"> • <xsd:length value="15" 1> <xsd:simp1eType name='DocumentTypeType> <xsd:annotation> <xsd:documentation>Type of Identity Document referenced. <xsd:restriction base="xsd:string"> <xsd:enumeration value="NL-Paspoort" /> <xsd:enumeration value="NL-Identiteitskaart" 1> <xsd:enumeration value="NL-Rijbewijs" 1> <xsd:simpleType name="GivenNamesType> <xsd:annotation> <xsd:documentation>Given names as these appear on the Identity Document referenced. If given names are not fully known than must contain all known initials. <xsd:restriction base="xsd:string"> <xsd:length value="200"> <xsd:simpleType name="SurNameTypen> <xsd:annotation> <xsd:documentation>Surname as appears on the Identity Document referenced. <xsd:restriction base="xsd:string"› <xsddength value="210°> <xsd:simpleType name="BirthDateTypep> <xsd:union> <xsd:simp1eType> <xsd:restriction base="xsd:date" 1> <xsd:simpleType > <xsd:restriction base="xsd:gYearMonth" <xsd:simp1eType > <xsd:restriction base="xsd:gYear" 1> <xsd:simpleType name="PlaceOfBirthType"> <xsd:annotation> <xsd:documentation>For Dutch places of birth this value must correSpond to the exact value as 1isted in table 33 of the logic design of the BRP. MUST NOT be used for foreign places of birth.

<xsd:restriction base="xsd:stringp> <xsd:length va1ue="40"> <xsd:element name="AssociateBSNResponse" r type="bsnkr:AssociateBSNResponseTypen> <xsd:annotation> <xsd:documentation> Response to a AssociateBSNRequest. <xsd:complexType name="AssociateBSNResponseTyPe"> <xsd:seguence> <xsd:element name="AssociationConfirmation" type="bsnkr:AssociationConfirmationType" 1> <xsd:attribute name="DateTime" type="xsd:dateTime" use="required" /> <xsd:simpleType name="AssociationConfirmationType"> <xsd:restriction base="xsd:string"› <xsd:length value="128" 1> <xsd:element name="AssociateBSNFault" type="bsnkr:AssociateBSNFaultTypen> <xsd:annotation> <xsd:docUmentation> Fault response to a AssociateBSNRequest. <xsd:complexType name="AssociateBSNFaultTypek> <xsd:sequence> <xsd:element name="FaultReasonk type="bsnkr:AssocationFaultReasonType" /> <xsd:element name="FahltDescription" type="bsnkr:FaultOescriptionType" maxOccurs="unbounded" />' <xsd-simpleType name=nAssocationFaultReasonTypen> <xsd:union memberTypes="bsnkr:FaultReasons bsnkr:AssociationFaultReasons" 1> <xsd:simffleType name="FaultReasonso> <xsd:restriction base="xSd:stringo> <xsd:enumeration value="NotFound"> <xsd:annotation> <xsd:documentation>Provided information resuits in zero matches. <xsd:enumeration value="AuthenticationErrorn> <xsd:annotation> <xsd:documentation>Signature invalid. <xsd:enumeration value="SyntaxErrorn>

L

<xsd:annotation>. <xsd:documentation>Request invalid. <xsd:simpleType name="AssociationFaultReasons"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="NotEnougInfon> <xsd:annotation> <xsd:documentation>Provided information may resolve to a unique match, but not enough assurance (e.g. against typos) can be established. . <xsd:enumeration value="NotUniqueb> <xsd:annotation> <xsd:documentation>provided information results in more than one match. <xsd:enumeration value="DocumentRejected"› <xsd:annotation> <xsd:documentation>Document not accepted. <xsd:enumeration value="AssociationRefused"› <xsd:annotation> <xsd:documentation>Association refused for other non-disclosed reason (e.g. already associated). <xsd:complexType name="FaultDescriptionTypen> <xsd:simpleContent> <xsd:extension base="xsd:string"› <xsd:attribute name="lang" type="xsd:language" /> <xsd:element name="DeassociateDSNRequest"> <xsd:annotation> <xsd:documentation>Request massage to de-associate a previously associated epecific pseudonym. <xsd:complexType name="DeassociateBSNRequestTypen> <xsd:complexContent> <xsd:extension base="bsnkr:BSNAssocationRequestBasetype"> <xsd:sequence> <xsd:element name="AssocationConfirmation" type="bsnkr:AssociationConfirmationType" />

<xsd:element name="DeassociatenSNResponse"> <xsd:annotation> <xsd:documentation>Response to a de-associate request. <xsd:complexType name="DeassociateBSNResponseType"> <xsd:sequence> <xsd:element name'DeassociationConfirmation" type="bsnkr:AssociationConfirmationType" />. <xsd:attribute name="DateTime" type="xsd:dateTime" use="required" /> <xsd:element name="DeassociatesSNFault type="bsnkr:DeassociatensNFaultType"/> <xsd:complexType name="DeassociateBSNraultType">. <xsd:sequence> <xsd:element name="FaultReasOn" type="bsnkr:DeassociationFaultReasons" 1> <xsd:element name="FaultDescription" type="bsnkr:FaultDescriptionType" maxOccurs="unbounded" /> <xsd:simpleType name="DeassocationFaultReasonTypen> <xsd:union memberTypes="bsnkr:FaultReasons bsnkr:DeassociationFaultReasons" 1> • <xsd:simpleType name="DeassociationFaultReasons"> <xsd:restriction base="xsd:string"› <xsd:enumeration value="AssociationAlreadyDeassociated", '<xsd:annotation> <xsd:documentation>The assOciation reqUested to be de-associated was already de-associated. <xsd:enumeration value="DeassociationRefused"> <xsd:annotation> <xsd:documentation>De-association refused for other non-disclosed reason (e.g. incorrect association confirmation). <wsdl:message name="BSNXR_AssociateBSNRoquest"). <wsdl:part name="in" element ="bsnkr:AssociateBSNRequest" 1> <wsdl:nessage name="BSNER AssociateRSNResponse", <wsdl:part name="out" element="bsnkr:AssociateBSNResponse" 1>

<wsdl:message name="BSNKR AssociateBSNFault", <wsdl:part name="fault" element="bsnkr:AssociateBSNFault" <wsdl:message name="BSNKR_DeassociateBSNRequest"› <wsdl:part name="in" eleMent="bsnkr:DeassociateBSNRequest" /> <wsdl:message name="BSNKR_DeassociateBSNResponse"› <wsdl:part name="out" element="bsnkr:DeassociateBSNResponse" /> <wsd1:message name="BSNKR_DeassociateBSNFaultp> <wsdl:part name="fault" e1ement="bsnkr:DeassociateBSNFau1t" 1> <wsdl:portType name="BSNKR_Association Fort"). <wsd1:operation name="BSNKR AssociateBSN;1> <wsdlyinput message="bsnkr:BéNKR AssociateBSNRequest" />, <wsd1:output message="bsnkr:BSNKR AssociateBSNResponse" 1> <wsdl:fault message="bsnkr:BSNKR AssociateBSNFault" name="BSNKR AssociateBSN_Fault"/> <wsd1:operation name="BSNKR DeassociateBSW> <wsdl:input message="bsnkr:BSNKR_DeassociateBSNRequest" /> <wsdl:output message="bsnkr:BSNKR_DeassociateBSNResponse" 1> <wsdl:fault message="bsnkr:BSNKR DeassociateBSNFault" name"BSNKR DeassociateBSN Fault"/> <wsdl:binding name="BSNKR_Association_SOAF" type="bsnkr:BSNKR Association Fort"> <soap:binding style="document" transport="http://schemas.2xmlsoap.org/soapflittp" 1> <wsdl:operation name="BSNKR AssociateBSN"> <soap:operation soapAction="urn:etoegang:1.9:bsn-koppelregister:Associate3SN" 1> <wsd1:input> <soap:body use="literal" 1> <wsdl:output> <soap:body use="literal" 1> <wsdl:fault name="BSNKR AssociateBSN Fault"> 1 <soap:fault name="BSNKR AssociateBSN Fault" use="literal" 1> <wsd1:operation name="BSNKR_DeassociateBSN"> <soap:oneration I soapAction="urn:etoegang:1.9:bsn-kopnelregister:DeassociateBsN" />. <wsdl:input> <soap:body use="literal" 1> <wsdl:output> <soap:body use="1iteral" 1> <wsdl:fault name="BSNKR DeasociateBSN_Fau1t"› I

<soap:fault name="BSNKR_DeassociateBSN_Fault" use="literal" /> <wsdl:service name="BSNKR Association_Service"> <wsdl:port binding="bsnkr:BSNKR Association SOAP" name="BSNKR Association"> <soap:address location="https://.../TODO/Association" />

j

Message level security The body of both request and response MUST be signed with a WS-Security header contaMing an XML Signature based on the PKIO cedificate. The WS-Securitysignature MUST include the KeyInto in the signature, as per WS-Security X.509 Cerifficate Token Protile 1.01 §3.3.3. The certificate referenced MUST be listed in the Metadata for participants in a KeyDescriptor of the AD marked for the use "signing" (or without use, the default includes signing). Both the certifiCate used for the WS-Security signature as welt as the certificate used for the US connectIon to the web servMe SHOULD contain an OIN matching the Entityl D of the requesting AD. al Note: For existing certificates without an OIN in their (PKTO-)cert this is accepted. At the next cedificate update a cediticate with the matching OIN MUST be used.

CharBeterSet As speciffed under General requirements, UW-8 MUST be used as character encoding. As character set for this interface, only values in the GBA-V (Teletex) character set MUST be used in the request attdbutes, as speciffed "Logisch Ontwerp GBA 3.r, §11.2.

Request Donsists of a registration request message in the SOAP body of the request message. • ElementAgeAttribute 0.:n DescrIptIon 0@tateTime

1

Time of issulng of the request.

<Speelt IcPseudonyrn> 1

The specific pseudonym Of the User.

cBSN>

1

Sector ID for Dutch cltizens. Text of g characters, in case a BSN consists of a number of Only 8 digits, the BSN Shell be padded with a preceding '0' (digit zero). As verification data at least DocumentID and ene or more other identity supporting elements (those other than DocumentType) MUST be provided.

0..1 Text max 20. Value represents the type of govemment issued document that was used. Possibte values are "NL-Paspoort", "NL-Identiteitskaart" and "NL-Rijbewijs". . . . . . • Text max 15. Value represents the loot government issued document that was used. MUST be present • together with .

cDocumentID> IvenNames>

<SurName>

0.1

Text max 200. Must contain all given names, if given names are not tukst known than MUST contain all known initials.

MUST be present together with cSurName>. An empty value can be used to specify the current subject bas not registered a given name in the BRP. • • 0..1 Text max 210. Surname including prefixes, as stated on the Identity Document. MUST be present together with .

0..1 Date of birth of the user. In XML-schema a choice between 'date', 'gYear' or rgYearMonth' formai. In case the specific day or month is unknown (also expressed as 1900-00-00 or 1900-03-00), the value MUST be expressed as a gYear or gYearMonth.

0..1

Text max 40. NB For Dutch places of btrth this value MUST correspond to the exact value as listed in table 33 of the logic . design of the BRP. MUST NOT be used for fareign places of birth.

N.B. Only providing the BSN is not deemed to identity a subject with suffience assurance, additional information must be provided for verlfication. In genera!: the more information is provided In the request, the more chance of a unique match with sufficlent assurance.

'

Example BSN assocfate request <soapenv:Envelope xmlns:bsnkr="urn:etoegang:1.9:bsn4koppelregister" xmins:soapenv="http://schemas.xmlsoap.org/scap/envelope/m xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:wsa="http://www.w3.org/2005/08/addressing"

Expand source

xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext1.0.xsd° xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility1.0.xsdn> <soapenv:Reader> <wsa:MessageID>uuid:8beca0d6-ddc4-11e4-a031-080027a35b78 <wsa:Action>urn:etoegang:1.9:bsn-koppelregister:AssociateBSN <wsa:To>https://.../TODO/AssociationOwsa:To> <wsa:Rep1yTo> <wsa:Address>http://www.w3.org/2005/08/addressing/anonymous <wsse:Security> ... ... ... CM=

0= ,C=NL

...634756977854956...

<soapenv:Body esu:1d="id-36C0693498ADABBB51142.5655705387144°>
>Expand

source

xmlns:wsse=u http://doce.oasis-open.org/wes/2004/01/oasis-200401-wss-wssecurity-secext -1.0.xed" xmlns:wsn=”http://docs.oasis-open.org/wss/2004/01/oasia-200401-wss-wesecurity-utility1.0.xsdo> <soapenv:Header> cwea:nessageT0>unid:18010020-ddoe-11e4-1oblf-080027a35b78 <wsa:Action>orn:etoegang:1.9:bsn-koppelregisterweassociateBSN <wea:To>https://.../TODO/Association <wsa:ReplyTo> <wsa:Address>http://www.w3.org/2005/08/addressing/anonynous <wsse:sedurity> : . ... <de:Reference URI= 1 #KI-B6C0693498ADAB3B511425657462019237W>

... ... in the SOAP body af the response message, containing a AssociationOOnftrmation. In case a response is received, the request resulted In a unique and Valid match and the pseudonym is assoclated with the WN. In case en error occurs a soAp &luit wilt be used. The SOAP faun will contain error codes as as described below, with one (or more) localized s. EfementMAttrIbute

0..n Descrrption

@DateTime

1

1

'The of issuing of the response. ' Confirmalion code of the request.

Example BSts1 assocfate response <7xMl version='1.0 encoding=1 UTF-8".2> <soapenviEnvelope xmlns:nsl="urn:etoegang:1.9:bsn-koppelregister" xmlnsgsoapenv="http://schemas.xmlsoap.org/soap/envelopeP xmlns:ds="http://www.w3.org/2000/09/xmldsigr xm1ns:wsa="http://www.w3.org/2005/08/addressing"

> Expand

souree

xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext1.0.xsd" xm1ns:wsn="http1//docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility1.0.xsdo> <soapenv:Header> <wsa:MessageID>uuid:206c0fb0-dddl-11e4-ab19-080027a35b76 <wsa:RelatesTo>uuid:6beca0d6-ddc4-11e4-a031-080027a35b78 <wsa:Action>urnietoegang:1.9:bsn-koppelregister:AssociatesSNOwsa:Action> <wsa:To>httP://www.w3.org/2005/08/addressing/anonymous <wsse:Security soapenvmustUnderstand="1"› cds:Reference 0RI=h#1d-349518723A"> ...
Algorithm="http://www.w3.org/2001/10/Kol-exc-cl4n#"/> <wsse:SecurityTokenReference> CN=

0= ..,C=NL

....5435438675574636.... <soapenv:Body wsuad=bId-349518723A"› <nsl:AssociateBSNResponse DateTioe="2015-03-06T16:28:25.433+01:00"> ! <nsl:AssociationConfirmation>c382bb42-ddca-11e4-ac18-080027a35b781Sibawn0I~KeKpp I zElOvGk7X1tx4x1plZvDeqfM=

• De-association response For de-assoolation en equivalent response massage dOeassociateBSNResponse> containtng a DeasSocialionConfinnat1011 Is used. ElementMAttrIbute

0..n DescrIption

tg•Datertme

1

. .

Time of tssuing of the response. Confirmation code of the request.

FaultReasons "The following response bodes are used to Indicate the status als response. ResponseCode • NotEnoughtnfo NotUnique NotFound DocumentRejected

DescriptIon Request rejected. Provided information may resolve to a unique match, bul not enough assuranoe (e.g. against typos) can be established. Request rejected. Provided information regulls In more than one match. . . Request rejected. Provided information results in zero matches. - Request rejected. Document not accepted.

AssoclatIonFiefused

Request rejected, Association refused for other non-dIsclosed reason (e.g. aiready associated).

AuthoilzattonError

Request rejected. Atrthentication Invalld or access denied. A HUP 403 status response MAY be gNen instead of a SOAP-fault with thls response.

SyntaxError

Request rejected. Request invaild.

TemporartiyUnavaltable Request could temporarily not be processed. A new request tor associallon MAY be send at a later moment by the requesting party.

Document 22

Interface specifications HM-AD 1.9 Sequence diagram HM-AD E enerkenrungsmakelaartai -'.

-Jac

j

Authentcatiedrenst

.fiwthnkequesr 2:RespanSe

1 This page desaibes the messages that are exchanged between an eHerkenningsmakelaar (HM) and an Authenticatiedienst (AD) (identity provider).in the interface descrlbed here, the use case OUDS Aantonen identiteit consists of an SAML 2.0 AtrthnRequest and Response. The specific content of these messages is described below. Delailed information about the value of fields can be found in Attribute elements. A column in a message description that starts with 'SMAL indicates that thls is the standard value. A value that starts with 'eHerkenning' indicates that the value is specific to eHerkenning.

[ AuthnRequest (1)1E Response (2) ] [Authenticat[on assertion ] [ LogoutRequest ]

AuthnRequest (1) @In

SAML: Unique message attribute

@Version '

SAML: Version of the SAML protocol. The value MUST be '2.0.

@Issuelnstant

SAML: Time at which the message was created.

ODestInation

SAML: URL of the AD on which the message Is offered. MUST match the HM's metadata

@Consent

eHerkenning: MUST NOT be included.

@ForceAuthn

The value 'truc indicates that an existing single sign-on session MUST NOT be used for the request In question. if the value is 'Mise' or empty or the specification is missing, the AD MAY use an e/cis-ling SSO session if one is open.

@IsPassIve

eHerkenning: MAY be included. if IsPassive is induded, the value MUST be 'Mise'.

@FrotocolBindIng

SAML: MUST NOT be included because ASsertionConsumerServicelndex is required in eHerkenning.

@AssertIonConsumerServiceindex ellerkenning: This attribute element indicates the URL to which the response must be sent. The value of AssertionConsumerServiceindex MUST match an index at the assertion consumer service in the HM's metadata @AssertionConsumerServiceLIRE

SAML: MUST NOT be included because AssertionConsumerServicelndex is required in eHerkenning.

@AttributeConsumingServicelndex eHerkenning: The value MUST be '4'. Indicates that it is about the interface described in this document. . . . . . . . . . . . .... @ProviderName eHerkenning: MUST match the OrganizationDisplayName of the DV in the Service catalog. . .. !mier eHerkenning: MUST contain the EntitylD of the HM. The ~lite& NameQualifier, SPNameQualifier. Formai and SPPro‘iderlD MUST NOT be included. Signature

eHerkénning: MUST contain the Digital sIgnature of the HM for the enveloping message.

ExtenslonS

eHerkenning: MUST contaln the attributes ServicelD and the corresponding ServiceUUID. If the DV queries additiona/ attributes (via an AttributeConsumingService as described in Interface specifications DV-HM 1.9 and the DV metadata for HM), they MUST be induded here by the HM. To this extent, one eHerkenning speeltje RequestedAttributes (see schema below) element MUST be included containIng the RequestedAttribute elements reflecting the DVs request. The requested attribute(s) MUST be dellned in the Atfiibeutcatalogus and MUST be declared as RequestedAttribute In the Service catalog entry for the requested service. An AD not able to provide these attributes MUST act as speciffed in the alternative use case described In Attributen niet leverbaar of niet toegestaan. Other XML attributes MUST NOT be included. Other elements MUST NOT be included.

Subject

eHerkenning: MUST NOT be included

NamelDPollcy


Condlttons


RequestedAutfinContext

eHerkenning: MAY contain an attribute Comparlsorgiminimumi and an element AuthnContextClassRef that contains the minimum Level of assurance required by the DV. When RequestedAuthnContext is included in the gem" then it must contaln a Level of assurance .(AuthnContextClassReh equal to or lower than the level of assurance included in the S ervice catalog for the requested service.

ScopIng


XML schema saml protocol extensions <xs:schema targetNamespace="urn:etoegang:1.9:samlp-extension" xmlns:xs="http://www.w3.org/2001/XMLSchemaP xmlns:md="urn:oasis:names:te:SAML:2.0:metadata" elementFormeefault="qualified" attributeFormDefault="unqualified">

Expand source

as: element name="RequestedAttributes"› <xs:complexType> cxs:sequence> <xs:element ref="md:RequestedAttribute" maxeccurs="unbounded"/> /xs:schema>

Example message

Expand source

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:prot000l" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:ds="http://www.w3.orq/2000/09/xmldsiO" xmlns:md="urn:oasis:names:tc:sAML:2.0:metadata" • xmlns:esp="urn:etoegang:1.9:samlp-extension" ID=h4b5af9ca-33ef-400f-9097-3g8abOc6e9071*. Destination="https://..." ForceAuthn="true" AssertionConsumerServiceIndex="1" AttributeConsumingServiceIndex="4" ProviderName="DV Name" IssueInstant="2015-04-10112:30:03Z" Version="2.0"> <samlassuer/>urn:etonang:RM:... urn:etoegang:DV- services:... <saml:Attribute Name="urn:etoeganpcore:Servicemip"› <saml:AttributeValue>bf8300ef-6c9d-443f-ac11-9df0a0a9d299 <esp:RequestedAttributes> <md:RequestedAttribute Name="urn:etonang:1.9:attribute:FirstName" j IsRequired="false" <samlp:RequestedAuthnContext Comparison="minimuM"> I <sam1:AuthnContextClassRef>urn:etoegansvcore:assurance-class:loa3
; 1

ClassRef>

Response (2) CID

SAML: Unique message characteristic.

elnResponsero SAML: Unique andbute of the AuthnRequest for which Ibis response message is the answer. @Version

• SAML: Version of the SAML protocol. The value MUST be 12.0'

eissuelnstant

SAML: Time at which the message was created.

ODestinatIon

SAML: UFIL of the HM on which the message is offered. MUST match the DVs metadata.

@Consent

eHerkenning: MUST NOT be Included.

Issuer

• eHerkenning: MUST contaln the EntitylD of the AO. The attributes Nameaualifier, SPNameaualifier, Format and SPProViderlD MUST NOT be included.

Signature

• eHerkenning: MUST contaln the Olgat signature of the AO for the enveloped message.

Extensions

efierkenning: MUST NOT be included

Status

eHerkenning: MUST be filled conform SAML 2.0 specs when the request is successfully processed. MUST be filled according to Error handling In case of an error or when the request was cancelled.

Assertien

eHerkenning: MUST conlain en assettfon about the authenticatfon (see the next Gestierd.

ExampleADResposne

Expand

<samlp:nesponse xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xm1ns:sam1='urn:oasis:names:tc:SAML:2.0:assertion" xmlnS:ds="http://www.w3.org/2000/09/xmldsig#' nestination="https://..." 1n="62619615-e452-47d3-a44b-93da245a76f9" inkesponseTo="4b5af9ca-33ef-400f-9c97-398ab0c8e9c7" IssueInstant="2015-04-/ST//:16:282° version="2.0"› <saml:Issuer>urn:etoegang:101... ... ... ... <samap:Status> <samlp:StatusCode Value="urn:oasis:na1nes:tc:SAML:2.0:status:Succeee"/> <saml:Assertion ID="f0ba7712-50e4-4d30-9bb5-e63071507de" IssueInstant="2015-04-10T21:16:282" Version:="2.0"› <saml:Issuer xmins:saml="urn:oasis:names:tc:SAMTA2.0:assertion">urn:etoegang:Ap:...

Note: the above example only provides the response. The response will be send via en Artifact binding.

Authentication assertion Assertion

@Version

SAML: Version of the SAML protocol. The value MUST be 2.0'

@ID

SAML: Unique reference to the assertion

Issuelnstant

SAML: Time at which the assertion was created

Issuer

eHerkenning: MUST contain the EntitylD of the AD.

Signature

The attributes NameOualiffer, SPNameQualifier, Format and SPProviderlD MUST NOT be included. . . . . . eHerkenning: MUST be included

Subject

eHerkenning: MUST contain a or an <EncryptedID> (see SAML encryption), depencling en the Inzetgebied (domein): • In case of "bedrijven (compantes): • the applicable identifier MUST be included as an <EncryptedID>. • In case of "burgers (citizensr: • a transient identifler MUST be incl uded as a : . • the applicable identifier to be included as an attribute 'ActingSubjectILY, see below. • In case of "consumenten (consumers)": • a translent identifier MUST be included as a : • the applicable identifier to be included as an attribute'ActingSubject101, see below. • In case of 'beroepsbeaetenaars (professionele)t t: • the applicable identifier MUST be lncluded as an <EncryptedID>. The applicable identifier: • In the case of representation: • MUST be an Interne' pseudonym of the user; • MUST be encrypted to the applicable MR for the user. • In the case of an acting citizen (G20, representation is not allowed: effectively, all services requesting a BSN for the EntityConcemed): • MUST be a Specific pseudonym of the ussr br the BSN koppelregister (KR). • MUST be encrypted using the public key In the certificate (marked for encryption usage, or the default if not marked for any usage) of the BSN koppelregister, as specified in the SAML metadata. • In case of a consumer enting without represenlation (620, effectively, all services not requesting a BSN and ussr selecting to act en its own behalf): • MUST be a Specific pseudonym of the user forthe Dlenstverlener (DV). • MUST be encrypted using the public key in the cerfificate (marked for encryption usage, or the default if not marked for any usage) of the Dienstverlener, as specified in the Service catalog. • In case of a professional without representation: • MUST be a Specific pseudonym of the user for the Dienstverlener (DV). • MUST be encrypted using the public key In the certificate (marked for encryption usage, or the default if not marked for any usage) of the Dienstverlener, as speciffed in the Service catalog.

• • Conditions

A SubjectConfirmalion element that meets the Web Browser SSO profile MUST be induded. Other SubjectConfirmallon or SubjectConfirmationData elements MUST NOT be included. eHerkenning: MUST be included. The attributes Not8efore and NotOnOrAfter MAY be included but should be ignored by the receiver. An Audience element in the AudlenceRestriction element that meets the Web Browser SSO profil° • MUST be included. Other audience elements MUST Include relevant naties: EntItylDs of the requesting DV and the MR/KR (if applicable) to whom the assertlon will be targelled. Other conditions MUST NOT be included.

Advice


AuthnStateMent

eHerkenning: The attribute Authnlnstant MUST contain the time of authentication. The AuthnContext element MUST contain an AuthnContextCrassRef element containing the level of assurance at which authentication took place and an AuthenticatingAuthority element containing the 01 N formai of the KvK number of the AD. In thecase of proxying, AuthenticatingAuthority element MUST be populated with a unique identifying athibute for the party that carried out the authentication. Other attributes and elements MUST NOT be included.

Optional Attribute-Statement

elierkenning: MUST be Included if StalusCode is 'Success'. MUST NOT be included otherwise. When this is included, the followIng requirements apply: • • • •

• • • • • •

Representation MUST be included. See Identificerende kenmerken. ServiceUUID MUST be lncluded. AuthorizationRegistrylD MAY te included. See EntitylD. ln the case of non-representation (meaning wittig by a einzen, consumer or a professional) exactly one attribute that klentifies the service consuMei MUST be included. The attribute MUST match one of the possible service consumer types 'that is allowed to use the service. • The attribute MUST have the Name 'um:eloegang:core:ActingSubjectID'. • The AttributeValue MUST be populated with a SAML arypted1D> (see SAML encryption) as value, containing the applicable identifier (see above under Subject). Additional attributes requesfed for which the user has granted consent MAY be included here only if the 5:talusCode is 'Success'. Addfttonal altributes MUST be induded as EncryptedAttribute whereby each encrypted attribute is' assIgned a unique Encrypted_DATAJD that is the same as the attribute name in the eHerkennIng attribute catalogue (e.g. urn:etoegang:1.9:attrIbute:FirsiName). The DV's service certificate that is included in the service cataloáue MUST be used for encryption. • in case.more than one certificate is listed for encryption for the recipient, the Attribute MUST be enen/Wed for each certiftcate. This MI result in multiple EncryptedKeys, see Encryption. A cipher value is included in the encrypted attribute. Thls cifitter Sue contains the encrypted value of the request attribute that is encrypted with the key of the DV in the service catalogue. Other AttdbuteStatement elements MUST NOT be included.

Example attribute after decryption

> Expand <saml:Attribute Neme="urn:eteegangattribute:FirstName" source xmlnsIsaml="urn:oasis:names:tc:SAMD:2.0:assertion" xmlns:attrext="urn:oasig:names:te:SAML:attributes:ext" xmlns:xs="http://www.w3.org/2001/xMLSehema" xmlns:xsi="http://www.w3.org/2001/xmSchema-instanee " attrext:OriginalIssuer="urneetoegang:1.9:attribute-sourceid:NLW/0" attrext:Lastmodified="2015-03-31T12:00:00Z"> <saml:Attributewalue xsi:type="xs:string"›...

Example AD Assertion representation

<saml:Assertion xmlns:saml="urn:oasis:names:te:SA24t:2.0:assertion" xmlns:xene="http://vmw.w3.org/2001/04/xmlener xmlns:ds="http://www:W3.org/2000/09/xmldsigr 10="f0ba7712-5004-4d30-8bb5-e63a771507de" IssueInstant="2015-04-10T11:16:28r Version="2.00> <sam/:/ssuer>urn:etoegang:AD:...

>

Expand

source

... ... .... :• <saml:Subject> <saml:RncrypedID> <xenc:SncryptedData Id=cd52e15a16e2a0aa751725ce76a619866" Type="http://www.w3.org/2001/04/xmlencijKlement"> <xenc:SperyptionMethod J Algorithm="http://www.w3.org/2001/04/xmlenckaes256-cbc" <xenc:CipherData> <xenc:CipherValue>... <xenc:EncryptedKey Id15531f77agfle0b5e0cce442aa3lbbd4" 1 Recipient="urn:etoegang:MR:..."> <xenc:EncryptionMethod nlgcrithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgflp"> cds:KeyInfo> ... <xenc:CipherData> <xenc:CipherValue>yRyg23W1gAl2MTgxlgohLiDBgi... <xenc:ReferenceList> . <xene:DataReference URI="C0d52e15a16e2a0aa7517250e76a6b866" 1> <jsamlancrypediD> <saml:SubjectConfirmation Methed="urn:oasis:names:tc:SAML:2.0:cm:bearer"› 1 <saml:SubjectConfirmationData InResponseTo="4b5afgea-33ef-400f-9c97-398ab0c8egc7" NotOnOrAfter="2015-04-10T11:18:28V Recipient="https://..." /> <saml:Conditions NotBefore="2015-04-10T11:16:282" NotOnOrAfter="2015-04-10T11:18:28S"› <sama:AudienceRestriction> <saml:Audience>urn:etoegang:HM:... <saml:Audience>urn:etoegang:MR:... <saml:Audience>urn:etoegang:DV:... .

1

<saml:AuthnStatement AuthnInstant="2015-04-10T11:16:282"› <saml:AuthnContext> <saml:AuthnContextClassRef>urn:etoegang:core:assurance-class:loa4 <saml:AuthenticatingAuthority>... <saml:AttributeStatement> <saml:Attribute Name="urn:etoegang:core:Representation"> <sami:AttributeValue>false <saml:Attribute Name="urn:etoegang:core:ServicenUID"› <saml:Attribute>bf83ccef-6c9d-443f-ac11-9df0a0a9d299 <saml:Attribute Name="urn:etoegang:core:ActingSubjectInu> <saml:AttributeValue> <saml:Encrypedln> <xenc:Encryptednata Id="_cd52e15a16e2a0aa751725ce76a6b666" Typen http://www.w3.org/2001/04/xmlenc#Elementu> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" /> <xenc:CipherData> <xenc:CipherValue>... <xenc:EncryptedKey Id="_15531277a9f1e0b5e0cce442aa3lbbd4' Recipient="urn:etoegang:MR:...m> <xenc:RnctyptionMethod Algorithm="http://www.w3.org/2001/04/xmlencilrsa-oaep-mgflpu>

!

Example AD Assertion - citizen domein <saml:Assertion xmlns:saml="urn:oasis:names:tc:3AML:2.0:assertion" xmlns:xenc="http://www.w3.org/2001/04/xmlenC#" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" ID="f0ba7712-50e4-4d30-8bb5-e63a771507de" IssueInstant="2015-04-10T11:16:28S" Version=1 r2.0"›

Expand source

<saml:Issuer>urn:etoegang:AD:... • ... ... ... <saml:Subject> <saml:NameID Format-iurn:oasis:names:tc:SAM*2 0-nameid-format:transient">d6730e65-500a-44e2-961e -ccaS3e7c60a4 <saml:SubjectConfirmation Method="urn:oasis:names:tc:S":2.0:cm:bearer"› <saml:SubjectConfirmationData InResponseTo="4b5af9ca-33ef-400f-9c97-398ab0c8e9c7" NotOnOrAfter="2015-04-10T11:18:28S" Recipient="https://..." /> <saml:Conditions Not3efore="2015-04-10T11:16:282" NotOnOrAftex="2015-04-10T11:18:282"› <sam1:AudienceRestriction> <saml:Audience>urn:etoegang:SM:... <sam1:Audience>urn:etoegang:KR:... <saml:Audience>urn:etoegang:DV:... <saml:AuthnStatement AuthnInstant="2015-04-10T11:16:28Z">

<saml:AuthnContext> <saml:AuthnContextClassRef>urn:etoegang:core:assurance-class:loa4 <saml:AuthenticatingAuthority>... <saml.AttributeStatement> <saml:Attribute Name="urn:etoegang:core:Representationn> <saml:AttributeValue>false <saml:Attribute Namermurn:etoegang:core:ServiceDDIDo> <saml:Attribute>bf63ccef-6c9d-443f-ac11-9df0a0a9d299 <saml:Attribute Name="urn:etoegang:core:ActingSubjectID"› <sam1:AttributeValue> <saml:EnCrypedID> <xenc:EncryptedData Id=0_cd52e15a16e2a0aa751725ce76a6b866" Type="http://www.w3.org/2001/04/xm1enc#E1ement"› <xenc:EncryptionMethod A1gorithm="http://www.w3.org/2001/04/xm1enc#aes256-cbc1 /> <xenc:CipherData> <xenc:CipherValue>... <xenc:EncryptedKey Id="_15631f77a9f1e0b5e000e442aa31bbd4" Recipient="urn:etoegang:KR:..."> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenciltrea-oaep-mgflp"› ... <xenc:CfpherData> <xenc:CipherValue>... <xenc:ReferenceList> <xenc:DataReference URI="Ccd52e15a16e2a0aa751725ce76a6b666" />

ExampleADAssertion-consumerdomaln <2xml version="1.0" encoding="UTF-8"7> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:xenc="http://www.w3.org/2001/04/xmlenct xmlns:ds="http://www.w3.org/2000/09/xmldsig#" ID="f0ba7712-50e4-4d30-8bb5-963a771507d& IssueInstant="2015-04-10T11:16:28Z" Version="2.0"›

Expand source

<samlassuer>urn:etoegang:AD:... ... ... ... <saml:Subject> <sam1:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">d6730e65-500a-44e2-961e -cca53e7c60a4 <saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <saml:SubjectConfirmationData InResponseTo="05af9ca-33ef-400f-9c97-398ab0c8e9c7" NotOnorAfter="2015-04-10T11:18:28Z" Recipient="https://..." 1> <saml:conditions NotRefore="2015-04-10T11:16:282" NotonorAfter="2015-04-10T11:18:28Z"> <saml:AudienceRestriction> <saml:Audience>urn:etoegang:SM:... <saml:Audience>urn:etoegang:DV:... . <saml:Authnstatement AuthnInstant="2015-04-10T11:16:282"› <saml:Authncontext>.

<saml:AuthnContextClassRef>urn:etoegang:core:assurance-class:loa4 <saml:AnthenticatingAuthority>... <saml:AttributeStatement> <saml:Attribute Name="urn:etoegang:core:Representationa> <saml:AttributeValue>false • <saml:Attribute Name="urn:etoegang:core:ServiceUUID"> <saml:Attribute>bf83ccef-6c9d-443f-ac11-9df0a0a9d299 <saml:Attribute Name="urn:etoegang:core:ActingSubjectilr> <saml:AttributeValue> <samlancrypediD> <xenc:EncryptedData 1d="_cd52e15a16e2a0aa751725ce76a6b866" Type="http://www.w3.org/2001/04/xmlenc#Element"› <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc" /> <xenc:CipherData> <xenc:CipherValue>... <xenc:EncryptedKey Id="_15531f77a9f1e0b5e000e442aa3lbbd4" Recipient="urn:etoegang:DV:..."> <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgflp"> ... <xenc:cipherData> <xenc:CipherValue>... <xenc:ReferenceList> <xenc:DataReference uRI="I cd52e15a16e2a0aa751725ce76a6b866" /> <saml:EncryptedAttribute> <xenc:EncryptedData Id="_copy Encrypted_FirstRame" Type="http://www.w3.org/2001/04/xmlenc0Element"› <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc4nes256-cbc" 1> ...

<xenc:CipherData> <xenc:CipherValue>... <saml:EncryptedAttribute> <xenc:EncryptedData Id="_copy_Encrypted_180rOlder" Type="http://www.w3.org/200//04/xmlenc#E1ement"› <xenc:EncryptionMethod Algorithm="http://www-w3.org/2001/04/xm1enc#aes256-cbc" 1> ... <xenc:CipherData> <xenc:CipherValue>...

Log outReq uest For single logout, the Single Logout Profile that ta part of the SAML 2.0 Web Browser SSO Profil° is applied on the understanding that the logout message is sent to the AD thtough the HM. The Interface for this message is described below. 9112 • @Version

SAML: Unique message attribute SAML: Version of the SAML protocol. The value MUST be '2.0'.

@issuefristant SAML: Time at which the message was created. • @Destination SAML: URL of the AD on which the message is offered. Na melte

eHerkenning: MUST contain a NamelD element, this MUST NOT contain the Internel pseudonym or Specific pseudonym of the user.

Issuer

eHerkenning: MUST confetti the EntitylD of the HM.

Signature .

eHerkenning: MUST contain the Digital signature of the HM for the enveloped message.

Document 23

Nota

Nederland

BankID Pilot kaders Belastingdienst Concept v0.3

15 mei 2015

Versie 0.3

Concept

Van

Telefoon

E-mail •

Betreft BankID Belastingdienst Pilot kaders Aan

Kopie aan

Inleiding De deelnemende banken en de Belastingdienst hebben samen een concept verklaring opgesteld die aangeeft welke afspraken er voor de Bankt D pilot gemaakt dienen te worden. In deze nota worden de kaders voor de pilot uiteengezet. Voor de langere termijn bestaat geen onlosmakelijke verbinding tussen SankID en de Belastingdienst, BankID vormt (bij landelijke implementatie) 1 van de authenticatiemiddelen • in Nederland. Doel van de pilot Het doel van de pilot is om een beheersbare start te maken met het product BanklD. De uitrol hiervan vindt in eerste aanleg plaats in samenwerking' met de Belastingdienst Centraal staat het authenticatle-

proces bij gebruik van het bankmiddel als e-authenticatiemiddel voor het verkrijgen van toegang (inloggen) tot diensten en persoonsgebonden informatie bij de Belastingdienét. De 'volgende doelstellingen zijn voor de pilot gedefinieerd:

Gezamenlijk 1. (functioneel) Aangetoonde werkende en relevante implementatie door de gehele keten; 2. (technisch) Aangetoonde performance bij gebruik op grote schaal 3. Aangetoonde werking koppeling BankID en BSN-K 4. Positieve, doelgerichte Samenwerking a. Constructieve aanpak b. Communicatie c. Probleem/crisis-management d. Testtraject/bevindingen/resultaat e. Proces-live brengen services 5. Vastgesteld gebruik en herhaalgebruik door end-user 6. Vastgestelde gebruikerservaring bij burgers, banken en Belastingdienst; 7. Ondersteuning multi-platform gebruik/meten gebruikservaring (mobile, smartphone/tablet, PC) 8. Informatie verzamelen voor het kunnen inschatten van de benodigde technische performance eisen alsmede de support inrichting; 9. Vaststellen in hoeverre het product voldoet aan de gestelde business reguirementsl. 1 Uitwerking In tater Stadium, kent gezamenlijke evenals organisatie-specifieke eisen

Nota

Nederland

>
Banklo-specifiek 1. Toetsing van positionering en merkwaarden. Z Toetsing van de crerealiseerde waarde voor De Belastingdienst en de bank; 3. Consistente ervaring bij gebruik icm diverse dienstaanbieders

Uitgangspunten Voor het opzetten van pilot zijn de volgende kern uitgangspunten gedefinieerd: Deze verder invullen -

Pilot moet beheersbaar zijn; —> Doelgroep ter grootte enkele 10-duizenden. Pilotfase loopt parallel met pilot-plateau elft er bestaat een afhankelijkheid van de makelaar &D en het BSN-koppelregister en daarmee van de start van het plateau (niet van andere Pilots) Pilot moet controleerbaar zijn; --> tussen elke fase Go/No-go moment„ monitoringsinfo beschikbaar en gedeeld. Resultaten Pilot moeten meetbaar zijn; —> user interactie, ktv, aantallen, response-tijden, foutsituaties en type foutmeldingen, vooraf criteria vaststellen, passend bij karakter pilot. Pilot zal maximaal 6 maanden duren met eind evaluatie mei/juni 2016;--> Verdere uitrol en opschaling bankenpilot is net als elD onderhevig aan politieke besluitvorming. Na afronding van de pilot zal Go/No-go beslissing worden genomen voor de introductie. Dit geldt ook tussen iedere pilot-fase --> Go/no-go in vooraf bepaalde g remia. De koppeling van een BankID-middel aan het BSN (in BSNK) wordt direct bij activering gerealiseerd door de authenticatiedienst. De burger zelf doorloopt hiervoor geen eigen activeringsproces.

Deze uitijangs punten zijn uitgewerkt en hebben tot de volgende verfijning geleid: De pilot bestaat uit 3 fases: 1. Een 'friends & family' pilot met een beperkte groep van burgers, zijnde medewerkers cq familie van. Hier keuze: worden in deze fase BD-diensten ontsloten of 'slechts' een mock-up icm authenticatie-flow? Bepalend voor duur fase: enkele weken bij mock-up, eventueel janger bij feitelijke diensten; 2. Een bredere groep van burgers (pilotdoelgroep, bovenop F&F populatie, met een beperkte set diensten bij de Belastingdienst; --> huidige focus ligt op het burgerportal inclusief beschikbare diensten (Geen Toeslagen, geen ondernemers-diensten) 3. Grootschalige groep van burgers Voor de pilot bestaat de doelgroep aan issuingzijde (de burgers) uit: • Natuurlijke personen; • Met eigen authenticatiemiddelen (bestaand middel, door bank uitgereikt aan natuurlijk persoon); • Die VVwft-compliant zijn geadministreerd. De uiteindelijke omvang van de pilot qua aantal burgers en beschikbare online diensten bij de Belastingdienst waar BankiD kan worden gebruikt wordt beperkt zodat het product na een onsuccesvolle pilot zonder reputatieschade van de markt gehaald kan worden. Hierbij worden de volgende uitgangspunten gehanteerd: -

Maximale omvang doelgroep wordt verdeeld over de verschillende banken;

Nota

Nederland

>
De doelgroepomvang, verhouding en mate van overtap met de pilot-doelgroep elD wordt nader bepaald in een gezamenlijke workshop. Binnen dit proces wordt ook uitgewerkt hoe de beoogde doelgroep wordt geselecteerd, welke organisatie deze doelgroep benadert en hoe de doelgroep gestimuleerd gaat warden BankID voor authenticatie bij de Belastingdienst te gebruiken. Beperking van de pilot-doelgroep kan door het aantal uitgegeven middelen te maximeren, of door-het gebruik bij de makelaar of dienstaanbieders te monitoren en bij een drempelwaarde de toegang onmogelijk te maken. Vast staat dat de BankID doelgroep beperkt is: x-duizend burgers in bezit van een bank-,middel van 1 vd banken 'krijgen' een Bankt!). Alleen dié groep kan in de pilotfase het bankmiddel als BankID gebruiken, bij zowel private als publieke diensten. De Belastingdienst start met het bieden van BankID in mijnbelastingdienstnl, dit zal vaar de pilot de scope zijn. Andere portalen volgen niet eerder dan na pilot-plateau elD. Opschalen doelgroep is wel denkbaar

-

Nog uit te werken -

BankID moet voldoen aan de conforrnancetest van het elD Stelsel: Makelaar moet voldoen aan het aansluiten op BankID infrastructuur: idem, inclusief afstemming marktpartij over samenwerking Belastingdienst moet voldoen aan aansluitvoorwaarden van de Makelaar: uitwerken planning en stappen (gebeurt in pilot-plateau)

-

In en buiten scope Pilot In scope: Werkpakketten -

Voorbereiden en uitvoeren Pilot voor BankiD; Vaststellen te behalen acceptatiecriteria; Marketing/branding/communicatie pilot; Formuleren eisen dienstverlening/support; Voorbereiden en inrichten dienstverlening/support; Analyseren en adviseren omtrent niet behaalde acceptatiecriteria; Aanpassen pilot plan en test scenario's indien nodig; Performance analyse; "Verhoogde dijk"-bewaking tijdens live-gaan van een bank en dienst bij De Belastingdienst; Inrichting en beheren van de Pilot Support Desk; Rapporteren omtrent bevindingen Support Desk; Uitvoeren evaluatieonderzoek/opstellen evaluatierapportage Zorgdragen dat marktonderzoek en gebruikersonderzoek worden uitgevoerd; Zorgdragen dat burgers die onderdeel zijn van de Pilot in BSN-koppelregister toegevoegd zijn of hiertoe zelf actie kunnen ondernemen;

Fasen/besluitvorming

-

Besluitvorming over start, tijdlijn en positionering pilot; Faciliteren besluitvorming per fase en Go/No go (rapporteren, escaleren, plan bijstellen etc); Implementatie pilot; Besluitvorming Go-live pitotEvaluatie van Pilot BankID per fase; Adviseren omtrent Go/No-go marktintroductie na afloop pilotfase

Buiten scope:

Nota

Nederland

>
- • Inrichting en beheren van een eerstelijns Support Desk voor burgers en de Belastingdienst dit is de verantwoordelijkheid van de desbetreffende banken en de Belastingdienst; Doorvoeren aanpassingen in technische en business architectuur/oplossing: de Pilot Werkgroep communiceert bevindingen naar de Business en Technische Werkgroep; Marktintroductie (na pilot-fase);

Afhankelijkheden • • • • • • • • • • • • •

Bestuurlijke instemming betrokken partijen Pre-self-assessment van pilot partijen is uitgevoerd, inclusief vaststelling dat data-kwaliteit van de pilot norm is behaald; Deelnemende partijen hebben hun oplossingen geïmplementeerd; Refereert ook aan beschikbaarheid resources elD implementeert tijdig en werkend het BSN-koppelregister; Normenkader elD helder, match bankmiddelen geverifieerd Formaatconversie tussen Bankld en BSN-domein; Naam en beeldmerk gereed; Merknaam geregistreerd Vastgestelde business requirements, acceptatiecriteda en prioriteitsstelling; Vastgestelde Use cases; Vastgestelde attributen en Level of Assurances; Oplossing voldoet aan eisen die vanuit risico, juridisch en vanuit privacy perspectief zijn gesteld. (elD eisen voor toetreding & RIA?)


Nota

Succescriteria Onderstaande succescriteria zijn gedefinieerd aan de hand van de doelstellingen. De resultaten van de metingen van deze succescitteria zullen bepatend zijn voor het al dan niet slagen van de pilot — de meah gespecificeerd. iten2

1

2.

3.

4.

Aantonen van een werkende en relevante implementatie door de gehele keten.

Vastgestelde gebruikerservaring bij burgers, de banken en de Belastingdienst;

Toetsing van positionering en rnerkwaardeit vertrouwen, veiligheid, gemak-, Toetsing van de gerealiseerde waarde voor, de bank en de productkenmerken

Pasilna 5 van 9

RaPPOrtage betreffende de uitkomsten van de pilot waarin wordt omschreven wat de bevindingen zijn aan de hand van: •

Antiaarden • •

•

de business regulrernents en de gestelde acceptatiecriterla; • Issue-lijst indusief Severity; • Aantallen succesvolle transacties . (ingelogd, gevraagde data gelevenl); • Beschlkbearhelds indicator;

• •

Uitgevoerd onderzoek bij zowel consumenten, banken en De Belastingdienst riet inzicht in: •

• • % burgers dat de merkwaarden en • merknaam herkent en het gebruik van BankID aanbeveelt aan anderen.

Uitgevoerd onderzoek bij zowel burgers: •

indicatie per acceptatieciiteria of c is behaald inclusief bewijs; Inzicht in issuelijst en st openstaande issues — voor eventi openstaande issues bestaat een i van aanpak hoe hier mee om te ga Aantallen succesvolle transacties; Percentage beschikbaarheid Bankt

Net Promotor Score (NPS); Customer Effort Score (CES)

NTB

NTB

Vaststellen of de juiste attributen ter beschikking worden gesteld;

NTB

<15 mei 20151

Nota

>
5.

6.

Informatie verzamelen voor het schatten van de benodigde technische performance eisen alsmede deeuppbrt inrichting; Vaststellen in hoeverre het product voldoet aan de business requirements en voor de business requirements waaraan niet wordt voldaan een impact analvse

Pagina 6 van 9

Eindrapportage omtrent de non-functional . performance testing en de aanbevelingen met betrekking tot de support inrichtig n.a.v. ervaringen tijdens de pilot;

Eindrapportage betreffende de wijze waarop is voldaan aan de gestelde business requirements en acceptatiecriteria. inclusief analyse en aanbevelingen omtrent de elementen die niet zijn behaald;

.

<15 mei 2015 1
Nota

r; Nederland

Fasering

BankiD pilot met Merchants BankID pilot Belastingdienst

BankID pilots met verschillende fasering en tijdslijnen

In onderstaande tabel wordt schematisch weergegeven hoe de pilot wordt opgedeeld en wat de belangrijkste activiteiten zijn.

- -inrichten plbitesm - Bevestigen piot deeinenners - PMcontract gezekerd - Plaming - Afgestemde Business requirmanisr accaptetrecriterie • Afgestemde scenario's • Commemicatieptan - Eindrapport

- Inrichten potteam - Bevestigen pilot deelnemers - Plicit contract getekend - Kinriem - Afgestemde Business requkrnenbt ecc eptailecrifeda - Afgestemde scenario's Communicatiaphin Eindrapport

- Klok-aft - Monitoren voortgang • Opstellen Ingelijst - Monitoren doonfoeren wizigingen - Valideren *gingen - Eind. rapportage

- Kick-off - Monitoren ~gang - °Patelen issunifst - Monitoren doorvoeren wijzigingen Vederen wiziEingen Eind • rappcitage

'
- Kick-off • MonitCren votrigang • Opdelen beverist - Monitoren doorvoeren *lokalen • Valideren wijzigbgen

andraPPoriage

rapportage

- Kick-off Monitoren voortgang - OpmSnn issuerijst - Monitoren doorvoeren wijzigingen - Vederen wigingen

- Evanelln gebruik). en marktonderzoek - Rapportage perfermancenst en infirlebg Barieerotgenisstie %Marktte acceptakeriterki Eind-rapportage van gehete pilot

- Evaluatie: gebruks- en marktonderzoek • Rapportage perronnenee.teet en Inrichfing Beheerorgensatie - Rapportage acceptaffecritarle

- Eind-rapportage

- Eind-rapportage van gehele piot

Na elke fase in de Pilot wordt een Go/No-go meeting georganiseerd. Hierin presenteert de Project Pilot Werkgroep een verslag van de desbetreffende fase en het voorstel om al dan niet door te gaan naar de volgende fase. Daarnaast kent iedere fase-overgang Go/No Go besluitvorming. Dit vindt binnen ketenpartijen plaats In bestuudijke gremla en gezamenlijk in een ronde tafel (In te richten pilot-sturing). De zwaarte van besluiten kan variëren afhankelijk van de face-overgang.

Pre-pilot Tijdens de pre-pilot fase worden de randvoorwaardelijkheden omtrent de daadwerkelijke pilot georganiseerd: Inrichten pilot team en pilot werkgroepen Bevestiging pilot deelnemers: pilot contract getekend voor AcquirIng en Issuing banken, De Belastingdienst en burgers. Afgestemde Pilot Planning met deelnemers per fase Afgestemde Business requIrements & acceptatiecriterta per fase Afgestemde scenario's: per fase Inclusief rol van verschillende deelnemers: Eindrapport Pre-pilot met een Go/No-go meeting betreffende de start van de Pilot.

Nota

Nederland

>
Friends & Family Na het bouwen en testen van het product wordt een pilot gestart in een beperkte omvang. Deze pilot wordt gehouden onder %nets & family. Het betreft wel een pilot in productie met echte klantdata. Doelgroep aan de issuingzijde zijn collega's bij BVN, de banken en de Belastingdienst. Doel is het optimaliseren van de technische en klantprocessen en het evalueren van de eerste indrukken voordat de pilot breder in de markt wordt gestart. Door de Project Pilot Werkgroep wordt de voortgang van de pilot gemanaged en gemeten. Tijdens de pilot worden eventuele issues gemonitorcl, geanalyseerd en doorgeleid naar de Technische en Business werkgroepen. Indien nodig worden eventuele doorgevoerde wijzigingen opnieuw gevalideerd door de pilot deelnemers. Tijdens het "Live" gaan van nieuwe banken en diensten vanuit de Belastingdienst vindt er verhoogde dijkbewaking plaats vanuit de Project Pilot Werkgroep.

Pilot Groep 1 en Pilot Groep 2 De tweede en derde stap in de pilot zijn een uitgebreidere pilot met een toenemende groep van burgers en diensten bij De Belastingdienst. Doel is te leren van de reacties — zowel bij de Belastingdienst als de burgers — en waar nodig en mogelijk het product te verbeteren voor de bredere marktintroductie,

Evaluatie Aan het einde van de gehele pilot wordt deze geëvalueerd aan de hand van de hand van de omschreven succescriteria:

-

Evaluatie gebruiksonderzoek; Evaluatie marktonderzoek; Rapportage omtrent bevindingen bad-test en Inrichting Beheerorganisatie; Rapportage a.d.h.v. acceptatiecriteria; Acceptabel businessmodel voor alle partijen.

Dit resulteert in een Eind-rapportage inclusief een advies omtrent een Go/No go voor de marktintroductie. De volgende elementen worden in deze fase opgeleverd: Evaluatie gebruiksonderzoek - Evaluatie-marktonderzoek Rapportage omtrent bevindingen load-test en Inrichting Beheerorganisatie Rapportage a.d.h.v. acceptatiecriteria Eind-rapportage van gehele pilot Milestones • Besluitvorming ronde tafel • Start pre-pilotfase • Selecteren makelaar door de Belastingdienst • Bouwen oplossing • Deployen voorzieningen en '
Nota >
• • • • • •

Live brengen makelaar icm BSNK Live-brengen BankID icm makelaar Ketentest Go/No-go F&F fase Uitrol BankIDT&F fase Go/No-Go

Nader uit te werken.

Nederland

Datum 1 3 JAN Betreft verzoek medewerking onderzoek gebruik autencicatiemiddelen van banken

Recommend Documents