Domeinarchitectuur toegang

Inhoudsopgave

1 Inleiding

1.1 Aanleiding

1.2 Dit document

1.3 Documentstructuur

1.4 Relatie met andere architecturen

1.5 Relatie met andere initiatieven

2 Kernbegrippen

2.1 Algemeen

2.2 Rollen

2.3 Functies

3 Veranderfactoren

3.1 Beleid

3.2 Wet- en regelgeving

4.3 Ontwikkelingen

4.4 Knelpunten

4 Doelarchitectuur

4.1 Architectuurvisie

4.2 Architectuurprincipes

4.3 Verdieping thema rolverdeling

4.4 Verdieping thema systeem naar systeem toegang

4.5 Veranderinitiatieven

5 Doelarchitectuur

5.1 Functies

5.2 Bedrijfsobjecten en begrippen

5.3 Rollen

5.4 Huidige voorzieningen

5.5 Standaarden

5.6 Relatie van architectuurprincipes met ADO en NORA

5.7 Betrokkenen

1 Inleiding

1.1 Aanleiding

De overheid digitaliseert en dat roept vragen op over hoe overheidsorganisaties hun processen, gegevens en systemen moeten inrichten. De Generieke Digitale Infrastructuur (GDI) ondersteunt de digitale overheid met afspraken, standaarden en voorzieningen. In de governancestructuur van het Meerjarenprogramma Infrastructuur Digitale Overheid (MIDO) werken overheidsorganisaties samen aan de doorontwikkeling van de digitale overheid en de GDI. Er is vanuit deze governance een meerjarenvisie en een Architectuur Digitale Overheid 2030 opgesteld die op hoofdlijnen beschrijft hoe de digitale overheid zich de komende jaren zou moeten doorontwikkelen. De Architectuur Digitale Overheid wordt nader uitgewerkt in vier domeinarchitecturen op het gebied van interactie, toegang, gegevensuitwisseling en infrastructuur.

Domein toegang gaat over beveiligde toegang tot diensten, gegevens en functionaliteit. Deze gegevens en functionaliteit worden richting gebruikers ontsloten in de context van het domein interactie. Gegevensuitwisseling is het domein dat gaat over het uitwisselen van gegevens tussen de informatiesystemen van overheidsorganisaties en met andere organisaties. Domein infrastructuur ondersteunt de andere domeinen met infrastructurele voorzieningen, zowel software- als hardwarematig.

Het domein toegang omvat alles dat nodig is om mensen, organisaties, applicaties en apparaten op een veilige en rechtmatige manier toegang te geven. Dit vraagt om het nemen van maatregelen, die voor een belangrijk deel ook relevant zijn in het kader van informatiebeveiliging. Domein toegang is grotendeels synoniem met wat ook wel "identity & access management" wordt genoemd. Dit is iets dat zowel binnen organisaties als over organisatiegrenzen heen aandacht vraagt. In de context van de GDI gaat het over toegang tot digitale publieke diensten. Dit staat los van hoe organisaties hun eigen medewerkers toegang verlenen, alhoewel het ook gebruikt kan worden om medewerkers van overheidsorganisaties toegang te geven tot digitale publieke diensten van andere overheidsorganisaties.

De toegangsinfrastructuur is de verzameling van gemeenschappelijke afspraken, standaarden en voorzieningen die nodig zijn om toegang te faciliteren. Er zijn meerdere toegangsinfrastructuren, zoals het Afsprakenstelsel Elektronische Toegangsdiensten (behorende bij eHerkenning), het nieuwe stelsel toegang en het EDI-stelsel NL (dat tevens een infrastructuur voor gegevensuitwisseling is). Landelijke voorzieningen zoals DigiD en eHerkenning zijn belangrijke onderwerpen van gesprek, maar het toegangslandschap is tevens aan het veranderen. Zo zullen er in de toekomst ook private middelen worden toegelaten om toegang te verkrijgen tot overheidsdiensten. Daarnaast worden er in het kader van de herziene eIDAS verordening European Digital Identity Wallets geïntroduceerd die ook als identificatiemiddel kunnen worden ingezet. In meer algemene zin hebben ontwikkelingen zoals Self Sovereign Identity grote impact op hoe idealiter met toegang wordt omgegaan.

Dit document

Dit document beschrijft de domeinarchitectuur voor toegang, als onderdeel van de GDI. Het gaat vooral in op toegang tot publieke digitale diensten, alhoewel een deel van de principes en modellen ook gebruikt kunnen worden voor toegang binnen overheidsorganisaties. Het betreft de huidige en gewenste afspraken, standaarden en voorzieningen voor toegang in de GDI. Het document is opgesteld in een interbestuurlijke architectuurwerkgroep met vertegenwoordigers van verschillende overheidsorganisaties. Deze werkgroep is ondersteund door bureau MIDO van het ministerie van BZK. Het document beschrijft relevant beleid, wet- & regelgeving en ontwikkelingen, en vertaalt deze naar een visie en richting voor de inrichting van toegang tot digitale publieke diensten.

Deze architectuur geeft richting aan ontwerpkeuzes die worden gemaakt bij het doorontwikkelen van de GDI of bij het aansluiten op de GDI. Het is input voor programmering en kan gebruikt worden om nieuwe programma’s en projecten te definiëren en initiëren. Het speelt een formele rol in de kaderstelling, toezicht en monitoring van programma’s en projecten die gefinancierd worden vanuit de MIDO governancestructuur. Het kan in de MIDO governancestructuur worden gebruikt om afwijkingen van de gewenste situatie te signaleren in programma’s en projecten. Het document is ook in meer algemene zin te gebruiken door overheidsorganisaties. Het bevat meer algemene kennis over wat er van overheidsorganisaties wordt verwacht met betrekking tot toegang. Daarnaast is het voor een belangrijk deel ook toe te passen als referentiekader voor de inrichting van toegang binnen individuele overheidsorganisties.

Het document is vooral gericht op enterprise-, informatie- en security-architecten bij overheidsorganisaties en op architecten die werken aan de vernieuwing van de toegangsinfrastructuur. Daarnaast kan het ook interessant zijn voor informatie-analisten, ontwerpers en product owners om te gebruiken als basis voor requirements en ontwerp. Het document is een doorontwikkeling van de eerdere domeinarchitecturen voor identificatie & authenticatie en machtigen & vertegenwoordigen maar kent een andere structuur en opzet. De voorgaande documenten komen met dit document te vervallen.

Er is voor gekozen om de architectuur in de modelleertaal ArchiMate uit te werken en de details ervan alleen online beschikbaar te stellen. Dit document is daarmee een samenvatting en verwijzing naar details die online te vinden zijn. Het bevat dan ook allerlei links die toegang geven tot meer informatie. De architectuur wordt online ook doorontwikkeld en beheerd in GitHub, waardoor de meest actuele versie daar te vinden is. Daar zijn ook bestanden te vinden die direct kunnen worden ingelezen in het Open Source modelleertool Archi.

We hebben ervoor gekozen om de terminologie in dit document af te stemmen op de begrippen van de NORA IAM werkgroep. We hebben ook actief meegewerkt aan de doorontwikkeling van laatstgenoemd begrippenkader, dat onderdeel zal gaan uitmaken van een nieuwe NORA begrippenlijst. Er is daarom ook geen begrippenlijst opgenomen in dit document. We adviseren om de NORA IAM begrippenlijst te raadplegen. De kernbegrippen zijn wel onderdeel van het bedrijfsobjectenmodel, die dus ook als een begrippenlijst gezien kan worden.

1.3 Documentstructuur

De architectuur is ingedeeld in vijf onderdelen:

De kernbegrippen zijn de kern van de taal zoals deze gehanteerd wordt in dit document en de bijbehorende tekst is een samenvatting van zaken die zijn beschreven in de bijlagen.
De veranderfactoren geven richting aan de architectuur, en bestaan uit beleid, wet- en regelgeving, ontwikkelingen en knelpunten.
De gewenste situatie beschrijft een architectuurvisie, architectuurprincipes en voorgestelde veranderinitiatieven. De architectuurprincipes zijn de overtuigingen die het hart van de architectuur vormen en die als richtinggevende uitspraken zijn opgeschreven.
De verdieping beschrijft een uitwerking van de architectuurvisie en architectuurprincipes op de voorgestelde rolverdeling en op het gebied van toegang tussen systemen. Het geeft aanvullende inzichten en handreikingen.
In de bijlagen zijn meer algemene modellen en beschrijvingen opgenomen van de functies, objecten, voorzieningen, standaarden en begrippen die van toepassing zijn op toegang. Het beschrijft ook de relatie van de architectuurprincipes met de Architectuur Digitale Overheid en NORA en de betrokkenen bij de totstandkoming van dit document.

1.4 Relatie met andere architecturen

Deze domeinarchitectuur is sterk gerelateerd aan de domeinarchitectuur gegevensuitwisseling. Dat komt enerzijds omdat het uitwisselen van gegevens in veel gevallen om toegang vraagt en anderzijds omdat er gegevens moeten worden uitgewisseld om te bepalen of toegang kan worden verstrekt. Er is bewust voor gekozen om geen grote delen uit de domeinarchitectuur gegevensuitwisseling in te kopiëren in deze architectuur, zodat er één duidelijke bron van informatie over gegevensuitwisseling is. De consequentie hiervan is dat lezers wordt gevraagd om de domeinarchitectuur gegevensuitwisseling ook te lezen om een volledig beeld van toegang te krijgen. De belangrijkste relaties tussen de beide domeinarchitecturen zijn:

De functie “verlenen toegang” in domeinarchitectuur gegevensuitwisseling is te beschouwen als een samenvoeging van de functies “authenticeren”, “autoriseren” en “auditing en monitoring” in de domeinarchitectuur toegang.
Functies voor het maken van verifieerbare verklaringen en het gebruik van verifieerbare verklaringen voor het verstrekken van toegang zijn onderdeel van de domeinarchitectuur toegang. Functies voor het beschikbaar stellen en valideren van verifieerbare verklaringen zijn onderdeel van de domeinarchitectuur gegevensuitwisseling.
Regie op gegevens, Self Sovereign Identity en de EDI wallet zijn sterk aan elkaar gerelateerd. De domeinarchitectuur gegevensuitwisseling beschrijft de ontwikkeling en een principe m.b.t. regie op gegevens. De domeinarchitectuur toegang beschrijft de ontwikkeling en geeft toelichting op Self Sovereign Identity. De EDI wallet wordt in beide domeinarchitecturen beschreven.
Gegevensruimtes zijn te zien als een meer geavanceerde vorm van gegevensuitwisseling waarbij datasoevereiniteit en vertrouwen centraal staan. Dat vraagt vooral mechanismen voor toegang. Gegevensruimtes worden daarom in beide domeinarchitecturen beschreven en domeinarchitectuur toegang gaat dieper in op de toegangsaspecten, waarbij vooral Policy Based Access Control relevant is.

Er is ook een relatie met de domeinarchitectuur interactie:

De domeinarchitectuur interactie stelt dat iedereen recht heeft op kwalitatief goede overheidsdiensten. In de domeinarchitectuur toegang wordt de impact hiervan op het kunnen verstrekken van toegang beschreven.
De domeinarchitectuur interactie stelt dat er een één-overheidsbeleving is met een eenvormige interactie. Een belangrijk aspect ervan is dat daarbij een gemeenschappelijke set van identificatiemiddelen wordt ondersteund, en dat de klantreis die wordt geboden voor inloggen uniform is.
De domeinarchitectuur interactie stelt dat interacties via meerdere kanalen mogelijk moet zijn. Dat betekent dat identiteiten via al deze kanalen bruikbaar moeten zijn.

Deze domeinarchitectuur is afgestemd op de Architectuur Digitale Overheid 2030 en de NORA. Hierdoor is de domeinarchitectuur te beschouwen als een doorvertaling en concretisering van deze overkoepelende architecturen.

1.5 Relatie met andere initiatieven

Er zijn andere initiatieven die zijn gerelateerd aan toegang. De belangrijkste programma’s die er op het moment van schrijven van dit document lopen zijn het programma/stelsel toegang en het programma EDI-stelsel NL. Deze domeinarchitectuur geeft context en kaders aan de architecturen die zijn of worden opgesteld in deze programma’s. Het programma/stelsel toegang heeft een “doelarchitectuur ICT-voorzieningen en werking stelsel toegang” opgesteld die met name inzicht geeft in welke ICT-voorzieningen nodig zijn voor het ondersteunen van de Wet digitale overheid (Wdo). Er heeft een review plaatsgevonden op deze doelarchitectuur door de architectuurwerkgroep. Het programma EDI-stelsel NL geeft aandacht aan de implementatie van de herziene eIDAS verordening, richt hiervoor een stelsel in en geeft daarbij specifieke aandacht aan het gebruik van European Digital Identity Wallets. Er is afgestemd met dit programma om dat wat hierover duidelijk is in de architectuur een plek te geven. Er loopt ook een project Federatieve Toegangs Verlening (FTV) dat onderzoekt hoe toegang tot gegevens in de context van gegevensuitwisseling kan worden gestandaardiseerd. Daarbij wordt expliciet gekeken naar de inzet van Policy Based Access Control.

2 Kernbegrippen

Dit hoofdstuk is bedoeld om de belangrijkste terminologie zoals gebruikt in dit document te verduidelijken. Een is een samenvatting en meer toegankelijke beschrijving van informatie die ook aanwezig is in de begrippenlijst, het functiemodel, het bedrijfsobjectmodel en de rollen. Voor een meer uitgebreide lijst van begrippen wordt dan ook naar de bijlage verwezen.

2.1 Algemeen

Dit document gaat over het verstrekken van toegang aan mensen, organisaties, applicaties en apparaten. Dat noemen we in dit document entiteiten. Daarbij geldt dat applicaties en apparaten altijd handelen namens een andere entiteit. Een entiteit krijgt toegang met een bepaalde identiteit. Dat is een verzameling van eigenschappen die kenmerkend zijn voor een entiteit. Entiteiten hebben in een specifieke gebruikscontext een specifieke identiteit (ook wel: deelidentiteit), waarin alleen de eigenschappen zitten die in die context relevant zijn. Praktisch worden eigenschappen uitgewisseld in de vorm van identiteitsgegevens. Dit soort gegevens over entiteiten heten in de context van toegang ook wel attributen. Deze gegevens worden verkregen uit gezaghebbende bronnen. Dat zijn bronnen waarvan kan worden verwacht dat deze nauwkeurige gegevens bieden.

Entiteiten krijgen toegang door gebruik te maken van een identificatiemiddel om mee te authenticeren. Daarmee is het identificatiemiddel een authenticatiemiddel. Een dergelijk identiteitsmiddel vraagt een vorm van bewijs van een gebruiker, zoals een wachtwoord en geeft vervolgens een authenticatieverklaring waarmee toegang kan worden gegeven. Een authenticatieverklaring is een specifiek soort verifieerbare verklaring. Dat zijn verklaringen over identiteiten, die vergezeld van een bewijs waarmee hun validiteit, integriteit, authenticiteit en geldigheid kan worden geverifieerd. Verifieerbare verklaringen kunnen gebruikt worden om allerlei gegevens uit te wisselen. In de context van het domein toegang zijn verklaringen belangrijk die iets zeggen over attributen die worden gebruikt om te bepalen of iemand toegang krijgt.

Toegang wordt verstrekt tot resources: diensten en de daaronder liggende gegevens en functionaliteiten. Welke diensten, gegevens en functionaliteiten toegang toe wordt verstrekt wordt bepaald door de bevoegdheden (ook wel: autorisaties) die aan een identiteit zijn gekoppeld. Entiteiten kunnen ook bevoegdheden krijgen doordat ze van iemand anders een machtiging hebben gekregen of omdat een door een wettelijke vertegenwoordiging formeel namens iemand anders mogen optreden. Dit leidt tot vertegenwoordigingsbevoegdheden, die net als bevoegdheden in meer algemene zin worden gebruikt om te bepalen of een entiteit toegang kan krijgen. Merk op dat we de term “machtiging” in dit document alleen gebruiken voor vrijwillig verstrekte vertegenwoordigingsbevoegdheden.

Het controleren van de bevoegdheden van een identiteit heet autoriseren. Daarbij wordt gebruik gemaakt van autorisatieregels die beschrijven waaraan moet worden voldaan om toegang te verkrijgen. Dit soort regels gebruiken de identiteitsgegevens uit verifieerbare verklaringen, maar kunnen ook naar contextuele eigenschappen kijken zoals de tijdstip, de plaats en het apparaat dat gebruikt wordt om toegang te krijgen. Uiteindelijk leidt dit tot een autorisatiebeslissing die aangeeft of wel of geen toegang wordt verstrekt.

2.2 Rollen

Toegang gaat voor een belangrijk deel over het uitwisselen van verifieerbare verklaringen. Aan de ene kant zijn er partijen die verklaringen kunnen verstrekken. Dat noemen we dan ook verklarende partijen. Denk daarbij aan authenticatiediensten die kunnen verklaren of een entiteit succesvol is geauthenticeerd of aan machtigingsdiensten die kunnen verklaren of een entiteit iemand anders mag vertegenwoordigen. Daarnaast zijn er aanbieders van identiteitsgegevens uit gezaghebbende bronnen die deze beschikbaar kunnen stellen in de vorm van verifieerbare verklaren. Brokers kunnen de verklaringen van deze verklarende partijen routeren, vertalen, bundelen en als één geïntegreerde dienst beschikbaar stellen. Overigens kunnen entiteiten ook dingen over zichzelf verklaren, en zijn zij dus in potentie ook een verklarende partij. Merk op dat niet al deze rollen altijd relevant zijn. In de context van de EDI wallet spreken we niet over rollen als authenticatiedienst en broker omdat verantwoordelijkheden daarbij anders zijn belegd.

Aan de andere kant zijn er vertrouwende partijen. Dat zijn typisch dienstverleners die diensten aanbieden waartoe toegang moet worden verstrekt aan entiteiten. Zij moeten kunnen vertrouwen op de verifieerbare verklaringen van verklarende partijen. Merk op dat in de context van de eIDAS verordening de term ook breder wordt gebruikt.

Om dit geheel te laten werken zijn er ook andere rollen nodig. Zo zijn er ook middelenuitgevers nodig die ervoor zorgen dat er erkende identificatiemiddelen kunnen worden uitgegeven. Er wordt ook gebruik gemaakt van leveranciers van vertrouwensdiensten, die bijvoorbeeld verifieerbare verklaringen kunnen maken of certificaten kunnen uitgeven die verklarende partijen kunnen verstrekken.

2.3 Functies

In deze domeinarchitectuur hebben we functies benoemd die in het algemeen relevant zijn voor toegang. In deze paragraaf beschrijven we de hoofdfuncties, die activiteiten op organisatieniveau beschrijven (het zijn bedrijfsfuncties). Deze functies worden gebruikt om andere zaken op te plotten en aan te relateren. Figuur 1 geeft een overzicht van deze functies. In de bijlage zijn ook de meer gedetailleerde functies beschreven.

Het is door organisaties zelf te bepalen aan welke partijen en afdelingen zij de functies in hun context toekennen. Er zijn wel een aantal functies specifiek gekoppeld aan rollen zoals beschreven in deze domeinarchitectuur. Zo hoort de hoofdfunctie "Beheren identificatiemiddelen" bij de rol middelenuitgever, de hoofdfunctie "authenticeren" bij de rol authenticatiedienst en de rol “beheren vertegenwoordigingsbevoegdheden” bij de rol machtigingsdienst. Het beheren van eigen bevoegdheden en het autoriseren zijn verantwoordelijkheden die bij vertrouwende partijen zelf ligt.

