Expertgroep Digitale Identificatie en authenticatie/2019-09-03: verschil tussen versies

Uit NORA Online
Naar navigatie springen Naar zoeken springen
(links toegevoegd)
k (afbeelding van left naar none)
 
(26 tussenliggende versies door 3 gebruikers niet weergegeven)
Regel 5: Regel 5:
|Datum=2019-09-03
|Datum=2019-09-03
|Tijd=14-17u
|Tijd=14-17u
|Locatie=Gemeente Den Haag
|Locatie=Stadsdeelkantoor Laak (achter station Hollands Spoor), Slachthuisplein 25, 2521 EC Den Haag, Vergaderzaal LA 00.37
|Publicatiedatum=
|Publicatiedatum=
|Nieuws=nee
|Nieuws=nee
|Beschrijving=Onderwerp: [[Bevoegdhedenbeheer]] c.q. autorisatiemanagement. <br>
Kees Jan Kolb van het Erasmus MC zal ervaringen delen over hoe je kunt omgaan met ABAC in relatie tot de bestaande implementaties van RBAC.
Mogelijk kunnen we dan ook al de 1e resultaten bespreken van de uitwerking van Authenticatie van natuurlijke personen i.r.t. de BRP.
}}
}}


==Voorstel Authenticatie van natuurlijke personen irt BRP==
===Hoe verloopt de authenticatie van een digitale identiteit van de BRP: qua proces en qua techniek?===
Er is geen eenduidig proces voor de authenticatie (verificatie) van een door RvIG uitgegeven digitale identiteit. De authenticatie vindt in de praktijk decentraal plaats en is ook afhankelijk van het middel dat daarbij wordt gebuikt. Authenticatie wordt doorgaans mogelijk gemaakt via herbruikbare bouwstenen of via diensten. Zo zijn er bijvoorbeeld diensten als DigiD, eHerkenning, Toegangsverleningsservice (TVS), die een autorisatie hebben op de BRP ihkv verificatie (authenticatie).


Middels de identity providers worden dienstverleners wel voor een deel ontzorgd. Specifiek toegang tot de authenticatiemiddelen (chip op paspoort, eNIK e.d.) hebben maar een paar partijen. Verificatie van de attributen op de chip(s) gebeurt via autorisaties. Vaak zijn die authenticatiemiddelen technisch gestandaardiseerd (bij DigiD bijvoorbeeld gebaseerd SAML).


Door standaardisatie op Informatie-/Applicatielaag wordt gestimuleerd de authenticaties te uniformeren. Vanuit deeloplossingen (rijbewijs, PKIO, Zorgpas, overheidspas, etc) treed ook enige standaardisatie op. Er is echter nog geen eenduidige architectuur voor de overheid waarin deze authenticatie is uitgewerkt.
Door VNG-Realisatie is het volgende overzicht opgesteld waarbij de verschillende koppelvlakken in beeld zijn gebracht inclusief de status van dat koppelvlak.


[[Afbeelding:Overzicht koppelvlakken presentatie Authenticatie van natuurlijke personen irt BRP.png|thumb|left|350px|Overzicht koppelvlakken|alt="Overzicht verschillende koppelvlakken inclusief de status van dat koppelvlak"]]
==Verslag==
Het was wederom een informatieve (en lange 😊) bijeenkomst.
Ditmaal bij de gemeente Den Haag, waar we zo’n anderhalf jaar geleden een van de eerste bijeenkomsten hielden met de expertgroep IAM.
Bijgaand is op hoofdlijnen aangegeven wat we met elkaar hebben besproken en afgesproken.
 
 
==Actiepunten==
We hebben de actiepunten van de bijeenkomst van 24 juli doorgenomen, zie het verslag [[Expertgroep Digitale Identificatie en authenticatie/2019-07-24]]
Er waren nog 2 openstaande actiepunten en die zijn inmiddels opgepakt:
* NORA Beheer is bij GEMMA Beheer nagegaan of, en zo ja hoe ArchiMate modellen opgenomen kunnen worden bij de processen van Identiteitenbeheer. Het lijkt er op dat in de GEMMA geen specifieke processen zijn beschreven voor het identiteitenbeheer. De GEMMA heeft wel meer algemene processen (typeringen), waar zo’n proces van Identiteitenbeheer onder zou kunnen vallen.
''': → ACTIE: Afgesproken is e.e.a. nog met elkaar te gaan bespreken. Voorstel is om de plaatjes voorlopig op te nemen in de NORA.'''
* Het COA is de organisatie die een registratie voert voor “vreemdelingen” die niet in de BRP (RNI) worden geregistreerd. Deze informatie is inmiddels opgenomen in de beschrijving van het Identiteitenbeheer van natuurlijke personen.
 
==Identiteitenbeheer==
Bob te Riele en enkele collega’s van RvIG (met name ook Frans Rijkers) hebben de teksten van het [[Identiteitenbeheer]] van natuurlijke personen al deels aangepast n.a.v. de eerder gemaakte opmerkingen. Ook is gekeken naar de opzet van de authenticatie van natuurlijke personen.  De aanvullingen die daarop van belang zijn, zullen worden verwerkt door de werkgroep Authenticatie, zie het kopje hieronder.
''': → ACTIE: Vanuit NORA Beheer gaan we na of alle gemaakte opmerkingen zijn verwerkt bij [[Identiteitenbeheer]]. Hierna kan de review kan plaatsvinden door Anne Schrijer (BZK) en Raymond Hofstra (Politie).
'''
   
   
De SAML + en SAML ++ koppelvlakken uit bovenstaand figuur zijn niet gestandaardiseerd. Het zijn ‘eigen’ invullingen van de SAML Metadata Extensions.  
==Authenticatie==
Interoperabiliteit van deze implementaties is een vraagstuk.
Menno Stigter (gemeente Den Haag), Harro Kremer (DJI) en Anne Schrijer (BZK) hebben een eerste uitwerking gemaakt van de {{Bestand met info|Authenticatie_van_Natuurlijke_Personen_v022.pdf|Authenticatie van Natuurlijke Personen i.r.t de BRP}}. Deze uitwerking is plenair besproken.


