Digikoppeling Identificatie en Authenticatie 1.4.3

Onderstaande tabel geeft de doelgroep van dit document weer.

Dit document gaat over de bedrijfsarchitectuur op landelijk niveau, en specifiek over de identificatie en authenticatie van organisaties. Eerst beschrijven we de probleemstelling in hoofdstuk 2. De kernbegrippen staan gedefinieerd in hoofdstuk 3. In hoofdstuk 4 analyseren we het gewenste niveau van de identiteit voor overheidsorganisaties, uitmondend in een architectuurprincipe. Hoofdstuk 5 gaat in op de vraag hoe de (nummer)identiteit vorm krijgt.

Dit document is een onderdeel van de Digikoppeling standaarden:

Identificatie is het kenbaar maken van de identiteit van een subject³ (een persoon/gebruiker of een proces/systeem). De identiteit wordt gebruikt om de autorisatie (zie verder) - de toegang tot een service - te beheersen.

³: Voor terminologie wordt aangesloten bij de OASIS standaarden, o.a. SAML: 'Subject: A principal in the context of a security domain. SAML assertions make declarations about subjects'. De term subject wordt ook gehanteerd in de PKI-wereld, X509.

Authenticatie is als volgt gedefinieerd:

Authenticatie is het proces waarbij nagegaan wordt of een subject daadwerkelijk is wie hij beweert te zijn, dat wil zeggen: daadwerkelijk de identiteit bezit die hij opgeeft.

Bij de authenticatie wordt bijv. gecontroleerd of een opgegeven bewijs van identiteit overeenkomt met echtheidskenmerken^{4 5}. Het proces van authenticatie is dus onlosmakelijk verbonden met identiteit.

⁴: Voor authenticatie wordt daarom ook wel de term verificatie gehanteerd.

⁵: De definitie van authenticatie in de NORA gaat meer in op het aspect hoe authenticatie wordt uitgevoerd dan op wat het is. Daarom wordt die definitie hier niet overgenomen.

Authenticatie levert als het ware de kwaliteit van de identificatie. Tevens speelt hier een 'chain of trust'. Als een paspoort beschikt over de echtheidskenmerken (en het is niet gestolen of verlopen) dan mag men op de inhoud vertrouwen. Hetzelfde geldt voor een PKIoverheid certificaat. Als het 'root' certificaat te vertrouwen is (en het certificaat is niet ingetrokken of verlopen) dan mag men op de inhoud vertrouwen.

Autorisatie is het proces waarin een subject rechten krijgt op het benaderen van een service. De autorisatie wordt toegekend door de service-eigenaar. Het leidende principe (met name bij persoonsgegevens) is doelbinding: je mag alleen zien wat je voor je taak nodig hebt.

De primaire reden voor het vaststellen van de identiteit van een subject is om op basis daarvan vervolgens vast te stellen of dat subject ook gerechtigd is om de gewenste service af te nemen. Die autorisatie (al of niet mede op basis van rollen, machtigingen, vertegenwoordigingen enzovoort) is nadrukkelijk een op de authenticatie volgende, aparte stap. De geauthenticeerde identiteit is dus nodig om autorisatie te kunnen doen. Autorisatie stelt eisen aan authenticatie.

Vooral het niveau van de identiteit is van belang . Het gaat dan om de vraag of het niveau 'organisatie' voldoende is of dat het meer gedetailleerde niveau 'medewerker binnen een organisatie' noodzakelijk is.

Met vastlegging wordt hier bedoeld het vastleggen (loggen, bijvoorbeeld in een audittrail) van het resultaat van authenticatie en autorisatie. De eisen die daaraan gesteld worden, zijn belangrijk. Moet jaren later nog voor de rechter bewezen kunnen worden dat dit subject op dit tijdstip een specifieke service vraag gesteld heeft, of wordt alleen vastgelegd ten behoeve van latere statistische bewerkingen.

De eisen die gesteld worden aan vastlegging, zijn weliswaar belangrijk, maar ze hebben met name betrekking op zaken als traceerbaarheid van authenticatie; heeft authenticatie wel plaatsgevonden en hoe dan wel enzovoort Ze hoeven geen rol te spelen bij de bepaling van de gewenste (niveau van) identiteit.

Dat kan anders zijn als de eisen aan niveau van zowel autorisatie als vastlegging verschillen. Dat zou het geval kunnen zijn als er regels gelden zoals: 'iedere medewerker van een geautoriseerde partij heeft toegang, maar er moet wel onweerlegbaar worden vastgelegd welke medewerker het betrof' (autorisatie op niveau van partij, vastlegging op niveau van medewerker). De eisen vanuit de behoefte aan autorisatie en de noodzakelijke vastlegging voor bewijs achteraf kunnen dus verschillen.