Organiseren toegang: Het organisatorisch inregelen van afspraken voor toegang.
Creëren vertrouwen: Het creëren van vertrouwen in de identiteit van natuurlijke en niet-natuurlijke personen en gegevens middels cryptografische technieken.
Beheren identiteiten: Het creëren, vastleggen, beschikbaarstellen, wijzigen en (logisch) verwijderen van (gegevens over) identiteiten.
Beheren identificatiemiddelen: Het verstrekken en intrekken van identificatiemiddelen en het administreren van de daarvoor benodigde gegevens.
Beheren eigen bevoegdheden: Het toekennen en intrekken van bevoegdheden (anders dan vertegenwoordigingsbevoegdheden) en het administreren van de daarvoor benodigde gegevens.
Beheren vertegenwoordigingsbevoegdheden: Het toekennen en intrekken van vertegenwoordigingsbevoegheden en het administreren van de daarvoor benodigde gegevens.
Auditing en monitoring: Het vastleggen van relevante gebeurtenissen rondom toegang en het uitvoeren van controlerende activiteiten om misbruik of fraude vast te stellen.
Authenticeren: Het bepalen of er voldoende vertrouwen is dat iemand een digitale identiteit heeft en het creëren, controleren, vertalen en vernietigen van daarbij behorende authenticatieverklaringen.
Autoriseren: Het bepalen op basis van autorisatieregels bepalen of een digitale identiteit beschikt over de bevoegdheden voor toegang tot diensten of informatieobjecten.

3 Veranderfactoren

Dit hoofdstuk geeft een overzicht van de veranderfactoren die richting geven aan de architectuur. Het beschrijft de belangrijkste beleid en wet- en regelgeving die van toepassing zijn, de ontwikkelingen die spelen en de knelpunten die er op dit moment bestaan.

3.1 Beleid

De domeinarchitectuur beschrijft een aantal belangrijke beleidsdocumenten die invloed hebben op gegevensuitwisseling. Overheidsorganisaties zouden zich bewust moeten zijn van dit beleid en van het feit dat dit directe invloed heeft op hun eigen beleidsvorming.

Agenda Digitale Open Strategische Autonomie	Doordat digitale innovatie in toenemende mate plaatsvindt buiten de EU, neemt onze afhankelijkheid van derde landen voor digitale technologie toe. Afhankelijkheden in het digitale domein kunnen risico’s met zich meebrengen. De intentie van dit beleidskader is om het vermogen van de EU om als mondiale speler, in samenwerking met internationale partners, op basis van eigen inzichten en keuzes publieke belangen te borgen en weerbaar te zijn in een onderling verbonden wereld. Die belangen zijn onder meer de nationale veiligheid, het lange termijn verdienvermogen, het vinden van oplossingen voor maatschappelijke uitdagingen, en de borging van de democratische rechtsstaat en fundamentele waarden.
Baseline Informatiebeveiliging Overheid	De Baseline Informatiebeveiliging Overheid (BIO) is een normenkader voor informatiebeveiliging en geeft het basisniveau voor informatiebeveiliging waar alle overheidspartijen aan moeten voldoen. Door dit eenduidige normenkader binnen de overheid, wordt een stevige basis gelegd voor de verdere optimalisering van informatiebeveiliging binnen de gehele overheid en ontstaat een gemeenschappelijke taal die bijdraagt aan veilige samenwerking in ketens binnen de overheid. De BIO is gebaseerd op de NEN-ISO/IEC 27002. In de nieuwe Cyberbeveiligingswet zal deze verplicht worden gesteld voor overheidsorganisaties.
GDI-Meerjarenvisie 2024-2028	Deze meerjarenvisie biedt in eerste instantie inzicht en overzicht in de relevante politieke, beleidsmatige en technische ontwikkelingen, ook internationaal, en geeft op basis daarvan richting aan de doorontwikkeling van de GDI. Ook benoemt het principes en uitgangspunten die worden gehanteerd bij de stapsgewijze realisatie van de beschreven ambities. Het MIDO is daarmee de concretisering van datgene dat interbestuurlijk gezamenlijk wordt georganiseerd aan afspraken, standaarden en voorzieningen om ambities waar te maken.
I-strategie Rijk	In deze I-strategie 2021-2025 staan de gezamenlijke prioriteiten van de Chief Information Officers (CIO’s) van het rijk voor de informatievoorziening. Iedere prioriteit is uitgewerkt in een aantal actiepunten. De i-Strategie vestigt in het thema digitale weerbaarheid aandacht op security en privacy en de toename en impact van cyberdreigingen. Het stelt dat een proactieve aanpak nodig is om incidenten te voorkomen, gebaseerd op analyse van de belangrijkste risico's.
Nederlandse Digitaliseringsstrategie	Er is een nieuwe Nederlandse Digitaliseringsstrategie in ontwikkeling. De doelstelling ervan is om digitale technologie verantwoord in te zetten en goede dienstverlening te bieden aan burgers en ondernemers. Naast goede dienstverlening moet de overheid haar digitale weerbaarheid en digitale autonomie versterken. Overheidsorganisaties moeten worden versterkt door politiek-bestuurlijke aansturing, efficiëntere samenwerking, zich als één overheid op te stellen en in te zetten op digitaal vakmanschap. De strategie richt zich in het bijzonder op kunstmatige intelligentie, data en cloud.

3.2 Wet- en regelgeving

De domeinarchitectuur beschrijft de belangrijkste wet- en regelgeving die van toepassing is op toegang. Dat betreft met name nieuwe wet- en regelgeving vanuit Europa, inclusief de Nederlandse invulling daarvan, gegeven dat dit een belangrijke bron voor verandering is voor toegang. De wet- en regelgeving is in de architectuur gekoppeld aan de architectuurprincipes die een belangrijke bijdrage leveren aan het implementeren van deze wet- en regelgeving. Er heeft nadrukkelijk geen detailanalyse van de wet- en regelgeving plaatsgevonden. Daarmee kan er ook geen garantie worden gegeven dat het volgen van deze architectuur automatisch leidt tot het voldoen aan de wet- en regelgeving.

General Data Protection Regulation	Deze verordening standaardiseert de regels voor de verwerking van persoonsgegevens door particuliere bedrijven en overheidsinstanties in de Europese Unie. Het doel van de verordening is het garanderen van de bescherming van persoonsgegevens binnen de Europese Unie en het waarborgen van het vrije verkeer van gegevens binnen de Europese interne markt. In Nederland staat de verordening bekend als de Algemene Verordening Gegevensbescherming (AVG).
Network and Information Systems (NIS) directive 2	De oorspronkelijke NIS-directive regelt de beveiliging van netwerk- en informatiesystemen van aanbieders van essentiële diensten (AED’s) en van digitale dienstverleners (DSP’s), onder meer door hen te laten voldoen aan een zorg- en meldplicht. De AED’s dienen door de lidstaten zelf te worden aangewezen. De NIS directive 2 vervangt de NIS-directive en stelt maatregelen vast om een hoog gemeenschappelijk niveau van cyberbeveiliging in de Unie te waarborgen. Dit betekent onder meer dat lidstaten nationale strategieën voor cyberbeveiliging moeten vaststellen en nationale autoriteiten, centrale contactpunten en computer security incident response teams (CSIRT’s) moeten aanwijzen. Daarnaast worden eisen gesteld aan risicobeheer, rapportage en het delen van informatie op het gebied van cyberbeveiliging. De NIS2 directive zal in Nederland worden geïmplementeerd in de vorm van de Cyberbeveiligingswet.
Wet digitale overheid	De Wet digitale overheid faciliteert de implementatie van de initiële eIDAS verordening uit 2014 in Nederland. Het regelt dat Nederlandse burgers en bedrijven veilig en betrouwbaar kunnen inloggen bij de (semi-)overheid. Het stelt eisen aan de betrouwbaarheid van identificatiemiddelen, waardoor overheidsorganisaties gedwongen worden op een meer professionele manier met toegang om te gaan. Burgers krijgen elektronische identificatiemiddelen met een substantiële of hoge mate van betrouwbaarheid. Er moeten ook private identificatiemiddelen kunnen worden ondersteund. De wet stelt daarnaast het toepassen van specifieke open standaarden verplicht.
eIDAS 1.0	eIDAS staat voor ‘Electronic Identification And Trust Services’. Met de eIDAS verordening hebben de Europese lidstaten afspraken gemaakt om dezelfde begrippen, betrouwbaarheidsniveaus en onderlinge digitale infrastructuur te gebruiken voor grensoverschrijdende transacties en het gebruik van vertrouwensdiensten. Een onderdeel van de verordening is het grensoverschrijdend gebruik van Europees erkende identificatiemiddelen. Dit kan alleen met een betrouwbare online identiteitscheck aan de voordeur. Hierdoor wordt het makkelijker en veiliger om binnen Europa online zaken te regelen. Concreet betekent dit dat burgers en organisaties die de beschikking hebben over een erkend identificatiemiddel dezelfde zaken moeten kunnen regelen als alle andere burgers en organisaties in een lidstaat. Levert een dienstverlener digitale toegang, dan wordt deze daarom verplicht, niet alleen Nederlandse, maar ook Europees erkende identificatiemiddelen te accepteren. Op basis van de eIDAS verordening zijn eHerkenning en DigiD genotificeerd (erkend) voor grensoverschrijdende dienstverlening.
eIDAS 2.0	De herziene versie van de verordening introduceert Europese digitale identiteits wallets waarmee burgers en organisaties gebruik kunnen maken van digitale diensten. Het gebruik van de wallet is op basis van vrijwilligheid en maakt het mogelijk voor burgers en organisaties om controle te hebben over hun gegevens. De wallet kan gebruikt worden als een identificatiemiddel, voor machtigen en vertegenwoordigen, voor elektronisch ondertekenen en als een middel voor het veilig delen van gegevens. Het maakt gebruikt van verifieerbare verklaringen om bewijzen te leveren aan vertrouwende partijen.

3.3 Ontwikkelingen

In deze architectuur beschrijven we een aantal belangrijke (vooral technische) ontwikkelingen op het gebied van toegang. De impact van deze ontwikkelingen is meegenomen in de beschrijving van de architectuur.

Contextuele en adaptieve toegangscontrole	Voor het verstrekken van toegang wordt steeds meer contextuele informatie over een gebruiker gebruikt. Denk daarbij bijvoorbeeld aan de locatie van de gebruiker, het tijdstip van toegang, het gebruikte apparaat, het type sessie en het aantal gelijktijdige sessies. Hierdoor kan toegang meer gericht worden verstrekt en wordt ongeautoriseerde toegang dus verder voorkomen. Contextuele toegangsregels kunnen op groepsniveau, maar ook individueel worden toegekend. Bij adaptieve toegangscontrole kan er dynamisch rekening worden gehouden met veranderende risicoprofielen en gebruikersgedrag. Ongebruikelijke gebruikspatronen kunnen daarbij aanleiding zijn om toegang te weigeren.
Cyberaanvallen	Er zijn toenemende aanvallen op computersystemen. Het doel van deze aanvallen is om deze computersystemen, netwerken of apparaten te verstoren, toegang te krijgen tot gegevens of deze te beschadigen. Deze aanvallen kunnen variëren van eenvoudige phishing-pogingen tot geavanceerde aanvallen door georganiseerde criminele groepen of zelfs door staten gesponsorde actoren. Het doel kan zijn om geheimen te verkrijgen om er militair, politiek of economisch voordeel uit te halen.
Gegevensruimtes	Gedreven vanuit de Europese datastrategie is er veel aandacht voor gegevensruimtes (data spaces). Er moet een Europese gegevensruimte komen, een interne markt voor data, waar zowel overheidsorganisaties als bedrijven gebruik van kunnen maken. Binnen deze Europese gegevensruimte ziet de Europese Commissie 14 gemeenschappelijke gegevensruimtes ontstaan voor specifieke sectoren. De precieze inrichting van veel van deze gegevensruimtes is nog onduidelijk. Kernaspecten van gegevensruimtes zijn data soevereiniteit en vertrouwen, wat vraagt om beveiligde toegang tot gegevens.
Quantum computing	Een quantumcomputer is een nieuw soort computer, met een fundamenteel andere werking dan die van een klassieke computer. Zo zal een quantumcomputer veel sneller zijn in het oplossen van bepaalde problemen. De komst van quantumcomputers kan grote gevolgen hebben voor organisaties die werken met versleutelde gegevens. Met een quantumcomputer wordt het mogelijk gegevens te ontsleutelen die beveiligd zijn met de meestgebruikte vormen van cryptografie. Gegevens die op dit moment nog voldoende beveiligd zijn, zijn dat na de komst van quantumcomputers niet meer. De gevolgen zijn echter nog groter: er kunnen nu al versleutelde gegevens worden onderschept, zodat ze in de toekomst met een quantumcomputer ontsleuteld kunnen worden.
Self Sovereign Identity	Self Sovereign Identity (SSI) is een visie op identiteiten waarbij de gebruiker zelf centraal staat. Het basisprincipe is dat gebruikers zelf controle hebben over hun eigen identiteit. Identiteiten zijn dus niet gebonden aan een specifieke site of partij. Ze zijn en blijven ten alle tijden van de gebruiker en deze kan er altijd naar refereren, deze aanpassen of zelfs verbergen. Gebruikers kunnen hun identiteit voorzien van allerlei verklaringen, die deels van henzelf komen en die deels afkomstig zijn van anderen. Deze verklaringen en andersoortige gegevens die deel uitmaken van de identiteit zijn altijd eenvoudig voor gebruikers te raadplegen. Verklaringen zijn daarmee niet noodzakelijkerwijs ook aan te passen door gebruikers, maar ze zijn er altijd bewust van. Gebruikers bepalen zelf aan wie ze de verklaringen en gegevens verstrekken en er worden geen gegevens verstrekt die niet nodig zijn. Identiteiten blijven lang geldig, in ieder geval zolang de gebruiker dat wil. Ze kunnen breed gebruikt worden. Er is niet één gemeenschappelijke interpretatie van de term SSI. Er zijn vooral allerlei interpretaties die een mate van overlap vertonen. Een deel van de oplossingen zoals voorgesteld voor SSI maakt gebruik van Blockchain technologie.
Verklaringen	Daar waar in het verleden rechten van gebruikers vooral bepaald werden door hun rol, worden rechten tegenwoordig steeds meer bepaald door verklaringen (ook wel: claims of attestaties) van partijen. Deze verklaringen hoeven niet direct over een specifiek recht te gaan, maar kunnen over allerlei eigenschappen (ook wel: attributen) van de gebruiker gaan. Dit wordt ook wel Attribute Based Credentials (ABC) genoemd. Hiermee ontstaat een meer flexibele vorm van autorisatie, die gebruik kan maken van veel meer eigenschappen, die door allerlei partijen kunnen worden geleverd. Het leidt tot een minder centraal model voor het toekennen van autorisaties. Verklaringen kunnen ook gericht zijn op het ondersteunen van specifieke informatiebehoeften, waardoor ze dataminimalisatie goed ondersteunen. Verklaringen zijn er in verschillende soorten, met een verschillend niveau van betrouwbaarheid. Verifieerbare verklaringen maken het mogelijk om de echtheid en geldigheid van de verklaring expliciet te controleren.
Wachtwoordloos inloggen	Bij wachtwoordloos inloggen wordt in plaats van een wachtwoord een andere combinatie van authenticatiefactoren gebruikt. Denk aan bijvoorbeeld een geregistreerd SMS, email, apparaat of token en mogelijk ook vormen van biometrie. Hierdoor hoeven gebruikers dus geen wachtwoord meer te gebruiken. Het gebruik van wachtwoorden is in het verleden vaker bekritiseerd, onder meer omdat mensen wachtwoorden hergebruiken, mensen geneigd zijn ze te vergeten, ze periodiek aangepast moeten worden en ze hierdoor op minder veilige manieren worden vastgelegd. Wachtwoordloze inlogmethoden maken typisch gebruik van public-key cryptografie.
Zero trust	Het is steeds minder duidelijk wie vertrouwd kan worden, bijvoorbeeld doordat het onderscheid tussen interne en externe medewerkers steeds minder scherp wordt en mensen steeds meer thuiswerken. In het zero trust model wordt ervan uitgegaan dat gebruikers, apparaten en het netwerk standaard niet vertrouwd kunnen worden, ook als apparaten verbonden zijn aan het lokale netwerk. Uitgangspunt is dan dat identiteiten altijd sterk worden gecontroleerd voorafgaand aan het verstrekken van toegang. Gebruikers krijgen ook alleen de minimaal noodzakelijke toegang. Het niveau van beveiliging wordt hierdoor verhoogd. Autorisatie dient plaatst te vinden op functionaliteiten en op basis van het need-to-know principle. Dit betekent dat de gebruiker alleen toegang krijgt tot tools, data en zones die daadwerkelijk noodzakelijk zijn voor het werk dat diegene doet. Daarbij wordt gebruik gemaakt van contextuele en adaptieve toegangscontrole.

3.4 Knelpunten

Knelpunten zijn omstandigheden in de huidige situatie die ertoe leiden dat organisaties niet kunnen voldoen aan beleid of wet- en regelgeving. Er heeft in het kader van de domeinarchitectuur een globale analyse van knelpunten plaatsgevonden. De resultaten van de analyse zijn samengevat en opgenomen in de architectuur. We zijn ons bewust van het feit dat dit slechts een subset is van de volledige set van knelpunten en dat de knelpunten niet voor alle overheidsorganisaties in gelijke mate gelden of van toepassing is. Een deel van deze knelpunten heeft betrekking op de toegangsinfrastructuur, maar nadere analyse is nodig of dat daadwerkelijk het geval is. Voor een deel van deze knelpunten geldt dat ook reeds aan oplossingen wordt gewerkt, zoals de knelpunten m.b.t. vertegenwoordigen en meervoudig inloggen. De volgende figuur plot de knelpunten op de meest passende functie in het bedrijfsfunctiemodel.

