Merge branch 'master' of https://github.com/MinBZK/gdi-toegang

model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-1064b8991eb64f4e8adc8f35fc1396ea.xml

@@ -2,7 +2,7 @@
     xmlns:archimate="http://www.archimatetool.com/archimate"
     name="Architectuurprincipes"
     id="id-1064b8991eb64f4e8adc8f35fc1396ea"
-    documentation="<p>Architectuurprincipes zijn richtinggevende uitspraken die vooral uitting geven aan een streven. Ze bestaan uit een stelling die uitting 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 vooral als argument worden meegenomen in het maken van keuzes, maar zijn niet per definitie doorslaggevend. Er kunnen contextueel altijd zwaarwegender argumenten zijn, waardoor het toch logischer is om van de principes af te wijken. Deze afweging moet wel expliciet worden gemaakt en vastgelegd. 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.</p>">
+    documentation="<p>Architectuurprincipes zijn richtinggevende uitspraken die vooral uiting geven aan een streven. Ze bestaan uit een stelling die uitting 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 vooral als argument worden meegenomen in het maken van keuzes, maar zijn niet per definitie doorslaggevend. Er kunnen contextueel altijd zwaarwegender argumenten zijn, waardoor het toch logischer is om van de principes af te wijken. Deze afweging moet wel expliciet worden gemaakt en vastgelegd. 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.</p>">
   <properties
       key="elementType"
       value="principle"/>

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="<p><b>Aanleiding</b>
<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 MIDO governancestructuur werken overheidsorganisaties samen aan de doorontwikkeling van de digitale overheid en de GDI. Er is 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 ontwikkelen. Deze architectuur wordt uitgewerkt in vier domeinarchitecturen op het gebied van interactie, toegang, gegevensuitwisseling en infrastructuur. Toegang gaat over het kunnen benaderen van diensten en informatie-objecten die beveiligd zijn. Gegevensuitwisseling is het domein dat gaat over het uitwisselen van gegevens tussen de informatiesystemen van overheidsorganisaties en met andere organisaties. Deze gegevens worden richting gebruikers ontsloten in de context van het domein interactie. Domein infrastructuur ondersteunt de andere domeinen met generieke software en hardware.</p>
<p>
<p>Toegang is onderdeel van de maatregelen die genomen moeten worden in het kader van informatiebeveiliging. Het 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 vooral over organisatie-overstijgende toegang voor burgers en organisaties. Dit staat relatief los van hoe organisaties hun eigen medewerkers toegang verlenen, alhoewel het ook gebruikt kan worden om medewerkers van de ene overheidsorganisatie toegang te geven tot andere overheidsorganisaties. Landelijke voorzieningen zoals DigiD en eHerkenning zijn de belangrijkste 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 nieuwe eIDAS 2.0 verordening European Digital Identity Wallets geïntroduceerd die ook als authenticatiemiddel kunnen worden ingezet. In meer algemene zin hebben ontwikkelingen zoals Self Sovereign Identity grote impact op hoe idealiter met toegang wordt omgegaan.</p>
<p><b>Dit document</b></p>
<p>Dit document beschrijft de domeinarchitectuur voor toegang, als onderdeel van de Generieke Digitale Infrastructuur. Het is opgesteld in een interbestuurlijke werkgroep met vertegenwoordigers van verschillende overheidsorganisaties. Deze zijn ondersteund door bureau MIDO van het ministerie van BZK. Het beschrijft de ontwikkelingen en wet- en regelgeving en vertaalt deze naar een visie en kaders voor de inrichting van toegang tot overheidsorganisaties. Het document is vooral gericht op enterprise-, informatie- en security-architecten bij overheidsorganisaties. Het document is een doorontwikkeling van de eerdere domeinarchitecturen voor identificatie & authenticatie en machtigen & vertegenwoordigen maar kent een andere structuur en opzet. Zo is er voor gekozen om de architectuur zoveel mogelijk in de modelleertaal ArchiMate uit te werken en de details ervan alleen on-line beschikbaar te stellen. Dit document is daarmee een samenvatting en verwijzing naar details die on-line te vinden zijn. De architectuur wordt on-line 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 modelleertool Archi.
</p>
<p>Deze domeinarchitectuur heeft een relatie met de andere domeinarchitecturen, de Architectuur Digitale Overheid en NORA. Met name de domeinarchitectuur gegevensuitwisseling is sterk gerelateerd aan deze domeinarchitectuur, omdat het uitwisselen van gegevens in veel gevallen om toegang vraagt. Er is bewust voor gekozen om geen 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. Deze domeinarchitectuur is nadrukkelijk 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 kun je de domeinarchitectuur zien als een doorvertaling en concretisering van deze overkoepelende architecturen.</p>
<p>De architectuur is ingedeeld in drie categorieën: referentie-architectuur, huidige situatie en gewenste situatie. De referentie-architectuur geeft een (relatief) tijdloze beschrijving van het domein toegang. In de beschrijving van de huidige situatie is een beschrijving van een aantal bestaande overheidsbrede voorzieningen opgenomen alsook een beschrijving van de belangrijkste knelpunten. De beschrijving van de gewenste situatie geeft aan welke ontwikkelingen, wet- en regelgeving, beleid, architectuurprincipes en standaarden van toepassing zijn en welke veranderinitiatieven worden voorgesteld. De architectuur moet vooral worden gezien als een beschrijving van best-practices. Ze geven richting aan ontwerpkeuzes die in programma's en projecten worden gemaakt.
</p>
<p><b>Relatie met andere initiatieven</b></p>
<p>Er zijn allerlei andere intiatieven die zijn gerelateerd aan toegang. Het belangrijkste programma dat er op dit moment loopt is het programma/stelsel toegang. In het kader van dit intiatief is een doelarchitectuur toegang opgesteld die met name inzicht geeft in de impact van de eerste tranche van de Wet digitale overheid. Er is afgestemd dit programma om ervoor te zorgen dat er geen conflicten en overlap ontstaat. Deze domeinarchitectuur kijkt met name breder en verder dan de doelarchitectuur toegang.</p>
<p>Andere belangrijke programma's die impact hebben op toegang zijn de programma's machtigen & vertegenwoordigen en het EDI programma. De eerste realiseert vooral nieuwe functionaliteit voor machtigen en vertegenwoordigen. Het programma EDI geeft aandacht aan de implementatie van de nieuwe eIDAS 2.0 verordening en het gebruik van European Digital Identity Wallets. Er is afgestemd met deze programma's om dat wat hierover duidelijk is in de architectuur een plek te geven.</p> ">
+    documentation="<p><b>Aanleiding</b>
<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 MIDO governancestructuur werken overheidsorganisaties samen aan de doorontwikkeling van de digitale overheid en de GDI. Er is vanuit deze governance 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. Deze architectuur wordt nader uitgewerkt in vier domeinarchitecturen op het gebied van interactie, toegang, gegevensuitwisseling en infrastructuur. Gegevensuitwisseling is het domein dat gaat over het uitwisselen van gegevens tussen de informatiesystemen van overheidsorganisaties en met andere organisaties. Deze gegevens worden richting gebruikers ontsloten in de context van het domein interactie. De beveiligde toegang tot gegevens is onderdeel van het domein toegang. Domein infrastructuur ondersteunt de andere domeinen met generieke voorzieningen, zowel software als hardwarematig.</p>
<p>Toegang is onderdeel van de maatregelen die genomen moeten worden in het kader van informatiebeveiliging. Het 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 vooral over organisatie-overstijgende toegang voor burgers en organisaties. Dit staat relatief los van hoe organisaties hun eigen medewerkers toegang verlenen, alhoewel het ook gebruikt kan worden om medewerkers van de ene overheidsorganisatie toegang te geven tot andere overheidsorganisaties. Landelijke voorzieningen zoals DigiD en eHerkenning zijn de belangrijkste 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 nieuwe eIDAS 2.0 verordening European Digital Identity Wallets geïntroduceerd die ook als authenticatiemiddel kunnen worden ingezet. In meer algemene zin hebben ontwikkelingen zoals Self Sovereign Identity grote impact op hoe idealiter met toegang wordt omgegaan.</p>
<p><b>Dit document</b></p>
<p>Dit document beschrijft de domeinarchitectuur voor toegang, als onderdeel van de Generieke Digitale Infrastructuur. Het is opgesteld in een interbestuurlijke werkgroep met vertegenwoordigers van verschillende overheidsorganisaties. Deze zijn ondersteund door bureau MIDO van het ministerie van BZK. Het beschrijft de ontwikkelingen en wet- en regelgeving en vertaalt deze naar een visie en kaders voor de inrichting van toegang tot overheidsorganisaties. Het document is vooral gericht op enterprise-, informatie- en security-architecten bij overheidsorganisaties. Het document is een doorontwikkeling van de eerdere domeinarchitecturen voor identificatie & authenticatie en machtigen & vertegenwoordigen maar kent een andere structuur en opzet. Zo is ervoor gekozen om de architectuur zoveel mogelijk in de modelleertaal ArchiMate uit te werken en de details ervan alleen on-line beschikbaar te stellen. Dit document is daarmee een samenvatting en verwijzing naar details die on-line te vinden zijn. De architectuur wordt on-line 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>Deze domeinarchitectuur heeft een relatie met de andere domeinarchitecturen, de Architectuur Digitale Overheid en NORA. Met name de domeinarchitectuur gegevensuitwisseling is sterk gerelateerd aan deze domeinarchitectuur, omdat het uitwisselen van gegevens in veel gevallen om toegang vraagt. Er is bewust voor gekozen om geen 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. Deze domeinarchitectuur is nadrukkelijk 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>
<p>De architectuur is ingedeeld in drie categorieën: referentie-architectuur, huidige situatie en gewenste situatie. De referentie-architectuur geeft een (relatief) tijdloze beschrijving van het domein toegang. In de beschrijving van de huidige situatie is een beschrijving van een aantal bestaande overheidsbrede voorzieningen opgenomen alsook een beschrijving van de belangrijkste knelpunten. De beschrijving van de gewenste situatie geeft aan welke ontwikkelingen, wet- en regelgeving, beleid, architectuurprincipes en standaarden van toepassing zijn en welke veranderinitiatieven worden voorgesteld. De architectuur moet vooral worden gezien als een beschrijving van best-practices. Ze geven richting aan ontwerpkeuzes die in programma's en projecten worden gemaakt.
</p>
<p><b>Relatie met andere initiatieven</b></p>
<p>Er zijn allerlei andere initiatieven die zijn gerelateerd aan toegang. Het belangrijkste programma dat er op het moment van schrijven van dit document loopt is het programma/stelsel toegang. In het kader van dit intiatief is een doelarchitectuur toegang opgesteld die met name inzicht geeft in de impact van de eerste tranche van de Wet digitale overheid. Er is afgestemd dit programma om ervoor te zorgen dat er geen conflicten en overlap ontstaat. Deze domeinarchitectuur kijkt met name breder en verder dan de doelarchitectuur toegang.</p>
<p>Andere belangrijke programma's die impact hebben op toegang zijn de programma's machtigen & vertegenwoordigen en het EDI programma. De eerste realiseert vooral nieuwe functionaliteit voor machtigen en vertegenwoordigen. Het programma EDI geeft aandacht aan de implementatie van de nieuwe eIDAS 2.0 verordening en het gebruik van European Digital Identity Wallets. Er is afgestemd met deze programma's om dat wat hierover duidelijk is in de architectuur een plek te geven.</p> ">
   <profiles
       href="folder.xml#id-b5e689fa75694829b24cf22fd76eacee"/>
 </archimate:Representation>