In de Service Gerichte benadering van de NORA maken applicaties van de ene organisatie gebruik van services van een andere organisatie. Een service mag alleen afgenomen worden door geautoriseerde afnemers, namelijk die afnemers die een juridische basis⁶ of een overeenkomst hebben met de aanbieder van de betreffende service.

⁶: De terminologie moet nog juridisch correct gemaakt worden; in deze notitie wordt (juridisch) wat losjes gesproken over 'zelfstandig bevoegd', 'juridische basis' enzovoort.

Afnemers in de overheid kennen vele organisatorische 'niveaus' met diverse juridische statussen: gemeentelijke diensten, departementale directoraten, agentschappen, ZBO’s etc., al dan niet zijnde rechtspersonen. De vraag is dus welk niveau, en dus welke identiteit, gebruikt zou moeten worden.

Het ligt voor de hand om hier uit te gaan van de organisatie(onderdeel), dat kennelijk zelfstandig bevoegd is (bijv. op basis van een besluit of mandaat) dan wel een juridische basis heeft. Een dergelijke vastlegging tussen aanbieder en afnemer noemen we hierna een overeenkomst.

Uitgangspunt is:

• de identiteit van de afnemer die gebruikt wordt voor autorisatie tot het afnemen van een service, moet overeenkomen met de identiteit van de organisatie(onderdeel) waarmee een overeenkomst bestaat tot het gebruik van de service. Authenticatie en vervolgens autorisatie vinden daarom in eerste instantie plaats op het niveau van de identiteit die is gebruikt bij de overeenkomst.

De vraag is of dat niveau het juiste niveau is voor autorisatie of dat er nog verfijning nodig is. Een serviceaanbieder kan theoretisch op verschillende manieren de autorisatie en de daarvoor benodigde identificatie inrichten. De aanbieder zou bijvoorbeeld kunnen stellen, dat medewerker X van afnemersorganisatie A een service wel mag afnemen en medewerker Y van diezelfde organisatie niet.

Er bestaat brede consensus (ook in andere landen), dat dit ongewenst is. Enerzijds is namelijk de afnemende organisatie verantwoordelijk voor eigen informatiebeveiliging, dus voor het op de juiste wijze autoriseren van de eigen medewerkers. Anderzijds wordt de organisatie die de service aanbiedt dan niet met medewerkers van een ander geconfronteerd en om dezelfde reden ook niet met 'afdelingen' of informatiesystemen van die organisatie. Het is gewenst is om alleen maar te autoriseren op het niveau van een organisatie.

Als dat het autorisatieprincipe is, dan stelt dat als eis aan de identificatie, dat alleen de identiteit van de afnemerorganisatie vastgesteld (geauthenticeerd) hoeft te worden.

1. Autorisatie tot afnemen van een service vindt plaats op basis van de identiteit van de zelfstandig bevoegde afnemerorganisatie, dat wil zeggen: op het niveau van de overheidsorganisatie waarop de juridische afspraak gemaakt is.
2. Autorisatie en authenticatie gebeurt bij de serviceaanbieder niet op een verder gedetailleerd niveau, zoals medewerker, afdeling, applicatie of wettelijke taak.

Ongeacht het voorgaande is het mogelijk, dat aan de afnemende organisatie strengere eisen gesteld worden aan het vastleggen van het gebruik van gegevens.

Ook de WBP formuleert, in het kader van verstrekking aan derden en informeren van betrokkene, de eisen op het niveau van verantwoordelijke dat wil zeggen de rechtspersoon. Aangezien het hier een juridische omgeving betreft en de WBP expliciet open geformuleerd is, dient dit in voorkomende gevallen verder juridisch uitgezocht te worden.

Uitgangspunt in dit document is dat – in termen van de WBP - bij verstrekking alleen de ontvangende verantwoordelijke relevant is en niet de kring van «personen die onder rechtstreeks gezag van de verantwoordelijke gemachtigd zijn om gegevens te verwerken». Personen lijken dus niet relevant, wel verantwoordelijken in de zin van de WBP.