Buitenlandse certificaten niet bruikbaar voor authenticatie	PKI certificaten van buitenlandse leveranciers van (gekwalificeerde) certificaten kunnen in Nederland niet zomaar voor authenticatie gebruikt worden, ondermeer omdat er geen OIN in staat. Een OIN wordt vooralsnog alleen aan Nederlandse rechtspersonen toegekend. Daarmee sluiten Nederlandse voorzieningen het gebruik van dit soort certificaten standaard uit. Formeel moeten we als Nederland gekwalificeerde certificaten uit andere Europese lidstaten accepteren. Het ontbreekt echter in Europa aan voldoende afspraken over organisatie-identificaties om dit praktisch uit te kunnen voeren.
DigiD alleen voor gebruik met BSN	Er is wettelijk bepaald dat DigiD alleen gebruikt mag worden voor diensten waarvoor BSN gebruikt moet worden. Dat beperkt het inzetgebied van DigiD. Er is bij verschillende overheidsorganisaties behoefte aan een betrouwbaar identificatiemiddel dan ook inloggen mogelijk maakt voor diensten waarvoor het BSN niet verwerkt mag worden.
Gebruik verouderde standaarden	De toegangsinfrastructuur is voor een belangrijk deel gebaseerd op de SAML standaard, die inmiddels verouderd is. Meer recente standaarden zoals OAuth en OIDC worden niet of nauwelijks ondersteund.
Gebruikers moeten vaak opnieuw inloggen	Er blijkt dat veel portalen expliciet vragen om in te loggen als de gebruiker even daarvoor ook is al is ingelogd. Dit is gebruiksonvriendelijk. DigiD ondersteunde single sign-on maar dit is destijds om beveiligingsredenen niet meer toegestaan. Er is inmiddels wel een herbevestiging in DigiD beschikbaar, waardoor volledig opnieuw inloggen in DigiD niet hoeft.
Geen betrouwbaarheidsniveau bij DigiD machtigen	DigiD machtigen weet niet of een gebruiker inlogt met een middel op laag, substantieel of hoog en legt dat dus ook niet vast. Hierdoor is het strikt genomen ook niet mogelijk om een vertegenwoordiger een hoger betrouwbaarheidsniveau dan laag te geven bij authenticatie. De keten is immers zo sterk als de zwakste schakel. Dit bied een sterke beperking van het inzetgebied van DigiD machtigen en levert in de praktijk beveiligingsrisico's op als dienstverleners zich dit niet beseffen.
Geen centraal onderzoek en meldpunt fraude voor eHerkenning	Het rapport "Digitale identiteit vraagt veel van DigiD en eHerkenning" van de Algemene Rekenkamer uit 2023 stelt dat er voor eHerkenning geen overkoepelende organisatie bestaat die fraudegevallen oppakt en dat er ook geen centraal fraudemeldpunt is. Het melden van en reageren op specifieke signalen en meldingen ligt decentraal: bij de organisaties zelf, bij de leverancier en/of dienstverlener. Hierdoor ontbreekt er een goed kwalitatief en kwantitatief beeld. Dit heeft als risico dat zaken langs elkaar heen lopen en fraude minder effectief wordt voorkomen dan wanneer dit beeld er wel zou zijn. Dit probleem wordt relevanter als er meer authenticatiediensten beschikbaar komen.
Geen eHerkenning machtigen met buitenlands middel	Het is niet mogelijk om met een buitenlands identificatiemiddel een machtiging te verstrekken of ontvangen binnen eHerkenning, omdat dit alleen werkt met eHerkenning middelen.
Geen pin reset mogelijk met DigiD hoog	Het is op dit moment niet mogelijk om een pin reset uit te voeren met DigiD hoog. Als een gebruiker zijn pincode vergeten is dat moet deze een nieuw identiteitsbewijs aanvragen. Het belang van DigiD hoog en het goed functioneren ervan is belangrijk in de context van de EDI wallet, omdat deze nodig is om de persoonsidentificatiegegevens te kunnen laden in de EDI wallet.
Geen uniforme gebruikservaring	Er is geen uniforme gebruikservaring voor het verkrijgen van toegang bij verschillende dienstverleners, ongeacht het betrouwbaarheidsniveau. Er zijn veel verschillende processen met verschillende mogelijkheden. Hierdoor is het voor gebruikers niet altijd intuïtief hoe toegang wordt verkregen.
Machtigingen verspreid over meerdere systemen	Er is op dit moment sprake van een groot aantal plaatsen waar vrijwillige machtigingen verstrekt kunnen worden. Naast DigiD machtigen en de machtigingsvoorzieningen van eHerkenning zijn er ook op andere plaatsen machtigingen geadministreerd zoals in het Handelsregister, in Digipoort en in het Digitaal Stelsel Omgevingswet. Dit komt deels doordat er beperkte machtigingsfunctionaliteit aanwezig is in DigiD machtigen en eHerkenning (keten)machtigen. Zo is het bijvoorbeeld niet mogelijk om te machtigen voor zaken of voor specifieke informatie-objecten. Hierdoor moeten overheidsorganisaties op meerdere machtigingsregisters aansluiten en gebruikers op allerlei plaatsen machtigingen verstrekken of ontvangen, waardoor ze het overzicht verliezen. De machtigingsfunctionaliteit in Digipoort was bedoeld als tijdelijk en is na bestuurlijke afweging met beperkingen geïmplementeerd.
Restgroepen worden niet goed ondersteund	Er zijn allerlei groepen burgers en bedrijven die niet worden bediend met DigiD, eHerkenning en PKI-overheid omdat ze niet in de onderliggende registers geregistreerd staan en omdat de betreffende afsprakenstelsels hier geen oplossing voor bieden. Het gaat bijvoorbeeld buitenlandse bedrijven die niet in het handelsregister zijn opgenomen. Daarnaast kunnen burgers zonder Nederlands identiteitsdocument hun DigiD niet op hogere betrouwbaarheidsniveaus activeren. Overheidsorganisaties kunnen restgroepen bedienen door hiervoor zelf een registratie te voeren, de wettelijke basis daarvoor te borgen, en een identificatiemiddel in te richten die voldoet aan de eisen in de Wdo en/of eIDAS. Er is inmiddels wel een tijdelijk register voor restgroepen in het bedrijvendomein, maar deze is alleen beschikbaar voor diensten van de Belastingdienst en alleen beschikbaar voor eHerkenning.
Schaalbaarheid en fijnmazigheid van dienstencatalogi	De huidige toegangsinfrastructuur is gebaseerd op toegang tot diensten. Deze diensten zijn echter niet gestandaardiseerd over organisaties, waardoor er een grote hoeveelheid van (deels soortgelijke) diensten in de dienstencatalogi staan, wat een grote administratieve lasten, onderhoudslasten en doorlooptijden levert. Dit maakt het lastig schaalbaar. Daarbij komt dat er behoefte is aan meer fijnmaziger vormen van machtiging om ervoor te zorgen dat alleen strikt noodzakelijke toegang wordt verstrekt. De enige manier om hier in de huidige voorzieningen mee om te gaan is door hier extra diensten voor te definiëren, wat tot een explosie aan diensten leidt. Er zijn ook partijen die graag een verzameling diensten als geheel machtigbaar zouden willen maken. Het is echter ook niet mogelijk om diensten gelaagd te definiëren.
Toegankelijkheid voor minder digitaal vaardigen	Het rapport "Digitale identiteit vraagt veel van DigiD en eHerkenning" van de Algemene Rekenkamer uit 2023 stelt dat DigiD en eHerkenning identificatiemiddelen niet optimaal werken voor minder digitaal vaardigen. Ook het aanvragen van DigiD machtigen blijkt lastig voor minder digitaal vaardigen. Ze kunnen wel door een beoogd gemachtigde een machtiging laten aanvragen of de machtiging via andere kanalen aanvragen. De betrouwbaarheid van die andere kanalen is wel lager en deze betrouwbaarheid wordt ook niet expliciet vastgelegd.
Vertegenwoordigen werkt nog niet voor iedereen	Professionele dienstverleners zoals bewindvoerders kunnen in veel gevallen niet overal digitaal als vertegenwoordiger optreden. Dat geldt ook voor ouders van minderjarige kinderen, curatoren, bewindvoerders, mentoren van volwassenen en mensen die ouderlijk gezag hebben. Dit probleem wordt verergerd doordat steeds meer diensten om hogere betrouwbaarheidsniveaus vragen, waardoor identificatiemiddelen niet meer eenvoudig kunnen worden gedeeld met vertegenwoordigers. Het vertegenwoordigen van en door buitenlandse organisaties werkt ook niet, als deze organisaties niet in het Handelsregister zijn opgenomen.

4 Gewenste situatie

Dit hoofdstuk geeft een overzicht van de gewenste situatie met betrekking tot toegang. Het start met een architectuurvisie die een overkoepelende beschrijving geeft van de gewenste situatie. Vervolgens worden architectuurprincipes beschreven die deze meer concreet maken. Op basis hiervan worden veranderinitiatieven voorgesteld, die aangeven welke nieuwe afspraken, standaarden of voorzieningen of wijzigingen daarin wenselijk zijn.

4.1 Architectuurvisie

4.1.1. Vertrouwen

Het is belangrijk dat iedereen op een veilige en betrouwbare manier gebruik kan maken van publieke diensten. Dit vraagt dat de identiteit van een gebruiker wordt vastgesteld en gecontroleerd als deze een dienst wil afnemen. Daarbij is vertrouwen een kernwoord. Voor veel maatschappelijke processen is het vertrouwen dat je zaken doet met de juiste organisatie of persoon cruciaal. Een dienstverlener wil kunnen vertrouwen op de identiteit van gebruikers; het is een vertrouwende partij. Daarvoor moet deze dienstverlener kunnen vertrouwen op partijen die verklaringen kunnen afgeven over de identiteiten van deze gebruikers. Voor het bouwen van vertrouwen kunnen partijen gebruik maken van vertrouwensnetwerken, waarin zij onderling afspraken hebben gemaakt. Burgers willen erop kunnen vertrouwen dat organisaties op een zorgvuldige manier omgaan met hun persoonsgegevens.

Het doel van de herziene eIDAS verordening is om EU-breed vertrouwen te creëren en daarmee de condities voor een veilige digitale ruimte, voor zowel burgers als bedrijven. Om vertrouwen te creëren tussen partijen zijn er vertrouwensdiensten nodig die hierin kunnen ondersteunen. De eIDAS verordening beschrijft deze vertrouwensdiensten. Het gaat onder meer om diensten voor het zetten van elektronische handtekeningen (door mensen), het elektronisch verzegelen van gegevens (door een organisatie), het creëren van elektronische verifieerbare verklaringen, het creëren van elektronische tijdstempels en het beschermen en bewijzen van elektronische uitwisseling van gegevens. Deze diensten worden aangeboden of ondersteund door leveranciers in de markt en zijn voor organisaties inzetbaar voor het ondersteunen van het verstrekken van toegang en het uitwisselen van gegevens.

In meer algemene zin vraagt vertrouwen expliciete aandacht voor een aantal morele en publieke waarden. Daarbij staan gebruikers centraal. De volgende figuur geeft een overzicht van voor toegang relevante waarden en hun impact: privacy, transparantie, keuzevrijheid, veiligheid, toegankelijkheid en gebruikersvriendelijkheid. Gebruikers willen dat hun privacy is geborgd, dat ze inzicht hebben in hun gegevens en alle handelingen m.b.t. toegang en dat ze kunnen kiezen welke diensten ze wel of niet afnemen en welke identificatiemiddelen ze daarbij gebruiken. Ze verwachten dat de veiligheid van de diensten is geborgd. Tegelijkertijd verwachten ze dat deze diensten wel toegankelijk en gebruikersvriendelijk zijn. Daarmee wordt niemand buitengesloten en wordt het gebruikers niet onnodig ingewikkeld gemaakt. In de volgende paragrafen worden deze waarden en hun impact verder uitgewerkt.

4.1.2 Privacy, transparantie en keuzevrijheid

Privacy gaat over het beschermen van de persoonlijke levenssfeer. Dat kun je niet los zien van transparantie en keuzevrijheid. Toegang gaat in de basis over het uitwisselen van identiteitsgegevens. Gebruikers willen dat deze identiteitsgegevens worden beschermd, maar willen daarbij ook inzicht in welke identiteitsgegevens nodig zijn voor het afnemen van een dienst. Als zij vinden dat de gevraagde gegevens niet in verhouding staan tot de waarde die de dienst levert, dan willen zij ervoor kunnen kiezen deze dienst niet af te nemen. Belangrijke kanttekening daarbij is dat dit met name geldt voor private diensten. Publieke diensten zijn voor een groot deel wettelijk bepaald en gebruikers hebben daarbij veelal niet de luxe om te kiezen deze diensten niet af te nemen. Privacy, transparantie en keuzevrijheid zijn ook de kern van regie op gegevens. Ook in de gegevensruimtes zoals voorgesteld in de Europese datastrategie hebben genoemde waarden een belangrijke rol. Partijen bepalen zelf aan wie zij hun gegevens in een gegevensruimte willen verstrekken en zijn daar alleen toe bereid alleen als zij vertrouwen hebben in de identiteit en bevoegdheden van andere partijen. Dit wordt ook wel datasoevereiniteit genoemd. De standaarden en richtlijnen die daarbij worden voorgeschreven vanuit de eIDAS verordening en de daaruit voortvloeiende uitvoeringsverordeningen zijn daarbij sterk bepalend en hebben dus ook voor gegevensuitwisseling veel impact. De volgende paragrafen gaan in op een aantal andere aspecten en oplossingen die relevant zijn in het kader van privacy, transparantie en keuzevrijheid.

Een belangrijk aspect van privacy is dataminimalisatie. Organisaties zouden niet meer gegevens moeten verwerken dan wat nodig is voor hun gebruiksdoel (en waarvoor ook een grondslag bestaat). Als het bijvoorbeeld voldoende is om te weten dat iemand 18 jaar of ouder is, zou niet de geboortedatum moeten worden uitgewisseld maar volstaat een ja/nee antwoord. Op basis van het antwoord kan bijvoorbeeld toegang tot een dienst worden geweigerd. Het experiment besluit BRP (2024) sorteert hier op voor door uitwisseling van informatieproducten in plaats van alle (onderliggende) gegevens mogelijk te maken. Voor toegang betekent dit bijvoorbeeld dat de toegangsinfrastructuur niet meer gegevens uitwisselt, dan wat noodzakelijk is om toegang te verstrekken. Als voor het afnemen van een dienst de precieze identiteit niet bekend hoeft te zijn, dan zou deze ook niet moeten worden uitgewisseld.

Self Sovereign Identity (SSI) is een visie op toegang en gegevensuitwisseling waarin privacy, transparantie en keuzevrijheid bij elkaar komen en waarin dataminimalisatie een belangrijke rol speelt. Het idee is dat gebruikers zelf meer in controle zijn en zelf bepalen wie hun identiteitsgegevens mag gebruiken en welke identiteitsgegevens ze mogen gebruiken. Het voorkomt ook afhankelijkheid van centrale partijen. Gebruikers creëren zelf een digitale representatie van hun identiteit, verzamelen verklaringen van verklarende partijen en verstrekken ze zelf aan dienstverleners. Verklarende partijen hebben in deze visie ook geen inzicht in de diensten die gebruikers afnemen. Gebruikers kunnen ook dingen over zichzelf verklaren. Ze hebben een persoonlijke omgeving waarin zij hun verklaringen beheren, die niet toegankelijk is voor anderen. Een dienstverlener die wil controleren of de identiteitsgegevens of een verklaring die een gebruiker verstrekt kloppen en nog geldig is kan gebruik maken van een registratie van verifieerbare gegevens. Deze registratie bevat ook gegevens over de (decentrale) identiteiten die gebruikers zelf hebben aangemaakt. Overigens kan een gebruiker ook besluiten een verklaring niet volledig door te geven aan een dienstverlener, maar alleen een subset of afgeleid gegeven (zoals dat deze ouder dan 18 jaar is). Dit heet ook wel een verifieerbare presentatie. Het zorgt er dus voor dat een dienstverlener alleen beschikt over de gegevens die relevant zijn voor het doel. De volgende figuur geeft een overzicht van de rollen en gegevensstromen. De scope van SSI is nadrukkelijk breder dan toegang; veel van de verklaringen zullen over gegevens gaan die voor toegang niet relevant zijn. Er zijn al allerlei oplossingen om SSI te ondersteunen, in de vorm van personal data management oplossingen (ook wel: wallets).

De EDI Wallet zoals voorgesteld in de eIDAS 2.0 verordening kun je zien als een invulling van SSI. Het biedt een Europees gestandaardiseerde manier om verifieerbare verklaringen uit te wisselen, op basis van specifieke standaarden. De EDI wallet is bruikbaar als identificatiemiddel (op betrouwbaarheidsniveau hoog), maakt het mogelijk om transacties en documenten te ondertekenen en ondersteunt het delen van gegevens. Gebruikers kunnen zelf verifieerbare verklaringen ophalen en bepalen zelf aan wie ze deze verklaringen verstrekken. Hiermee wordt het voor burgers en organisaties mogelijk om meer zelf in controle te komen van de gegevens die ze delen met dienstverleners. In tegenstelling tot de SSI visie wordt vooral gebruik gemaakt van door de overheid uitgegeven identiteitsgegevens die ook in andere Europese lidstaten kunnen worden gebruikt. Het is wel mogelijk om bij het gebruik van de EDI wallet als identificatiemiddel een pseudoniem te gebruiken. De eIDAS verordening onderkent dat er onderscheid is in gekwalificeerde en niet gekwalificeerde verklaringen. Gekwalificeerde verklaringen voldoen aan extra eisen en zijn uitgegeven door toegelaten vertrouwensdienstverleners die aan gestelde eisen voldoen, waardoor ze extra zekerheden bieden. De verordening gaat ervanuit dat elke lidstaat één of meerdere EDI wallets erkent en deze beschikbaar stelt aan haar burgers en bedrijven. De lidstaat voorziet de wallet(s) van identiteitsgegevens waarmee de persoon zichzelf kan identificeren en toegang kan krijgen tot zowel publieke als private diensten. Met de EDI wallet ontstaat er een nieuw soort identificatiemiddel. Er zullen in de toekomst mogelijk ook andere publieke en private identificatiemiddelen beschikbaar komen voor burgers en bedrijven. Er zal bijvoorbeeld een publiek (gratis) zakelijk identificatiemiddel beschikbaar worden gesteld, die in ieder geval bij de Belastingdienst kan worden gebruikt (motie van der Molen). Gebruikers kunnen zelf kiezen welk identificatiemiddel ze willen gebruiken, passend bij het gevraagde betrouwbaarheidsniveau.

In voorgaande wordt duidelijk dat verifieerbare verklaringen in de toekomst een belangrijke rol zullen krijgen in de context van SSI in algemene in en de EDI wallet in het bijzonder. Wij zien dat verifieerbare verklaringen ook los van deze ontwikkelingen waardevol zijn. Door gebruik te maken van verifieerbare verklaringen is het mogelijk om te controleren dat gegevens valide, integer, authentiek en geldig zijn. Ze zorgen voor een mate van vertrouwen in de gegevens die worden uitgewisseld. Het onderscheid tussen toegang en gegevensuitwisseling vervaagt ook door het gebruik van verifieerbare verklaringen. Verifieerbare verklaringen kunnen gaan over identiteitsgegevens die relevant zijn voor toegang, maar kunnen ook relevant zijn voor het verlenen van de diensten zelf en voor gegevensuitwisseling in meer algemene zin. Er is synergie gewenst tussen de afspraken, standaarden en voorzieningen voor gegevensuitwisseling en voor toegang. Verifieerbare verklaringen maken ook meer decentrale gegevensuitwisseling mogelijk. Dat betekent voor toegang dat identiteitsgegevens uit allerlei bronnen kunnen komen. Dat geldt ook voor machtigingen, die uiteindelijk ook gewoon identiteitsgegevens zijn. Dat betekent dat het belang van centrale machtigingsvoorzieningen afneemt. Alhoewel veelvoorkomende vormen van machtiging daarmee prima kunnen en moeten worden ondersteund, zullen er daarnaast dus vooral ook allerlei decentrale machtigingsregistraties zijn. Gebruikers willen wel hun verstrekte en ontvangen machtigingen op één plaats kunnen inzien. In meer algemene zin hebben afspraken de voorkeur boven standaarden boven voorzieningen.

4.1.3 Veiligheid

Gebruikers en dienstverleners moeten erop kunnen vertrouwen dat dienstverlening op een veilige manier verloopt. Organisaties moeten voldoende beveiligingsmaatregelen nemen om de impact van mensen met kwade bedoelingen zoveel mogelijk te beperken. Voor diensten moet duidelijk zijn wat het gevraagde betrouwbaarheidsniveau is, zodat ook duidelijk is welke identificatiemiddelen gebruikt kunnen worden. Ook bij het verstrekken van machtigingen is belangrijk dat het betrouwbaarheidsniveau bekend en vastgelegd is. Het vaststellen van het betrouwbaarheidsniveau van diensten is een kern van de Wdo. Er is een nieuwe versie van de handreiking betrouwbaarheidsniveaus, die aanvullend is op de Wdo en de Regeling betrouwbaarheidsniveaus. De EDI wallet maakt het mogelijk om een gebruiker te authenticeren op niveau hoog. Er zouden ook andere middelen beschikbaar moeten zijn op niveau hoog, zodat gebruikers niet gedwongen worden de EDI wallet te gebruiken. Uit onderzoek van Logius blijkt dat dit met de huidige identificatiemiddelen zou kunnen door gebruik te maken van remote identity proofing.