model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-99cbfb6171e24415a2d555ae897ba9d6.xml

@@ -2,7 +2,7 @@
     xmlns:archimate="http://www.archimatetool.com/archimate"
     name="Bedrijfsfuncties"
     id="id-99cbfb6171e24415a2d555ae897ba9d6"
-    documentation="<p>
Bedrijfsfuncties zijn activiteiten die organisaties uitvoeren, los van hoe ze zijn georganiseerd. In deze domeinarchitectuur hebben we functies benoemd die in het algemeen relevant zijn voor toegang. De functies beschrijven vooral activiteiten op organisatieniveau, maar ze zijn ook te zien als functies van informatiesystemen. Organisaties zullen ervoor moeten worden dat deze bedrijfsfuncties 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 intermediars of dienstverleners. Op landelijk niveau zijn er ook generieke voorzieningen beschikbaar die invulling geven aan een aantal van deze functies. 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 capabilities, architectuurprincipes, bedrijfsobjecten, voorzieningen en standaarden.
</p>
<p>
<img src="https://minbzk.github.io/gdi-toegang/images/functiemodel.svg">
</p>">
+    documentation="<p>
Bedrijfsfuncties zijn activiteiten die organisaties uitvoeren, los van hoe ze zijn georganiseerd. In deze domeinarchitectuur hebben we functies benoemd die in het algemeen relevant zijn voor toegang. De functies beschrijven vooral activiteiten op organisatieniveau, maar ze zijn ook te zien als functies van informatiesystemen. Organisaties zullen ervoor moeten worden dat deze bedrijfsfuncties 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. 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 capabilities, architectuurprincipes, bedrijfsobjecten, voorzieningen en standaarden.
</p>
<p>
<img src="https://minbzk.github.io/gdi-toegang/images/functiemodel.svg">
</p>">
   <properties
       key="elementType"
       value="business-function"/>