Een praktisch argument om niet de gegevens van medewerkers van de afnemer vast te leggen bij de aanbieder is, dat overheidsorganisaties vaak een dossier of zaak behandelen, waarbij diverse medewerkers van de betreffende organisatie betrokken zijn. De aanbiedende organisatie kan hooguit zicht houden op de toevallige eerste medewerker die informatie opvraagt, maar niet op alle volgende medewerkers. Dat geldt zeker wanneer dat dossier actueel gehouden wordt door (een mechanisme van) abonnementen.

De bovenstaande redenatie voor medewerkers is ook geldig voor andere onderverdelingen, zoals medewerker afdeling, systeem, enzovoort bij de (zelfstandig bevoegde) afnemer.

Conclusie:

Gevolg van dit uitgangspunt is, dat een verantwoordelijke alleen maar inzage kan geven in de organisaties aan wie gegevens zijn verstrekt. Die andere organisatie moet dan vervolgens inzicht kunnen geven welke medewerkers (en welke andere organisaties, indien van toepassing) de informatie hebben opgevraagd.

Iets heel anders is, dat er onderling kan worden afgesproken dat een naam van een medewerker wordt meegegeven als onderdeel van de via de service uitgewisselde informatie, zodat men daarmee contact kan opnemen bij verdere vragen (vergelijk 'behandeld door').

Een bijzondere situatie ontstaat wanneer er sprake is van een intermediaire organisatie. Deze situatie komt tussen overheidsorganisaties het meest voor aan de rand van een sector. Partijen in de sector communiceren via een sector koppelpunt met de wereld buiten de sector. Zie hierover NORA paragraaf 6.5:

Koppelpunten versus aanspreekpunten

Voor de koppeling tussen servicebussen kan gekozen worden tussen twee niveaus:

• een puur logistieke koppeling, dat wil zeggen: een overslagpunt waarin verkeer over de ene bus naar de andere wordt overgebracht door middel van koppelpunten, zonder interpretatie van de gegevensinhoud;

• een inhoudelijke koppeling, dat wil zeggen: een keten, sector- of domeinloket of –aanspreekpunt, dat de interne complexiteit van de keten, de sector of het domein voor de buitenwereld afschermt.

De belangrijkste factor in dit onderscheid zit niet op de eerste plaats in het technische of functionele. Veel belangrijker is dat er in geval van een inhoudelijke koppeling een echte overheidsorganisatie (of wellicht privaat publieke organisatie) moet worden aangewezen of gecreëerd die de bedoelde inhoudelijke diensten ook feitelijk namens de keten, de sector of het domein kan aanbieden of afnemen en daarvoor inhoudelijk verantwoordelijk gehouden kan worden, op basis van en/of passend in toepasselijke wetgeving. Anders gezegd, hier is sprake van inhoudelijke intermediatie. Denk hierbij bijvoorbeeld aan:

• een virtueel ketendossier dat via één loket voor afnemers buiten de keten wordt ontsloten

• het sectorloket voor het onderwijsveld, ondergebracht bij de IB-Groep

• het BKWI dat namens het werk- en inkomensveld bevragingen doet bij de RDW e.a.

Aanspreekpunten kunnen beide kanten op werken: zij kunnen services namens de hele sector, keten of domein aanbieden aan 'externe partijen', maar zij kunnen ook, namens de gehele sector, keten of domein diensten afnemen van buiten.

Een inhoudelijke koppeling is niet mogelijk zonder een logistieke koppeling. Andersom kan wel: een logistieke koppeling zonder een inhoudelijk aanspreekpunt. In dat geval is er alleen sprake van een logistieke 'brug' naar de sector, zonder dat de keten, de sector of het domein als geheel is aan te spreken of handelt. Mengvormen zijn ook mogelijk, waarin de sector, het domein of de keten voor bepaalde services als geheel optreedt en voor andere niet.

Op basis van het voorgaande wordt voorgesteld om voor gebruik op Digikoppeling als OIN te hanteren:

• ofwel het RSIN voor de grote groep organisaties waarvoor dat RSINr bestaat en gebruikt kan worden.

• ofwel een nieuw nummer voor de overige organisaties. Dat nieuwe nummer wordt uitgereikt door Logius als beheerdervan Digikoppeling.

Verder:

• Wanneer later organisaties uit de tweede categorie (dus zonder bruikbaar Fi-nummer) alsnog opgenomen worden in het HR, kan het OIN daarmee in overeenstemming worden gebracht. De inhoud van het HR blijft leidend.

Dat OIN wordt opgenomen in het PKIoverheid certificaat. Omdat PKIoverheid certificaten niet alleen door overheidsorganisaties gebruikt worden voor identificatie naar andere overheidsorganisaties, maar ook bijvoorbeeld voor bedrijfsleven naar overheid, is het nodig onderscheid te kunnen maken naar het soort nummer.