Er is toenemend aandacht voor zero-trust. De algemene standaard voor informatiebeveiliging (ISO 27002:2022) benoemt expliciet dat organisaties ‘zero trust’-beginselen behoren te overwegen. Deze algemene standaard is ook de basis voor de nieuwe Baseline Informatiebeveiliging Overheid (2.0), die ook verplicht zal worden voor overheidsorganisaties in de context van de nieuwe Cyberbeveiligingswet. Zero-trust betekent dat er niet van wordt uitgegaan dat gebruikers, apparaten en het netwerk vertrouwd kunnen worden. Alle toegang tot resources wordt voortdurend geverifieerd en gevalideerd. Contextuele en adaptieve toegangscontrole is ook een expliciet onderdeel van zero-trust. Het betekent verder ook dat toegang wordt beperkt tot dat wat strikt noodzakelijk is voor het uitvoeren van taken (least privilege). Als er sprake is van een inbraak of ander ernstig incident dan moet snel kunnen worden ingegrepen, en gecompromitteerde partijen moeten snel kunnen worden ontkoppeld van de toegangsinfrastructuur.

Organisaties zullen verder specifiek aandacht moeten geven aan allerlei nieuwe cyberdreigingen en een deel van de (overheids)organisaties wordt daar door de Europese NIS2-richtlijn ook toe gedwongen. Er geldt een zorg-, melding- en registratieplicht en organisaties vallen onder toezicht. Dit betekent bijvoorbeeld dat zij expliciet een risicobeoordeling moeten uitvoeren, gebruik moeten maken van sterke authenticatie en dat ze een plicht hebben om incidenten binnen 24 uur te melden. Dit laatste vraagt om detectie en monitoring van security-relevante gebeurtenissen. Er zou ook landelijk inzicht moeten zijn mogelijke identiteitsfraude, zodat over de grenzen van authenticatiediensten heen misbruik kan worden gedetecteerd en afgehandeld. Overheidsorganisaties hebben daarin een bijzondere positie omdat ze vaak als essentiële entiteiten worden beschouwd. Dit betekent dat ze een cruciale rol spelen in de continuïteit van essentiële diensten en dat een verstoring van hun netwerk- en informatiesystemen aanzienlijke gevolgen kan hebben voor de samenleving en de economie. De impact van beslissingen van de overheid op het leven van mensen kan ook heel groot zijn. Overheden kunnen net als bedrijven echter op voorhand niet zomaar vertrouwd worden. De overheid bestaat ook gewoon uit mensen is daarmee inherent gevoelig voor fouten en verkeerde intenties. Daarom zouden er extra waarborgen voor overheidsorganisaties moeten zijn voor risico's met betrekking tot privacy en informatiebeveiliging.

Het is verder belangrijk dat organisaties de streefbeeldafspraken voor de informatieveiligheidsstandaarden van Forum Standaardisatie naleven en de verplichte standaarden uitvragen en implementeren. Er is ook specifieke aandacht nodig voor de impact van quantum computing om er voor te zorgen dat versleutelde gegevens onleesbaar blijven. Dit vraagt om quantumveilige cryptografische oplossingen. Het NCSC adviseert organisaties om een actieplan op te stellen.

4.1.4 Toegankelijkheid en gebruikersvriendelijkheid

Het is belangrijk dat iedereen toegang kan krijgen tot diensten, waarbij toegang tot digitale diensten speciale aandacht vraagt. Iedereen moet mee kunnen doen in het digitale tijdperk. Er moet specifiek rekening worden gehouden met mensen die digitaal minder vaardig zijn of die om een andere redenen specifieke aandacht vragen. Het onderscheid tussen digitale en niet-digitale kanalen is in zekere zin ook niet zo relevant meer. Mensen willen op allerlei momenten bepaalde diensten afnemen, gebruiken het kanaal dat ze op dat moment handig vinden en schakelen op een later moment ook weer net zo makkelijk naar een ander kanaal. Toegang moet worden ondersteund door gebruiksvriendelijke voorzieningen en met voldoende instructies door mensen die dat nodig hebben. Naast toegang voor eindgebruikers is er ook toegang tussen systemen noodzakelijk. Daarbij moeten organisaties in andere landen geautomatiseerd toegang kunnen krijgen tot Nederlandse publieke diensten en vice versa. Daarbij zou het voldoende moeten zijn om een Europees gekwalificeerd certificaat te hebben. Vergelijkbaar zouden gebruikers in andere landen ook grensoverschrijdend machtigingen moeten kunnen verstrekken.

Er is een goede balans nodig tussen veiligheid en gebruikersvriendelijkheid. Gebruikers zouden niet moeten worden lastig gevallen met beveiligingsmaatregelen die meer zekerheid creëren dan nodig is voor specifieke gevallen. We moeten ervoor zorgen dat de dienstverlening van de overheid voldoende toegankelijk blijft en geen onnodige drempels opwerpt. Het vaststellen van het juiste betrouwbaarheidsniveau voor toegang tot een bepaalde dienst is daarbij essentieel. Een te hoog betrouwbaarheidsniveau leidt bij gebruikers tot extra handelingen en extra kosten. Gebruikers moeten verder bij het inloggen zoveel mogelijk uniforme ervaring hebben. Bij het inloggen moet daarbij standaard met machtigen en wettelijke vertegenwoordiging rekening worden gehouden. Mensen moeten zich namelijk altijd kunnen laten vertegenwoordigen. Gebruikers die inloggen hebben daarmee naast hun eigen bevoegdheden ook bevoegdheden die horen bij de partijen die ze vertegenwoordigen. Gebruikers willen bij voorkeur ook maar één keer inloggen.

4.2 Architectuurprincipes

Architectuurprincipes zijn richtinggevende uitspraken die vooral uiting geven aan een streven. Ze bestaan uit een stelling die uiting geeft aan de overtuiging die eraan ten grondslag ligt, een rationale die meer informatie geeft over de drijfveren en implicaties die de consequenties beschrijven. Architectuurprincipes moeten als argument worden meegenomen in het maken van keuzes. De architectuurprincipes zijn in de domeinarchitectuur gekoppeld aan de relevante wet- en regelgeving waar ze invulling aan geven en aan de bedrijfsfuncties die ingericht moeten zijn om ze te implementeren. Er is ook een mapping van deze architectuurprincipes op de uitgangspunten in de Architectuur Digitale Overheid 2030 en de principes en implicaties in NORA. Deze geeft een verdere onderbouwing en verdieping van de architectuurprincipes.

1. Iedereen kan toegang krijgen tot diensten

Rationale	Dienstverlening moet voor iedereen toegankelijk zijn en dat betekent dat er ook toegang tot alle diensten verzorgd moet worden. Er mogen geen maatregelen worden genomen die ertoe leiden dat bepaalde groepen of individuen worden gediscrimineerd of uitgesloten. Er is specifieke aandacht nodig voor mensen met een functiebeperking of minder digitaal vaardigen. De focus van de toegangsinfrastructuur ligt op toegang tot digitale publieke diensten, maar faciliteert mogelijk ook toegang tot niet-digitale diensten.
Implicaties	1. Er is bij verantwoordelijken voor de toegangsinfrastructuur zicht op alle groepen van mensen en organisaties die toegang zouden moeten hebben tot een dienst. 2. Er zijn voor alle doelgroepen gezaghebbende bronnen waarin hun identiteitsgegevens worden beheerd en deze registers zijn aangesloten op de toegangsinfrastructuur. 3. De toegangsinfrastructuur legt geen beperkingen op die bepaalde groepen onnodig uitsluiten of benadelen. 4. De toegangsinfrastructuur voldoet aan de eisen van de Digitoegankelijk standaard (die verplicht is via de Wdo), zodat ook mensen met een functiebeperking er zoveel mogelijk gebruik van kunnen maken. 5. Er wordt in de toegangsinfrastructuur expliciet rekening gehouden met minder digitaal vaardigen. 6. Diensten zijn ook via niet-digitale kanalen beschikbaar, inclusief bijbehorende toegangsvoorzieningen. 7. Mensen en organisaties hebben het recht om zich te laten vertegenwoordigen (conform Awb).

2. Toegang is gebaseerd op verifieerbare verklaringen

Rationale	Dienstverleners kunnen vertrouwen op een identiteit als zij hierover verifieerbare verklaringen ontvangen. Door het gebruik van verifieerbare verklaringen is ook minder relevant of bevoegdheden centraal worden geadministreerd. Het verdient de voorkeur om administratie te laten daar waar het hoort.
Implicaties	1. Dienstverleners gebruiken verifieerbare verklaringen voor het verlenen van toegang. 2. Er is bewijs dat een verifieerbare verklaring hoort bij de gebruiker (of vertegenwoordigde). 3. Een verklaring wordt alleen vertrouwd als deze valide, integer, authentiek en geldig is (bepaalde toepassingen staan wel een bepaalde overschrijding van de geldigheidstermijn toe). 4. De mate van vertrouwen in een verklaring is gebaseerd op onder meer het betrouwbaarheidsniveau, de geldigheid, de verstrekker, de actualiteit en of deze gekwalificeerd is. 5. Dienstverleners kunnen verklaringen bij verschillende verklarende partijen ophalen om voldoende vertrouwen te krijgen. 6. Gebruikers kunnen ook dingen over zichzelf verklaren en deze beschikbaar stellen als verifieerbare verklaring. 7. Bij toegang namens een organisatie is er een verifieerbare verklaring die de vertegenwoordigingsbevoegdheid bevat voor het vertegenwoordigen van de organisatie. 8. Verklaringen kunnen ook weer worden ingetrokken en partijen moeten daarom de geldigheid van verklaringen kunnen verifiëren.

3. Organisaties wisselen alleen strikt noodzakelijke gegevens uit

Rationale	Dataminimalisatie is een uitgangspunt in de AVG en betekent dat de persoonsgegevens die worden gebruikt zijn beperkt tot het hoogst noodzakelijke. Dit heeft in de context van toegang vooral betrekking op de verklaringen die worden gevraagd aan verklarende partijen over de identiteiten en de eigenschappen die in deze verklaringen zitten. Informatie is ook niet altijd voor alle handelingen binnen een dienst relevant. Het zou daarom niet passend zijn om specifieke verklaringen en informatie op te halen als niet zeker is dat deze ook daadwerkelijk nodig is. Voor veel diensten is het helemaal niet relevant wie de precieze persoon is, welke BSN daarbij hoort en of deze persoon uit Nederland komt of niet. Voor deze diensten volstaat een pseudoniem. Opsporingsdiensten hebben wel duidelijk andere informatiebehoeften en bevoegdheden. Veel belangrijker is het om te weten of de gebruiker over de juiste bevoegdheden beschikt. Daarnaast kan het nodig zijn om comfortinformatie uit te wisselen. Dat is informatie die strikt genomen niet nodig is, maar wel belangrijk is om betekenisvol informatie te presenteren naar gebruikers in een gebruikersinterface zoals namen van mensen en organisaties.
Implicaties	1. Het is duidelijk wat de wettelijke grondslag en de doelbinding is van het gebruik waarvoor de gegevens worden uitgewisseld. 2. In de toegangsinfrastructuur wordt geregistreerd welke (voor toegang relevante) attributen van entiteiten noodzakelijk zijn om een dienst uit te kunnen voeren. 3. De attributen die dienstverleners vragen zijn strikt noodzakelijk voor de doelbinding. 4. Gebruikers hebben voorafgaand aan hun handelen inzicht in de voor de dienst gevraagde attributen (en kunnen besluiten een dienst niet af te nemen). 5. De toegangsinfrastructuur verstrekt alleen de attributen die eerder zijn geregistreerd bij de dienst. 6. Afhankelijk van het betrouwbaarheidsniveau van de dienst kunnen gebruikers anoniem, met een pseudoniem of met een bekende identiteit toegang krijgen tot de dienst. 7. Als kan worden volstaan met het resultaat van het toepassen van een regel dan worden niet de onderliggende gegevens opgehaald; om te weten of iemand volwassen is hoef je niet zijn geboortedatum te kennen. 8. Bij het gebruik van pseudoniemen, wordt per dienstverlener een apart pseudoniem gebruikt, zodat dienstverleners gezamenlijk geen 'profiel' van een persoon kunnen maken op basis van één pseudoniem. 9. Bevoegde autoriteiten hebben vanuit toezicht en handhaving de mogelijkheid om pseudoniemen te herleiden naar een natuurlijk persoon of organisatie.

4. De toegangsinfrastructuur ontzorgt partijen

Rationale	De toegangsinfrastructuur is in ontwikkeling en evolueert. Er kunnen bijvoorbeeld nieuwe identificatiemiddelen worden toegelaten. Met de herziene eIDAS verordening kunnen straks ook European Digital Identity Wallets worden gebruikt. Daarnaast zijn er allerlei machtigingsdiensten die van toepassing kunnen zijn. Het is inefficiënt voor dienstverleners als ieder voor zich met alle authenticatie- en machtigingsdiensten individuele afspraken en koppelingen moeten maken en beheren. Het is voor bronhouders inefficiënt als zij zelf alles moeten inrichten voor het verstrekken van verifieerbare verklaringen. De GDI is een verzameling afspraken, standaarden en voorzieningen, waarbij afspraken de voorkeur hebben boven standaarden boven voorzieningen.
Implicaties	1. Er zijn afspraken, standaarden en mogelijk ook voorzieningen die het partijen eenvoudiger maken om aan te sluiten op de toegangsinfrastructuur. 2. Voorzieningen worden zoveel mogelijk optioneel gemaakt, zodat partijen ook zelf kunnen besluiten om eigen inrichtingskeuzes te maken. 3. De toegangsinfrastructuur ontzorgt dienstverleners in het verkrijgen van veelvoorkomende (voor toegang relevante) attributen. 4. De toegangsinfrastructuur ontzorgt bronhouders in het verstrekken van verifieerbare verklaringen voor veelvoorkomende (voor toegang relevante) attributen. 5. De toegangsinfrastructuur hanteert voor de uitwisseling van voor toegang relevante attributen dezelfde afspraken en standaarden als de infrastructuur voor gegevensuitwisseling.

5. Toegang tot diensten en gegevens is zo laagdrempelig als mogelijk voor het gevraagde betrouwbaarheidsniveau

Rationale	Veiligheid en gebruikersvriendelijkheid staan op gespannen voet. Een hogere mate van veiligheid vraagt in veel gevallen meer handelingen van gebruikers. Er zijn ook vereenvoudigingen in de toegangsprocessen mogelijk die de veiligheid niet verlagen. Dit is niet alleen vriendelijker voor de gebruiker, het voorkomt ook dat mensen minder veilige omwegen bedenken om hetzelfde te bereiken. Daarnaast zijn alle digitale handelingen drempels voor minder digitaal vaardigen en zouden ook alternatieve kanalen moeten worden geboden.
Implicaties	1. Het optimaliseren van de interne organisatie van toegangsprocessen bij overheidsorganisaties is minder belangrijk dan het bieden van een optimale klantreis. 2. Gebruikers hoeven maar één keer in te loggen (mogelijk wel met herbevestiging) voor een bepaald betrouwbaarheidsniveau om gebruik te maken van verschillende diensten die voldoende hebben aan dit niveau. 3. Dienstverleners eisen geen hoger betrouwbaarheidsniveau dan wat nodig is voor het verkrijgen van toegang tot een dienst (ondanks dat dit wettelijk is toegestaan). 4. Er wordt een aanvullende (step-up) authenticatie uitgevoerd als een gebruiker een handeling wil uitvoeren die een hoger betrouwbaarheidsniveau vraagt dan waarmee deze initieel is ingelogd. 5. Het is een standaard optie om iemand te vertegenwoordigen bij het inloggen, en dit is transparant voor een dienstverlener.

6. Toegang is beperkt tot wat noodzakelijk is

Rationale	Het beperken van toegang tot alleen de diensten en gegevens die strikt noodzakelijk zijn voor het uitvoeren van de activiteiten van een entiteit verhoogt de veiligheid en is een kernaspect van zero-trust. Het aanvalsoppervlak wordt geminimaliseerd, de potentiële schade bij een beveiligingsbreuk wordt beperkt en schade door onbedoelde acties wordt zoveel mogelijk voorkomen. Het vereenvoudigt ook het beheer van bevoegdheden en voorkomt een wildgroei van bevoegdheden. Het stimuleert ook het veiligheidsbewustzijn.
Implicaties	1. Dienstverleners definiëren bevoegdheden voor hun diensten, gegevens en functionaliteiten die zijn afgestemd op de specifieke soorten gebruikers en hun specifieke taken. 2. Machtigingen worden beperkt tot bevoegdheden die precies voldoende zijn voor een vertegenwoordiger. 3. Entiteiten krijgen op basis van hun verifieerbare verklaringen alleen toegang tot diensten, functionaliteiten en gegevens die passen bij de aangeleverde verklaringen. 4. Organisaties hebben processen waarbij de rollen en (vertegenwoordigings)bevoegheden van medewerkers regelmatig worden geevalueerd en aangepast, zoals bij doorstroom en uitstroom. 5. Organisaties geven hun certificaten en/of sleutels niet af aan derde partijen, die daar vervolgens bevoegdheden mee krijgen die ze kunnen misbruiken, maar verstrekken hen alleen een machtiging.

7. Er zijn extra waarborgen bij overheidsorganisaties voor risico's rondom privacy en informatiebeveiliging

Rationale	We gaan er vaak standaard vanuit dat we de overheid kunnen vertrouwen. In de realiteit bestaat de overheid vooral uit mensen en mensen maken fouten en hebben soms verkeerde intenties. De impact van beslissingen van de overheid op het leven van mensen kan echter heel groot zijn. Daarnaast komen we er ook steeds meer achter dat bepaalde machtshebbers andere morele waarden hanteren waardoor de belangen van individuen eenvoudig opzij kunnen worden geschoven. Er zouden daarom waarborgen moeten zijn ingebouwd om te beschermen tegen (medewerkers van) overheidsorganisaties die grenzen willen overschrijden. De fundamentele rechten en vrijheden van individuen moeten worden bewaakt. De NIS2 richtlijn beschrijft ook een aantal maatregelen die een hiervoor een basis kunnen bieden, zoals de verplichting tot het aanwijzen van een toezichthoudende autoriteit. In Nederland is hiervoor de Rijksinspectie Digitale Infrastructuur (RDI) aangewezen.
Implicaties	1. Er wordt bij de uitwerking van maatschappelijke vraagstukken bewust nagedacht over welke gegevens door de overheid moeten worden beheerd en/of mogen worden gedeeld, rekening houdend met beveiligings- en privacyrisico’s, alsook met de fundamentele rechten en vrijheden van individuen. 2. Er worden geen privacy hotspots (grote concentraties van persoonsgegevens) gecreëerd in systemen van individuele (overheids)organisaties als dat kan worden voorkomen door bijvoorbeeld pseudonimisering. 3. Beveiligingsmaatregelen zijn vooraf toetsbaar en achteraf auditeerbaar door de toezichthoudende autoriteit.. 4. Burgers en organisaties hebben regie op hun eigen gegevens (zie principe in domeinarchitectuur gegevensuitwisseling). 5. Burgers en organisaties hebben inzicht in wie toegang heeft gekregen tot gegevens over henzelf en op basis van welk identificatiemiddel, welke vertegenwoordigingsbevoegdheden en welke autorisatieregels.

8. Systemen in de keten autoriseren op basis van de identiteit en de bevoegdheden van de gebruiker die de interactie start