===Koppelvlak DigiD CGI===
''': → ACTIE: De expertgroep zal de komende weken nog diverse aanpassingen doen, zoals:
Nog flink aantal gemeenten zijn aangesloten op dit oorspronkelijke DigiD koppelvlak, gebaseerd op een oude standaard. Dit koppelvlak is ‘end of life’. Het is de bedoeling dat gemeenten overstappen naar een nieuw koppelvlak. De vraag is welke keuze deze gemeenten moeten maken. Aansluiten op het DigiD SAML-koppelvlak of wachten op de routeringsvoorziening? En welk koppelvlak van de routeringsvoorziening moet men dan implementeren? Aansluiten op het huidige DigiD SAML-koppelvlak of wachten op de beschikbaarheid van het OIDC-koppelvlak, omdat dan pas andere toegangsdiensten via de routeringsvoorziening worden ontsloten?
* Omzetten naar het vijflaagsmodel van de NORA: om discussies te beslechten en vraagstukken te duiden;
* Dubbele tekststukken over natuurlijke personen en authenticatie verwijderen;
* Koppelvlakken van de voorzieningen toelichten;
* Op onderdelen de W&R toelichten: naast een analoge ID is nu ook een digitale ID nodig (denk aan de wet online identiteit en de pilot met virtuele ID’s);
* Een overzicht maken op het niveau van het IAM-kader en de relatie met de uitgewerkte pagina’s in de NORA over identiteitenbeheer en authenticatie;
* Antwoord geven op wat wordt bedoeld met het “proces van authenticatie op de BRP”.'''


===Koppelvlak DigiD SAML===
Het huidige DigiD SAML koppelvlak is substantieel en hoog bestendig en als dusdanig ook beproeft in de DigiD-Hoog pilot van 2017. Het DigiD SAML koppelvlak biedt geen ondersteuning voor machtigingen.


===Koppelvlak routeringsvoorziening Logius (Identity Bridge van de Belastingdienst in 'plus versie')===
==Identiteitenbeheer Bedrijven==
De routeringsvoorziening start met het DigiD SAML-koppelvlak. Hierop komen DigiD en eIDAS (met alleen BSN, dus zonder attributen) beschikbaar. Er wordt gewerkt aan de definitie van een OIDC-koppelvlak waarmee aanvullende attributen, machtigen en aanvullend middel(en) kunnen worden ontsloten. De planning hiervan is niet duidelijk. Er is een globale fasering weergegeven over de komende jaren.
Jurriaan Raaijmakers (gemeente Almere), Wim Schut (Belastingdienst) en Henk Romein (DICTU) hebben een eerste uitwerking gemaakt van het document {{Bestand met info|NORA_-_Identiteitenbeheer_van_Bedrijven_versie_3sep19.pdf|Identiteitenbeheer van Bedrijven}}. Er wordt nog steeds gewerkt aan deze uitwerking, dus als je wilt kan je jouw opmerkingen nog toevoegen aan het document. Opmerkingen ontvangen we graag via [mailto:nora@ictu.nl nora@ictu.nl].  