Er wordt daarom een prefix gehanteerd voorafgaand aan dat nummer, dat aangeeft of het een HR of Fi-nummer, of bijvoorbeeld een KvK-nummer betreft, ofwel een door Logius uitgereikt nummer.

De systematiek in deze notitie is bedoeld om zo duidelijk mogelijk te zijn over de inrichting van identificatie en authenticatie bij gebruik van Digikoppeling. Het is uitgesloten, dat hiermee de gehele werkelijkheid wordt afgedekt. Daarom beslist de beheerder van Digikoppeling over alle verzoeken die afwijken van de in deze notitie aangegeven lijn.

In 2017 is voor het OIN een nieuw beleid actief geworden waarin de uitgifte voor het OIN is verduidelijkt en op sommige punten is verruimd. Zo kunnen overheidsorganisaties (formeel organisaties met Publiekrechtelijke Rechtspersoonlijkheid) eenvoudig een subOIN aanvragen voor

• samenwerkingverbanden waar ze zelf deel aan nemen,

• eigen organisatieonderdelen en

• voorzieningen waar ze beheer over voeren

Met nadruk stellen we dat deze mogelijkheid facultatief. Ook is duidelijk gemaakt hoe en wanneer organisaties een OIN kunnen krijgen als ze niet aan een van hierboven gestelde eisen kunnen doen, zoals buitenlandse partijen of organisaties uit het onderwijs. In de Digikoppeling Voorwaarden worden de voorwaarden voor uitgifte en gebruik van het OIN exact beschreven.

Het basisformaat van het OIN - Organisatie Identificatie Nummer- is:

<prefix><nummer><suffix>

Voor het nummer maakt Logius voor overheidsorganisaties primair gebruik van het Rechtspersonen en Samenwerkingsverbanden Identificatie Nummer (RSIN) uit het HR. In die gevallen waar een overheidsorganisatie geen RSIN heeft, kan worden uitgeweken naar alternatieven. Het RSIN is inhoudelijk gelijk aan het Fiscaal(Fi)-nummer.

Om rekening te houden met een andere systematiek in de toekomst is de lengte van het prefixveld bepaald op 8 posities.

De prefix definieert welk soort nummer volgt.

De waarde van het OIN in het OIN Register en in het veld subject.serialNumber is inclusief de prefix en suffix en daarbij behorende voorloopnullen. Door het gehele nummer te gebruiken wordt zeker gesteld dat het nummer uniek is.

Een aangesloten overheidsregister krijgt een prefix (per uniek nummer) als het register wordt toegevoegd aan het OIN-stelsel. Dit wordt ook een OIN register genoemd. De prefix tabel wordt als aparte lijst beheerd door de beheerder van het OIN-stelsel en wordt gepubliceerd op de website.

¹⁰: In uitzonderlijke gevallen kan het Fi-nummer worden gebruikt indien verstrekt door de organisatie zelf. Dit is b.v. het geval bij onderdelen van de Staat der Nederlanden die niet ingeschreven in het Handelsregister zoals de Tweede Kamer der Staten-Generaal of de Algemene Rekenkamer.

¹¹: Het KvK nummer mag worden gebruikt door private partijen in de communicatie met de overheid.

• Het RSIN wordt opgegeven door de aanvrager en bij het HR gecontroleerd door Logius..

• Het KvK-nummer kan in het Handelsregister van de KvK na opgave door de aanvrager gecontroleerd worden door Logius.

¹²: Logius OIN Hoofdnummer: Voor organisaties uit het caribisch deel van het Koninkrijk der Nederlanden is dit nummer opgebouwd als 4 posities landnummer gevolgd door 5 posities volgnummer, conform landentabel BRP.

Voorbeelden:

OIN o.b.v. RSIN: 00000001123456789000

OIN o.b.v. Logius-beheerder: 00000004123456789000

Het gehele nummer wordt opgenomen in het certificaat (subject.serialNumber). Dat gehele nummer geldt dus als OIN.

De opbouw van het HRN (Handels Register Nummer) is identiek aan het OIN:

<prefix><nummer><suffix>

Voor het HRN worden tot nog toe alleen onderstaande mogelijkheden onderkend.

In de HRN-variant worden de nummers vastgesteld door de TSP, op basis van het door de aanvrager opgegeven KvK-nummer, dat door de TSP wordt gecontroleerd.