Rationale	Door autorisatie van gebruikers in alle belangrijke systemen in de keten plaats te laten vinden worden beveiligingsrisico's geminimaliseerd. Het voorkomt dat er halverwege de keten met een generieke identiteit (bijvoorbeeld een systeemaccount) toch ongeautoriseerd toegang kan worden verkregen tot persoonsgegevens. Tegelijkertijd kunnen overheidsorganisaties een wettelijke basis hebben om gegevens van gebruikers te delen, zonder dat de gebruiker daar expliciet toestemming voor geeft. In die gevallen is het propageren van de identiteit van de gebruiker niet relevant.
Implicaties	1. Autorisaties in alle systemen in de keten, zijn gebaseerd op de identiteit van de gebruiker. 2. Relevante (delen van) de authenticatieverklaring en bevoegdheidsverklaringen van de gebruiker worden doorgegeven in de keten van gebruikersinterface tot achterliggende systemen.

4.3 Verdieping: rolverdeling

Dit hoofdstuk beschrijft de belangrijkste interactiepatronen die een rol spelen bij toegang en gaat vervolgens in op de belangrijkste rollen, hun verantwoordelijkheden en onderlinge samenhang. Het geeft ook richtlijnen voor deze rollen.

Interactiepatronen

De volgende figuur geeft een overzicht van de belangrijkste interactiepatronen die relevant zijn in het kader van toegang. Het gewenste interactiepatroon voor de toekomst is het patroon waarbij de gebruiker centraal staat omdat deze de privacy maximaal beschermt en de gebruiker maximaal zelf laat bepalen. De overige patronen zijn alleen nodig door beperkingen en keuzes in de huidige situatie.

Interactiepatroon 1: Gebruiker centraal

Het interactiepatroon “gebruiker centraal” komt overeen met de rolverdeling zoals voorgesteld in de context van Self Sovereign Identity en de EDI wallet. Bij dit patroon hebben gebruikers regie op hun eigen gegevens en bepalen ze zelf welke identiteitsgegevens worden verstrekt aan dienstverleners. Aanbieders van identiteitsgegevens hebben ook geen zicht op welke dienstverleners de identiteitsgegevens gebruiken. Daarmee is privacy maximaal beschermd. De gebruiker wordt daarbij dus ondersteund door een wallet, die je kunt zien als een soort authenticatiedienst. Het werkt alleen anders dan een authenticatiedienst. De gebruiker is al eerder geauthenticeerd door aanbieders van identiteitsgegevens bij het laden van verifieerbare verklaringen in de wallet. Bij het verzoek om een dienst kan de gebruiker alle relevante verklaringen verstrekken aan een dienstverlener, inclusief een verklaring over zijn/haar identiteit. Merk op dat machtigingsdiensten ook kunnen worden gezien als een bijzondere vorm van aanbieders van identiteitsgegevens, en in die zin ook niet anders behandeld hoeven te worden.

Interactiepatroon 2: Traditioneel

In meer traditionele interactiepatronen speelt de authenticatiedienst een meer centrale rol. Deze wordt aangeroepen door de dienstverlener en ontvangt bewijs van de identiteit van de gebruiker, bijvoorbeeld in de vorm van een wachtwoord. Als er aanvullende identiteitsgegevens nodig zijn, die niet worden verstrekt door de authenticatiedienst, dan dient de dienstverlener deze zelf op te halen bij andere aanbieders van identiteitsgegevens. Daarmee ligt er veel complexiteit bij de dienstverlener. Daarnaast worden er hoge eisen gesteld aan de beschikbaarheid van de authenticatiedienst en aanbieders van identiteitsgegevens. Dit is het patroon dat ook de kern vormt van DigiD en eHerkenning en dat ook in de toekomst nog veel gebruikt zal worden. Een belangrijke reden daarvoor is dat er niet vanuit kan worden gegaan dat iedereen een wallet heeft, deze is immers niet verplicht. Daarnaast moeten ook andere authenticatiemiddelen kunnen worden ondersteund in de context van de Wet digitale overheid.

Interactiepatroon 3: Ontzorgd door broker(s)

Om dienstverleners te ontzorgen kunnen dienstverleners gebruik maken van brokers, die complexiteit afschermen doordat ze verklaringen van één of meer verklarende partijen kunnen routeren, vertalen en aggregeren. Er bestaan brokers op meerdere niveaus. Zo is een makelaar een standaard rol in de context van eHerkenning en is CombiConnect onderdeel van DigiD. Deze laatste zorgt dat verklaringen over machtigingen worden teruggegeven bij het resultaat van authenticatie met DigiD. Ook de bevoegdhedenverklaringsdienst is een broker; deze aggregeert verklaringen over wettelijke vertegenwoordigingen. Daarnaast kunnen dienstverleners ook andere brokers inzetten, zoals TVS of een commerciële broker. Dit soort brokers zijn in staat om over meerdere soorten authenticatiedienst heen te aggregeren en zorgen dus voor maximale ontzorging. Ze zouden echter niet verplicht moeten zijn voor dienstverleners. Extra schakels in een keten leiden ook tot extra risico’s m.b.t. informatiebeveiliging.

In de volgende paragrafen worden de kernrollen verder beschreven. Bij elke rol worden functies benoemd, gebaseerd op het functiemodel. Er worden ook richtlijnen beschreven, die zijn gebaseerd op onder meer de architectuurprincipes en knelpunten, alsook op van toepassing zijnde wet- en regelgeving. Daarnaast staan er voorbeelden van partijen of voorzieningen die bij deze rol horen. Strikt genomen zijn de beheerpartijen van de voorzieningen de verantwoordelijke voor de rol, maar om redenen van herkenbaarheid staat er de naam van de voorziening.

Gebruiker

Een gebruiker is natuurlijk persoon die gegevens en/of functionaliteit gebruikt voor het uitvoeren van werkzaamheden.

Een gebruiker is bij meer traditionele interactiepatronen de partij die de interactie start door een verzoek te doen bij een dienstverlener en bewijs (zoals een wachtwoord) te verstrekken aan een authenticatiedienst. Bij het interactiepatroon waarbij de gebruiker centraal staat gebruikt deze gebruiker een wallet. Die wallet geeft ook invulling aan de rol authenticatiedienst en heeft daarmee ook de daarbij behorende verantwoordelijkheden. Tegelijkertijd doet de term authenticatiedienst eigenlijk geen recht aan de fundamenteel andere interactie die een wallet ondersteunt. Een wallet lijkt ook in zekere zin op een broker, omdat het in staat is om verklaringen te vertalen en te aggregeren. Tegelijkertijd doet ook die term geen recht aan wat een wallet is..

Aanbieder van identiteitsgegevens

Een aanbieder is verantwoordelijk voor het aanbieden van gegevens van bronhouders op een manier die aansluit bij de behoeften en het gebruik van afnemers. In de context van toegang zijn dat identiteitsgegevens. Een aanbieder van identiteitsgegevens is een verlener van vertrouwensdiensten, omdat deze ook in staat moet zijn om verifieerbare verklaringen te kunnen leveren.

Functies:

Elektronisch verklaren;
Verstrekken identiteitsgegevens.

Voorbeelden: RvIG, KvK, RDW, QTSP.

Een aanbieder van identiteitsgegevens:

biedt identiteitsgegevens aan in de vorm van verifieerbare verklaringen;
kan verifieerbare verklaringen aanbieden die voldoen aan de standaarden voor de EDI wallet (OpenID for Verifiable Credentials en NEN-ISO/IEC 18013-5).

Authenticatiedienst

Een authenticatiedienst geeft authenticatieverklaringen af op basis van een identificatiemiddel.

Voorbeelden: Logius (voor DigiD), eHerkenning authenticatiedienst, EDI Wallet.

Functies:

Uitvoeren authenticatie;
Vastleggen auditlog;
Vastleggen gebruik identificatiemiddel;/li>
Uitloggen;
Bestrijden fraude en misbruik./li>

Een authenticatiedienst:

controleert bij een authenticatieverzoek de authenticiteit en geldigheid van het gebruikte identificatiemiddel bij de verantwoordelijke middelenuitgever;
registreert authenticatieverzoeken en hun resultaat in een auditlog;
registreert metagegevens over authenticatieverzoeken en hun resultaat in een inzageregister dat inzichtelijk is voor gebruikers;
ondersteunt de OpenID Connect standaard conform het Nederlands profiel OpenID.NLGov (geldt niet voor EDI Wallet);
ondersteunt het uitloggen van entiteiten met een bepaalde identiteit;
is verantwoordelijk voor het voorkomen, detecteren, opvolgen en herstellen van fraude met identificatiemiddelen;/li>
stuurt metagegevens over authenticatieverzoeken en hun resultaat door naar centrale misbruikbestrijding./li>

Broker

Een broker biedt één ingangspunt voor het routeren, vertalen en aggregeren van verklaringen van één of meer verklarende partijen.

Voorbeelden: Logius (voor CombiConnect, bevoegdhedenverklaringsdienst en eIDAS koppelpunt), DICTU (voor TVS), eHerkenning makelaar.

Functies:

Orkestreren login;
Vertalen authenticatieverklaring;
Vertalen identifier.

Een broker:

kan het inlogproces richting een eindgebruiker orkestreren;
kan vertalingen uitvoeren op verifieerbare verklaringen;
kan gebruik maken van andere brokers.

Een broker die het inlogproces orkestreert:

biedt gebruikers een klantreis die voldoet aan de afspraken voor het inlogproces;
maakt het standaard mogelijk om iemand te vertegenwoordigen bij het inloggen;
ontzorgt dienstverleners in het verkrijgen van veelvoorkomende (voor toegang relevante) attributen;
ondersteunt de OpenID Connect standaard conform het Nederlands profiel OpenID.NLGov (geldt niet voor EDI Wallet).

Dienstverlener

Een dienstverlener levert volgens afspraken diensten aan een klant. Een dienstverlener is een vertrouwende partij.

Voorbeelden: rijksoverheden, uitvoeringsorganisaties, gemeenten, provincies, waterschappen, commerciële dienstverleners.

Functies:

Auditing, monitoring en misbruikbestrijding;

Autoriseren;

Beheren eigen bevoegdheden.

Een dienstverlener:

biedt diensten die zijn afgestemd op de specifieke soorten gebruikers en hun specifieke taken;
bepaalt voor elke dienst een noodzakelijk betrouwbaarheidsniveau;
eist geen hoger betrouwbaarheidsniveau dan wat nodig is voor het verkrijgen van toegang tot een dienst;
accepteert alle erkende publieke en private identificatiemiddelen;
registreert de attributen die nodig zijn voor het verstrekken van toegang tot een dienst in de toegangsinfrastructuur;
maakt duidelijk welke wettelijke grondslag en doelbinding ten grondslag liggen aan de attributen die worden gevraagd;
maakt duidelijk aan welke derde partijen attributen worden doorgegeven en op basis van welke wettelijke grondslag en doelbinding;
vraagt niet meer attributen dan wat strikt noodzakelijk is voor het leveren van een dienst;
geeft gebruikers voorafgaand aan hun handelen inzicht in de voor een dienst gevraagde attributen;
kan zelf kiezen of deze gebruik maakt van een broker of verifieerbare verklaringen direct haalt bij een authenticatiedienst, machtigingsdienst of andere aanbieder van identiteitsgegevens;
controleert of verifieerbare verklaringen valide, integer, authentiek en geldig zijn;
kan omgaan met gebruikers die andere entiteiten vertegenwoordigen;
minimaliseert het aantal keer dat gebruikers wordt gevraagd om in te loggen;
is zelf verantwoordelijk voor het autoriseren van entiteiten met een bepaalde identiteit;
biedt alleen toegang tot diensten, functionaliteiten en gegevens die passen bij de aangeleverde verklaringen en bijbehorende attributen;
baseert autorisaties in achterliggende systemen op de identiteit van de gebruiker;
registreert gevoelige verwerkingen die een entiteit uitvoert in een auditlog.

Machtigingsdienst

Een machtigingsdienst kan machtigingen vastleggen en op basis daarvan bevoegdheids-verklaringen afgeven. Een machtigingsdienst kan worden gezien als een leverancier van identiteitsgegevens en zou dan ook de daarbij behorende verantwoordelijkheden moeten hebben.

Voorbeelden: Logius (voor DigiD machtigen), eHerkenning machtigingsdienst.

Een machtigingsdienst:

registreert metagegevens over machtigingen, wijzigingen daarin en bevoegdheidsverklaringen die deze afgeeft in een inzageregister dat inzichtelijk is voor gebruikers;
registreert het betrouwbaarheidsniveau waarop een machtiging is afgegeven;
maakt het mogelijk om het betrouwbaarheidsniveau van een machtiging op te hogen;
notificeert vertegenwoordigden en vertegenwoordigers over wijzigingen in machtigingen;
stuurt metagegevens over afgegeven bevoegdheidsverklaringen door naar centrale misbruikbestrijding./li>

Middelenuitgever

Een middelenuitgever draagt zorg voor de uitgifte van erkende identificatiemiddelen aan natuurlijke personen of niet-natuurlijke personen.

Voorbeelden: RvIG (voor paspoort), RDW (voor rijbewijs), Logius (voor DigiD), eHerkenning middelenuitgever, EDI wallet aanbieder.

Functies:

Beheren identificatiemiddelen

Een middelenuitgever:

registreert het uitgeven en intrekken van identificatiemiddelen in een inzageregister dat inzichtelijk is voor gebruikers;
ondersteunt het intrekken van een identificatiemiddel.

5 Verdieping

Dit hoofdstuk beschrijft een verdieping op de architectuurvisie en de architectuurprincipes op de onderwerpen rolverdeling en systeem naar systeem toegang.

5.1 Verdieping: systeem naar systeem toegang

Dit hoofdstuk gaat dieper in op hoe systemen toegang kunnen krijgen tot andere systemen. Het is een onderwerp waarvoor relatief weinig aandacht is, maar dat steeds relevanter wordt door toenemende uitwisseling van gegevens tussen organisaties. Het beschrijft een aantal standaarden en technische mogelijkheden die daarbij gebruikt kunnen worden. Het beschrijft zowel huidige standaarden als een aantal nieuwe standaarden die gebruikt zouden moeten worden. Het geeft ook in meer algemene zin uitleg aan gegevensruimtes, de EDI wallets en het EDI-stelsel NL.

Public Key Infrastructure

Voor de veilige uitwisseling van gegevens tussen systemen wordt gebruik gemaakt van certificaten. Een certificaat is een combinatie van een identiteit en een openbare sleutel die gewaarmerkt is door de uitgever, een certificaatautoriteit. Met deze openbare sleutel kan een ontvanger de identiteit van de zender vaststellen. Certificaten zijn dus gebaseerd op asymetrische cryptografie, waarbij alleen de eigenaar van het certificaat beschikt over een privésleutel en de openbare sleutel wordt gedeeld met anderen. De certificaatautoriteit waarborgt de integriteit en authenticiteit van het certificaat en staat dus in voor de identiteit van de certificaatbezitter. Een public key infrastructure (PKI) is een systeem waarmee uitgiften en beheer van digitale certificaten kan worden gerealiseerd.

PKIoverheid is de public key infrastructure (PKI) van de Nederlandse overheid, waarbij de Staat der Nederlanden de certificaatautoriteit is en verantwoordelijk is voor het stamcertificaat. Hierdoor is PKIoverheid niet afhankelijk van (buitenlandse) commerciële partijen. Dit stelsel is afgestemd op Europese en wereldwijde afspraken en standaarden. PKIoverheid wordt beheerd door Logius. Logius geeft zelf geen certificaten uit; hiervoor zijn commerciële partijen als qualified trust service provider benoemd. PKIoverheid stelt eisen aan de uitgifte van certificaten. Zo moet bijvoorbeeld naar organisaties in een PKIoverheid certificaat worden verwezen met een OIN. Deze OIN systematiek maakt het mogelijk om organisaties te voorzien van een unieke identificatie, ook als ze niet zijn opgenomen in het Handelsregister. Op dit moment zijn er echter bepaalde organisaties (restgroepen) die geen OIN kunnen krijgen en dus ook geen gebruik kunnen maken van PKIoverheid certificaten, zoals buitenlandse bedrijven.

De herziene eIDAS verordening onderkent verschillende soorten PKI certificaten, los van het onderscheid tussen wel of niet gekwalificeerde certificaten. Een Electronic Signature certificaat kan door een persoon gebruikt worden voor het ondertekenen van documenten. Een Electronic Seal (eSeal) certificaat kan door organisaties gebruikt worden voor het verzegelen van documenten. Een Qualified Website Authentication Certificate (QWAC) is bedoeld voor het aantonen van de authenticiteit van een website. Deze QWAC-certificaten zouden ook gebruikt kunnen worden voor het beschermen van communicatie tussen systemen. Er zijn op dit moment echter onvoldoende afspraken tussen lidstaten over organisatie-identificaties om dit praktisch uit te kunnen voeren.

In het algemeen kost het (tijdig) aanvragen en configureren van certificaten relatief veel aandacht van organisaties. Het Automatic Certificate Management Environment (ACME) is een protocol voor het geautomatiseerd uitgeven en vernieuwen van beveiligingscertificaten en kan de gevraagde beheerslast verminderen. Deze standaard is aangemeld bij het Forum Standaardisatie en er zal onderzocht worden of deze standaard formeel onderdeel zou moeten zijn van één van de lijsten van het forum. Het NCSC raadt het gebruik van de standaard reeds aan.

PKIoverheid is ook een belangrijke basis onder de Digikoppeling standaard. Deze richt zich specifiek op beveiligde uitwisseling van gegevens. Onderdeel daarvan zijn afspraken over hoe wordt omgegaan met authenticatie bij gegevensuitwisseling. Daarbij vooral wordt verwezen naar het gebruik van PKIoverheid certificaten en het tweezijdig gebruik van TLS. Dat betekent dat zowel het zendende systeem als het ontvangende systeem moet beschikken over een PKIoverheid certificaat. Er zijn ook afspraken en standaarden voor het inhoudelijk versleutelen en ondertekenen van berichten die worden uitgewisseld, als aanvullende beveiligingsmaatregelen nodig zijn.

OpenID Connect en OAuth

De OpenID Connect en OAuth standaarden worden tegenwoordig veel gebruikt om namens een gebruiker een ander systeem te benaderen. Dat is dus altijd in de context van een interactie die is gestart door en gebruiker. OpenID Connect is een protocol dat specifiek gericht is op authenticatie en gezien kan worden als een extensie van OAuth. OAuth is een protocol voor autorisatie en specifiek gericht op het autoriseren van het systeem waarmee een gebruiker interacteert, om namens die gebruiker gegevens van die gebruiker op te halen bij een ander systeem.

Er zijn Nederlandse profielen opgesteld voor OpenID Connect en OAuth: OpenID.NLGov en NL GOV Assurance profile for OAuth 2.0. Beiden staan op de "pas toe of leg uit" lijst van Forum Standaardisatie. Het Overheidsbreed Beleidsoverleg Digitale Overheid (OBDO) heeft besloten dat er een transitie van SAML naar OpenID.NLGov moet worden ingezet. Het OAuth profiel wordt op dit moment doorontwikkeld, waardoor het beter zal aansluiten op de FSC standaard (zie verderop) en ondersteuning zal bieden voor token exchange waarmee identiteiten van eindgebruikers kunnen worden doorgegeven in de keten.