===Koppelvlak routeringsvoorziening TVS===
Uit de bespreking van dit document kwamen de volgende opmerkingen naar voren:
Het zorgveld beproefd een eigen routeringsvoorziening, de TVS. De TVS maakt gebruik van een SAML-'plus' koppelvlak. Een specifiek voor de TVS ontwikkeld koppelvlak op basis van SAML. Dit koppelvlak maakt het mogelijk om naast DigiD, ook andere middelen en machtigen te ontsluiten.  
* We zijn op zoek naar de verschillende digitale identiteiten die in Nederland aan bedrijven worden toegekend en hoe dat proces verloopt;
* De opzet die nu is gemaakt gaan we z.s.m. publiceren, zodat we reacties daarop kunnen verkrijgen en verwerken;
* Vertegenwoordiging van de KvK zal daar expliciet bij worden betrokken;
* De begrippen en omschrijvingen zijn nog erg overlappend en onduidelijk. Het lijkt soms met name vanuit het perspectief van de Belastingdienst bezien;
* We willen meer als basis aanhouden hoe een register wordt onderhouden en door welke verantwoordelijke(n), zoals KvK met HandelsRegister (HR);
* De definities en nummers zullen worden uitgewerkt;
* Het OIN (door Logius beheerd) is een afspraak om uniciteit over alle domeinen heen te borgen, ook in de tijd gezien (meer info is te verkrijgen via Logius / Pieter Hering;
* De Handelsnaam is alleen unieke binnen een sector (zo’n sector is trouwens wat anders dan overheidsdomeinen!);
* De Statutaire Naam is waarschijnlijk wel uniek in Nederland;
* In het elektronische Toegangsdiensten (eTD) worden ook koppelvlakken en attributen / nummers beschreven;
* Internationaal: LEI en EORIE, De Legel Entity Identifier (LEI) wordt door KvK in NL en KvK’s in BL uitgegeven;
* eIDAS heeft ook een Legal Identifier: die lijkt op het OIN, maar wijkt af van de LEI;
* Een vraagstuk voor later: Hoe gaat een dienst-specifiek identificerend nummer werken (via pseudoniemen / BSNk e.d)?


===Koppelvlak DigiD Machtigen===
Dat pakken we op irt “de wolk”: SSI, IRMA en DigitalMe, Attribute Services e.d., zie [[Hoe_pas_je_Identity_%26_Access_Management_toe%3F#Ontwikkelingen_waar_toepassing_in_de_toekomst_binnen_moet_passen| Ontwikkelingen waar toepassing in de toekomst binnen moet passen]].
Het huidige DigiD Machtigen bestaat al een tijd en kent een eigen koppelvlak gebaseerd op SAML. Hiervan is aangegeven dat dit koppelvlak ‘end of life’ is. Bij de introductie van de nieuwe machtigingsvoorziening (het stelsel van vertegenwoordiging, met een nieuw koppelvlak) wordt dit bestaande koppelvlak op termijn uitgefaseerd. Het bestaande koppelvlak is namelijk niet geschikt om de nieuwe functionele toepassingen van het nieuwe stelsel te ontsluiten richting de gemeente. Het advies is derhalve hier nu al niet meer op aan te sluiten, tenzij zeer weloverwogen en met urgent belang.
* In het afsprakenstelsel eHerkenning is opgenomen aan welke kwaliteitseisen een digitale identiteit moet voldoen;
Waar moet een gemeente dan wel op aansluiten om snel aan de slag te kunnen met machtigen? Direct op het nieuwe koppelvlak voor machtigen, of wachten op de routeringsvoorziening? Wanneer ontsluit die routeringsvoorziening machtigen? Hierover is al aangegeven dat dit alleen wordt ontsloten via het nieuwe koppelvlak op de routeringsvoorziening gebaseerd op de OIDC-standaard. Vooralsnog is er voor machtigen geen alternatief voor handen anders dan het terug vallen op een papieren proces.
* PKIO heeft ook een normenkader voor digitale identiteiten;
* Een normenkader van het stelsel eID is er nog niet;


===Koppelvlak 'stelsel van vertegenwoordiging' (de nieuwe machtigingsvoorziening)===
Aansluiten op het stelsel van vertegenwoordiging kan op termijn op de zogenoemde 'Bevoegdheidsverklaringsdienst'. Hiervoor wordt een eigen SAML-koppelvlak ontwikkeld. Voor pilotdoeleinden komt een eerste versie in 2019 beschikbaar. Later volgen ook de specificaties voor een OIDC-koppelvlak is de planning. Partijen kunnen dan mogelijk kiezen welk koppelvlak men toepast.
==Beleidsstukken over IAM ==
Onbekend is of beide koppelvlakken straks volledig dezelfde functionaliteit ondersteunen en hoe lang het SAML-koppelvlak wordt ondersteund. De beide routeringsvoorzieningen kunnen ook aansluiten op dit koppelvlak (SAML en later ook OIDC), waardoor aangesloten partijen op de routeringsvoorziening alleen het koppelvlak van de routeringsvoorziening hoeven te implementeren (en zich niet meer druk hoeven te maken om het koppelvlak van de bevoegdheidsverklaringsdienst). Alleen: wanneer is dit beschikbaar en kan/wil men hierop wachten? (met het risico dat het OIDC-koppelvlak op de routeringsvoorziening veel langer op zich laat wachten dan voorspelt).  
Kees Jan Kolb (Erasmus MC) en Erik Kuijpers (UWV) hebben de Agenda Digitale Overheid / NL DIGIbeter en de beleidsbrief Regie op Gegevens (RoG) doorgenomen om na te gaan in hoeverre wij als expertgroep IAM invulling kunnen geven aan specifieke onderdelen van deze landelijke (beleids)kaders. Zie ook [[Expertgroep_Digitale_Identificatie_en_authenticatie/2019-07-24#Agenda_Digitale_Overheid_en_NL_DIGIbeter|Agenda Digitale Overheid en NL DIGIbeter]].


===Koppelvlak ETD===
Hun bevindingen hebben ze gepresenteerd, {{Bestand met info|IAM_NORA_en_Wetgeving_Regie_op_gegevensv3.pdf|Wetgeving Regie op gegevens}} en we hebben daaruit het volgende geconcludeerd:
Het afsprakenstelsel Elektronische Toegangsdiensten kent een eigen, op SAML gebaseerd, koppelvlak. Het zou goed zijn om te onderzoeken of hergebruik kan worden gemaakt van deze koppelvlakdefinities. Is het logisch om de makelaars binnen het ETD een ander koppelvlak te laten ondersteunen dan de routeringsvoorziening(en) en de machtigingsregisters een ander koppelvlak dan de machtigingsvoorziening (stelsel van vertegenwoordiging)? Over de ETD-koppelvlakken is al goed nagedacht en zijn bovendien breed geïmplementeerd (ook bij gemeenten). Alleen kent ETD nog geen concrete plannen om over te stappen op de OIDC-standaard, wat wel weer de strategie is bij de andere genoemde voorzieningen.
* Het gedachtegoed van NL DIGIbeter was ons op hoofdlijnen wel bekend, maar het was niet eerder zo expliciet en in samenhang benoemd;
* Naar onze inschatting is al veel beschikbaar van de benoemde toekomstbeelden;
* Met name van belang is een gemeenschappelijk beeld over digitale identiteiten van burgers en de wettelijke verankering ervan;.
* Regie op Gegevens (RoG) in de vorm van het op eigen initiatief van een burger laten delen van een basisset gegevens (of het door laten leveren) is nieuw, zeker via MijnOverheid.nl;
* RoG is een lopend programma dat zich daar op richt en IAM is daar een voorwaardelijk aspect voor. De vraag die bij ons voorligt is daarom: hoe gaan we RoG ondersteunen met onze kennis en ervaring?


===Hoe is de identificatie van natuurlijke personen in de diverse wetten verankerd?===
* Hoe wordt omgegaan met “contacthistorie” (wie heeft wat namens jou gedaan met welke gegevens?);
Identificatie van natuurlijke personen is beschreven in de [https://www.rvig.nl/binaries/rvig/documenten/richtlijnen/2019/01/30/handleiding-uitvoeringsprocedures---hup---versie-3.2/HUP+BRP+3.2.pdf/ Handleiding Uitvoeringsprocedures (HUP)]. Hierin staan de procedures beschreven om personen in te schrijven als ingezetene in de Basisregistratie Personen (BRP). De HUP beschrijft verder hoe gegevens in de BRP moeten worden gewijzigd en gecorrigeerd. Als onderdeel van de HUP is de identificatie nader beschreven.
* Is RoG zoals een blauwe knop: een onderdeel van een dienst digitaliseren? Dat is niet echt regie vanuit de burger.  
''EB: In par 1.4 zijn de voor het document relevante stukken opgesomd.
* De huidige IAM uitgangspunten ondersteunen al grotendeels de uitgangspunten van RoG, echter hoe kan IAM er voor zorgen dat RoG op een veilige wijze verloopt?
De lijken allen gericht op het Identiteitenbeheer en niet zo zeer op verifiëren van identiteiten (=authenticatie).
* Wat is het ontwerp dat de architecten hierin voorstaan?
De WID staat er niet tussen, maar lijkt de meest -en mogelijk ook enig- relevante: [https://wetten.overheid.nl/BWBR0006297/2017-03-01#HoofdstukI_Artikel1/ Hoofdstuk I Artikel 1].''
* Het zal waarschijnlijk niet alles linken aan een BSN.
* Mogelijk zal meer gedaan moeten worden met dataminimalisatie, polymorfe pseudoniemen en gebruiksregisters (audittrails);
* Het veilig gebruik van gegevens bevorderen;
* Faciliteren dat het doorleveren van gegevens wordt geregistreerd (gelogd).


Echter, het gaat telkens om authenticatie van de persoon t.b.v. juiste registratie in de BRP, dan wel voor niet-digitale aspecten. Daar staat niets over digitale authenticatie irt de BRP, dus authenticatie op basis van een digitale identiteit.
De hele beschrijving is opgezet rondom de identiteit in de analoge/reële wereld en niet rondom de digitale identiteit. In de gesprekken rondom de toekomst van de BRP komt dit aspect ook naar boven.


In het ID-protocol van de NvvB (Nederlandse vereniging van Burgerzaken) is beschreven welke handelingen een medewerker Burgerzaken kan uitvoeren om met meer zekerheid te komen tot een validatie van de identiteit van een Burger, dan wel de initiële vaststelling van een identiteit voor een Burger: [https://nvvb.nl/nl/producten/handreikingen/id-management/ ID-protocol]
[[Afbeelding:Belang voor IAM.jpg|thumb|none|750px|Belang voor IAM|alt=”regie op gegevens IAM”|link=Expertgroep Digitale Identificatie en authenticatie/2019-09-03]]
Pas op blz 11 in de handleiding voor de medewerkers, wordt gesproken over het “zich digitaal melden van de burger bij de overheid”. En daarna gaat alles over documenten en niet over digitale authenticatie. Ook hier dus dezelfde opmerking als hierboven.
==ABAC==


Voor de afgifte van eHerkenning cq. eIDAS middelen is het geheel vastgelegd in deze specificaties per betrouwbaarheidsniveau: [https://afsprakenstelsel.etoegang.nl/display/as/Technische+specificaties+en+procedures+voor+uitgifte+van+authenticatiemiddelen/ afsprakenstelsel Technische specificaties en procedures voor uitgifte van authenticatiemiddelen]  
Kees Jan Kolb van het Erasmus MC heeft zijn ervaringen gedeeld over hoe je kunt omgaan met Attribute Based Access Control (ABAC) in relatie tot de bestaande implementaties van RBAC {{Bestand met info|IAM_NORA_bevoegdheden_RBAC_ABAC_model_V2_inc_notes.pdf|RBAC ABAC model}}. Hiermee oriënteren we ons dus op de nadere invulling van Bevoegdhedenbeheer c.q. autorisatiemanagement, zie [[Bevoegdhedenbeheer]].  
Interessant zijn met name 2.1.2 Bewijs en verificatie van Identiteit (natuurlijk persoon).
De volgende zaken kwamen naar voren:
En voor Identificatie / authenticatie van bedrijven is dan interessant: 2.1.3 Bewijs en verificatie van identiteit (rechtspersoon).
* De focus ligt op Identiteitenbeheer en Bevoegdhedenbeheer: welke identiteiten hebben bevoegdheden? zijn de bevoegdheden passend? Is men in control?
* Er is onderscheid tussen 1e orde en 2e orde bevoegdheden: 1e orde is wat mag een identiteit? 2e orde is voor welke data subset is de wat (1e orde) van toepassing?
* Toegang tot applicaties wordt nu geregeld o.b.v. de identiteit: usernaam / medewerkernummer;
* ABAC kan je eigenlijk niet goed binnen een applicatie regelen, wel erbuiten;
* Business rules tbv ABAC is goed toepasbaar buiten de applicaties mbv een IGA tool: veel rollen kunnen automatisch worden toegekend o.b.v. regels en attribuut-waarden;
* Erasmus MC gebruikt nu vooral nog attributen vanuit het HR systeem en Finance, maar in de toekomst worden mogelijk ook attributen uit andere systemen gebruikt;
* Naast de medewerkers uit HRM is de gedachte om op termijn ook andere federatieve bronnen voor identiteiten te gaan gebruiken we denken dan aan externen, studenten en zelfs patiënten als gebruikers van het IAM-systeem;
* Koppelen tussen het IAM-systeem en de applicaties kan op verschillende manieren, maar de voorkeur van Erasmus MC gaat uit naar SCIM (open source REST API): zie onder meer [http://www.simplecloud.info/ SCIM: System for Cross-domain Identity Management] en [https://www.forumstandaardisatie.nl/standaard/scim/ SCIM|Forum Standaardisatie];
* Flat RBAC wordt vaak gebruikt, maar heeft als nadeel dat er per identiteit bijna een rol moet worden gedefinieerd;
* Een 2 laags rollen model (Enterprise Roles vs Application Roles);
* Eigenaarschap van processen en de bijbehorende data dient goed belegd te zijn om op een verantwoorde manier de bevoegdheden tot functionaliteiten en data gecontroleerd te organiseren;
* Mogelijk dat deze aanpak ook werkt voor applicaties van andere organisaties?
* Zouden diensten aan burgers en bedrijven ook op zo’n manier ontsloten kunnen worden?
* De complexiteit van bevoegdhedenbeheer is zo groot, dat je niet alles kunt regelen met regels en rollen: je zult af en toe ook bevoegdheden / autorisaties moeten toekennen op persoonlijk niveau;
* Kunnen organisaties wel doorgaan met data bij elkaar te zetten (zoals in datawarehouses) en daar dezelfde rollen-structuur op los te laten?
* Of moeten we andere vormen van attribuut-uitwisseling gaan hanteren, zoals met (inter)nationale APi’s?
* Het scheiden van data en functionaliteiten wordt belangrijker.
''': → ACTIE Kees Jan stuurt binnenkort zijn geactualiseerde presentatie zodat die kan worden gepubliceerd.'''


'''NB.''' Opgemerkt moet worden dat de eHerkenning cq. eIDAS middelen beschouwd moeten worden als afgeleide middelen, immers ze zijn te allen tijde gebaseerd op een validatie / verificatie van de door het Bevoegd gezag vastgestelde identiteit.


===Welke identificatiemiddelen zijn toepasbaar?===
==Volgende bijeenkomst 15 oktober 2019==
Alle WID’s zoals beschreven in de wet: [https://wetten.overheid.nl/BWBR0006297/2017-03-01#HoofdstukI_Artikel1/ wet Hoofdstuk I Artikel 1].  
De volgende bijeenkomst is op 15 oktober 2019 bij het UWV te Amsterdam.
Door het RvIG is een [[Identificatieplichten wetgeving 2012-20190117-01| overzicht]] opgesteld (hier een link naar het Excel-bestand van Bob) in welke wet gebruik wordt gemaakt van welke voorgeschreven identificatiemiddelen. Van de 115 geïnventariseerde wetten, zijn er 75 welke over de volle breedte van de beschreven WID’s gebruik maken.  
Erik Kuijpers is dan onze gastheer en we gaan -naast het aanhoren van de IAM-aanpak van het UWV- verder met de uitwerking van Bevoegdhedenbeheer en Machtigen.
Dit zijn de volgende documenten:


1Als documenten waarmee in bij de wet aangewezen gevallen de identiteit van personen kan worden vastgesteld, worden aangewezen:
* 1°.een geldig reisdocument als bedoeld in [https://wetten.overheid.nl/BWBR0005212/2017-10-01/#HoofdstukI_Artikel2/ artikel 2, eerste lid, onder a, b, c, d, e en g], of een Nederlandse identiteitskaart en vervangende Nederlandse identiteitskaart als bedoeld in artikel 2, tweede lid, van de Paspoortwet;
* 2°.de documenten waarover een vreemdeling ingevolge de [https://wetten.overheid.nl/BWBR0011823/2019-02-27/ Vreemdelingenwet 2000] moet beschikken ter vaststelling van zijn identiteit, nationaliteit en verblijfsrechtelijke positie;
* 3°.een geldig nationaal, diplomatiek of dienstpaspoort dat is afgegeven door het daartoe bevoegde gezag in een andere lidstaat van de Europese Gemeenschappen of in een andere staat die partij is bij de Overeenkomst betreffende de Europese Economische Ruimte, voor zover de houder de nationaliteit van die andere lidstaat bezit;
* 4°.een geldig rijbewijs dat is afgegeven op basis van de Wegenverkeerswet, een geldig rijbewijs als bedoeld in [https://wetten.overheid.nl/BWBR0006622/2019-07-01/#HoofdstukVI_Afdeling1_Artikel107/ artikel 107 van de Wegenverkeerswet 1994] of een rijbewijs dat is afgegeven door het daartoe bevoegde gezag in een andere lidstaat van de Europese Gemeenschappen of in een andere staat die partij is bij de Overeenkomst betreffende de Europese Economische Ruimte, waarvan de houder in Nederland woonachtig is, zolang de bij de [https://wetten.overheid.nl/BWBR0006622/2019-07-01/ Wegenverkeerswet 1994] vastgestelde termijn van geldigheid in Nederland niet is verstreken, aan de houder geen administratieve maatregel bedoeld in [https://wetten.overheid.nl/BWBR0006622/2019-07-01/#HoofdstukV_Paragraaf9/ paragraaf 9 van hoofdstuk VI van de Wegenverkeerswet 1994] is opgelegd of aan hem niet de bijkomende straf bedoeld in [https://wetten.overheid.nl/BWBR0006622/2019-07-01/#HoofdstukXI_Artikel179/ artikel 179 van die wet] is opgelegd en mits het rijbewijs is voorzien van een pasfoto van de houder.
In 13 verschillende wetten wordt gesproken van een kopie van een geldig identiteitsbewijs, op basis hiervan mag geconcludeerd worden dat deze identificatie slechts tot doel heeft de administratieve verantwoording op orde te houden, en geen feitelijke identificatie bevat.
Van de overige referenties aan identificatie wordt in 22 gevallen het gebruik van een rijbewijs uitgesloten,
In de overige gevallen zijn er beperkingen op het gebeid van buitenlandse identiteitsbewijzen, of zijn er aanvullende eisen gesteld zoals een leveranciersmiddel.


===En welke niveau’s van authenticatie zijn mogelijk voor die authenticatiemiddelen?===
Voor uitgifte WID is geen betrouwbaarheidsniveau vast gesteld, immers het betreft hier een initiële identiteitsvaststelling op basis waarvan opname in de BRP geschied. Indien je daar een betrouwbaarheidsniveau aan zou willen koppelen, is dit altijd een hoger niveau dan het “niveau hoog’ zoals dit beschreven is in de eIdas verordening.
Binnen de eIdas verordening worden de volgende betrouwbaarheidsniveaus onderkend:
* Laag
* Substantieel
* Hoog
Het betrouwbaarheidsniveau ‘Laag’ is in de basis ‘Self-declared’. Concreet betekend dit dat de middelaanvrager zelf zijn identiteit invuld, zonder dat daar een vaidatie middels een identiteitsbewijs aan gekoppeld is.
Het betrouwbaarheidsniveau ‘Substantieel’ is ook ‘Self Declared’ met het verschil dat een verplichte validatie op basis van een WID onderdeel uit maakt van de identiteits vaststelling.
Het betrouwbaarheidsniveau ‘Hoog’ tenslotte wordt gebaseerd op een Face-2-Face validatie van de houder van een WID en het WID. Hiermee wordt het hoogste niveau geborgd.


===Is een proces (document) beschikbaar voor het opzetten / aanvragen van authenticatie bij de BRP?===
==Bijlagen==
(wat moet je bij wie regelen ed)
* {{Bestand met info|NORA - voorstel Authenticatie van natuurlijke personen irt BRP.pdf| Voorstel Authenticatie van natuurlijke personen irt BRP}}
Op basis van de instructies uit de HUP en het ID-Protocol zijn er diverse partijen (AMP, GWK Travelex, notariaat?) die identiteitsvaststelling als dienstverlening aanbieden.  
* {{Bestand met info|Identificatieplichten wetgeving 2012-20190117-01.ods|Identificatieplichten in wetgeving}}
Maar een bedrijf B met authenticatiemiddel A kan niet zomaar de BRP gaan gebruiken. Gecontroleerd wordt of een middel voldoet en wordt toegelaten. Het geheel van processen (inschrijving, middelen aanvraag etc) is gedocumenteerd en gevisualiseerd door RvIG. Die stukken worden momenteel opgevraagd. Voor de toelating is niet de middelenuitgever maar de authenticatiedienst (Logius DigiD) verantwoordelijk geworden. Dat lijkt een beetje een ‘kromme’ situatie, aangezien de digitale authenticatiemiddelen ALTIJD afgeleid moeten worden van de ‘moederkaart’ c.q. identiteitskaart/paspoort van RvIG.

Huidige versie van 21 nov 2019 om 12:00


Nieuws & Agenda
Contact
NORA Beheer
nora@ictu.nl
Status


Bijeenkomst van Expertgroep IAM op dinsdag 3 september 2019, 14-17u, locatie: Stadsdeelkantoor Laak (achter station Hollands Spoor), Slachthuisplein 25, 2521 EC Den Haag, Vergaderzaal LA 00.37.
Doel: Het wat en waarom van Digitale Identificatie en Authenticatie in kaart brengen, opdat we breed gedeelde kennis en beelden krijgen en daarmee onze vraagstukken beter en geprioriteerd kunnen uitwerken om tot gedeelde architectuur oplossingen te komen.
Doelgroep: architecten en collega’s uit de publieke sector actief betrokken op thema authenticatie en identificatie. .



Verslag[bewerken]

Het was wederom een informatieve (en lange 😊) bijeenkomst. Ditmaal bij de gemeente Den Haag, waar we zo’n anderhalf jaar geleden een van de eerste bijeenkomsten hielden met de expertgroep IAM. Bijgaand is op hoofdlijnen aangegeven wat we met elkaar hebben besproken en afgesproken.


Actiepunten[bewerken]

We hebben de actiepunten van de bijeenkomst van 24 juli doorgenomen, zie het verslag Expertgroep Digitale Identificatie en authenticatie/2019-07-24 Er waren nog 2 openstaande actiepunten en die zijn inmiddels opgepakt:

  • NORA Beheer is bij GEMMA Beheer nagegaan of, en zo ja hoe ArchiMate modellen opgenomen kunnen worden bij de processen van Identiteitenbeheer. Het lijkt er op dat in de GEMMA geen specifieke processen zijn beschreven voor het identiteitenbeheer. De GEMMA heeft wel meer algemene processen (typeringen), waar zo’n proces van Identiteitenbeheer onder zou kunnen vallen.

: → ACTIE: Afgesproken is e.e.a. nog met elkaar te gaan bespreken. Voorstel is om de plaatjes voorlopig op te nemen in de NORA.

  • Het COA is de organisatie die een registratie voert voor “vreemdelingen” die niet in de BRP (RNI) worden geregistreerd. Deze informatie is inmiddels opgenomen in de beschrijving van het Identiteitenbeheer van natuurlijke personen.


Identiteitenbeheer[bewerken]

Bob te Riele en enkele collega’s van RvIG (met name ook Frans Rijkers) hebben de teksten van het Identiteitenbeheer van natuurlijke personen al deels aangepast n.a.v. de eerder gemaakte opmerkingen. Ook is gekeken naar de opzet van de authenticatie van natuurlijke personen. De aanvullingen die daarop van belang zijn, zullen worden verwerkt door de werkgroep Authenticatie, zie het kopje hieronder. : → ACTIE: Vanuit NORA Beheer gaan we na of alle gemaakte opmerkingen zijn verwerkt bij Identiteitenbeheer. Hierna kan de review kan plaatsvinden door Anne Schrijer (BZK) en Raymond Hofstra (Politie).

Authenticatie[bewerken]

Menno Stigter (gemeente Den Haag), Harro Kremer (DJI) en Anne Schrijer (BZK) hebben een eerste uitwerking gemaakt van de Authenticatie van Natuurlijke Personen i.r.t de BRP (PDF, 498 kB). Deze uitwerking is plenair besproken.

: → ACTIE: De expertgroep zal de komende weken nog diverse aanpassingen doen, zoals:

  • Omzetten naar het vijflaagsmodel van de NORA: om discussies te beslechten en vraagstukken te duiden;
  • Dubbele tekststukken over natuurlijke personen en authenticatie verwijderen;
  • Koppelvlakken van de voorzieningen toelichten;
  • Op onderdelen de W&R toelichten: naast een analoge ID is nu ook een digitale ID nodig (denk aan de wet online identiteit en de pilot met virtuele ID’s);
  • Een overzicht maken op het niveau van het IAM-kader en de relatie met de uitgewerkte pagina’s in de NORA over identiteitenbeheer en authenticatie;
  • Antwoord geven op wat wordt bedoeld met het “proces van authenticatie op de BRP”.


Identiteitenbeheer Bedrijven[bewerken]

Jurriaan Raaijmakers (gemeente Almere), Wim Schut (Belastingdienst) en Henk Romein (DICTU) hebben een eerste uitwerking gemaakt van het document Identiteitenbeheer van Bedrijven (PDF, 309 kB). Er wordt nog steeds gewerkt aan deze uitwerking, dus als je wilt kan je jouw opmerkingen nog toevoegen aan het document. Opmerkingen ontvangen we graag via nora@ictu.nl.

Uit de bespreking van dit document kwamen de volgende opmerkingen naar voren:

  • We zijn op zoek naar de verschillende digitale identiteiten die in Nederland aan bedrijven worden toegekend en hoe dat proces verloopt;
  • De opzet die nu is gemaakt gaan we z.s.m. publiceren, zodat we reacties daarop kunnen verkrijgen en verwerken;
  • Vertegenwoordiging van de KvK zal daar expliciet bij worden betrokken;
  • De begrippen en omschrijvingen zijn nog erg overlappend en onduidelijk. Het lijkt soms met name vanuit het perspectief van de Belastingdienst bezien;
  • We willen meer als basis aanhouden hoe een register wordt onderhouden en door welke verantwoordelijke(n), zoals KvK met HandelsRegister (HR);
  • De definities en nummers zullen worden uitgewerkt;
  • Het OIN (door Logius beheerd) is een afspraak om uniciteit over alle domeinen heen te borgen, ook in de tijd gezien (meer info is te verkrijgen via Logius / Pieter Hering;
  • De Handelsnaam is alleen unieke binnen een sector (zo’n sector is trouwens wat anders dan overheidsdomeinen!);
  • De Statutaire Naam is waarschijnlijk wel uniek in Nederland;
  • In het elektronische Toegangsdiensten (eTD) worden ook koppelvlakken en attributen / nummers beschreven;
  • Internationaal: LEI en EORIE, De Legel Entity Identifier (LEI) wordt door KvK in NL en KvK’s in BL uitgegeven;
  • eIDAS heeft ook een Legal Identifier: die lijkt op het OIN, maar wijkt af van de LEI;
  • Een vraagstuk voor later: Hoe gaat een dienst-specifiek identificerend nummer werken (via pseudoniemen / BSNk e.d)?

Dat pakken we op irt “de wolk”: SSI, IRMA en DigitalMe, Attribute Services e.d., zie Ontwikkelingen waar toepassing in de toekomst binnen moet passen.

  • In het afsprakenstelsel eHerkenning is opgenomen aan welke kwaliteitseisen een digitale identiteit moet voldoen;
  • PKIO heeft ook een normenkader voor digitale identiteiten;
  • Een normenkader van het stelsel eID is er nog niet;


Beleidsstukken over IAM[bewerken]

Kees Jan Kolb (Erasmus MC) en Erik Kuijpers (UWV) hebben de Agenda Digitale Overheid / NL DIGIbeter en de beleidsbrief Regie op Gegevens (RoG) doorgenomen om na te gaan in hoeverre wij als expertgroep IAM invulling kunnen geven aan specifieke onderdelen van deze landelijke (beleids)kaders. Zie ook Agenda Digitale Overheid en NL DIGIbeter.

Hun bevindingen hebben ze gepresenteerd, Wetgeving Regie op gegevens (PDF, 386 kB) en we hebben daaruit het volgende geconcludeerd:

  • Het gedachtegoed van NL DIGIbeter was ons op hoofdlijnen wel bekend, maar het was niet eerder zo expliciet en in samenhang benoemd;
  • Naar onze inschatting is al veel beschikbaar van de benoemde toekomstbeelden;
  • Met name van belang is een gemeenschappelijk beeld over digitale identiteiten van burgers en de wettelijke verankering ervan;.
  • Regie op Gegevens (RoG) in de vorm van het op eigen initiatief van een burger laten delen van een basisset gegevens (of het door laten leveren) is nieuw, zeker via MijnOverheid.nl;
  • RoG is een lopend programma dat zich daar op richt en IAM is daar een voorwaardelijk aspect voor. De vraag die bij ons voorligt is daarom: hoe gaan we RoG ondersteunen met onze kennis en ervaring?
  • Hoe wordt omgegaan met “contacthistorie” (wie heeft wat namens jou gedaan met welke gegevens?);
  • Is RoG zoals een blauwe knop: een onderdeel van een dienst digitaliseren? Dat is niet echt regie vanuit de burger.
  • De huidige IAM uitgangspunten ondersteunen al grotendeels de uitgangspunten van RoG, echter hoe kan IAM er voor zorgen dat RoG op een veilige wijze verloopt?
  • Wat is het ontwerp dat de architecten hierin voorstaan?
  • Het zal waarschijnlijk niet alles linken aan een BSN.
  • Mogelijk zal meer gedaan moeten worden met dataminimalisatie, polymorfe pseudoniemen en gebruiksregisters (audittrails);
  • Het veilig gebruik van gegevens bevorderen;
  • Faciliteren dat het doorleveren van gegevens wordt geregistreerd (gelogd).


”regie op gegevens IAM”
Belang voor IAM

ABAC[bewerken]

Kees Jan Kolb van het Erasmus MC heeft zijn ervaringen gedeeld over hoe je kunt omgaan met Attribute Based Access Control (ABAC) in relatie tot de bestaande implementaties van RBAC RBAC ABAC model (PDF, 7,8 MB). Hiermee oriënteren we ons dus op de nadere invulling van Bevoegdhedenbeheer c.q. autorisatiemanagement, zie Bevoegdhedenbeheer. De volgende zaken kwamen naar voren:

  • De focus ligt op Identiteitenbeheer en Bevoegdhedenbeheer: welke identiteiten hebben bevoegdheden? zijn de bevoegdheden passend? Is men in control?
  • Er is onderscheid tussen 1e orde en 2e orde bevoegdheden: 1e orde is wat mag een identiteit? 2e orde is voor welke data subset is de wat (1e orde) van toepassing?
  • Toegang tot applicaties wordt nu geregeld o.b.v. de identiteit: usernaam / medewerkernummer;
  • ABAC kan je eigenlijk niet goed binnen een applicatie regelen, wel erbuiten;
  • Business rules tbv ABAC is goed toepasbaar buiten de applicaties mbv een IGA tool: veel rollen kunnen automatisch worden toegekend o.b.v. regels en attribuut-waarden;
  • Erasmus MC gebruikt nu vooral nog attributen vanuit het HR systeem en Finance, maar in de toekomst worden mogelijk ook attributen uit andere systemen gebruikt;
  • Naast de medewerkers uit HRM is de gedachte om op termijn ook andere federatieve bronnen voor identiteiten te gaan gebruiken we denken dan aan externen, studenten en zelfs patiënten als gebruikers van het IAM-systeem;
  • Koppelen tussen het IAM-systeem en de applicaties kan op verschillende manieren, maar de voorkeur van Erasmus MC gaat uit naar SCIM (open source REST API): zie onder meer SCIM: System for Cross-domain Identity Management en SCIM|Forum Standaardisatie;
  • Flat RBAC wordt vaak gebruikt, maar heeft als nadeel dat er per identiteit bijna een rol moet worden gedefinieerd;
  • Een 2 laags rollen model (Enterprise Roles vs Application Roles);
  • Eigenaarschap van processen en de bijbehorende data dient goed belegd te zijn om op een verantwoorde manier de bevoegdheden tot functionaliteiten en data gecontroleerd te organiseren;
  • Mogelijk dat deze aanpak ook werkt voor applicaties van andere organisaties?
  • Zouden diensten aan burgers en bedrijven ook op zo’n manier ontsloten kunnen worden?
  • De complexiteit van bevoegdhedenbeheer is zo groot, dat je niet alles kunt regelen met regels en rollen: je zult af en toe ook bevoegdheden / autorisaties moeten toekennen op persoonlijk niveau;
  • Kunnen organisaties wel doorgaan met data bij elkaar te zetten (zoals in datawarehouses) en daar dezelfde rollen-structuur op los te laten?
  • Of moeten we andere vormen van attribuut-uitwisseling gaan hanteren, zoals met (inter)nationale APi’s?
  • Het scheiden van data en functionaliteiten wordt belangrijker.

: → ACTIE Kees Jan stuurt binnenkort zijn geactualiseerde presentatie zodat die kan worden gepubliceerd.


Volgende bijeenkomst 15 oktober 2019[bewerken]

De volgende bijeenkomst is op 15 oktober 2019 bij het UWV te Amsterdam. Erik Kuijpers is dan onze gastheer en we gaan -naast het aanhoren van de IAM-aanpak van het UWV- verder met de uitwerking van Bevoegdhedenbeheer en Machtigen.


Bijlagen[bewerken]

Een beschrijving van een complex geheel, en van de principes die van toepassing zijn op de ontwikkeling van het geheel en zijn onderdelen.

Het bekend maken van de identiteit van personen, organisaties of IT-voorzieningen.

Nederlandse Overheid Referentie Architectuur.

Alle belanghebbenden van overheidsdienstverlening in de ruimste zin van het woord.

Overgenomen van "https://www.noraonline.nl/index.php?title=Expertgroep_Digitale_Identificatie_en_authenticatie/2019-09-03&oldid=39102"