diff --git a/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-5c41c1e562644d3dac34f20476569d06.xml b/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-5c41c1e562644d3dac34f20476569d06.xml new file mode 100644 index 00000000..c21fe27f --- /dev/null +++ b/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-5c41c1e562644d3dac34f20476569d06.xml @@ -0,0 +1,8 @@ + + + diff --git a/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-62a0afc676e04f8280ed2271dd61cd44.xml b/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-62a0afc676e04f8280ed2271dd61cd44.xml index 5204c4da..eafe472f 100644 --- a/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-62a0afc676e04f8280ed2271dd61cd44.xml +++ b/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-62a0afc676e04f8280ed2271dd61cd44.xml @@ -2,7 +2,7 @@ xmlns:archimate="http://www.archimatetool.com/archimate" name="Kernbegrippen" id="id-62a0afc676e04f8280ed2271dd61cd44" - documentation="<p>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.</p> <h2>2.1 Algemeen</h2> <p> Dit document gaat over het verstrekken van toegang aan mensen, organisaties, applicaties en apparaten. Dat noemen we in dit document <b>entiteiten</b>. Een entiteit krijgt toegang met een bepaalde <b>identiteit</b>. 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 <b>identiteitsgegevens</b>. Dit soort gegevens over entiteiten heten in de context van toegang ook wel <b>attributen</b>. Deze gegevens worden verkregen uit <b>gezaghebbende bronnen</b>. Dat zijn bronnen waarvan kan worden verwacht dat deze nauwkeurige gegevens bieden. </p> <p> Entiteiten krijgen toegang door gebruik te maken van een <b>identificatiemiddel</b> 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 <b>authenticatieverklaring</b> waarmee toegang kan worden gegeven. Een authenticatieverklaring is een specifiek soort <b>verifieerbare verklaring</b>. 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. </p> <p> Toegang wordt verstrekt tot <b>resources</b>: <b>diensten</b> en de daaronder liggende gegevens en functionaliteiten. Welke diensten, gegevens en functionaliteiten toegang toe wordt verstrekt wordt bepaald door de <b>bevoegdheden</b> (ook wel: autorisaties) die aan een identiteit zijn gekoppeld. Entiteiten kunnen ook bevoegdheden krijgen doordat ze van iemand anders een <b>machtiging</b> hebben gekregen of omdat een door een <b>wettelijke vertegenwoordiging</b> 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. </p> <p> Het controleren van de bevoegdheden van een identiteit heet <b>autoriseren</b>. Daarbij wordt gebruik gemaakt van <b>autorisatieregels</b> 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 <b>autorisatiebeslissing</b> die aangeeft of wel of geen toegang wordt verstrekt. <h2>2.2 Rollen</h2> <p> 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 <b>verklarende partijen</b>. Denk daarbij aan <b>authenticatiediensten</b> die kunnen verklaren of een entiteit succesvol is geauthenticeerd of aan <b>machtigingsdiensten</b> 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. </p> <p> Aan de andere kant zijn er <b>vertrouwende partijen</b>. 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. </p> <p> Om dit geheel te laten werken zijn er ook andere rollen nodig. Zo zijn er ook <b>middelenuitgevers</b> nodig die ervoor zorgen dat er erkende <b>identificatiemiddelen</b> kunnen worden uitgegeven. Er wordt ook gebruik gemaakt van <b>leveranciers van vertrouwensdiensten</b>, die bijvoorbeeld verifieerbare verklaringen kunnen maken of certificaten kunnen uitgeven die verklarende partijen kunnen verstrekken. <p> <h2>2.3 Functies</h2> <p> 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. </p> <p> 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. </p> <p> <p><center><img src="https://minbzk.github.io/gdi-toegang/images/functiemodel_hoofdlijnen.svg"></center></p> <p> <ul> <li>Organiseren toegang: Het organisatorisch inregelen van afspraken voor toegang.</li> <li>Creëren vertrouwen: Het creëren van vertrouwen in de identiteit van natuurlijke en niet-natuurlijke personen en gegevens middels cryptografische technieken.</li> <li>Beheren identiteiten: Het creëren, vastleggen, beschikbaarstellen, wijzigen en (logisch) verwijderen van (gegevens over) identiteiten.</li> <li>Beheren identificatiemiddelen: Het verstrekken en intrekken van identificatiemiddelen en het administreren van de daarvoor benodigde gegevens.</li> <li>Beheren eigen bevoegdheden: Het toekennen en intrekken van bevoegdheden (anders dan vertegenwoordigingsbevoegdheden) en het administreren van de daarvoor benodigde gegevens.</li> <li>Beheren vertegenwoordigingsbevoegdheden: Het toekennen en intrekken van vertegenwoordigingsbevoegheden en het administreren van de daarvoor benodigde gegevens.</li> <li>Auditing en monitoring: Het vastleggen van relevante gebeurtenissen rondom toegang en het uitvoeren van controlerende activiteiten om misbruik of fraude vast te stellen.</li> <li>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.</li> <li>Autoriseren: Het bepalen op basis van autorisatieregels bepalen of een digitale identiteit beschikt over de bevoegdheden voor toegang tot diensten of informatieobjecten.</li> </ul> </p> "> + documentation="<p>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.</p> <h2>2.1 Algemeen</h2> <p> Dit document gaat over het verstrekken van toegang aan mensen, organisaties, applicaties en apparaten. Dat noemen we in dit document <b>entiteiten</b>. Daarbij geldt dat applicaties en apparaten altijd handelen namens een andere entiteit. Een entiteit krijgt toegang met een bepaalde <b>identiteit</b>. 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 <b>identiteitsgegevens</b>. Dit soort gegevens over entiteiten heten in de context van toegang ook wel <b>attributen</b>. Deze gegevens worden verkregen uit <b>gezaghebbende bronnen</b>. Dat zijn bronnen waarvan kan worden verwacht dat deze nauwkeurige gegevens bieden. </p> <p> Entiteiten krijgen toegang door gebruik te maken van een <b>identificatiemiddel</b> 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 <b>authenticatieverklaring</b> waarmee toegang kan worden gegeven. Een authenticatieverklaring is een specifiek soort <b>verifieerbare verklaring</b>. 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. </p> <p> Toegang wordt verstrekt tot <b>resources</b>: <b>diensten</b> en de daaronder liggende gegevens en functionaliteiten. Welke diensten, gegevens en functionaliteiten toegang toe wordt verstrekt wordt bepaald door de <b>bevoegdheden</b> (ook wel: autorisaties) die aan een identiteit zijn gekoppeld. Entiteiten kunnen ook bevoegdheden krijgen doordat ze van iemand anders een <b>machtiging</b> hebben gekregen of omdat een door een <b>wettelijke vertegenwoordiging</b> 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. </p> <p> Het controleren van de bevoegdheden van een identiteit heet <b>autoriseren</b>. Daarbij wordt gebruik gemaakt van <b>autorisatieregels</b> 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 <b>autorisatiebeslissing</b> die aangeeft of wel of geen toegang wordt verstrekt. <h2>2.2 Rollen</h2> <p> 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 <b>verklarende partijen</b>. Denk daarbij aan <b>authenticatiediensten</b> die kunnen verklaren of een entiteit succesvol is geauthenticeerd of aan <b>machtigingsdiensten</b> die kunnen verklaren of een entiteit iemand anders mag vertegenwoordigen. Daarnaast zijn er <b>aanbieders van identiteitsgegevens</a> 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. </p> <p> Aan de andere kant zijn er <b>vertrouwende partijen</b>. 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. </p> <p> Om dit geheel te laten werken zijn er ook andere rollen nodig. Zo zijn er ook <b>middelenuitgevers</b> nodig die ervoor zorgen dat er erkende <b>identificatiemiddelen</b> kunnen worden uitgegeven. Er wordt ook gebruik gemaakt van <b>leveranciers van vertrouwensdiensten</b>, die bijvoorbeeld verifieerbare verklaringen kunnen maken of certificaten kunnen uitgeven die verklarende partijen kunnen verstrekken. <p> <h2>2.3 Functies</h2> <p> 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. </p> <p> 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. </p> <p> <p><center><img src="https://minbzk.github.io/gdi-toegang/images/functiemodel_hoofdlijnen.svg"></center></p> <p> <ul> <li>Organiseren toegang: Het organisatorisch inregelen van afspraken voor toegang.</li> <li>Creëren vertrouwen: Het creëren van vertrouwen in de identiteit van natuurlijke en niet-natuurlijke personen en gegevens middels cryptografische technieken.</li> <li>Beheren identiteiten: Het creëren, vastleggen, beschikbaarstellen, wijzigen en (logisch) verwijderen van (gegevens over) identiteiten.</li> <li>Beheren identificatiemiddelen: Het verstrekken en intrekken van identificatiemiddelen en het administreren van de daarvoor benodigde gegevens.</li> <li>Beheren eigen bevoegdheden: Het toekennen en intrekken van bevoegdheden (anders dan vertegenwoordigingsbevoegdheden) en het administreren van de daarvoor benodigde gegevens.</li> <li>Beheren vertegenwoordigingsbevoegdheden: Het toekennen en intrekken van vertegenwoordigingsbevoegheden en het administreren van de daarvoor benodigde gegevens.</li> <li>Auditing en monitoring: Het vastleggen van relevante gebeurtenissen rondom toegang en het uitvoeren van controlerende activiteiten om misbruik of fraude vast te stellen.</li> <li>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.</li> <li>Autoriseren: Het bepalen op basis van autorisatieregels bepalen of een digitale identiteit beschikt over de bevoegdheden voor toegang tot diensten of informatieobjecten.</li> </ul> </p> "> diff --git a/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-9704fa59cc7b4b5e9daa53f1b32ec98d.xml b/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-9704fa59cc7b4b5e9daa53f1b32ec98d.xml index 30ad2e65..9ddc789a 100644 --- a/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-9704fa59cc7b4b5e9daa53f1b32ec98d.xml +++ b/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-9704fa59cc7b4b5e9daa53f1b32ec98d.xml @@ -2,7 +2,7 @@ xmlns:archimate="http://www.archimatetool.com/archimate" name="Inleiding" id="id-9704fa59cc7b4b5e9daa53f1b32ec98d" - documentation="<h2>1.1 Aanleiding</h2> <p>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 <a href="https://pgdi.nl/files/view/82435cdb-9861-4a46-8152-288f666dc32f/gdi-meerjarenvisie.pdf">meerjarenvisie</a> en een <a href ="https://pgdi.nl/ado">Architectuur Digitale Overheid 2030</a> 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.</p> 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.</p> <p>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.</p> <p>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.</p> <h2>Dit document</h2> <p>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. </p> <p> 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. </p> <p> 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.</p> <p>Er is voor gekozen om de architectuur in de modelleertaal ArchiMate uit te werken en de details ervan alleen <a href="https://github.com/minbzk/gdi-toegang">online</a> 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 <a href="https://github.com/minbzk/gdi-toegang">GitHub</a>, 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. </p> <p> 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. </p> <h3>1.3 Documentstructuur</h3> <p> De architectuur is ingedeeld in vijf onderdelen: </p> <p> <ul> <li>De <b>kernbegrippen</b> 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. </li> <li>De <b>veranderfactoren</b> geven richting aan de architectuur, en bestaan uit beleid, wet- en regelgeving, ontwikkelingen en knelpunten.</li> <li>De <b>gewenste situatie</b> beschrijft een architectuurvisie, architectuurprincipes, een streefbeeld en voorgestelde veranderinitiatieven. De architectuurprincipes zijn de overtuigingen die het hart van de architectuur vormen en die als richtinggevende uitspraken zijn opgeschreven.</p> <li>De <b>verdieping</b> beschrijft een uitwerking van de architectuurvisie en architectuurprincipes op de voorgestelde rolverdeling en op het gebied van toegang tussen systemen. Het is vooral bedoeld als uitleg en geeft aanvullende inzichten en handreikingen. </li> <li> In de <b>bijlagen</b> 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. </ul> <h2>1.4 Relatie met andere architecturen</h2> <p> 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 <a href="https://github.com/minbzk/gdi-gegevensuitwisseling">domeinarchitectuur gegevensuitwisseling</a> ook te lezen om een volledig beeld van toegang te krijgen. De belangrijkste relaties tussen de beide domeinarchitecturen zijn: </p> <p> <ul> <li>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.</li> <li>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.</li> <li>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.</li> <li>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.</li> </ul> </p> <p>Er is ook een relatie met de domeinarchitectuur interactie: </p> <p> <ul> <li>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.</li> <li>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.</li> <li>De domeinarchitectuur interactie stelt dat interacties via meerdere kanalen mogelijk moet zijn. Dat betekent dat identiteiten via al deze kanalen bruikbaar moeten zijn.</li> </ul> </p> <p> Deze domeinarchitectuur is afgestemd op de <a href ="https://pgdi.nl/ado">Architectuur Digitale Overheid 2030</a> en de <a href="https://www.noraonline.nl">NORA</a>. Hierdoor is de domeinarchitectuur te beschouwen als een doorvertaling en concretisering van deze overkoepelende architecturen.</p> <h3>1.5 Relatie met andere initiatieven</h3> <p>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 <a href="https://wetten.overheid.nl/BWBR0048156/2023-07-01">Wet digitale overheid (Wdo)</a>. 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.</p> "> + documentation="<h2>1.1 Aanleiding</h2> <p>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 <a href="https://pgdi.nl/files/view/82435cdb-9861-4a46-8152-288f666dc32f/gdi-meerjarenvisie.pdf">meerjarenvisie</a> en een <a href ="https://pgdi.nl/ado">Architectuur Digitale Overheid 2030</a> 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.</p> 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.</p> <p>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.</p> <p>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.</p> <h2>Dit document</h2> <p>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. </p> <p> 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. </p> <p> 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.</p> <p>Er is voor gekozen om de architectuur in de modelleertaal ArchiMate uit te werken en de details ervan alleen <a href="https://github.com/minbzk/gdi-toegang">online</a> 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 <a href="https://github.com/minbzk/gdi-toegang">GitHub</a>, 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. </p> <p> 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. </p> <h3>1.3 Documentstructuur</h3> <p> De architectuur is ingedeeld in vijf onderdelen: </p> <p> <ul> <li>De <b>kernbegrippen</b> 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. </li> <li>De <b>veranderfactoren</b> geven richting aan de architectuur, en bestaan uit beleid, wet- en regelgeving, ontwikkelingen en knelpunten.</li> <li>De <b>gewenste situatie</b> 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.</p> <li>De <b>verdieping</b> 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. </li> <li> In de <b>bijlagen</b> 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. </ul> <h2>1.4 Relatie met andere architecturen</h2> <p> 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 <a href="https://github.com/minbzk/gdi-gegevensuitwisseling">domeinarchitectuur gegevensuitwisseling</a> ook te lezen om een volledig beeld van toegang te krijgen. De belangrijkste relaties tussen de beide domeinarchitecturen zijn: </p> <p> <ul> <li>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.</li> <li>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.</li> <li>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.</li> <li>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.</li> </ul> </p> <p>Er is ook een relatie met de domeinarchitectuur interactie: </p> <p> <ul> <li>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.</li> <li>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.</li> <li>De domeinarchitectuur interactie stelt dat interacties via meerdere kanalen mogelijk moet zijn. Dat betekent dat identiteiten via al deze kanalen bruikbaar moeten zijn.</li> </ul> </p> <p> Deze domeinarchitectuur is afgestemd op de <a href ="https://pgdi.nl/ado">Architectuur Digitale Overheid 2030</a> en de <a href="https://www.noraonline.nl">NORA</a>. Hierdoor is de domeinarchitectuur te beschouwen als een doorvertaling en concretisering van deze overkoepelende architecturen.</p> <h3>1.5 Relatie met andere initiatieven</h3> <p>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 <a href="https://wetten.overheid.nl/BWBR0048156/2023-07-01">Wet digitale overheid (Wdo)</a>. 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.</p> "> diff --git a/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-df84c34285474bdebefd163a965d6403.xml b/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-df84c34285474bdebefd163a965d6403.xml index 973fb98d..06bfa877 100644 --- a/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-df84c34285474bdebefd163a965d6403.xml +++ b/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-df84c34285474bdebefd163a965d6403.xml @@ -2,7 +2,7 @@ xmlns:archimate="http://www.archimatetool.com/archimate" name="Verdieping: rolverdeling" id="id-df84c34285474bdebefd163a965d6403" - documentation="<p>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.</p> <h3>Interactiepatronen</h3> <p> De volgende figuur geeft een overzicht van de belangrijkste interactiepatronen die relevant zijn in het kader van toegang. Het belangrijkste interactiepatroon voor de toekomst is het patroon waarbij de gebruiker centraal staat. </p> <p><center><img src="https://minbzk.github.io/gdi-toegang/images/interactiepatronen.svg"></center></p> <p> 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. </p> <p> 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. </p> <p> 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. </p> <p> 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. </p> <h4>Gebruiker</h4> <p> Een gebruiker is natuurlijk persoon die gegevens en/of functionaliteit gebruikt voor het uitvoeren van werkzaamheden. </p> <p> 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.. </p> <h4>Aanbieder van identiteitsgegevens</h4> <p> 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. </p> <p>Functies: <ul> <li>Elektronisch verklaren;</li> <li>Verstrekken identiteitsgegevens.</li> </ul> </p> <p>Voorbeelden: RvIG, KvK, RDW, QTSP.</p> <p> Een aanbieder van identiteitsgegevens: <ul> <li> biedt identiteitsgegevens aan in de vorm van verifieerbare verklaringen;</li> <li> kan verifieerbare verklaringen aanbieden die voldoen aan de standaarden voor de EDI wallet (OpenID for Verifiable Credentials en NEN-ISO/IEC 18013-5).</li> </ul> </p> <h4>Authenticatiedienst</h4> <p>Een authenticatiedienst geeft authenticatieverklaringen af op basis van een identificatiemiddel.</p> <p>Voorbeelden: Logius (voor DigiD), eHerkenning authenticatiedienst, EDI Wallet.</p> <p>Functies: <ul> <li>Uitvoeren authenticatie;</li> <li>Vastleggen auditlog;</li> <li>Vastleggen gebruik identificatiemiddel;/li> <li>Uitloggen;</li> <li>Bestrijden fraude en misbruik./li> </ul> </p> <p> Een authenticatiedienst: <ul> <li>controleert bij een authenticatieverzoek de authenticiteit en geldigheid van het gebruikte identificatiemiddel bij de verantwoordelijke middelenuitgever;</li> <li>registreert authenticatieverzoeken en hun resultaat in een auditlog;</li> <li>registreert metagegevens over authenticatieverzoeken en hun resultaat in een inzageregister dat inzichtelijk is voor gebruikers;</li> <li>ondersteunt de OpenID Connect standaard conform het Nederlands profiel OpenID.NLGov (geldt niet voor EDI Wallet);</li> <li>ondersteunt het uitloggen van entiteiten met een bepaalde identiteit;</li> <li>is verantwoordelijk voor het voorkomen, detecteren, opvolgen en herstellen van fraude met identificatiemiddelen;/li> <li>stuurt metagegevens over authenticatieverzoeken en hun resultaat door naar centrale misbruikbestrijding./li> </ul> </p> <h4>Broker</h4> <p>Een broker biedt één ingangspunt voor het routeren, vertalen en aggregeren van verklaringen van één of meer verklarende partijen.</p> <p>Voorbeelden: Logius (voor CombiConnect, bevoegdhedenverklaringsdienst en eIDAS koppelpunt), DICTU (voor TVS), eHerkenning makelaar.</p> <p>Functies: <ul> <li>Orkestreren login;</li> <li>Vertalen authenticatieverklaring;</li> <li>Vertalen identifier.</li> </ul> </p> <p> Een broker: <ul> <li>kan het inlogproces richting een eindgebruiker orkestreren;</li> <li>kan vertalingen uitvoeren op verifieerbare verklaringen;</li> <li>kan gebruik maken van andere brokers.</li> </ul> <p> Een broker die het inlogproces orkestreert: <ul> <li> biedt gebruikers een klantreis die voldoet aan de afspraken voor het inlogproces;</li> <li>maakt het standaard mogelijk om iemand te vertegenwoordigen bij het inloggen;</li> <li>ontzorgt dienstverleners in het verkrijgen van veelvoorkomende (voor toegang relevante) attributen;</li> <li>ondersteunt de OpenID Connect standaard conform het Nederlands profiel OpenID.NLGov (geldt niet voor EDI Wallet).</li> </ul> </p> <h4>Dienstverlener</h4> <p>Een dienstverlener levert volgens afspraken diensten aan een klant. Een dienstverlener is een vertrouwende partij.</p> <p>Voorbeelden: rijksoverheden, uitvoeringsorganisaties, gemeenten, provincies, waterschappen, commerciële dienstverleners.</p> <p>Functies: <li>Auditing, monitoring en misbruikbestrijding;</li> <li>Autoriseren;</li> <li>Beheren eigen bevoegdheden.</li> </ul> </p> <p>Een dienstverlener: <ul> <li>biedt diensten die zijn afgestemd op de specifieke soorten gebruikers en hun specifieke taken;</li> <li>bepaalt voor elke dienst een noodzakelijk betrouwbaarheidsniveau;</li> <li>eist geen hoger betrouwbaarheidsniveau dan wat nodig is voor het verkrijgen van toegang tot een dienst; </li> <li>accepteert alle erkende publieke en private identificatiemiddelen;</li> <li>registreert de attributen die nodig zijn voor het verstrekken van toegang tot een dienst in de toegangsinfrastructuur;</li> <li>maakt duidelijk welke wettelijke grondslag en doelbinding ten grondslag liggen aan de attributen die worden gevraagd;</li> <li>maakt duidelijk aan welke derde partijen attributen worden doorgegeven en op basis van welke wettelijke grondslag en doelbinding;</li> <li>vraagt niet meer attributen dan wat strikt noodzakelijk is voor het leveren van een dienst;</li> <li>geeft gebruikers voorafgaand aan hun handelen inzicht in de voor een dienst gevraagde attributen;</li> <li>kan zelf kiezen of deze gebruik maakt van een broker of verifieerbare verklaringen direct haalt bij een authenticatiedienst, machtigingsdienst of andere aanbieder van identiteitsgegevens;</li> <li>controleert of verifieerbare verklaringen valide, integer, authentiek en geldig zijn;</li> <li>kan omgaan met gebruikers die andere entiteiten vertegenwoordigen;</li> <li>minimaliseert het aantal keer dat gebruikers wordt gevraagd om in te loggen;</li> <li>is zelf verantwoordelijk voor het autoriseren van entiteiten met een bepaalde identiteit;</li> <li>biedt alleen toegang tot diensten, functionaliteiten en gegevens die passen bij de aangeleverde verklaringen en bijbehorende attributen;</li> <li>baseert autorisaties in achterliggende systemen op de identiteit van de gebruiker;</li> <li>registreert gevoelige verwerkingen die een entiteit uitvoert in een auditlog.</li> </ul> </p> <h4>Machtigingsdienst</h4> <p>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.</p> <p>Voorbeelden: Logius (voor DigiD machtigen), eHerkenning machtigingsdienst.</p> <p>Een machtigingsdienst: <ul> <li>registreert metagegevens over machtigingen, wijzigingen daarin en bevoegdheidsverklaringen die deze afgeeft in een inzageregister dat inzichtelijk is voor gebruikers;</li> <li>registreert het betrouwbaarheidsniveau waarop een machtiging is afgegeven;</li> <li>maakt het mogelijk om het betrouwbaarheidsniveau van een machtiging op te hogen;</li> <li>notificeert vertegenwoordigden en vertegenwoordigers over wijzigingen in machtigingen;</li> <li>stuurt metagegevens over afgegeven bevoegdheidsverklaringen door naar centrale misbruikbestrijding./li> </ul> <h4>Middelenuitgever</h4> <p>Een middelenuitgever draagt zorg voor de uitgifte van erkende identificatiemiddelen aan natuurlijke personen of niet-natuurlijke personen.</p> <p>Voorbeelden: RvIG (voor paspoort), RDW (voor rijbewijs), Logius (voor DigiD), eHerkenning middelenuitgever, EDI wallet aanbieder.</p> <p>Functies: <ul> <li>Beheren identificatiemiddelen</li> </ul> </p> <p>Een middelenuitgever: <ul> <li>registreert het uitgeven en intrekken van identificatiemiddelen in een inzageregister dat inzichtelijk is voor gebruikers;</li> <li>ondersteunt het intrekken van een identificatiemiddel.</li> </ul> </p>"> + documentation="<p>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.</p> <h3>Interactiepatronen</h3> <p> 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. </p> <p><center><img src="https://minbzk.github.io/gdi-toegang/images/interactiepatronen.svg"></center></p> <h4>Interactiepatroon 1: Gebruiker centraal</h4> <p> 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. </p> <h4>Interactiepatroon 2: Traditioneel</h4> <p> 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. </p> <h4>Interactiepatroon 3: Ontzorgd door broker(s)</h4> <p> 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. </p> <p> 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. </p> <h4>Gebruiker</h4> <p> Een gebruiker is natuurlijk persoon die gegevens en/of functionaliteit gebruikt voor het uitvoeren van werkzaamheden. </p> <p> 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.. </p> <h4>Aanbieder van identiteitsgegevens</h4> <p> 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. </p> <p>Functies: <ul> <li>Elektronisch verklaren;</li> <li>Verstrekken identiteitsgegevens.</li> </ul> </p> <p>Voorbeelden: RvIG, KvK, RDW, QTSP.</p> <p> Een aanbieder van identiteitsgegevens: <ul> <li> biedt identiteitsgegevens aan in de vorm van verifieerbare verklaringen;</li> <li> kan verifieerbare verklaringen aanbieden die voldoen aan de standaarden voor de EDI wallet (OpenID for Verifiable Credentials en NEN-ISO/IEC 18013-5).</li> </ul> </p> <h4>Authenticatiedienst</h4> <p>Een authenticatiedienst geeft authenticatieverklaringen af op basis van een identificatiemiddel.</p> <p>Voorbeelden: Logius (voor DigiD), eHerkenning authenticatiedienst, EDI Wallet.</p> <p>Functies: <ul> <li>Uitvoeren authenticatie;</li> <li>Vastleggen auditlog;</li> <li>Vastleggen gebruik identificatiemiddel;/li> <li>Uitloggen;</li> <li>Bestrijden fraude en misbruik./li> </ul> </p> <p> Een authenticatiedienst: <ul> <li>controleert bij een authenticatieverzoek de authenticiteit en geldigheid van het gebruikte identificatiemiddel bij de verantwoordelijke middelenuitgever;</li> <li>registreert authenticatieverzoeken en hun resultaat in een auditlog;</li> <li>registreert metagegevens over authenticatieverzoeken en hun resultaat in een inzageregister dat inzichtelijk is voor gebruikers;</li> <li>ondersteunt de OpenID Connect standaard conform het Nederlands profiel OpenID.NLGov (geldt niet voor EDI Wallet);</li> <li>ondersteunt het uitloggen van entiteiten met een bepaalde identiteit;</li> <li>is verantwoordelijk voor het voorkomen, detecteren, opvolgen en herstellen van fraude met identificatiemiddelen;/li> <li>stuurt metagegevens over authenticatieverzoeken en hun resultaat door naar centrale misbruikbestrijding./li> </ul> </p> <h4>Broker</h4> <p>Een broker biedt één ingangspunt voor het routeren, vertalen en aggregeren van verklaringen van één of meer verklarende partijen.</p> <p>Voorbeelden: Logius (voor CombiConnect, bevoegdhedenverklaringsdienst en eIDAS koppelpunt), DICTU (voor TVS), eHerkenning makelaar.</p> <p>Functies: <ul> <li>Orkestreren login;</li> <li>Vertalen authenticatieverklaring;</li> <li>Vertalen identifier.</li> </ul> </p> <p> Een broker: <ul> <li>kan het inlogproces richting een eindgebruiker orkestreren;</li> <li>kan vertalingen uitvoeren op verifieerbare verklaringen;</li> <li>kan gebruik maken van andere brokers.</li> </ul> <p> Een broker die het inlogproces orkestreert: <ul> <li> biedt gebruikers een klantreis die voldoet aan de afspraken voor het inlogproces;</li> <li>maakt het standaard mogelijk om iemand te vertegenwoordigen bij het inloggen;</li> <li>ontzorgt dienstverleners in het verkrijgen van veelvoorkomende (voor toegang relevante) attributen;</li> <li>ondersteunt de OpenID Connect standaard conform het Nederlands profiel OpenID.NLGov (geldt niet voor EDI Wallet).</li> </ul> </p> <h4>Dienstverlener</h4> <p>Een dienstverlener levert volgens afspraken diensten aan een klant. Een dienstverlener is een vertrouwende partij.</p> <p>Voorbeelden: rijksoverheden, uitvoeringsorganisaties, gemeenten, provincies, waterschappen, commerciële dienstverleners.</p> <p>Functies: <li>Auditing, monitoring en misbruikbestrijding;</li> <li>Autoriseren;</li> <li>Beheren eigen bevoegdheden.</li> </ul> </p> <p>Een dienstverlener: <ul> <li>biedt diensten die zijn afgestemd op de specifieke soorten gebruikers en hun specifieke taken;</li> <li>bepaalt voor elke dienst een noodzakelijk betrouwbaarheidsniveau;</li> <li>eist geen hoger betrouwbaarheidsniveau dan wat nodig is voor het verkrijgen van toegang tot een dienst; </li> <li>accepteert alle erkende publieke en private identificatiemiddelen;</li> <li>registreert de attributen die nodig zijn voor het verstrekken van toegang tot een dienst in de toegangsinfrastructuur;</li> <li>maakt duidelijk welke wettelijke grondslag en doelbinding ten grondslag liggen aan de attributen die worden gevraagd;</li> <li>maakt duidelijk aan welke derde partijen attributen worden doorgegeven en op basis van welke wettelijke grondslag en doelbinding;</li> <li>vraagt niet meer attributen dan wat strikt noodzakelijk is voor het leveren van een dienst;</li> <li>geeft gebruikers voorafgaand aan hun handelen inzicht in de voor een dienst gevraagde attributen;</li> <li>kan zelf kiezen of deze gebruik maakt van een broker of verifieerbare verklaringen direct haalt bij een authenticatiedienst, machtigingsdienst of andere aanbieder van identiteitsgegevens;</li> <li>controleert of verifieerbare verklaringen valide, integer, authentiek en geldig zijn;</li> <li>kan omgaan met gebruikers die andere entiteiten vertegenwoordigen;</li> <li>minimaliseert het aantal keer dat gebruikers wordt gevraagd om in te loggen;</li> <li>is zelf verantwoordelijk voor het autoriseren van entiteiten met een bepaalde identiteit;</li> <li>biedt alleen toegang tot diensten, functionaliteiten en gegevens die passen bij de aangeleverde verklaringen en bijbehorende attributen;</li> <li>baseert autorisaties in achterliggende systemen op de identiteit van de gebruiker;</li> <li>registreert gevoelige verwerkingen die een entiteit uitvoert in een auditlog.</li> </ul> </p> <h4>Machtigingsdienst</h4> <p>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.</p> <p>Voorbeelden: Logius (voor DigiD machtigen), eHerkenning machtigingsdienst.</p> <p>Een machtigingsdienst: <ul> <li>registreert metagegevens over machtigingen, wijzigingen daarin en bevoegdheidsverklaringen die deze afgeeft in een inzageregister dat inzichtelijk is voor gebruikers;</li> <li>registreert het betrouwbaarheidsniveau waarop een machtiging is afgegeven;</li> <li>maakt het mogelijk om het betrouwbaarheidsniveau van een machtiging op te hogen;</li> <li>notificeert vertegenwoordigden en vertegenwoordigers over wijzigingen in machtigingen;</li> <li>stuurt metagegevens over afgegeven bevoegdheidsverklaringen door naar centrale misbruikbestrijding./li> </ul> <h4>Middelenuitgever</h4> <p>Een middelenuitgever draagt zorg voor de uitgifte van erkende identificatiemiddelen aan natuurlijke personen of niet-natuurlijke personen.</p> <p>Voorbeelden: RvIG (voor paspoort), RDW (voor rijbewijs), Logius (voor DigiD), eHerkenning middelenuitgever, EDI wallet aanbieder.</p> <p>Functies: <ul> <li>Beheren identificatiemiddelen</li> </ul> </p> <p>Een middelenuitgever: <ul> <li>registreert het uitgeven en intrekken van identificatiemiddelen in een inzageregister dat inzichtelijk is voor gebruikers;</li> <li>ondersteunt het intrekken van een identificatiemiddel.</li> </ul> </p>"> diff --git a/model/diagrams/ArchimateDiagramModel_id-a19f7ecd3614470aab77710880939cd5.xml b/model/diagrams/ArchimateDiagramModel_id-a19f7ecd3614470aab77710880939cd5.xml index a88c08ee..45c097ec 100644 --- a/model/diagrams/ArchimateDiagramModel_id-a19f7ecd3614470aab77710880939cd5.xml +++ b/model/diagrams/ArchimateDiagramModel_id-a19f7ecd3614470aab77710880939cd5.xml @@ -231,11 +231,21 @@ xsi:type="archimate:AssociationRelationship" href="AssociationRelationship_id-b3f188c6e4994e56b18264ca58fb8243.xml#id-b3f188c6e4994e56b18264ca58fb8243"/> + + + + height="553"/> @@ -308,7 +318,7 @@ value="2"/> + + + + + diff --git a/model/motivation/id-0c31399185fd47a1874a2b4db2b2b8a7/Meaning_id-af549567dc354a888dff1cf13dad4fea.xml b/model/motivation/id-0c31399185fd47a1874a2b4db2b2b8a7/Meaning_id-af549567dc354a888dff1cf13dad4fea.xml index 094c8ac8..2b5b1250 100644 --- a/model/motivation/id-0c31399185fd47a1874a2b4db2b2b8a7/Meaning_id-af549567dc354a888dff1cf13dad4fea.xml +++ b/model/motivation/id-0c31399185fd47a1874a2b4db2b2b8a7/Meaning_id-af549567dc354a888dff1cf13dad4fea.xml @@ -5,5 +5,5 @@ documentation="Een object dat gedrag kan vertonen."> + value="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. "/> diff --git a/model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-77965a4ab86c43fb809656f759830dc1.xml b/model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-77965a4ab86c43fb809656f759830dc1.xml index 68e0cb0c..bdfa0193 100644 --- a/model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-77965a4ab86c43fb809656f759830dc1.xml +++ b/model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-77965a4ab86c43fb809656f759830dc1.xml @@ -2,7 +2,7 @@ xmlns:archimate="http://www.archimatetool.com/archimate" name="3. Organisaties wisselen alleen strikt noodzakelijke gegevens uit" id="id-77965a4ab86c43fb809656f759830dc1" - documentation="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. Veel belangrijker is het om te weten of de gebruiker over de juiste bevoegdheden beschikt. Opsporingsdiensten hebben wel duidelijk andere informatiebehoeften en bevoegdheden. 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."> + documentation="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."> diff --git a/model/relations/AssociationRelationship_id-17cd51c4d13e44558be72f23e3401f5f.xml b/model/relations/AssociationRelationship_id-17cd51c4d13e44558be72f23e3401f5f.xml index 50160c41..dedffba4 100644 --- a/model/relations/AssociationRelationship_id-17cd51c4d13e44558be72f23e3401f5f.xml +++ b/model/relations/AssociationRelationship_id-17cd51c4d13e44558be72f23e3401f5f.xml @@ -1,11 +1,11 @@ + value="14"/> diff --git a/model/relations/AssociationRelationship_id-4687050efd0d480e9ca037fdaa0d3682.xml b/model/relations/AssociationRelationship_id-4687050efd0d480e9ca037fdaa0d3682.xml index 61cb6b2d..8eb627fc 100644 --- a/model/relations/AssociationRelationship_id-4687050efd0d480e9ca037fdaa0d3682.xml +++ b/model/relations/AssociationRelationship_id-4687050efd0d480e9ca037fdaa0d3682.xml @@ -1,11 +1,11 @@ + value="19"/> diff --git a/model/relations/AssociationRelationship_id-7811a9b72ef543ae96853109042fcbb4.xml b/model/relations/AssociationRelationship_id-7811a9b72ef543ae96853109042fcbb4.xml index 427e2af7..79fc102b 100644 --- a/model/relations/AssociationRelationship_id-7811a9b72ef543ae96853109042fcbb4.xml +++ b/model/relations/AssociationRelationship_id-7811a9b72ef543ae96853109042fcbb4.xml @@ -1,11 +1,11 @@ + value="15"/> diff --git a/model/relations/AssociationRelationship_id-7fd58b0daf6b409aa81b822a2a194b4d.xml b/model/relations/AssociationRelationship_id-7fd58b0daf6b409aa81b822a2a194b4d.xml index 558921f0..fcc09be2 100644 --- a/model/relations/AssociationRelationship_id-7fd58b0daf6b409aa81b822a2a194b4d.xml +++ b/model/relations/AssociationRelationship_id-7fd58b0daf6b409aa81b822a2a194b4d.xml @@ -1,11 +1,11 @@ + value="17"/> diff --git a/model/relations/AssociationRelationship_id-8efdc7f6ba8346d8b389d49e851c3df3.xml b/model/relations/AssociationRelationship_id-8efdc7f6ba8346d8b389d49e851c3df3.xml index 3ae465bf..9182ca7a 100644 --- a/model/relations/AssociationRelationship_id-8efdc7f6ba8346d8b389d49e851c3df3.xml +++ b/model/relations/AssociationRelationship_id-8efdc7f6ba8346d8b389d49e851c3df3.xml @@ -1,11 +1,11 @@ + value="16"/> diff --git a/model/relations/AssociationRelationship_id-9e0ceccb2f5648a289ceea6506fc5265.xml b/model/relations/AssociationRelationship_id-9e0ceccb2f5648a289ceea6506fc5265.xml index c446a9ff..c20ea7a3 100644 --- a/model/relations/AssociationRelationship_id-9e0ceccb2f5648a289ceea6506fc5265.xml +++ b/model/relations/AssociationRelationship_id-9e0ceccb2f5648a289ceea6506fc5265.xml @@ -1,11 +1,11 @@ + value="22"/> diff --git a/model/relations/AssociationRelationship_id-a3e2c5d67feb4d7a8d61c86731ca4ae3.xml b/model/relations/AssociationRelationship_id-a3e2c5d67feb4d7a8d61c86731ca4ae3.xml index e7582a31..b0be043b 100644 --- a/model/relations/AssociationRelationship_id-a3e2c5d67feb4d7a8d61c86731ca4ae3.xml +++ b/model/relations/AssociationRelationship_id-a3e2c5d67feb4d7a8d61c86731ca4ae3.xml @@ -1,11 +1,11 @@ + value="20"/> diff --git a/model/relations/AssociationRelationship_id-b3f188c6e4994e56b18264ca58fb8243.xml b/model/relations/AssociationRelationship_id-b3f188c6e4994e56b18264ca58fb8243.xml index 98298049..6dcfb79d 100644 --- a/model/relations/AssociationRelationship_id-b3f188c6e4994e56b18264ca58fb8243.xml +++ b/model/relations/AssociationRelationship_id-b3f188c6e4994e56b18264ca58fb8243.xml @@ -1,11 +1,11 @@ + value="23"/> diff --git a/model/relations/AssociationRelationship_id-c4f11611cc614ba5b9dc5d93c320ea20.xml b/model/relations/AssociationRelationship_id-c4f11611cc614ba5b9dc5d93c320ea20.xml index d126967e..a2aeb79a 100644 --- a/model/relations/AssociationRelationship_id-c4f11611cc614ba5b9dc5d93c320ea20.xml +++ b/model/relations/AssociationRelationship_id-c4f11611cc614ba5b9dc5d93c320ea20.xml @@ -1,11 +1,11 @@ + value="21"/> diff --git a/model/relations/AssociationRelationship_id-c6fc15b8efbf4eada6956dc5b92c7148.xml b/model/relations/AssociationRelationship_id-c6fc15b8efbf4eada6956dc5b92c7148.xml new file mode 100644 index 00000000..d4556c59 --- /dev/null +++ b/model/relations/AssociationRelationship_id-c6fc15b8efbf4eada6956dc5b92c7148.xml @@ -0,0 +1,18 @@ + + + + + + diff --git a/model/relations/AssociationRelationship_id-f93e114a5fb24da288f3673c2947dce7.xml b/model/relations/AssociationRelationship_id-f93e114a5fb24da288f3673c2947dce7.xml index 7f27808d..c1078d52 100644 --- a/model/relations/AssociationRelationship_id-f93e114a5fb24da288f3673c2947dce7.xml +++ b/model/relations/AssociationRelationship_id-f93e114a5fb24da288f3673c2947dce7.xml @@ -1,11 +1,11 @@ + value="18"/>