Het gebruik van OpenID Connect en OAuth werkt ongeveer als volgt. Een gebruiker voert gebruikersnaam en wachtwoord in en deze worden gecontroleerd bij een OpenID Connect Provider. Na succesvolle authenticatie met OpenID Connect ontstaan er drie tokens: een ID-token dat een beschrijving geeft van de ingelogde gebruiker, een access token dat gezien kan worden als de authenticatieverklaring en een refresh token dat gebruikt kan worden om het access token te vernieuwen als het is verlopen. De tokens worden door het systeem dat ze heeft verkregen doorgegeven aan het systeem dat wordt aangeroepen. Deze heeft daarmee toegang tot gegevens over de identiteit van de eindgebruiker en weet dat persoonsgegevens die daarbij horen kunnen worden geleverd aan het aanroepende systeem.

Op dit moment ondersteunen DigiD en eHerkenning nog geen OpenID Connect, maar de SAML standaard. Dat betekent dat het gebruik van OpenID Connect en OAuth vooralsnog alleen gebruikt kan worden in scenario’s waarin geen DigiD of eHerkenning wordt gebruikt. Denk daarbij bijvoorbeeld aan scenario’s om toegang te geven aan medewerkers voor het gebruik van systemen van de werkgever van deze medewerker (en daarmee de daaronder liggende systemen).

Federated Service Connectivity

De Federated Service Connectivity (FSC) standaard is ontwikkeld in de context van het Common Ground programma voor gemeenten. Het standaardiseert de werking van tussenliggende componenten dat het gebruik van API’s vereenvoudigt. De standaard wordt inmiddels ondersteund door verschillende leveranciers en is gepositioneerd als een brede standaard die door alle overheidsorganisaties kan worden gebruikt. Het is voorgesteld als onderdeel van het Digikoppeling profiel voor REST API’s, maar kan in bredere zin worden gebruikt voor gegevensuitwisseling tussen systemen over HTTP.

De kern van de FSC standaard is dat het een vertrouwensnetwerk kan creëren tussen systemen door het creëren van contracten tussen partijen. De API's die worden aangeboden en de bijbehorende contracten worden geregistreerd in een directory, waarvan er meerdere kunnen zijn. In een directory kunnen API's worden gezocht en op basis daarvan kunnen ze worden aangeroepen door systemen, waarbij het resulterende berichtenverkeer verloopt over tussenliggende FSC componenten. Er is een tussenliggend componenten bij het zendende systeem (outway) en een tussenliggend component bij het ontvangende systeem (inway). In deze componenten kan ook extra functionaliteit worden aangeroepen, zoals het loggen van de berichten. Hiervoor wordt een transactie-identificatie gegenereerd, die bij elkaar behorende berichten kan correleren. Daarnaast zijn er manager componenten die vooral verantwoordelijk zijn voor de contractafhandeling. Vanuit het perspectief van toegang is met name relevant dat authenticatie en autorisatie van afnemers door aanbieders een integraal onderdeel is van de standaard. Verder is het mogelijk om machtigingen tussen systemen toe te kennen. Hierdoor kan een systeem van een derde partij (bijvoorbeeld een SaaS leverancier) een machtiging ontvangen om namens een overheidsorganisatie gebruik te maken van een ander systeem. Dit voorkomt dat er certificaten en/of sleutels aan deze derde partij moeten worden verstrekt, wat vanuit beveiligingsperspectief onwenselijk is. FSC gaat zelf ook uit van het gebruik van certificaten, waarbij voor de communicatie over organisatiegrenzen gebruik moet worden gemaakt van PKIoverheid certificaten. Het gaat ervan uit dat er een eenduidig vertrouwensraamwerk van certificaten bestaat. Het maakt verder gebruik van de OAuth standaard voor authenticatie van verzoeken.

Gegevensruimtes

Gedreven vanuit de Europese datastrategie is er veel aandacht voor gegevensruimtes (data spaces). Er moet een Europese gegevensruimte komen, een interne markt voor data, waar zowel overheidsorganisaties als bedrijven gebruik van kunnen maken. Binnen deze Europese gegevensruimte ziet de Europese Commissie negen gemeenschappelijke gegevensruimtes ontstaan voor specifieke sectoren. De precieze inrichting van veel van deze gegevensruimtes is nog onduidelijk. Veel van de ideeën en ontwikkelingen rondom gegevensruimtes kunnen we breder omarmen. Je kunt gegevensruimtes zien als afsprakenstelsels en vertrouwensnetwerken waarbinnen gegevens tussen systemen kunnen worden uitgewisseld. Er zijn inmiddels allerlei referentie-architecturen voor gegevensruimtes beschikbaar van bijvoorbeeld OpenDEI, de International Data Spaces Association (IDSA), en het Data Spaces Support Center (DSSC). Er zijn verschillende partijen die hierop zijn ingesprongen en die oplossingen bieden om gegevensruimtes te ondersteunen. De referentie-architectuur van IDSA wordt ondersteund door generieke softwarecomponenten en een uitwisselprotocol. Daarnaast zijn er andere initiatieven zoals iShare en GAIA-X die oplossingen bieden. Een uitgebreider overzicht van dit soort initiatieven is beschikbaar in de verkenning die Geonovum heeft uitgevoerd.

Een gemeenschappelijk vertrekpunt bij al deze initiatieven is datasoevereiniteit, wat betekent dat gegevenseigenaren zelf willen kunnen beslissen over het beschikbaar stellen van hun gegevens. Als gevolg daarvan bieden ze allemaal gemeenschappelijke diensten voor toegang, waarbij vooral gebruik wordt gemaakt van (profielen op) internationale standaarden. Uitgangspunt daarbij is dat voorwaarden en regels van data-aanbieders zoveel mogelijk geautomatiseerd worden gecontroleerd als een afnemer om gegevens vraagt. Een aantal initiatieven biedt daarbij ondersteuning voor Policy Based Access Control, waarbij voorwaarden zoveel mogelijk in machineleesbare vorm als autorisatieregels zijn beschreven zodat ze geautomatiseerd kunnen worden getoetst. Het is daarmee te zien als een uitbreiding op attribute based access control, waarbij er autorisatieregels worden toegepast op de beschikbare attributen. In onderstaande figuur is de essentie van Policy Based Access Control beschreven aan de hand van de begrippen in de veelgebruikte XACML standaard. Naast de XACML standaard bestaat ook de ODRL standaard, die meer vanuit Digital Rights Management komt maar erg vergelijkbaar is met XACML en die ook breder wordt omarmd. Policy Based Access Control is ook een belangrijk aspect van een Zero Trust architectuur.

In Policy Based Access Control zijn er verschillende componenten. De autorisatieregels (policies) worden beheerd in een Policy Administration Point (PAP). Ze worden gebruikt in een Policy Decision Point (PDP) die ze interpreteert om er een autorisatiebeslissing op te baseren. Deze beslissing wordt afgedwongen in een Policy Enforcement Point (PEP) naar aanleiding van een verzoek dat wordt gesteld door een systeem. Het Policy Information Point (PIP) stelt hiervoor identiteitsgegevens beschikbaar. Naast een autorisatiebeslissing levert het PDP ook verplichtingen (obligations) op, die leiden tot specifieke acties die randvoorwaardelijk zijn om toegang te kunnen krijgen. Voorgaande begrippen worden vaak ook breder gebruikt in de context van toegang. Ze vormen een soort referentie-architectuur voor toegang. Wat verder belangrijk is in de context van Policy Based Access Control is dat er ook allerlei eigenschappen van de identiteit, de actie, de resource en de context kunnen worden gebruikt om autorisatiebeslissingen op te baseren. Denk bijvoorbeeld aan de tijd waarop de beslissing wordt genomen of de locatie van de identiteit. Het ondersteunt daarmee contextuele en adaptieve toegangscontrole.

In de IDS RAM wordt aanvullend op access control gesproken over usage control. Dit is een uitgebreidere vorm van toegangscontrole waarbij controles ook aan de kant van de afnemer plaats vinden. Deze verregaande vorm van controle stelt dus allerlei eisen aan de afnemer. Deze worden in die architectuur voor een belangrijk deel geborgd in de connector van de afnemer. Connectoren zijn een kernonderdeel van die architectuur en de plaats waar aan de kant van aanbieder en afnemer allerlei functionaliteit zoals controles kunnen worden ingebouwd. Naar verwachting zal usage control alleen in hele specifieke contexten relevant zijn, waarin hele hoge eisen worden gesteld aan de beveiliging van gegevens.

EDI Wallet

European Digital Identity wallets zullen in de toekomst ook gebruikt kunnen worden door organisaties. Hoe dit precies zal werken is nog niet duidelijk, maar naar verwachting zal dat grotendeels analoog werken aan hoe deze wallets door burgers gebruikt zullen worden. De vraag is of zij ook gebruikt kunnen worden voor communicatie tussen systemen van organisaties. Dat is op dit moment ook nog niet duidelijk.

Het EDI-stelsel NL dient toe te groeien naar een stelsel waarin in ieder geval de uit de eIDAS-revisie voortvloeiende rollen en voorzieningen functioneren. Het betreft onder meer:

id-wallets die door Nederland zijn toegelaten en gecertificeerd,
id-wallets die door andere lidstaten zijn toegelaten en gecertificeerd,
publieke en private (authentieke) bronnen,
publieke en private dienstverleners die voor dienstverlening vertrouwen op (gegevens uit) id-wallets,
gekwalificeerde verleners van vertrouwensdiensten voor het uitgeven van verifieerbare verklaringen, elektronisch ondertekenen en verzegelen,
registraties van leveranciers van identiteiten, leveranciers van wallets en vertrouwende partijen,
validatie- en authenticatiemechanismen voor dienstverleners, id-wallets, digitale identiteiten en gekwalificeerde verifieerbare verklaringen.

Er is voor de borging van de veiligheid en betrouwbaarheid nodig dat er geaccrediteerde conformiteitsbeoordelingsinstanties zijn voor de certificering van id-wallets (en vertrouwensdiensten) en dat er één of meerdere toezichthouders worden aangewezen om toezicht te houden op de veiligheid en betrouwbaarheid in het stelsel.

Ook reeds bestaande (nationale) voorzieningen zijn van belang voor het stelsel. Er moet gezocht worden naar samenhang tussen het EDI-stelsel NL en wat er onder de Wdo en in het stelsel toegang is voorzien.

De EDI wallet maakt geen gebruik van de OpenID Connect standaard, maar van de OpenID for Veriable Credentials standaard. Dit is een uitbreiding op de OpenID Connect standaard, en biedt expliciete ondersteuning voor het uitgeven en verifiëren van verifieerbare verklaringen. Het is net als OpenID Connect gebaseerd op de OAuth standaard. Het biedt ondersteuning voor verschillende formaten, zoals ISO 18013-5 (mDL), SD-JWT en het W3C Verifiable Credentials datamodel. Daarnaast biedt het ondersteuning voor verschillende cryptografische suites, soorten identifiers en schema’s. Er is inmiddels voor een aantal standaard OpenID Connect oplossingen ondersteuning beschikbaar voor de OpenID for Verifiable Presentations standaard.

5.2 Veranderinitiatieven

De domeinarchitectuur beschrijft veranderinitiatieven die worden voorgesteld omdat ze nodig zijn om ervoor te zorgen dat de digitale overheid kan voldoen aan de beschreven architectuur. Het zijn in eerste instantie alleen voorstellen en ze zijn ook nog niet voorzien van informatie over kosten en baten. Ze zijn vooral input voor nog op te stellen vernieuwingsvoorstellen, in het kader waarvan kosten en baten kunnen worden uitgewerkt. Er is ook bewust voor gekozen om niet alle initiatieven die al deel uitmaken van lopende programma’s of projecten te benoemen, omdat dat weinig meerwaarde heeft. Een deel van de voorgestelde initiatieven loopt reeds, zoals die m.b.t. vertegenwoordigen en meervoudig inloggen. De volgende figuur plot de voorgestelde veranderinitiatieven op de meest passende functie in het functiemodel. De figuur die daarop volgt laat zien hoe de veranderinitiatieven gekoppeld zijn aan de eerder beschreven knelpunten.

Betrouwbaarheidsniveau vastleggen in DigiD machtigen	Het is nodig om het betrouwbaarheidsniveau van de identiteit waarmee een machtiging is afgegeven wordt vastgelegd bij DigiD machtigen. Daarbij is het ook nodig om het betrouwbaarheidsniveau waarmee een machtiging eerder is vastgelegd op te kunnen hogen naar substantieel (en hoog). Dit heeft impact op bestaande dienstverleners en de impact hiervan moet worden bepaald en afgestemd.
Eenmalig inloggen	Dienstverleners moeten ervoor zorgen dat het aantal keren dat gebruikers moeten inloggen wordt geminimaliseerd. Binnen hun eigen dienstverlening zou dat in principe mogelijk moeten zijn. Over dienstverleners heen zou dat met herbevestiging kunnen werken, wat onderdeel is van DigiD.
Inrichten centraal onderzoek en meldpunt fraude en misbruik	Het is wenselijk om één centraal onderzoek- en meldpunt fraude en misbruik in te richten om een goed kwalitatief en kwantitatief beeld te creëren. Dat is in eerste instantie vooral relevant voor eHerkenning, maar in de toekomst ook voor andere identificatiemiddelen.
Migratie van SAML naar OpenID Connect	De positie van de SAML standaard zoals ondersteund door DigiD en eHerkenning is in de markt inmiddels ingenomen door OpenID Connect. Het OBDO heeft besloten dat er een transitie naar OpenID Connect (OpenID.NLGov) ingezet moet worden. Aanbieders van identity diensten zullen daarom komende periode zowel OpenID.Gov als SAML moeten ondersteunen. Uiteindelijk zal de SAML standaard moeten worden uitgefaseerd.
Onderzoek ondersteuning buitenlandse certificaten	Het is op dit moment niet zomaar mogelijk om PKI certificaten van buitenlandse leveranciers te accepteren in voorzieningen in Nederland. Er is onderzoek nodig om te bepalen hoe dit opgelost kan worden. Europees gekwalificeerde certificaten moeten worden ondersteund.
Onderzoeken identificatiemiddel zonder BSN	Er zou een betrouwbaar identificatiemiddel moeten zijn die het mogelijk maakt om zonder BSN in te loggen. Er zijn situaties waarin de dienstverlener deze BSN niet mag verwerken. Voor het nieuwe stelsel toegang zullen in ieder geval ook private partijen gebruik willen kunnen maken van publieke middelen. Dat zou een uitbreiding van DigiD kunnen zijn (met toepassing van pseudonimisering). Het kan ook zijn dat hier alleen de EDI wallet voor wordt gepositioneerd, waarmee het ook mogelijk wordt om met een pseudoniem in te loggen. Het bepalen van de oplossingsrichting vraagt nader onderzoek.
Pin reset voor DigiD hoog	Het is vanuit gebruiksvriendelijkheid en daarmee voor de acceptatie van de EDI wallet belangrijk dat het mogelijk wordt om de pincode van DigiD hoog te kunnen resetten.
Restgroepen ondersteunen	Er zijn allerlei organisatie-restgroepen die niet door eHerkenning worden ondersteund, met name doordat ze niet zijn ingeschreven in het Handelsregister. Er is een entiteitenregister voorzien waarin deze restgroepen kunnen worden beheerd. Tegelijkertijd is het niet per definitie nodig en haalbaar dat er één register komt. Er kunnen ook bestaande registers worden aangewezen en ontsloten. Dit zou expliciet moeten worden onderzocht.
Standaardiseren dienstencatalogi	Er moet worden onderzocht of de dienstencatalogi van DigiD machtigen en eHerkening kunnen worden vereenvoudigd door gebruik te maken van een meer gestandaardiseerde lijst van diensten. Het gebruik van de Uniforme Productnamenlijst ligt daarbij voor de hand. Daarbij zou tevens moeten worden onderzocht in hoeverre een gelaagdheid van diensten mogelijk is.
Uitbreiden machtigingsmogelijkheden	Er is behoefte aan meer uitgebreide en meer fijnmazige vormen van machtigen in DigiD machtigen en eHerkenning machtigen. Een eerste stap zou kunnen zijn om één niveau dieper dan dienst machtigingen te kunnen toekennen. . Een volgende stap is het ondersteunen van zaakmachtigen. De precieze eisen en wensen moeten nog verzameld worden.
Uniformeren gebruikservaring	Er dient een standaard gebruikservaring te worden uitgewerkt en deze dient geïmplementeerd te worden in alle inlogportalen.
Verbeteren toegankelijkheid voor minder digitaal vaardigen	De toegankelijkheid van DigiD en eHerkenning is niet optimaal voor minder digitaal vaardigen. Er is een onderzoek nodig om te bepalen welke verbeteringen nodig zijn en de aanbevelingen uit dat onderzoek moeten worden geïmplementeerd.
Vertegenwoordigen bewindvoerders, curatoren, mentoren en ouderlijk gezag	Bewindvoerders, curatoren, mentoren en mensen die ouderlijk gezag hebben zouden als vertegenwoordiger moeten kunnen optreden. De gezaghebbende bron voor beschermingsbewind is het WvR register van de Raad voor de Rechtspraak. Dit register moet toegankelijk worden gemaakt via de toegangsinfrastructuur.
eHerkenning machtigen met buitenlands middel	Het moet mogelijk gemaakt worden dat organisaties met een buitenlands middel ook mee kunnen doen met machtigingen in eHerkenning.

6 Bijlagen

6.1 Functies

In deze domeinarchitectuur hebben we functies benoemd die in het algemeen relevant zijn voor toegang. De functies beschrijven vooral activiteiten op organisatieniveau (bedrijfsfuncties), maar ze zijn ook te zien als functies van informatiesystemen (applicatiefuncties). Het onderscheid is op dit niveau lastig te maken, mede doordat het afhankelijk is van de mate waarin activiteiten zijn geautomatiseerd. Organisaties zullen zelf moeten bepalen in hoeverre deze functies worden uitgevoerd door mensen en/of informatiesystemen. Daarbij kunnen ze ervoor kiezen om ze door andere organisaties te laten uitvoeren zoals aanbieders of andere soorten intermediairs of dienstverleners. Op landelijk niveau zijn er ook generieke voorzieningen beschikbaar die invulling geven aan een aantal van deze functies. We hebben ervoor gekozen om bij een aantal functies de hoofdactiviteit als naam van de functie te gebruiken, maar de volledige lading van deze functies is dus eigenlijk breder en is beschreven in de definitie ervan. De lijst van functies kan gebruikt worden om inzicht te geven in de huidige en gewenste inrichting van organisatie, processen en informatiesystemen. In de domeinarchitectuur zijn ze gekoppeld aan de architectuurprincipes, bedrijfsobjecten, rollen, voorzieningen en standaarden.