model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-c01f60f9719f4ef2bfcb8cf050cc36d2.xml

@@ -2,7 +2,7 @@
     xmlns:archimate="http://www.archimatetool.com/archimate"
     name="Standaarden"
     id="id-c01f60f9719f4ef2bfcb8cf050cc36d2"
-    documentation="<p>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. Deze zijn aangevuld met andere standaarden die breder worden gebruikt of relevant zijn. De standaarden zijn voorzien van een aantal standaard eigenschappen zoals de beheerorganisatie en een URL naar meer informatie. Ze zijn ook gekoppeld aan bedrijfsfuncties en bedrijfsobjecten zodat hun toepassingsgebied duidelijk is. Bij de standaarden van Forum Standaardisatie zijn ook de status en het functioneel toepassingsgebied overgenomen.</p>">
+    documentation="<p>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, waarbij alleen de domein/sectoroverstijgende standaarden zijn overgenomen. Deze zijn aangevuld met andere standaarden die breder worden gebruikt of relevant zijn. De standaarden zijn voorzien van een aantal standaard eigenschappen zoals de beheerorganisatie en een URL naar meer informatie. Ze zijn ook gekoppeld aan bedrijfsfuncties en bedrijfsobjecten zodat hun toepassingsgebied duidelijk is. Bij de standaarden van Forum Standaardisatie zijn ook de status en het functioneel toepassingsgebied overgenomen.</p>">
   <properties
       key="elementType"
       value="constraintStandaard"/>