Aansluiten partij	Het toelaten van een dienstverlener, verklarende partij of gebruikersorganisatie tot de toegangsinfrastructuurm, het toetsen of deze kan voldoen aan de bijbehorende afspraken en het intrekken van een eerdere toelating.
Auditing, monitoring en misbruikbestrijding	Het vastleggen van relevante gebeurtenissen rondom toegang om de integere werking aan te kunnen tonen, zo snel mogelijk in te grijpen als de (integere) werking niet gegarandeerd lijkt en om fraude en misbruik te bestrijden.
Authenticeren	Het vaststellen van de identiteit van een entiteit en het verstrekken van een authenticatieverklaring hierover.
Autoriseren	Het op basis van autorisatieregels bepalen of een identiteit beschikt over de benodigde bevoegdheden voor toegang tot resources.
Autoriseren voor dienst	Het bepalen of een identiteit geautoriseerd is voor toegang tot een dienst.
Autoriseren voor functionaliteit	Het bepalen of een identiteit geautoriseerd is voor toegang tot specifieke functionaliteit.
Autoriseren voor gegevens	Het bepalen of een identiteit geautoriseerd is voor toegang tot specifieke gegevens.
Beheren autorisatieregels	Het creëren, vastleggen, verstrekken, wijzigen en (logisch) verwijderen van gegevens over autorisatieregels, die aangeven onder welke condities identiteiten toegang hebben tot welke resources.
Beheren eigen bevoegdheden	Het toekennen en intrekken van bevoegdheden (anders dan vertegenwoordigingsbevoegdheden) en de daarvoor randvoorwaardelijke activiteiten.
Beheren gegevens over diensten	Het creëren, vastleggen, verstrekken, wijzigen en (logisch) verwijderen van gegevens over diensten.
Beheren identificatiemiddelen	Het verstrekken en intrekken van identificatiemiddelen en de daarvoor randvoorwaardelijke activiteiten.
Beheren identiteiten	Het vastleggen, verstrekken, wijzigen en (logisch) verwijderen van (gegevens over) identiteiten.
Beheren machtigingen	Het creëren, vastleggen, verstrekken, wijzigen en (logisch) verwijderen van gegevens over machtigingen.
Beheren resources	Het creëren, vastleggen, verstrekken, wijzigen en (logisch) verwijderen van gegevens over gegevens en functionaliteiten waartoe toegang kan worden verstrekt als resource.
Beheren vertegenwoordigingsbevoegdheden	Het toekennen en intrekken van vertegenwoordigingsbevoegheden en de daarvoor randvoorwaardelijke activiteiten.
Beheren wettelijke vertegenwoordiging	Het creëren, vastleggen, verstrekken, wijzigen en (logisch) verwijderen van gegevens over wettelijke vertegenwoordigingsbevoegdheden.
Bestrijden fraude en misbruik	Het voorkomen, detecteren, opvolgen en herstellen van fraude en misbruik met identificatiemiddelen.
Borgen vertrouwen	Het waarborgen van de veiligheid, betrouwbaarheid en juridische erkenning van digitale transacties.
Controleren conflicterende bevoegdheden	Het controleren van en rapporteren over bevoegdheden van identiteiten die met elkaar kunnen conflicteren.
Controleren verschil tussen huidige en gewenste autorisaties	Het bepalen of de daadwerkelijk in systemen aanwezige autorisaties overeenkomen met de gewenste autorisaties en het inzichtelijk maken van de verschillen.
Creëren bevoegdheidsverklaring	Het creëren en intrekken van een bewijs dat een identiteit een bepaalde bevoegdheid heeft.
Creëren pseudoniem	Het creëren en vastleggen van een pseudoniem die een entiteit identificeert.
Creëren vertegenwoordigingsbevoegdheidsverklaring	Het creëren en intrekken van een bewijs dat een identiteit behorende bij een bepaalde vertegenwoordiger een bepaalde vertegenwoordigingsbevoegdheid heeft.
Elektronisch dateren	Het creëren, verifiëren en valideren van een bewijs dat bepaalde gegevens op een specifiek moment bestaan.
Elektronisch ondertekenen	Het creëren, verifiëren en valideren van een bewijs dat bepaalde gegevens afkomstig zijn van een specifiek natuurlijk persoon.
Elektronisch verklaren	Het creëren, verifiëren en valideren van een verifieerbare verklaring over bepaalde eigenschappen van een entiteit.
Elektronisch verzegelen	Het creëren, verifiëren en valideren van een bewijs dat bepaalde gegevens afkomstig zijn van een specifiek niet-natuurlijk persoon.
Evalueren en bijstellen toegangsinfrastructuur	Het bepalen in welke mate een toegangsinfrastructuur werkt en voldoende waarde oplevert en het aanpassen van afspraken, standaarden en voorzieningen aan nieuwe inzichten.
Identificeren	Het bepalen van de entiteit die behoort bij een identiteit op basis van een verzameling identiteitsgegevens.
Informeren over vertegenwoordigingsbevoegdheden	Het actief attenderen van belanghebbenden en vertegenwoordigers over (wijzigingen in) vertegenwoordigingsbevoegdheden, en het gebruik van vertegenwoordigingsbevoegdheden.
Inzage geven in bevoegdheden	Het ontsluiten van informatie over bevoegdheden, inclusief de koppeling met diensten, dienstverleners, resources en identiteiten.
Inzage geven in vertegenwoordigingsbevoegdheden	Het ontsluiten van informatie over machtigingen en wettelijke vertegenwoordigingen, inclusief het gebruik.
Ontsleutelen pseudoniem	Het terugvertalen van een versleuteld pseudoniem naar het pseudoniem waar het op gebaseerd is.
Organiseren toegang	Het organisatorisch inregelen van afspraken voor toegang.
Organiseren toegangsinfrastructuur	Het creëren van afspraken, het bepalen van standaarden en het inrichten van voorzieningen voor toegang.
Orkestreren inloggen	Het ontvangen en routeren van een verzoek tot authenticatie naar de benodigde verklarende partijen en het verstrekken van een authenticatieverklaring.
Registreren identificatiemiddel	Het creëren en vastleggen van gegevens over een identificatiemiddel en de bijbehorende authenticatiefactoren, inclusief een koppeling met de identiteit.
Toekennen bevoegdheden	Het creëren, wijzigen en verwijderen van relaties van identiteiten of rollen naar bevoegdheden.
Toekennen rollen	Het creëren, wijzigen en verwijderen van relaties tussen identiteiten en rollen en het beheren van de daarvoor noodzakelijke gegevens over rollen.
Toelaten identificatiemiddelen	Het toelaten van identificatiemiddelen tot een toegangsinfrastructuur en het administreren van de daarvoor noodzakelijke gegevens.
Toezicht houden op toegangsinfrastructuur	Het vanuit een onafhankelijke rol controleren of de toegangsinfrastructuur werkt en voldoende waarde oplevert.
Uitgeven identificatiemiddel	Het overhandigen van gegevens en middelen die behoren bij een identificatiemiddel aan de entiteit met de bijbehorende identiteit, volgens een proces dat voldoet aan de normen van een specifiek betrouwbaarheidsniveau.
Uitloggen	Het ervoor zorgen dat gecreëerde authenticatieverklaringen niet meer gebruikt kunnen worden om toegang te krijgen tot resources.
Uitvoeren assessment op aansluiting	Het uitvoeren van een assessment voor de aansluiting van partijen op de toegangsinfrastructuur om de veiligheid ervan te bewaken.
Uitvoeren authenticatie	Het bepalen of er voldoende bewijs is aangeleverd om zeker te stellen dat iemand daadwerkelijk de geclaimde identiteit heeft.
Vastleggen auditlog	Het vastleggen van relevante gebeurtenissen in een auditlog.
Vastleggen gebruik identificatiemiddel	Het vastleggen welk identificatiemiddel is gebruikt bij een authenticatie, zodat daar op een later moment inzicht in kan worden gegeven.
Vastleggen identiteitsgegevens	Het vastleggen van gegevens die horen bij een identiteit.
Versleutelen pseudoniem	Het encrypten van een pseudoniem in de context van een identifcatiemiddel om de privacy of vertrouwelijkheid te beschermen.
Verstrekken gegevens over identificatiemiddelen	Het beschikbaar stellen van gegevens over identificatiemiddelen en hun gebruik.
Verstrekken identiteitsgegevens	Het beschikbaar stellen van identiteitsgegevens.
Vertalen authenticatieverklaring	Het vertalen van een authenticatieverklaring naar een andere vorm, zodat deze breder gebruikt kan worden.
Vertalen identifier	Het vertalen van een identifier van en naar een andere identifier, zoals van een landspecifieke identifier naar een eIDAS Unique Identifier en vice versa.
Wijzigen en beëindigen identificatiemiddel	Het wijzigen van gegevens behorend bij een identificatiemiddel, inclusief het blokkeren en het beëindigen van de geldigheid van een identificatiemiddel.
Wijzigen en beëindigen identiteit	Het wijzigen van de gegevens die horen bij een identiteit, inclusief het beëindigen van de geldigheid van een identiteit.

6.2 Bedrijfsobjecten en begrippen

Bedrijfsobjecten zijn dingen in de werkelijkheid waarover gegevens worden vastgelegd. Een model van bedrijfsobjecten is te zien als een hoog niveau gegevensmodel. Het geeft een overzicht van de belangrijkste begrippen die leiden tot gegevens die organisaties moeten vastleggen. Het is ook bruikbaar als checklist om verantwoordelijkheden van organisaties, mensen, processen en informatiesystemen toe te wijzen. In de domeinarchitectuur zijn ze gekoppeld aan de functies en standaarden.

De begrippen zoals gebruikt in het bedrijfsobjectenmodel zijn onderdeel van de bredere lijst van begrippen zoals gebruikt in dit document. Deze begrippenlijst is waar mogelijk afgestemd met de nieuwe algemene NORA begrippenlijst, die nog in ontwikkeling is. Soms is ervoor gekozen een iets meer specifieke betekenis te hanteren om de rol van het begrip in de context van toegang duidelijker te maken. De toelichtingen zijn ook beperkt en specifiek gemaakt voor wat relevant is in dit document. Voor een meer uitgebreide toelichting wordt verwezen naar de NORA begrippenlijst.

attribuutsoort

Definitie	De definitie van een categorie van attributen.
Toelichting	De gegevens "Jan" en "Katrien" worden als gelijksoortig gezien en worden daarom ondergebracht in Attribuutsoort naam.
Heeft bron	MIM 1.2

authenticatiefactor

Definitie	Iets dat iemand heeft, weet of is en waarmee bewijs kan worden geleverd van de identiteit.
Toelichting	Bij een identificatiemiddel kunnen meerdere authenticatiefactoren horen.

authenticatieverklaring

Definitie	Een verifeerbare verklaring over de uitkomst van een authenticatie.
Alternatieve term	token
Toelichting	In een authenticatie wordt de identiteit van een entiteit vastgesteld. Een authenticatieverklaring verklaart daarmee dat de geautenticeerde entiteit een bepaalde identiteit heeft.

autorisatiebeslissing

Definitie	Het resultaat van het evalueren van autorisatieregels.
Toelichting	Een autorisatiebeslissing bepaalt of een entiteit met een bepaalde identiteit toegang krijgt tot een resource.

autorisatieregel

Definitie	Een regel die is gesteld voor toegang tot een resource en waaraan moet worden voldaan voordat een entiteit met een bepaalde identiteit toegang krijgt tot die resource.
Alternatieve term	policy
Toelichting	Een autorisatiebeslissing bepaalt of een identiteit toegang krijgt tot een resource.

betrouwbaarheidsniveau

Definitie	De mate van zekerheid waarmee identiteitsgegevens, identificatiemiddelen en/of bevoegdheden zijn vastgesteld.
Toelichting	In de Regeling betrouwbaarheidsniveaus wordt onderscheid gemaakt tussen de betrouwbaarheidsniveaus laag, substantieel en hoog.

bevoegdheid

Definitie	Het bezitten van toestemming om een handeling te mogen verrichten.
Alternatieve term	autorisatie
Toelichting	In de context van toegang gaat het vooral over het bezitten van toestemming om gebruik te maken van een resource. Een bevoegdheid kan aan een organisatie of een natuurlijke persoon worden toegekend. Een bevoegdheid is randvoorwaardelijk voor het krijgen van toegang, maar niet voldoende.

bevoegdheidsverklaring

Definitie	Een verifieerbare verklaring over dat een identiteit een bepaalde bevoegdheid heeft.

bron

Definitie	Een registratie die is aangewezen als de plaats waarin gegevens worden beheerd.

dienst

Definitie	Een geheel van handelingen die een dienstverlener beschikbaar stelt.
Toelichting	Een dienst ontsluit gegevens en functionaliteit. In de NORA begrippenlijst wordt hier een hele algemene definitie van gegeven: “Een ondersteunde dienst”. In de context van toegang hebben we het echter specifiek over handelingen en is het ook niet relevant of wel of geen ondersteuning wordt geboden.

dienstverlener

Definitie	Een organisatie die een dienst levert aan een afnemer.

entiteit

Definitie	Een object dat gedrag kan vertonen.
Toelichting	In de context van toegang zijn dit mensen, organisaties, applicaties of apparaten. Er wordt in het “Party-Driven Actor” model van TNO onderscheid gemaakt tussen partijen en actoren. Partijen zijn daarbij de entiteiten die doelen hebben en beslissingen nemen. Actoren zijn de actieve entiteiten die namens partijen handelen. Daarbij zijn organisaties wel een partij, maar geen actor omdat organisaties niet zelf gedrag kunnen vertonen. Applicaties of apparaten zijn wel een actor, maar geen partij omdat ze altijd namens iemand anders gedrag vertonen.

gegeven

Definitie	Een vastgelegde waarneming of bewering over een eigenschap van een object.

gezaghebbende bron

Definitie	Een bron waarin identiteitsgegevens worden beheerd en formeel is erkend als bron hiervoor binnen de toegangsinfrastructuur.

identificatiemiddel

Definitie	Een middel dat verifieerbare verklaringen over identiteitsgegevens kan verstrekken.
Toelichting	In de domeinarchitectuur beschouwen we identificatiemiddelen als authenticatiemiddelen. Het zijn dan middelen die gebruikt worden voor authenticatie. Dit is in lijn met de eIDAS verordening die de term “elektronisch identificatiemiddel” gebruikt met een vergelijkbare betekenis. Niet alle identificatiemiddelen zijn ook authenticatiemiddelen. Zo is een buitenlands paspoort wel een identificatiemiddel, maar kun je deze in Nederland niet als authenticatiemiddel gebruiken. Er zijn ook authenticatiemiddellen die geen identificatiemiddel zijn. Denk bijvoorbeeld aan een toegangspas voor bezoekers of een one-time password generator.

identifier

Definitie	Een identiteitsgegeven dat een entiteit uniek identificeert.
Alternatieve term	digitale identiteit
Toelichting	Dit is in veel gevallen een pseudoniem. Er kunnen ook andere gegevens die gezamenlijk gebruikt kunnen worden om een entiteit te identificeren. Dit noemen we geen identifiers. Er hoeft geen identifier onderdeel te zijn van de verzameling identiteitsgegevens bij een identiteit.
Voorbeeld	DigiD gebruikersnaam, eHerkenning pseudo

identiteit

Definitie	Een verzameling van kenmerkende eigenschappen van een object.
Toelichting	In de context van toegang gaat het vooral over entiteiten. Entiteiten kunnen meerdere identiteiten hebben. De kenmerkende eigenschappen worden gerepresenteerd in de vorm van identiteitsgegevens. In een specifieke gebruikscontext zijn er een beperkt aantal kenmerken relevant. Deze deelverzameling wordt ook wel een deelidentiteit of partiële identiteit genoemd. De term bronidentiteit wordt ook wel gebruikt als een verzameling eigenschappen waarvan de bijbehorende identiteitsgegevens worden beheerd in één of meer gezaghebbende bronnen.

identiteitsgegeven

Definitie	Een gegeven dat een kenmerk van een identiteit representeert.
Alternatieve term	attribuut
Toelichting	Bij één identiteit hoort een verzameling identiteitsgegevens.

machtiging

Definitie	De uitdrukking van de verlening van een bevoegdheid aan een natuurlijk persoon om namens een andere natuurlijk persoon of namens een organisatie handelingen te verrichten.
Alternatieve term	vrijwillige machtiging
Toelichting	Een wettelijke vertegenwoordiging is dus geen machtiging. Aan een machtiging worden geen vormeisen gesteld en kunnen dus zowel mondeling als schriftelijk zijn. Een machtiging is inherent vrijwillig en herroepbaar. Er is juridisch gezien onderscheid tussen verschillende vormen van machtiging. Bij het verrichten van publiekrechtelijke rechtshandelingen wordt gesproken over een mandaat (zie artikel 10:1 van de Algemene wet bestuursrecht). Bij het verrichten van privaatrechtelijke rechtshandelingen wordt gesproken over een volmacht (zie artikel 3:60, lid 1 van het Burgerlijk Wetboek). Bij het verrichten van feitelijke handelingen is sprake van een bestuursrechtelijke machtiging (zie artikel 2:1, lid 1 van de Algemene wet bestuursrecht). Er wordt ook wel onderscheid gemaakt tussen verticale machtigingen en horizontale machtigingen. Een verticale machtiging is een machtiging waarbij een natuurlijk persoon een organisatie mag vertegenwoordigen. Een horizontale machtiging is een machtiging waarbij er een vertegenwoordiging is van een natuurlijk persoon door een ander natuurlijk persoon zonder hiërarchische verhouding.

resource

Definitie	Een dienst, gegevens of functionaliteit waartoe een entiteit met een bepaalde identiteit toegang zou kunnen krijgen.

rol

Definitie	Een set van taken, bevoegdheden en verantwoordelijkheden die door een identiteit ingevuld kan worden.
Alternatieve term	profiel
Toelichting	De voorkeursterm in de NORA begrippenlijst is “profiel”, maar dat is geen gangbare term in de context van toegang.

systeem

Definitie	Een applicatie of een apparaat.
Toelichting	In de NORA begrippenlijst wordt hier een hele algemene definitie van gegeven: “Een samenhangend en geïntegreerd geheel van componenten die elkaar wederzijds beïnvloeden”. In de context van toegang hebben we het echter specifiek over applicaties of apparaten.

verifieerbare verklaring

Definitie	Een verzameling van identiteitsgegevens, vergezeld van een bewijs dat deze afkomstig zijn van een specifieke verklarende partij.
Toelichting	Met een verifieerbare verklaring kan de validiteit, integriteit, authenticiteit en geldigheid van identiteitsgegevens worden gecontroleerd.

verklarende partij

Definitie	Een organisatie die verifieerbare verklaringen uitgeeft.

vertegenwoordigingsbevoegdheid

Definitie	Een machtiging of wettelijke vertegenwoordiging.

vertrouwende partij

Definitie	Een rol die vertrouwt op verifieerbare verklaringen van een verklarende partij.
Toelichting	Met een vertrouwende partij wordt meestal een dienstverlener bedoeld. In de eIDAS verordening is de definitie echter breder: “een natuurlijke of rechtspersoon die vertrouwt op elektronische identificatie, Europese portemonnees voor digitale identiteit of andere elektronische identificatiemiddelen, of op een vertrouwensdienst”.

wettelijke vertegenwoordiging

Definitie	De bevoegdheid van een natuurlijk persoon of organisatie op grond van de wet of een rechtelijke uitspraak om te handelen namens een andere natuurlijk persoon.
Toelichting	Wettelijke vertegenwoordiging gaat onder meer over gezag (zie titel 14 van het Burgerlijk Wetboek), bewind (zie artikel 1:431, lid 1 van het Burgerlijk Wetboek), curatele (zie artikel 1:378, lid 1 van het Burgerlijk Wetboek) of mentorschap (zie artikel 1:450, lid 1 van het Burgerlijk Wetboek).

6.3 Rollen

Rollen zijn een clustering van taken, bevoegheden en verantwoordelijkheden. De architectuur benoemt de belangrijkste rollen in de context van toegang en verbindt ze aan de functies om de belangrijkste verantwoordelijkheden duidelijk te maken.

Aanbieder van identiteitsgegevens Een rol die verantwoordelijk is voor het aanbieden van identiteitsgegevens van bronhouders op een manier die aansluit bij de behoeften en het gebruik van afnemers.
Authenticatiedienst Een rol die op basis van een identificatiemiddel een authenticatieverklaring afgeeft (bron: Wet digitale overheid).
Broker Een rol die één ingangspunt biedt voor het routeren, vertalen en aggregeren van verklaringen van één of meer verklarende partijen.
Bronhouder Een rol die verantwoordelijk is voor het inwinnen, beheren en het verbeteren van de kwaliteit van gegevens.
Centrale misbruikbestrijding Een rol die verantwoordelijk is voor het detecteren van fraude en misbruik met meerdere identificatiemiddelen of bij meerdere dienstverleners.
Dienstverlener Een rol die volgens afspraken diensten levert aan een klant.
Gebruiker Een natuurlijk persoon die gegevens en/of functionaliteit gebruikt voor het uitvoeren van werkzaamheden.
Machtigingsdienst Een rol die machtigingen kan vastleggen en op basis daarvan bevoegdheidsverklaringen kan afgeven.
Middelenuitgever Een rol die zorg draagt voor de uitgifte van erkende identificatiemiddelen aan natuurlijke personen of niet-natuurlijke personen.
Regisseur toegangsinfrastructuur Een rol die verantwoordelijk is voor het inrichten en besturen van een toegangsinfrastructuur.
Toezichthouder Een rol die vanuit een onafhankelijke positie controleert of de toegangsinfrastructuur werkt en voldoende waarde oplevert.
Verklarende partij Een organisatie die verifieerbare verklaringen uitgeeft.
Verlener van vertrouwensdiensten Een natuurlijke persoon of niet-natuurlijke persoon die een of meer vertrouwensdiensten verleent als een gekwalificeerde of als een niet-gekwalificeerde verlener van vertrouwensdiensten.
Vertrouwende partij Een rol die vertrouwt op verifieerbare verklaringen van een verklarende partij.

6.4 Huidige voorzieningen

De Generieke Digitale Infrastructuur bestaat uit een aantal generieke voorzieningen, die breed gebruikt kunnen worden door overheidsorganisaties. In deze paragraaf wordt een overzicht gegeven van de belangrijkste voorzieningen met betrekking tot toegang die we onder de aandacht willen brengen. Deze voorzieningen zijn gerelateerd aan de functies om inzicht te geven in hun functionaliteit. Ze zijn ook voorzien van eigenschappen die beschrijven wie verantwoordelijk is voor het beheer en waar meer informatie over de voorziening kan worden gevonden. De beschrijvingen en modellen zijn gebaseerd op informatie van Logius over de huidige situatie zoals die bestond in mei 2024. Daarmee zijn ze een specifieke momentopname en kan deze afwijken van de situatie zoals die bestaat op het moment van lezen van dit document.

In de volgende diagrammen wordt een overzicht gegeven van de voorzieningen en hun samenhang. De eerste laat zien welke gegevensstromen met name relevant zijn voorafgaand aan een specifiek authenticatieverzoek. Het diagram erna laat met name zien wat er gebeurt tijdens het uitvoeren van een authenticatieverzoek. Er zijn bepaalde gegevensstromen die niet zo eenvoudig in één van deze twee categorieën in te delen zijn, bijvoorbeeld omdat ze in beide situaties afhankelijk van de omstandigheden kunnen plaatsvinden. Die zijn dan in het meest logische diagram geplaatst.

Gegevensstromen voorafgaand aan een authenticatieverzoek

Gegevensstromen tijdens een authenticatieverzoek

Autorisatielijst BSN-gerechtigden	Op de Autorisatielijst BSN-gerechtigden (ALB) staan de organisaties waarvan RvIG heeft vastgesteld dat ze voor hun publieke taken het burgerservicenummer (BSN) mogen gebruiken.
BRP koppelpunt	Een voorziening die zorgt voor het vaststellen of een burger die met een buitenlands middel inlogt al in de BRP bekend is. Het BRP koppelpunt is een departementsverantwoordelijkheid van het ministerie van BZK. Het BRP koppelpunt geeft invulling aan de BZK verantwoordelijkheid voor registratie van natuurlijke personen. Het BRP koppelpunt registreert de koppeling tussen de uniqueness id en het BSN.
BSNk-Activatie	Een voorziening die een polymorfe identiteit (PI) en polymorf pseudoniem (PP) bepaalt op basis van persoonsgegevens.
BSNk-Decryptie	Een voorziening die zorgt voor het omzetten van een VI/VP naar een BSN respectievelijk pseudoniem van een gebruiker.
BSNk-Sleutelbeheer	Een voorziening die de sleutels beheert en verstrekt die gebruikt kunnen worden om een versleutelde identiteit (VI) en versleuteld pseudoniem (VP) terug te vertalen naar een polymorfe identiteit (PI) en polymorf pseudoniem (PP).
BSNk-Transformatie	Een voorziening die een geactiveerde polymorfe identiteit (PI) en polymorf pseudoniem (PP) vertaalt naar een versleutelde identiteit (VI) en versleuteld pseudoniem (VP).
Bevoegdheidsverklaringsdienst	Een voorziening die bevoegdheidsverklaringen opstelt voor een reeds geauthenticeerde identiteit op basis van gezagsverklaringen en bewindsverklaringen.
Bewind	Een voorziening die de bewindsrelatie (bewindvoering, curatele, mentorschap) voor professionele en particuliere vertegenwoordigers bepaalt op basis van actuele gegevens in het wettelijk vertegenwoordigingsregister van de Raad voor de Rechtspraak en hiervoor bewindsverklaring opstelt.
Centrale OIN Raadpleegvoorziening	De Centrale OIN Raadpleegvoorziening (COR) is de voorziening die de uitgegeven openbare Organisatie-identificatienummers (OIN) beheert.
CombiConnect Orchestratie	Een component dat een koppelvlak vormt richting DigiD en DigiD machtigen dat gebruikers routeert o.b.v. of ze alleen voor zichzelf inloggen of voor iemand anders. Alleen het Orchestratie deel, niet de SAML connector in meer algemene zin.
Dienstencatalogus wettelijk vertegenwoordigen	Een registratie van de diensten waarvoor belanghebbenden zich kunnen laten vertegenwoordigen door een wettelijk vertegenwoordiger.
DigiD	Een authenticatiedienst gericht op burgers.
DigiD dienstencatalogus	Een registratie van de diensten voor DigiD en DigiD machtigen.
DigiD machtigen	Een voorziening voor het verstrekken van vrijwilige machtigingen die gebruikt kunnen worden als onderdeel van DigiD.
Gezag	Een voorziening die ouderlijk gezag bepaalt op basis van de actuele gegevens in de BRP en hiervoor een gezagsverklaring opstelt.
Inzageregister	Een registratie van de status van identificatiemiddelen en status van de machtigingsrelatie per machtingsregister.
PROBAS	De protocollaire basisadministratie die gegevens beheert over ambassades.
Register wettelijke vertegenwoordiging rechtspraak	Het wettelijk vertegenwoordigingsregister van de Raad voor de Rechtspraak.
TVS	De ToegangVerleningService (TVS) is een voorziening die het mogelijk maakt om via één koppelvlak meerdere authenticatiediensten te ontsluiten.
Tijdelijk Register Restgroepen	Het Tijdelijk Register Restgroepen (TRR) wordt gebruikt voor organisaties die niet in het Handelsregister kunnen worden ingeschreven en diensten van de Belastingdienst afnemen.
eHerkenning authenticatiedienst	Een rol binnen het eHerkenning stelsel die de verantwoordelijkheid heeft voor het authenticeren van entiteiten of hun vertegenwoordigers.
eHerkenning dienstencatalogus	De registratie van de diensten waarvoor toegang kan worden verstrekt in de context van eHerkenning.
eHerkenning machtigingsregister	Een rol binnen het eHerkenning stelsel die de verantwoordelijkheid heeft voor het registreren, beheren, controleren van machtigingen en andere bevoegdheden en het afleggen van verklaringen over bevoegdheden.
eHerkenning makelaar	Een rol binnen het eHerkenning stelsel die het single point of contact vormt waarlangs dienstverleners eHerkenningsdiensten afnemen, die het berichtenverkeer van en naar de dienstverleners ontkoppelt van de interne berichten binnen het netwerk en die optreedt als routeerder naar alle deelnemende authenticatiediensten en machtigingenregisters.
eHerkenning middelenuitgever	Een rol binnen het eHerkenning stelsel die de verantwoordelijkheid heeft voor het uitgeven van middelen conform de eisen van het gespecificeerde betrouwbaarheidsniveau.
eHerkenning stelsel metadata	De registratie van gegevens over verklarende partijen.
eIDAS koppelpunt	Het Nederlandse eIDAS Koppelpunt faciliteert de interoperabiliteit tussen het Nederlandse stelsel Toegang en de buitenlandse eIDAS koppelpunten. eIDAS koppelpunt houdt een registratie bij van de handelende personen en registreert per persoon de PP/PI.

6.5 Standaarden

In de domeinarchitectuur is een lijst van standaarden opgenomen die relevant zijn in het kader van toegang. De basis voor deze lijst zijn de lijsten van Forum Standaardisatie. We hebben ervoor gekozen om alleen de generieke standaarden op te nemen en niet de toepassingspecifieke standaarden. Deze standaarden zijn aangevuld met andere standaarden die breder worden gebruikt of relevant zijn. Deze aanvullende standaarden zijn te beschouwen als aanbeveling vanuit deze architectuur. De aanbeveling is vooral om deze standaarden te bestuderen en hun inzet te overwegen bij het inrichten of aanpassen van gegevensuitwisseling. De standaarden zijn voorzien van een aantal standaard eigenschappen zoals de beheerorganisatie en een URL naar meer informatie. Ze zijn ook gekoppeld aan functies en bedrijfsobjecten zodat hun toepassingsgebied duidelijk is. Bij de standaarden van Forum Standaardisatie zijn ook de status en het functioneel toepassingsgebied overgenomen. De volgende figuur geeft een overzicht van de standaarden geplot op de meest passende functie in het functiemodel.

ACME	Het Automatic Certificate Management Environment (ACME) is een protocol voor het geautomatiseerd uitgeven en vernieuwen van beveiligingscertificaten.
ASN.1	Abstract syntax notation one (ASN.1) een standaard interfacebeschrijvingstaal voor het definiëren van datastructuren die op een platformonafhankelijke manier kunnen worden geserialiseerd.
AdES Baseline Profiles	De Advanced Electronic Signature (AdES) standaard voorziet in het digitaal tekenen van documenten met een geavanceerde of gekwalificeerde digitale handtekening.
Authenticatie-standaarden	Deze registratie vervangt de afzonderlijke registraties van SAML, NL GOV AP OIDC en OIDC op de lijst open standaarden. Deze gecombineerde verplichting zet een transitie in gang met afbouw van SAML en opbouw naar OpenID.NLGov.
DID	Decentralised identifiers (DIDs) maken het mogelijk om decentraal identiteiten te creëren.
FIDO	Een verzameling normen voor het ondersteunen van wachtwoordloze authenticatie.
FSC	De Federated Service Connectivity (FSC) standaard beschrijft hoe organisaties kunnen interacteren op een uniforme en geautomatiseerde wijze.
JWT	JSON Web Token (JWT) is een compacte, URL-veilige manier om verklaringen uit te wisselen tussen twee partijen.
NEN-ISO/IEC 18013-5	ISO/IEC 18013-5 is een internationale standaard die betrekking heeft op identiteitsdocumenten voor mobiliteitsdoeleinden, met de nadruk op smartphone-toepassingen.
NL GOV Assurance profile for OAuth 2.0	NL GOV Assurance profile for OAuth 2.0 legt bindende afspraken vast over het gebruik van de standaard OAuth 2.0 bij de Nederlandse overheid.
OAuth	OAuth is een standaard voor het autoriseren van systemen op basis van machtigingen van gebruikers.
ODRL	De Open Digital Rights Language (ODRL) is een taal voor het vastleggen van afspraken over gebruik van gegevens en diensten.
OpenID Connect	OpenID Connect (OIDC) is een protocol voor authenticatie, gebaseerd op de OAuth standaard.
OpenID for Verifiable Credentials	Deze standaard maakt het mogelijk om verifieerbare verklaringen te gebruiken in de context van OpenID Connect.
OpenID.NLGov	OpenID.NLGov legt bindende afspraken vast over het gebruik van de standaard OpenID Connect bij de Nederlandse overheid.
SAML	Security Assertion Markup Language (SAML) is een standaard voor het veilig uitwisselen van authenticatie- en autorisatiegegevens van gebruikers tussen verschillende organisaties.
SCIM	System for Cross-domain Identity Management (SCIM) zorgt ervoor dat identiteitsinformatie van gebruikers systeemoverstijgend op de juiste plek aanwezig is.
SD-JWT	Selective Disclosure JWT (SD-JWT) is een standaard die het mogelijk maakt om een subset van verklaringen in een getekende JWT te delen.
SD-JWT VC	SD-JWT-based Verifiable Credentials (SD-JWT VC) is een specificatie die het mogelijk maakt om verifieerbare verklaringen op basis van de SD-JWT standaard te beschrijven en deze ook in JWS JSON te serialiseren.
TOTP	TOTP zorgt ervoor dat een twee-factor authenticatie mogelijk is via een eenmalig wachtwoord dat op dat moment gegenereerd wordt en daarmee nog niet in het bezit was vooraf aan de aanvraag.
Verifiable Credentials	Deze specificatie biedt een mechanisme om beweringen over iets of iemand uit te drukken op een manier die cryptografisch veilig is, de privacy respecteert en machinaal verifieerbaar is.
X.509	X.509 is een standaard die het formaat van digitale certificaten bepaalt.
XACML	Dit is een op XML gebaseerde taal voor het uitdrukken van autorisatieregels.

6.6 Relatie van architectuurprincipes met ADO en NORA

Deze bijlage relateert de architectuurprincipes zoals beschreven in deze domeinarchitectuur aan de uitgangspunten in de Architectuur Digitale Overheid 2030 en de principes en implicaties in NORA. Het levert daarmee een verdere onderbouwing en verdieping van de architectuurprincipes.

Architectuurprincipe	Uitgangspunt in Architectuur Digitale Overheid 2030	Principe of implicatie in NORA
1. Iedereen kan toegang krijgen tot diensten	Gebruikersvriendelijk, begrijpelijk, transparant en toegankelijk voor iedereen	Verplaats je in de gebruiker Maak de dienst toegankelijk voor alle gebruikers Maak de dienst toegankelijk voor anderstaligen
2. Toegang is gebaseerd op verifieerbare verklaringen		Maak stelselafspraken over identificatie en authenticatie
3. Organisaties wisselen alleen strikt noodzakelijke gegevens uit	Overheden mogen alleen persoonsgegevens verwerken als het niet anders kan. Dus: als zij zonder deze gegevens hun doel niet kunt bereiken.	Pas doelbinding toe
4. De Nederlandse toegangsinfrastructuur ontzorgt dienstverleners		Bied één contactpunt (Single point of contact)
5. Toegang tot diensten en gegevens is zo laagdrempelig als mogelijk voor het gevraagde betrouwbaarheidsniveau	Kanalen dienen – waar nodig – ook via machtigen en vertegenwoordigen toegankelijk te zijn.	Verplaats je in de gebruiker Maak beveiligingsmaatregelen zo gebruiksvriendelijk mogelijk Maak toegang tot applicaties en gegevens afhankelijk van authenticatieniveau
6. Toegang is beperkt tot wat noodzakelijk is		Verleen alleen strikt noodzakelijke toegangsrechten
7. Er zijn extra waarborgen bij overheidsorganisaties voor risico's rondom privacy en informatiebeveiliging		Beheers risico's voortdurend Borg de vertrouwelijkheid van gegevens in maatregelen
8. Systemen in de keten autoriseren op basis van de digitale identiteit en de bevoegdheden van de gebruiker die de interactie start

6.7 Betrokkenen

De volgende mensen waren onderdeel van de architectuurwerkgroep toegang en hebben bijgedragen aan de totstandkoming van dit document.

Bert-Jan Geveke, sponsor (DUO)
Ron Beemster, voorzitter (IenW)
Danny Greefhorst, secretaris en redacteur (BZK/Bureau MIDO)
Catelijne de Koning (KvK)
Harro Kremer (JIO)
Sheila Ghosh (ICTU)
Guy Rutten (Logius)
Eric Nijenhuis (UWV)
Johann Schreurs (DUO)
Marco Eikenaar (Belastingdienst)
Fokke Rispens (NICTIZ)
Alexander Bielowski (ICTU)
Michel de Winter (RvIG)

De volgende organisaties hebben reviewcommentaar geleverd op een concept versie van deze domeinarchitectuur:

Ministerie van Binnenlandse Zaken en Koninkrijksrelaties, inclusief Logius, Bureau Forum Standaardisatie, de Rijksdienst voor Identiteitsgegevens, Programma Federatief Data Stelsel, Programma EDI-stelsel NL
Ministerie van Volksgezondheid, Welzijn en Sport
Ministerie van Economische Zaken en Landbouw, inclusief de Rijksdienst voor Ondernemend Nederland
Belastingdienst
Kamer van Koophandel
Interprovinciaal Overleg
Provincie Overijssel
Unie van Waterschappen
NORA IAM expertgroep
UWV
DUO
SURF

1	Inleiding
1.1	Aanleiding
1.2	Dit document
1.3	Documentstructuur
1.4	Relatie met andere architecturen
1.5	Relatie met andere initiatieven
2	Kernbegrippen
2.1	Algemeen
2.2	Rollen
2.3	Functies
3	Veranderfactoren
3.1	Beleid
3.2	Wet- en regelgeving
4.3	Ontwikkelingen
4.4	Knelpunten
4	Doelarchitectuur
4.1	Architectuurvisie
4.2	Architectuurprincipes
4.3	Verdieping thema rolverdeling
4.4	Verdieping thema systeem naar systeem toegang
4.5	Veranderinitiatieven
5	Doelarchitectuur
5.1	Functies
5.2	Bedrijfsobjecten en begrippen
5.3	Rollen
5.4	Huidige voorzieningen
5.5	Standaarden
5.6	Relatie van architectuurprincipes met ADO en NORA
5.7	Betrokkenen

Aanbieder van identiteitsgegevens	Een rol die verantwoordelijk is voor het aanbieden van identiteitsgegevens van bronhouders op een manier die aansluit bij de behoeften en het gebruik van afnemers.
Authenticatiedienst	Een rol die op basis van een identificatiemiddel een authenticatieverklaring afgeeft (bron: Wet digitale overheid).
Broker	Een rol die één ingangspunt biedt voor het routeren, vertalen en aggregeren van verklaringen van één of meer verklarende partijen.
Bronhouder	Een rol die verantwoordelijk is voor het inwinnen, beheren en het verbeteren van de kwaliteit van gegevens.
Centrale misbruikbestrijding	Een rol die verantwoordelijk is voor het detecteren van fraude en misbruik met meerdere identificatiemiddelen of bij meerdere dienstverleners.
Dienstverlener	Een rol die volgens afspraken diensten levert aan een klant.
Gebruiker	Een natuurlijk persoon die gegevens en/of functionaliteit gebruikt voor het uitvoeren van werkzaamheden.
Machtigingsdienst	Een rol die machtigingen kan vastleggen en op basis daarvan bevoegdheidsverklaringen kan afgeven.
Middelenuitgever	Een rol die zorg draagt voor de uitgifte van erkende identificatiemiddelen aan natuurlijke personen of niet-natuurlijke personen.
Regisseur toegangsinfrastructuur	Een rol die verantwoordelijk is voor het inrichten en besturen van een toegangsinfrastructuur.
Toezichthouder	Een rol die vanuit een onafhankelijke positie controleert of de toegangsinfrastructuur werkt en voldoende waarde oplevert.
Verklarende partij	Een organisatie die verifieerbare verklaringen uitgeeft.
Verlener van vertrouwensdiensten	Een natuurlijke persoon of niet-natuurlijke persoon die een of meer vertrouwensdiensten verleent als een gekwalificeerde of als een niet-gekwalificeerde verlener van vertrouwensdiensten.
Vertrouwende partij	Een rol die vertrouwt op verifieerbare verklaringen van een verklarende partij.