From 4daed007cfcfd43b67130c52f3184fc41079bf04 Mon Sep 17 00:00:00 2001 From: Danny Greefhorst <46052032+dgreefhorst@users.noreply.github.com> Date: Tue, 3 Sep 2024 15:30:21 +0200 Subject: [PATCH] een deel van het reviewcommentaar verwerkt --- ...on_id-57896b8c4e854e7b92ed667986aa09ee.xml | 2 +- ...on_id-9704fa59cc7b4b5e9daa53f1b32ec98d.xml | 2 +- ...on_id-e572700165f84f9783f1b3d0e3162a5c.xml | 2 +- ...on_id-96ff8c5d886f4013b003c77ee8907044.xml | 5 ++ ...on_id-c89765631a7f4df58760c8fc9d6acea7.xml | 4 +- ...on_id-ed79e8b5aed54001b5024d2c02233232.xml | 5 -- ...el_id-01f6b7a9881e4290a6180343cd8d7e1f.xml | 39 ++++++--- ...el_id-08c765dc4dea4790a2a37c17bfbe69aa.xml | 27 ------- ...el_id-28e4eab18ef74a56baae2e328f6b5734.xml | 27 ------- ...el_id-7158d8c170f34df984206df5a91c3916.xml | 33 ++++++-- ...el_id-87cdcc2afbb3401e82d091e571f05fd3.xml | 4 +- ...el_id-c0c8bbad71bf41afa2492c477d80c6fa.xml | 33 ++++++-- ...el_id-c535327b8e144674afbd41117a90a47e.xml | 79 ++++++++++++++++++- ...el_id-95ac19da61da4880ae11cd3bd2a82ff2.xml | 27 ------- ...el_id-e1cf58e0b07f4907bdce34ba561b9a18.xml | 48 +++++------ ...el_id-d87b04d2bc5640e99880cbefb656ffde.xml | 60 +++++++------- ...ge_id-4751ff0f92c04cec9018b13305d1f476.xml | 5 ++ ...ge_id-d9b8e51c53c74a589f8dadf156c1786c.xml | 4 +- ...ge_id-dd07b5c0a2b74ce78e00c000687f637e.xml | 4 +- ...nt_id-26a67ab67a2345c59d5176c597443a38.xml | 2 +- ...nt_id-3a7e254272734fc3a2fccc69a94232cc.xml | 5 ++ ...nt_id-516315a21d3943c48d3859fd7c28308e.xml | 5 ++ ...nt_id-9e52332306d7404a9bc5432da3040f4b.xml | 5 ++ ...nt_id-dcdf473919e14835becc91f9cd0ea123.xml | 2 +- ...nt_id-dcf64f87176748e19a4fbbcc16dd4f08.xml | 2 +- ...le_id-77965a4ab86c43fb809656f759830dc1.xml | 6 +- ...le_id-b304c80b029c48498a32d80d14337ea3.xml | 21 +++++ ...le_id-b4dce57205fe4d48b888481350c6fae1.xml | 10 +-- ...le_id-d1b6dbdd642f48b0b7c831258051bbc7.xml | 2 +- ...le_id-eaf013562885445e9b0263d9289a8800.xml | 30 ------- ...p_id-a2e50ce89a764bdd9694cecb48431157.xml} | 4 +- ...ip_id-422f62cd38e8492fa95bf2d57e82bd30.xml | 11 +++ ...ip_id-63c1a979dc9e41628bb9d3f57708ba30.xml | 11 +++ ...ip_id-f128220572384499aaecae01e1881fd8.xml | 11 +++ ...ip_id-d5686691ddb64aa1916d220edf4d6009.xml | 2 +- 35 files changed, 310 insertions(+), 229 deletions(-) create mode 100644 model/business/id-9cf74dde1b46462398225462cac533db/BusinessFunction_id-96ff8c5d886f4013b003c77ee8907044.xml delete mode 100644 model/business/id-9cf74dde1b46462398225462cac533db/BusinessFunction_id-ed79e8b5aed54001b5024d2c02233232.xml create mode 100644 model/implementation_migration/id-7f88a37d7f6d448eb35e03e10aa0e64d/WorkPackage_id-4751ff0f92c04cec9018b13305d1f476.xml create mode 100644 model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-3a7e254272734fc3a2fccc69a94232cc.xml create mode 100644 model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-516315a21d3943c48d3859fd7c28308e.xml create mode 100644 model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-9e52332306d7404a9bc5432da3040f4b.xml create mode 100644 model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-b304c80b029c48498a32d80d14337ea3.xml delete mode 100644 model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-eaf013562885445e9b0263d9289a8800.xml rename model/relations/{CompositionRelationship_id-52ba6cebed32469b91fc99ee8046c05a.xml => CompositionRelationship_id-a2e50ce89a764bdd9694cecb48431157.xml} (72%) create mode 100644 model/relations/InfluenceRelationship_id-422f62cd38e8492fa95bf2d57e82bd30.xml create mode 100644 model/relations/InfluenceRelationship_id-63c1a979dc9e41628bb9d3f57708ba30.xml create mode 100644 model/relations/InfluenceRelationship_id-f128220572384499aaecae01e1881fd8.xml diff --git a/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-57896b8c4e854e7b92ed667986aa09ee.xml b/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-57896b8c4e854e7b92ed667986aa09ee.xml index c1c829d4..e7a2517c 100644 --- a/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-57896b8c4e854e7b92ed667986aa09ee.xml +++ b/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-57896b8c4e854e7b92ed667986aa09ee.xml @@ -2,7 +2,7 @@ xmlns:archimate="http://www.archimatetool.com/archimate" name="Architectuurvisie" id="id-57896b8c4e854e7b92ed667986aa09ee" - documentation="<p>Deze architectuurvisie geeft een overzicht van de belangrijkste overtuigingen in de domeinarchitectuur. Het kan voor een belangrijk deel worden gezien als het overkoepelende verhaal en een samenvatting en verbinding van de architectuurprincipes. Het bevat dan ook verwijzingen naar deze architectuurprincipes, waar meer over hun rationale en implicaties kan worden gelezen. </p> <h2>Inleiding</h2> <p> Het is belangrijk dat iedereen op een veilige en betrouwbare manier gebruik kan maken van de digitale dienstverlening van overheidsorganisaties. Dit vraagt dat de digitale identiteit van een gebruiker wordt gecontroleerd en dat wordt bepaald of deze ook namens iemand anders mag handelen. Voor burgers is hiervoor de landelijke voorziening DigiD beschikbaar, inclusief functionaliteit voor machtigen. Voor bedrijven en andere organisaties is het eHekenning (Afsprakenstelsel Elektronische Toegangsdiensten) ingericht, waarbij marktpartijen zich kunnen aanbieden als makelaar, machtigingsregister en/of middelenverstrekker. Er is ook een ketenmachtigingsvoorziening beschikbaar, waarmee organisaties elkaar kunnen machtigen voor specifieke diensten. Het is inmiddels ook mogelijk om grensoverstijgend toegang te krijgen tot digitale diensten van Europese lidstaten. Het is de verantwoordelijkheid van (overheids)organisaties zelf om te controleren of een gebruiker ook geautoriseerd is voor een specifieke dienst, functionaliteit of set van gegevens. </p> <p> Vanuit de wet- en regelgeving is met name de herziene verordening <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-3d6bbaf27b0c44bf84e270f33ac5ed6a.html">"Electronic Identification And Trust Services" (eIDAS)</a> een belangrijke drijfveer voor verandering. In de verordening wordt een European Digital Identity (EDI) Wallet geïntroduceerd. Hiermee wordt het voor burgers en organisaties mogelijk om meer zelf in controle te komen van de gegevens die ze delen met dienstverleners. Dit is een belangrijke stap in de richting van Self Sovereign Identity (SSI), waarbij de gebruiker zelf centraal staat. De verordening gaat ervanuit dat elke lidstaat een of meerdere digitale identity wallets erkent en deze beschikbaar stelt aan haar burgers en bedrijven. De lidstaat voorziet de digitale identity wallet(s) van een nationale PID (persoons identificatie data) waarmee de persoon zichzelf kan identificeren en toegang kan krijgen tot zowel publieke als private diensten.</p> <p> In Nederland is de <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-e3c05a29b4c149c785cc57d71372db2f.html">Wet digitale overheid</a> belangrijk, die voor een deel een doorvertaling is van de eIDAS verordening uit 2014. In dat kader worden eisen gesteld aan de betrouwbaarheid van identificatiemiddelen, waardoor overheidsorganisaties gedwongen worden op een meer professionele manier met toegang om te gaan. Het betekent ook dat er ook private identificatiemiddelen kunnen worden ondersteund. In de herziene versie van de verordening kader wordt een European Digital Identity (EDI) Wallet geïntroduceerd. Hiermee wordt het voor burgers en organisaties mogelijk om meer zelf in controle te komen van de gegevens die ze delen met dienstverleners. Dit is een belangrijke stap in de richting van Self Sovereign Identity (SSI), waarbij gebruikers zelf controle hebben over hun eigen identiteit. </p> <h2>Vertrouwen</h2> <p> Een belangrijk thema in de context van toegang is vertrouwen. Voor veel maatschappelijke processen is het vertrouwen dat je zaken doet met de juiste organisatie of persoon cruciaal. Een dienstverlener wil kunnen vertrouwen op de identiteit van gebruikers; het is een vertrouwende partij. Daarvoor moet deze dienstverlener kunnen vertrouwen op partijen die verklaringen kunnen afgeven over de identiteiten van deze gebruikers en hun attributen (eigenschappen, inclusief bevoegdheden). Door <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-b4dce57205fe4d48b888481350c6fae1.html">gebruik te maken van verifieerbare verklaringen</a> is het mogelijk om te controleren dat deze attributen kloppen en dat ze nog geldig zijn. Daarbij is ook het betrouwbaarheidsniveau waarmee de verklaring tot stand is gekomen relevant. Voor het bouwen van vertrouwen tussen partijen wordt gebruik gemaakt van vertrouwensnetwerken, waarin zij onderling afspraken hebben gemaakt. Een voorbeeld van een vertrouwensnetwerk is eHerkenning. Ook in de gegevensruimtes zoals voorgesteld in de Europese datastrategie speelt vertrouwen een sleutelrol. Partijen bepalen zelf aan wie zij hun gegevens willen verstrekken en zijn daar alleen toe bereid als zij vertrouwen hebben in de identiteit en bevoegdheden van andere partijen.</p> <p> Burgers willen erop kunnen vertrouwen dat organisaties op een zorgvuldige manier omgaan met hun persoonsgegevens. Daarbij is dataminimalisatie een concreet aandachtspunt. Organisaties zouden niet meer gegevens moeten verwerken dan wat nodig is voor hun gebruiksdoel. Als het bijvoorbeeld voldoende is om te weten dat iemand 18 jaar of ouder is, zou niet de geboortedatum moeten worden uitgewisseld maar volstaat een ja/nee antwoord. Het experiment besluit BRP (2024) sorteert hier op voor door uitwisseling van informatie in plaats van alle (onderliggende) gegevens mogelijk te maken. Voor toegang betekent dit bijvoorbeeld dat <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-77965a4ab86c43fb809656f759830dc1.html">de toegangsinfrastructuur niet meer gegevens uitwisselt, dan wat noodzakelijk is om toegang te verstrekken</a>. </p> <p> SSI is een visie op toegang en gegevensuitwisseling die specifiek gericht is op het beschermen van de privacy van gebruikers en het ondersteunen van autonomie. Daarbij zijn gebruikers zelf maximaal in controle. Het minimaliseert de kans op misbruik van persoonsgegevens en voorkomt ook afhankelijkheid van centrale partijen. Gebruikers creëren zelf hun identiteit, verzamelen verklaringen van verklarende partijen en verstrekken ze zelf aan vertrouwende partijen. Ze kunnen ook dingen over zichzelf verklaren. Ze hebben een persoonlijke omgeving waarin zij hun verklaringen beheren, die niet toegankelijk is voor anderen. Een dienstverlener die wil controleren of een identiteit of verklaring die een gebruiker verstrekt klopt en nog geldig is kan gebruik maken van een registratie van verifieerbare gegevens. Deze registratie bevat ook gegevens over de (decentrale) identiteiten die gebruikers zelf hebben aangemaakt. Overigens kan een gebruiker ook besluiten een verklaring niet volledig door te geven aan een dienstverlener, maar alleen een subset of afgeleid gegeven (zoals dat deze ouder dan 18 jaar is). Dit heet ook wel een verifieerbare presentatie. Een gebruiker kan ook besluiten om de eigen identiteit niet kenbaar te maken naar de dienstverlener, maar alleen een specifieke verklaring. Het zorgt er dus voor dat een dienstverlener alleen beschikt over de gegevens die relevant zijn voor het doel. De verstrekker van gegevens heeft ook geen zicht op de dienstverleners aan wie de verklaringen zijn verstrekt. Er zijn al allerlei oplossingen om SSI te ondersteunen, in de vorm van personal data management oplossingen (ook wel: wallets).</p> <p><center><img src="https://minbzk.github.io/gdi-toegang/images/vc.svg"></center></p> <p> In de context van de eIDAS 2.0 verordening (2024) wordt een European Digital Identity Wallet voorgesteld. Het biedt een Europees gestandaardiseerde manier om verifieerbare verklaringen uit te wisselen, op basis van specifieke standaarden. De EDI-wallet is een combinatie van een identificatiemiddel (op betrouwbaarheidsniveau hoog) en een manier om gegevens te delen. Gebruikers kunnen zelf verifieerbare verklaringen ophalen en bepalen zelf aan wie ze deze verklaringen verstrekken. Het sluit daarmee voor een belangrijk deel aan bij de SSI visie. In tegenstelling tot de SSI visie maken gebruikers zelf geen identiteit aan, maar wordt gebruik gemaakt van de door de overheid uitgegeven identiteit die ook in andere Europese landen kan worden gebruikt. De eIDAS verordening onderkent dat er onderscheid is in gekwalificeerde en niet gekwalificeerde verklaringen. Gekwalificeerde verklaringen voldoen aan extra eisen en zijn uitgegeven door expliciet goedgekeurde partijen, waardoor ze extra zekerheden bieden. Om vertrouwen te creëren tussen partijen zijn er vertrouwensdiensten nodig die hierin kunnen ondersteunen. De eIDAS verordening beschrijft een aantal van dit soort vertrouwensdiensten. Het gaat onder meer om diensten voor het zetten van elektronische handtekeningen (door mensen), het elektronisch verzegelen van gegevens (door een organisatie), het creëren van elektronische verifieerbare verklaringen, het creëren van elektronische tijdstempels en het beschermen en bewijzen van elektronische uitwisseling van gegevens. Deze diensten worden aangeboden of ondersteund door leveranciers in de markt en zijn voor organisaties inzetbaar voor het ondersteunen van het verstrekken van toegang en het uitwisselen van gegevens. </p> <h2>Toegankelijk en veilig</h2> <p> Het is belangrijk dat <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-8149432665a347bba7f3d97a5f506193.html">iedereen die daar recht op heeft toegang krijgt tot digitale diensten</a>. Iedereen moet mee kunnen doen in het digitale tijdperk. Dat vraagt naast het ondersteunen van alle restgroepen ook dat de toegangsinfrastructuur digitoegankelijk is zodat mensen met een functiebeperking er ook gebruik van kunnen maken. Mensen die minder digitaal vaardig zijn moeten ook op andere manieren toegang kunnen te krijgen tot digitale dienstverlening van de overheid, via andere kanalen. Toegang moet worden ondersteund door gebruiksvriendelijke voorzieningen en met voldoende instructies door mensen die dat nodig hebben. Het is bekend dat bestaande identificatiemiddelen niet optimaal toegankelijk zijn voor minder digitaal vaardigen. Er is ook een goede balans nodig tussen veiligheid en gebruikersvriendelijkheid. <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-d1b6dbdd642f48b0b7c831258051bbc7.html">Gebruikers zouden niet moeten worden lastig gevallen met beveiligingsmaatregelen die meer zekerheid creëren dan nodig is voor specifieke gevallen</a>. We moeten ervoor zorgen dat de dienstverlening van de overheid voldoende toegankelijk blijft en geen onnodige drempels opwerpt. </p> <p>Naast toegankelijkheid is ook veiligheid belangrijk. Organisaties moeten <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-4532a251a8ba490298dc08824ef4799a.html">voldoende beveiligingsmaatregelen</a> nemen om de impact van mensen met kwade bedoelingen zoveel mogelijk te beperken. Het toepassen van een <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-eaf013562885445e9b0263d9289a8800.html">zero-trust beveiligingsmodel</a> is daarvoor een belangrijke basis. Zero-trust betekent dat er niet van wordt uitgegaan dat gebruikers, apparaten en het netwerk vertrouwd kunnen worden. Alle toegang tot resources wordt voortdurend geverifieerd en gevalideerd. Organisaties zullen specifiek aandacht moeten geven aan allerlei nieuwe cyberdreigingen en een deel van de overheid wordt daar door de Europese NIS2-richtlijn ook toe gedwongen. Er geldt een zorg-, melding- en registratieplicht en organisaties vallen onder toezicht. Dit betekent bijvoorbeeld dat zij expliciet een risicobeoordeling moeten uitvoeren, gebruik moeten maken van sterke authenticatie en dat ze een plicht hebben om incidenten binnen 24 uur te melden. Overheidsorganisaties hebben daarbij een bijzondere positie. We willen ze in de basis kunnen vertrouwen, maar de realiteit is dat de overheid ook uit mensen bestaat en daarmee inherent gevoelig is voor fouten en verkeerde intenties. De impact van beslissingen van de overheid op het leven van mensen kan echter heel groot zijn. Er zou daarom <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-4532a251a8ba490298dc08824ef4799a.html">expliciete aandacht moeten zijn om misbruik door overheden te voorkomen</a>. Uiteraard vraagt ook potentieel misbruik en fraude door niet-overheden expliciete aandacht. </p> <h2>Doorontwikkeling nationale toegangsinfrastructuur</h2> <p>De toegangsinfrastructuur zou partijen moeten <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-05cd71c3758c4182878ba143b870582f.html">ontzorgen</a> met afspraken, standaarden en voorzieningen. Daarbij hebben afspraken de voorkeur boven standaarden boven voorzieningen. Daarnaast beweegt de GDI van centrale voorzieningen naar stelsels en standaarden, zoals beschreven in de meerjarenvisie. Een goed gedefinieerd en toekomstvast koppelvlak dat door allerlei partijen kan worden ondersteund, is in veel gevallen waardevoller en flexibeler dan een centrale voorziening. Deze beweging is ook zichtbaar rondom gegevensuitwisseling, waar de Europese Commissie inzet op gegevensruimtes en er in Nederland gewerkt wordt aan een federatief datastelsel. Het gebruik van verifieerbare verklaringen maakt het ook veel eenvoudiger om gegevens meer decentraal te administreren; de beschikbaarheid van een verifieerbare verklaring van een vertrouwde partij is voldoende om vertrouwen te krijgen in de authenticiteit en integriteit van digitale identiteiten, hun attributen en bevoegdheden.</p> <p>Het is duidelijk dat wet- en regelgeving een belangrijke drijfveer is voor de doorontwikkeling van de nationale toegangsinfrastructuur. Er loopt al langere tijd een initiatief voor het inrichten van een nieuw toegangsstelsel, dat ernaar streeft om toegangsinfrastructuur voor burgers en bedrijven te integreren. Het zorgt ervoor dat burgers en bedrijven veilig toegang hebben tot digitale dienstverlening en de beschikking hebben over betrouwbare inlogmiddelen om namens henzelf of namens een ander op het juiste betrouwbaarheidsniveau in te kunnen loggen bij organisaties. Op basis van de eIDAS verordening zijn eHerkenning en DigiD genotificeerd (erkend) voor grensoverschrijdende dienstverlening. In de toekomst zullen er extra publieke en private identificatiemiddelen beschikbaar komen voor burgers en bedrijven. Als gevolg van de herziening van de eIDAS verordening zullen er ID-wallets komen, die als identificatiemiddel gebruikt kunnen worden. Het zal mogelijk worden om gebruik te maken van private identificatiemiddelen zoals iDIN. De politiek heeft ook aangegeven dat er een publiek (gratis) zakelijk inlogmiddel beschikbaar zal worden gesteld (motie van der Molen). Er zal voor burgers een digitale bronidentiteit komen die iedereen uniek identificeert, en die ook bruikbaar is in het bedrijvendomein. Burgers kunnen hun basisgegevens uit de digitale bronidentiteit toevoegen aan de toegelaten identificatiemiddelen. </p> <p> Er zijn ook een aantal andere zaken die doorontwikkeling van de nationale toegangsinfrastructuur vragen. Zo is het bijvoorbeeld voor <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-388da3df069946eb8fcc9f6b801b1882.html">een aantal restgroepen niet mogelijk om in te loggen met DigiD of eHerkenning</a>. Het is daarom nodig om gezaghebbende bronnen te creëren of aan te wijzen voor deze restgroepen en deze voor breder gebruik beschikbaar te stellen. Het is het op dit moment ook niet goed mogelijk om mensen <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-26a67ab67a2345c59d5176c597443a38.html">wettelijk te laten vertegenwoordigen door bewindvoerders, curatoren en mentoren</a>. Mensen zijn namelijk niet altijd in staat om zelf gebruik te maken van digitale diensten, of zijn mogelijk zelf niet eens bevoegd om digitale diensten te gebruiken. Bij het inloggen moet standaard met vertegenwoordiging rekening worden gehouden. Gebruikers die inloggen hebben naast hun eigen bevoegdheden ook altijd bevoegdheden die horen bij de partijen die ze wettelijk vertegenwoordigen. Er is ook een behoefte aan een identificatiemiddel voor toegang tot diensten die geen BSN morgen verwerken. Verder is de vraag hoe in de toekomst met machtigingsregisters zou moeten worden omgegaan. Functionaliteit voor machtigen is nu verspreid over allerlei systemen, mede doordat er behoefte is aan meer specifieke machtigingsfunctionaliteit zoals het kunnen machtigen voor zaken. Zoals hiervoor beschreven, betekent dat niet per definitie dat er meer centraal moet worden geadministreerd. Door gebruik te maken van verifieerbare verklaringen kunnen vertegenwoordigingsbevoegdheden ook decentraal worden vastgelegd en beschikbaar gesteld. De nieuwe EDI wallet zal ook functionaliteit bieden voor machtigen en is bij uitstek in staat om verifieerbare verklaringen te verstrekken. </p> <p> Voor toegang van systemen tot andere systemen is het PKIoverheid afsprakenstelsel ingericht. Tegelijkertijd zijn er Europese afspraken en standaarden waar we als Nederland op zouden moeten aansluiten. De Federated Service Connectivity standaard, zoals ontwikkeld in de context van het Common Ground programma, biedt waardevolle mogelijkheden voor toegang zoals het kunnen machtigen van partijen voor het geautomatiseerd uitwisselen van gegevens. Er is in de Europese datastrategie ook aandacht voor gegevensruimtes, waarvoor inmiddels ook een aantal afsprakenstelsels en voorzieningen beschikbaar zijn. Deze bieden ook oplossingen voor toegang tussen systemen, waarbij datasoevereiniteit het uitgangspunt is. In de context daarvan ontstaat meer aandacht voor Policy Based Access Control, waarbij meer fijnmazig, contextueel en adaptief toegang kan worden verstrekt. Het is ook in bredere zin relevanter aan het worden, bijvoorbeeld om autorisatieregels los van applicaties te kunnen beheren. Het is ook een kernaspect van zero-trust architecturen en daarmee een maatregel om de beveiliging te verhogen. </p>"> + documentation="<p>Deze architectuurvisie geeft een overzicht van de belangrijkste overtuigingen in de domeinarchitectuur. Het kan voor een belangrijk deel worden gezien als het overkoepelende verhaal en een samenvatting en verbinding van de architectuurprincipes. Het bevat dan ook verwijzingen naar deze architectuurprincipes, waar meer over hun rationale en implicaties kan worden gelezen. </p> <h2>Inleiding</h2> <p> Het is belangrijk dat iedereen op een veilige en betrouwbare manier gebruik kan maken van de digitale dienstverlening van digitale publieke diensten. Dit vraagt dat de digitale identiteit van een gebruiker wordt gecontroleerd en dat wordt bepaald of deze ook namens iemand anders mag handelen. Voor burgers is hiervoor de landelijke voorziening DigiD beschikbaar, inclusief functionaliteit voor machtigen. Voor bedrijven en andere organisaties is het eHekenning (Afsprakenstelsel Elektronische Toegangsdiensten) ingericht, waarbij marktpartijen zich kunnen aanbieden als makelaar, machtigingsregister en/of middelenverstrekker. Er is ook een ketenmachtigingsvoorziening beschikbaar, waarmee organisaties elkaar kunnen machtigen voor specifieke diensten. Het is inmiddels ook mogelijk om grensoverstijgend toegang te krijgen tot digitale diensten van Europese lidstaten. Het is de verantwoordelijkheid van (overheids)organisaties zelf om te controleren of een gebruiker ook geautoriseerd is voor een specifieke dienst, functionaliteit of set van gegevens. </p> <p> Vanuit de wet- en regelgeving is met name de herziene verordening <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-3d6bbaf27b0c44bf84e270f33ac5ed6a.html">"Electronic Identification And Trust Services" (eIDAS)</a> een belangrijke drijfveer voor verandering. In de verordening wordt een European Digital Identity (EDI) Wallet geïntroduceerd. Hiermee wordt het voor burgers en organisaties mogelijk om meer zelf in controle te komen van de gegevens die ze delen met dienstverleners. Dit is een belangrijke stap in de richting van Self Sovereign Identity (SSI), waarbij de gebruiker zelf centraal staat. De verordening gaat ervanuit dat elke lidstaat een of meerdere digitale identity wallets erkent en deze beschikbaar stelt aan haar burgers en bedrijven. De lidstaat voorziet de digitale identity wallet(s) van een nationale PID (persoons identificatie data) waarmee de persoon zichzelf kan identificeren en toegang kan krijgen tot zowel publieke als private diensten.</p> <p> In Nederland is de <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-e3c05a29b4c149c785cc57d71372db2f.html">Wet digitale overheid</a> belangrijk, die voor een deel een doorvertaling is van de eIDAS verordening uit 2014. In dat kader worden eisen gesteld aan de betrouwbaarheid van identificatiemiddelen, waardoor overheidsorganisaties gedwongen worden op een meer professionele manier met toegang om te gaan. Het betekent ook dat er ook private identificatiemiddelen kunnen worden ondersteund. In de herziene versie van de verordening kader wordt een European Digital Identity (EDI) Wallet geïntroduceerd. Hiermee wordt het voor burgers en organisaties mogelijk om meer zelf in controle te komen van de gegevens die ze delen met dienstverleners. Dit is een belangrijke stap in de richting van Self Sovereign Identity (SSI), waarbij gebruikers zelf controle hebben over hun eigen identiteit. </p> <h2>Vertrouwen</h2> <p> Een belangrijk thema in de context van toegang is vertrouwen. Voor veel maatschappelijke processen is het vertrouwen dat je zaken doet met de juiste organisatie of persoon cruciaal. Een dienstverlener wil kunnen vertrouwen op de identiteit van gebruikers; het is een vertrouwende partij. Daarvoor moet deze dienstverlener kunnen vertrouwen op partijen die verklaringen kunnen afgeven over de identiteiten van deze gebruikers en hun attributen (eigenschappen, inclusief bevoegdheden). Door <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-b4dce57205fe4d48b888481350c6fae1.html">gebruik te maken van verifieerbare verklaringen</a> is het mogelijk om te controleren dat deze attributen kloppen en dat ze nog geldig zijn. Daarbij is ook het betrouwbaarheidsniveau waarmee de verklaring tot stand is gekomen relevant. Voor het bouwen van vertrouwen tussen partijen wordt gebruik gemaakt van vertrouwensnetwerken, waarin zij onderling afspraken hebben gemaakt. Een voorbeeld van een vertrouwensnetwerk is eHerkenning. Ook in de gegevensruimtes zoals voorgesteld in de Europese datastrategie speelt vertrouwen een sleutelrol. Partijen bepalen zelf aan wie zij hun gegevens willen verstrekken en zijn daar alleen toe bereid als zij vertrouwen hebben in de identiteit en bevoegdheden van andere partijen.</p> <p> Burgers willen erop kunnen vertrouwen dat organisaties op een zorgvuldige manier omgaan met hun persoonsgegevens. Daarbij is dataminimalisatie een concreet aandachtspunt. Organisaties zouden niet meer gegevens moeten verwerken dan wat nodig is voor hun gebruiksdoel. Als het bijvoorbeeld voldoende is om te weten dat iemand 18 jaar of ouder is, zou niet de geboortedatum moeten worden uitgewisseld maar volstaat een ja/nee antwoord. Het experiment besluit BRP (2024) sorteert hier op voor door uitwisseling van informatie in plaats van alle (onderliggende) gegevens mogelijk te maken. Voor toegang betekent dit bijvoorbeeld dat <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-77965a4ab86c43fb809656f759830dc1.html">de toegangsinfrastructuur niet meer gegevens uitwisselt, dan wat noodzakelijk is om toegang te verstrekken</a>. </p> <p> SSI is een visie op toegang en gegevensuitwisseling die specifiek gericht is op het beschermen van de privacy van gebruikers en het ondersteunen van autonomie. Daarbij zijn gebruikers zelf maximaal in controle. Het minimaliseert de kans op misbruik van persoonsgegevens en voorkomt ook afhankelijkheid van centrale partijen. Gebruikers creëren zelf hun identiteit, verzamelen verklaringen van verklarende partijen en verstrekken ze zelf aan vertrouwende partijen. Ze kunnen ook dingen over zichzelf verklaren. Ze hebben een persoonlijke omgeving waarin zij hun verklaringen beheren, die niet toegankelijk is voor anderen. Een dienstverlener die wil controleren of een identiteit of verklaring die een gebruiker verstrekt klopt en nog geldig is kan gebruik maken van een registratie van verifieerbare gegevens. Deze registratie bevat ook gegevens over de (decentrale) identiteiten die gebruikers zelf hebben aangemaakt. Overigens kan een gebruiker ook besluiten een verklaring niet volledig door te geven aan een dienstverlener, maar alleen een subset of afgeleid gegeven (zoals dat deze ouder dan 18 jaar is). Dit heet ook wel een verifieerbare presentatie. Een gebruiker kan ook besluiten om de eigen identiteit niet kenbaar te maken naar de dienstverlener, maar alleen een specifieke verklaring. Het zorgt er dus voor dat een dienstverlener alleen beschikt over de gegevens die relevant zijn voor het doel. Er zijn al allerlei oplossingen om SSI te ondersteunen, in de vorm van personal data management oplossingen (ook wel: wallets).</p> <p><center><img src="https://minbzk.github.io/gdi-toegang/images/vc.svg"></center></p> <p> In de context van de eIDAS 2.0 verordening (2024) wordt een European Digital Identity Wallet voorgesteld. Het biedt een Europees gestandaardiseerde manier om verifieerbare verklaringen uit te wisselen, op basis van specifieke standaarden. De EDI-wallet is een combinatie van een identificatiemiddel (op betrouwbaarheidsniveau hoog) en een manier om gegevens te delen. Gebruikers kunnen zelf verifieerbare verklaringen ophalen en bepalen zelf aan wie ze deze verklaringen verstrekken. Het sluit daarmee voor een belangrijk deel aan bij de SSI visie. In tegenstelling tot de SSI visie maken gebruikers zelf geen identiteit aan, maar wordt gebruik gemaakt van de door de overheid uitgegeven identiteit die ook in andere Europese landen kan worden gebruikt. De eIDAS verordening onderkent dat er onderscheid is in gekwalificeerde en niet gekwalificeerde verklaringen. Gekwalificeerde verklaringen voldoen aan extra eisen en zijn uitgegeven door expliciet goedgekeurde partijen, waardoor ze extra zekerheden bieden. Om vertrouwen te creëren tussen partijen zijn er vertrouwensdiensten nodig die hierin kunnen ondersteunen. De eIDAS verordening beschrijft een aantal van dit soort vertrouwensdiensten. Het gaat onder meer om diensten voor het zetten van elektronische handtekeningen (door mensen), het elektronisch verzegelen van gegevens (door een organisatie), het creëren van elektronische verifieerbare verklaringen, het creëren van elektronische tijdstempels en het beschermen en bewijzen van elektronische uitwisseling van gegevens. Deze diensten worden aangeboden of ondersteund door leveranciers in de markt en zijn voor organisaties inzetbaar voor het ondersteunen van het verstrekken van toegang en het uitwisselen van gegevens. </p> <h2>Toegankelijk en veilig</h2> <p> Het is belangrijk dat <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-8149432665a347bba7f3d97a5f506193.html">iedereen die daar recht op heeft toegang krijgt tot digitale diensten</a>. Iedereen moet mee kunnen doen in het digitale tijdperk. Dat vraagt naast het ondersteunen van alle restgroepen ook dat de toegangsinfrastructuur digitoegankelijk is zodat mensen met een functiebeperking er ook gebruik van kunnen maken. Mensen die minder digitaal vaardig zijn moeten ook op andere manieren toegang kunnen te krijgen tot digitale dienstverlening van de overheid, via andere kanalen. Toegang moet worden ondersteund door gebruiksvriendelijke voorzieningen en met voldoende instructies door mensen die dat nodig hebben. Het is bekend dat bestaande identificatiemiddelen niet optimaal toegankelijk zijn voor minder digitaal vaardigen. Er is ook een goede balans nodig tussen veiligheid en gebruikersvriendelijkheid. <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-d1b6dbdd642f48b0b7c831258051bbc7.html">Gebruikers zouden niet moeten worden lastig gevallen met beveiligingsmaatregelen die meer zekerheid creëren dan nodig is voor specifieke gevallen</a>. We moeten ervoor zorgen dat de dienstverlening van de overheid voldoende toegankelijk blijft en geen onnodige drempels opwerpt. </p> <p>Naast toegankelijkheid is ook veiligheid belangrijk. Organisaties moeten <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-4532a251a8ba490298dc08824ef4799a.html">voldoende beveiligingsmaatregelen</a> nemen om de impact van mensen met kwade bedoelingen zoveel mogelijk te beperken. Het toepassen van een <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-eaf013562885445e9b0263d9289a8800.html">zero-trust beveiligingsmodel</a> is daarvoor een belangrijke basis. Zero-trust betekent dat er niet van wordt uitgegaan dat gebruikers, apparaten en het netwerk vertrouwd kunnen worden. Alle toegang tot resources wordt voortdurend geverifieerd en gevalideerd. Organisaties zullen specifiek aandacht moeten geven aan allerlei nieuwe cyberdreigingen en een deel van de overheid wordt daar door de Europese NIS2-richtlijn ook toe gedwongen. Er geldt een zorg-, melding- en registratieplicht en organisaties vallen onder toezicht. Dit betekent bijvoorbeeld dat zij expliciet een risicobeoordeling moeten uitvoeren, gebruik moeten maken van sterke authenticatie en dat ze een plicht hebben om incidenten binnen 24 uur te melden. Overheidsorganisaties hebben daarbij een bijzondere positie. We willen ze in de basis kunnen vertrouwen, maar de realiteit is dat de overheid ook uit mensen bestaat en daarmee inherent gevoelig is voor fouten en verkeerde intenties. De impact van beslissingen van de overheid op het leven van mensen kan echter heel groot zijn. Er zou daarom <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-4532a251a8ba490298dc08824ef4799a.html">expliciete aandacht moeten zijn om misbruik door overheden te voorkomen</a>. Uiteraard vraagt ook potentieel misbruik en fraude door niet-overheden expliciete aandacht. </p> <h2>Doorontwikkeling nationale toegangsinfrastructuur</h2> <p>De toegangsinfrastructuur zou partijen moeten <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-05cd71c3758c4182878ba143b870582f.html">ontzorgen</a> met afspraken, standaarden en voorzieningen. Daarbij hebben afspraken de voorkeur boven standaarden boven voorzieningen. Daarnaast beweegt de GDI van centrale voorzieningen naar stelsels en standaarden, zoals beschreven in de meerjarenvisie. Een goed gedefinieerd en toekomstvast koppelvlak dat door allerlei partijen kan worden ondersteund, is in veel gevallen waardevoller en flexibeler dan een centrale voorziening. Deze beweging is ook zichtbaar rondom gegevensuitwisseling, waar de Europese Commissie inzet op gegevensruimtes en er in Nederland gewerkt wordt aan een federatief datastelsel. Het gebruik van verifieerbare verklaringen maakt het ook veel eenvoudiger om gegevens meer decentraal te administreren; de beschikbaarheid van een verifieerbare verklaring van een vertrouwde partij is voldoende om vertrouwen te krijgen in de authenticiteit en integriteit van digitale identiteiten, hun attributen en bevoegdheden.</p> <p>Het is duidelijk dat wet- en regelgeving een belangrijke drijfveer is voor de doorontwikkeling van de nationale toegangsinfrastructuur. Er loopt al langere tijd een initiatief voor het inrichten van een nieuw toegangsstelsel, dat ernaar streeft om toegangsinfrastructuur voor burgers en bedrijven te integreren. Het zorgt ervoor dat burgers en bedrijven veilig toegang hebben tot digitale dienstverlening en de beschikking hebben over betrouwbare inlogmiddelen om namens henzelf of namens een ander op het juiste betrouwbaarheidsniveau in te kunnen loggen bij organisaties. Op basis van de eIDAS verordening zijn eHerkenning en DigiD genotificeerd (erkend) voor grensoverschrijdende dienstverlening. In de toekomst zullen er extra publieke en private identificatiemiddelen beschikbaar komen voor burgers en bedrijven. Als gevolg van de herziening van de eIDAS verordening zullen er ID-wallets komen, die als identificatiemiddel gebruikt kunnen worden. Het zal mogelijk worden om gebruik te maken van private identificatiemiddelen zoals iDIN. De politiek heeft ook aangegeven dat er een publiek (gratis) zakelijk inlogmiddel beschikbaar zal worden gesteld (motie van der Molen). </p> <p> Er zijn ook een aantal andere zaken die doorontwikkeling van de nationale toegangsinfrastructuur vragen. Zo is het bijvoorbeeld voor <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-388da3df069946eb8fcc9f6b801b1882.html">een aantal restgroepen niet mogelijk om in te loggen met DigiD of eHerkenning</a>. Het is daarom nodig om gezaghebbende bronnen te creëren of aan te wijzen voor deze restgroepen en deze voor breder gebruik beschikbaar te stellen. Het is het op dit moment ook niet goed mogelijk om mensen <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-26a67ab67a2345c59d5176c597443a38.html">wettelijk te laten vertegenwoordigen door bewindvoerders, curatoren, mentoren en mensen die ouderlijk gezag hebben</a>. Mensen zijn namelijk niet altijd in staat om zelf gebruik te maken van digitale diensten, of zijn mogelijk zelf niet eens bevoegd om digitale diensten te gebruiken. Bij het inloggen moet standaard met vertegenwoordiging rekening worden gehouden. Gebruikers die inloggen hebben naast hun eigen bevoegdheden ook altijd bevoegdheden die horen bij de partijen die ze wettelijk vertegenwoordigen. Er is ook een behoefte aan een identificatiemiddel voor toegang tot diensten die geen BSN morgen verwerken. Verder is de vraag hoe in de toekomst met machtigingsregisters zou moeten worden omgegaan. Functionaliteit voor machtigen is nu verspreid over allerlei systemen, mede doordat er behoefte is aan meer specifieke machtigingsfunctionaliteit zoals het kunnen machtigen voor zaken. Zoals hiervoor beschreven, betekent dat niet per definitie dat er meer centraal moet worden geadministreerd. Door gebruik te maken van verifieerbare verklaringen kunnen vertegenwoordigingsbevoegdheden ook decentraal worden vastgelegd en beschikbaar gesteld. De nieuwe EDI wallet zal ook functionaliteit bieden voor machtigen en is bij uitstek in staat om verifieerbare verklaringen te verstrekken. </p> <p> Voor toegang van systemen tot andere systemen is het PKIoverheid afsprakenstelsel ingericht. Tegelijkertijd zijn er Europese afspraken en standaarden waar we als Nederland op zouden moeten aansluiten. De Federated Service Connectivity standaard, zoals ontwikkeld in de context van het Common Ground programma, biedt waardevolle mogelijkheden voor toegang zoals het kunnen machtigen van partijen voor het geautomatiseerd uitwisselen van gegevens. Er is in de Europese datastrategie ook aandacht voor gegevensruimtes, waarvoor inmiddels ook een aantal afsprakenstelsels en voorzieningen beschikbaar zijn. Deze bieden ook oplossingen voor toegang tussen systemen, waarbij datasoevereiniteit het uitgangspunt is. In de context daarvan ontstaat meer aandacht voor Policy Based Access Control, waarbij meer fijnmazig, contextueel en adaptief toegang kan worden verstrekt. Het is ook in bredere zin relevanter aan het worden, bijvoorbeeld om autorisatieregels los van applicaties te kunnen beheren. Het is ook een kernaspect van zero-trust architecturen en daarmee een maatregel om de beveiliging te verhogen. </p>"> diff --git a/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-9704fa59cc7b4b5e9daa53f1b32ec98d.xml b/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-9704fa59cc7b4b5e9daa53f1b32ec98d.xml index 565785ba..44a49472 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="<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/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. 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 infrastructurele voorzieningen, zowel software- als hardwarematig.</p> <p>Het domein toegang omvat alles dat nodig is om de identiteit en bevoegdheden van mensen, organisaties en apparaten te controleren. Toegangsmaatregelen zijn nodig 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 vooral over toegang tot overheidsdiensten 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.</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. 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> <p><b>Dit document</b></p> <p>Dit document beschrijft de domeinarchitectuur voor toegang, als onderdeel van de GDI. Het gaat vooral in op toegang voor burgers en bedrijven, alhoewel een deel van de principes en modellen ook gebruikt kunnen worden voor interne toegang voor medewerkers. Het is opgesteld in een interbestuurlijke architectuurwerkgroep met vertegenwoordigers van verschillende overheidsorganisaties. Deze zijn ondersteund door bureau MIDO van het ministerie van BZK. Het beschrijft relevant beleid, wet- & regelgeving en ontwikkelingen, en vertaalt deze naar een visie en richting 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. De voorgaande documenten blijven grotendeels geldig en waardevol als beschrijving van het domein, maar dit document is leidend daar waar tegenstrijd bestaat. </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 Wet digitale overheid en de begrippen van de NORA IAM werkgroep. We hebben ook actief meegewerkt aan het 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> <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> 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 onderdelen: veranderfactoren, doelarchitectuur en bijlagen. De veranderfactoren geven richting aan de architectuur. De doelarchitectuur bevat de inhoud van de architectuur zelf, in de vorm van een visie en architectuurprincipes. Er is ook een verdiepend hoofdstuk op het gebied van toegang tussen systemen. In de bijlage zijn meer algemene modellen en beschrijvingen opgenomen van de functies, objecten, rollen, voorzieningen en standaarden die van toepassing zijn op toegang. Het beschrijft ook de relatie van de architectuurprincipes met de Architectuur Digitale Overheid en NORA. De architectuur moet vooral worden gezien als een beschrijving van algemene best-practices. Het geeft 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 initiatief 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 breder en verder dan de doelarchitectuur toegang.</p> <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. In het kader programma/stelsel toegang is een doelarchitectuur toegang opgesteld die met name inzicht geeft in de impact van de eerste tranche van de Wet digitale overheid. Er heeft een review plaatsgevonden op deze doelarchitectuur door de architectuurwerkgroep. Deze domeinarchitectuur kijkt met name breder en verder dan de doelarchitectuur toegang. 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. Een punt van aandacht is het feit dat de eerste tranche van de Wdo en daarmee het programma/stelsel toegang gebaseerd is op de eerste eIDAS verordening uit 2014 en het programma EDI-stelsel NL juist in op de in 2024 van kracht geworden eIDAS 2.0. Op een zeker moment zal ook de Wdo op eIDAS 2.0 moeten worden aangepast.</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 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. 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 infrastructurele voorzieningen, zowel software- als hardwarematig.</p> <p>Het domein toegang omvat alles dat nodig is om de identiteit en bevoegdheden van mensen, organisaties en apparaten te controleren. Toegangsmaatregelen zijn nodig 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 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. 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> <p><b>Dit document</b></p> <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 zijn ondersteund door bureau MIDO van het ministerie van BZK. Het beschrijft relevant beleid, wet- & regelgeving en ontwikkelingen, en vertaalt deze naar een visie en richting voor de inrichting van toegang tot digitale publieke diensten. De architectuur geeft richting aan ontwerpkeuzes die worden gemaakt bij het doorontwikkelen van de GDI of bij het aansluiten op de GDI. Het speelt een formele rol in de kaderstelling, toezicht en monitoring van programma’s en projecten die gefinancierd worden vanuit de MIDO governancestructuur. 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. De voorgaande documenten blijven grotendeels geldig en waardevol als beschrijving van het domein, maar dit document is leidend daar waar tegenstrijd bestaat. </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 Wet digitale overheid en de begrippen van de NORA IAM werkgroep. We hebben ook actief meegewerkt aan het 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> <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> 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 onderdelen: veranderfactoren, doelarchitectuur en bijlagen. De veranderfactoren geven richting aan de architectuur. De doelarchitectuur bevat de inhoud van de architectuur zelf, in de vorm van een visie en architectuurprincipes. Er is ook een verdiepend hoofdstuk op het gebied van toegang tussen systemen. In de bijlage zijn meer algemene modellen en beschrijvingen opgenomen van de functies, objecten, rollen, voorzieningen en standaarden die van toepassing zijn op toegang. Het beschrijft ook de relatie van de architectuurprincipes met de Architectuur Digitale Overheid en NORA. De architectuur moet vooral worden gezien als een beschrijving van algemene best-practices. Het geeft 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 initiatief 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 breder en verder dan de doelarchitectuur toegang.</p> <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. In het kader programma/stelsel toegang is een doelarchitectuur toegang opgesteld die met name inzicht geeft in de impact van de eerste tranche van de Wet digitale overheid. Er heeft een review plaatsgevonden op deze doelarchitectuur door de architectuurwerkgroep. Deze domeinarchitectuur kijkt met name breder en verder dan de doelarchitectuur toegang. 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. Een punt van aandacht is het feit dat de eerste tranche van de Wdo en daarmee het programma/stelsel toegang gebaseerd is op de eerste eIDAS verordening uit 2014 en het programma EDI-stelsel NL juist in op de in 2024 van kracht geworden eIDAS 2.0. Op een zeker moment zal ook de Wdo op eIDAS 2.0 moeten worden aangepast.</p> "> diff --git a/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-e572700165f84f9783f1b3d0e3162a5c.xml b/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-e572700165f84f9783f1b3d0e3162a5c.xml index ace245cc..afdcc6bb 100644 --- a/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-e572700165f84f9783f1b3d0e3162a5c.xml +++ b/model/business/id-3cd2cc8bd47a4442bb045fa63af162b2/Representation_id-e572700165f84f9783f1b3d0e3162a5c.xml @@ -1,6 +1,6 @@ diff --git a/model/business/id-9cf74dde1b46462398225462cac533db/BusinessFunction_id-c89765631a7f4df58760c8fc9d6acea7.xml b/model/business/id-9cf74dde1b46462398225462cac533db/BusinessFunction_id-c89765631a7f4df58760c8fc9d6acea7.xml index f0be039a..990f1409 100644 --- a/model/business/id-9cf74dde1b46462398225462cac533db/BusinessFunction_id-c89765631a7f4df58760c8fc9d6acea7.xml +++ b/model/business/id-9cf74dde1b46462398225462cac533db/BusinessFunction_id-c89765631a7f4df58760c8fc9d6acea7.xml @@ -1,5 +1,5 @@ + documentation="Het toelaten van een dienstverlener, verklarende partij of gebruikersorganisatie tot de toegangsinfrastructuur en het toetsen of deze kan voldoen aan de bijbehorende afspraken."/> diff --git a/model/business/id-9cf74dde1b46462398225462cac533db/BusinessFunction_id-ed79e8b5aed54001b5024d2c02233232.xml b/model/business/id-9cf74dde1b46462398225462cac533db/BusinessFunction_id-ed79e8b5aed54001b5024d2c02233232.xml deleted file mode 100644 index 0a5d0aee..00000000 --- a/model/business/id-9cf74dde1b46462398225462cac533db/BusinessFunction_id-ed79e8b5aed54001b5024d2c02233232.xml +++ /dev/null @@ -1,5 +0,0 @@ - diff --git a/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-01f6b7a9881e4290a6180343cd8d7e1f.xml b/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-01f6b7a9881e4290a6180343cd8d7e1f.xml index de06b21a..6f2a4c75 100644 --- a/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-01f6b7a9881e4290a6180343cd8d7e1f.xml +++ b/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-01f6b7a9881e4290a6180343cd8d7e1f.xml @@ -29,7 +29,7 @@ + + + + + + + diff --git a/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-08c765dc4dea4790a2a37c17bfbe69aa.xml b/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-08c765dc4dea4790a2a37c17bfbe69aa.xml index 117e09f2..367d2f26 100644 --- a/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-08c765dc4dea4790a2a37c17bfbe69aa.xml +++ b/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-08c765dc4dea4790a2a37c17bfbe69aa.xml @@ -1063,15 +1063,6 @@ xsi:type="archimate:CompositionRelationship" href="CompositionRelationship_id-12111efbd22a4c5f9127143f7b74bb9e.xml#id-12111efbd22a4c5f9127143f7b74bb9e"/> - - - - - - - - diff --git a/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-28e4eab18ef74a56baae2e328f6b5734.xml b/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-28e4eab18ef74a56baae2e328f6b5734.xml index 249cbb1a..15b41e49 100644 --- a/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-28e4eab18ef74a56baae2e328f6b5734.xml +++ b/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-28e4eab18ef74a56baae2e328f6b5734.xml @@ -1117,15 +1117,6 @@ xsi:type="archimate:CompositionRelationship" href="CompositionRelationship_id-12111efbd22a4c5f9127143f7b74bb9e.xml#id-12111efbd22a4c5f9127143f7b74bb9e"/> - - - - - - - - diff --git a/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-7158d8c170f34df984206df5a91c3916.xml b/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-7158d8c170f34df984206df5a91c3916.xml index a1c0a7bc..025ecd33 100644 --- a/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-7158d8c170f34df984206df5a91c3916.xml +++ b/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-7158d8c170f34df984206df5a91c3916.xml @@ -14,7 +14,7 @@ x="408" y="22" width="241" - height="291"/> + height="351"/> + height="351"/> @@ -136,7 +136,7 @@ value="2"/> + height="351"/> + height="351"/> + + + + + @@ -375,7 +392,7 @@ x="36" y="180" width="109" - height="133"/> + height="193"/> diff --git a/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-87cdcc2afbb3401e82d091e571f05fd3.xml b/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-87cdcc2afbb3401e82d091e571f05fd3.xml index 6bd42b4d..9cffecd2 100644 --- a/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-87cdcc2afbb3401e82d091e571f05fd3.xml +++ b/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-87cdcc2afbb3401e82d091e571f05fd3.xml @@ -124,7 +124,7 @@ + href="Principle_id-b304c80b029c48498a32d80d14337ea3.xml#id-b304c80b029c48498a32d80d14337ea3"/> diff --git a/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-c0c8bbad71bf41afa2492c477d80c6fa.xml b/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-c0c8bbad71bf41afa2492c477d80c6fa.xml index 76c63607..83c54b83 100644 --- a/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-c0c8bbad71bf41afa2492c477d80c6fa.xml +++ b/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-c0c8bbad71bf41afa2492c477d80c6fa.xml @@ -13,7 +13,7 @@ x="348" y="22" width="181" - height="339"/> + height="411"/> + height="411"/> @@ -107,7 +107,7 @@ value="2"/> + height="411"/> + height="411"/> + + + + + @@ -289,7 +306,7 @@ x="36" y="204" width="109" - height="157"/> + height="229"/> diff --git a/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-c535327b8e144674afbd41117a90a47e.xml b/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-c535327b8e144674afbd41117a90a47e.xml index 72673cd4..25a4a2b6 100644 --- a/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-c535327b8e144674afbd41117a90a47e.xml +++ b/model/diagrams/id-3043fb9e60f34504bda3f28a53243393/ArchimateDiagramModel_id-c535327b8e144674afbd41117a90a47e.xml @@ -113,6 +113,15 @@ xsi:type="archimate:InfluenceRelationship" href="InfluenceRelationship_id-d9fce38ba2ab479b9596a8a76d380efb.xml#id-d9fce38ba2ab479b9596a8a76d380efb"/> + + + + id="id-fa49ee9ce72c4e39acbfcc4a8f3db676" + targetConnections="id-f76ed2b6e3e942af8c4f9a9ee7bca022" + textPosition="1"> + + + + + + + + + + + + + + + + + + + diff --git a/model/diagrams/id-b5963dab370f41879dc444ad90d62798/ArchimateDiagramModel_id-95ac19da61da4880ae11cd3bd2a82ff2.xml b/model/diagrams/id-b5963dab370f41879dc444ad90d62798/ArchimateDiagramModel_id-95ac19da61da4880ae11cd3bd2a82ff2.xml index fdd5842d..fdcc901f 100644 --- a/model/diagrams/id-b5963dab370f41879dc444ad90d62798/ArchimateDiagramModel_id-95ac19da61da4880ae11cd3bd2a82ff2.xml +++ b/model/diagrams/id-b5963dab370f41879dc444ad90d62798/ArchimateDiagramModel_id-95ac19da61da4880ae11cd3bd2a82ff2.xml @@ -1040,15 +1040,6 @@ - - - - - - - - - - - - - - - - + + + + + diff --git a/model/diagrams/id-bc9d41d41e384d6286e4f732a80047dd/ArchimateDiagramModel_id-d87b04d2bc5640e99880cbefb656ffde.xml b/model/diagrams/id-bc9d41d41e384d6286e4f732a80047dd/ArchimateDiagramModel_id-d87b04d2bc5640e99880cbefb656ffde.xml index 422eb3c6..42418c12 100644 --- a/model/diagrams/id-bc9d41d41e384d6286e4f732a80047dd/ArchimateDiagramModel_id-d87b04d2bc5640e99880cbefb656ffde.xml +++ b/model/diagrams/id-bc9d41d41e384d6286e4f732a80047dd/ArchimateDiagramModel_id-d87b04d2bc5640e99880cbefb656ffde.xml @@ -1062,15 +1062,6 @@ xsi:type="archimate:CompositionRelationship" href="CompositionRelationship_id-12111efbd22a4c5f9127143f7b74bb9e.xml#id-12111efbd22a4c5f9127143f7b74bb9e"/> - - - + + + - - - - - + + + + + @@ -2570,7 +2570,7 @@ id="id-4a5b80a1f1f34d8b8871f97c4ac6a61d" lineColor="#808080" source="id-5038b7828bbd4b698e4bac1b7e1683b6" - target="id-04960e79e462462ab4eb36512125dda1"> + target="id-110251fac2744e3dbe3b3c185f65d9dc"> diff --git a/model/implementation_migration/id-7f88a37d7f6d448eb35e03e10aa0e64d/WorkPackage_id-4751ff0f92c04cec9018b13305d1f476.xml b/model/implementation_migration/id-7f88a37d7f6d448eb35e03e10aa0e64d/WorkPackage_id-4751ff0f92c04cec9018b13305d1f476.xml new file mode 100644 index 00000000..281d1d9e --- /dev/null +++ b/model/implementation_migration/id-7f88a37d7f6d448eb35e03e10aa0e64d/WorkPackage_id-4751ff0f92c04cec9018b13305d1f476.xml @@ -0,0 +1,5 @@ + diff --git a/model/implementation_migration/id-7f88a37d7f6d448eb35e03e10aa0e64d/WorkPackage_id-d9b8e51c53c74a589f8dadf156c1786c.xml b/model/implementation_migration/id-7f88a37d7f6d448eb35e03e10aa0e64d/WorkPackage_id-d9b8e51c53c74a589f8dadf156c1786c.xml index 28d370f8..7e57ea37 100644 --- a/model/implementation_migration/id-7f88a37d7f6d448eb35e03e10aa0e64d/WorkPackage_id-d9b8e51c53c74a589f8dadf156c1786c.xml +++ b/model/implementation_migration/id-7f88a37d7f6d448eb35e03e10aa0e64d/WorkPackage_id-d9b8e51c53c74a589f8dadf156c1786c.xml @@ -1,5 +1,5 @@ + documentation="Bewindvoerders, curatoren, mentoren en mensen die ouderlijk gezag hebben zouden als vertegenwoordiger moeten kunnen optreden. De gezaghebbende bron voor beschermingsbewind is het WvR register van de Raad voor de Rechtspraak. Een aansluiting op dit register reeds gerealiseerd, maar deze moet nog wel door de toegangsinfrastructuur breed toegankelijk worden gemaakt."/> diff --git a/model/implementation_migration/id-7f88a37d7f6d448eb35e03e10aa0e64d/WorkPackage_id-dd07b5c0a2b74ce78e00c000687f637e.xml b/model/implementation_migration/id-7f88a37d7f6d448eb35e03e10aa0e64d/WorkPackage_id-dd07b5c0a2b74ce78e00c000687f637e.xml index 4541ec10..10868db8 100644 --- a/model/implementation_migration/id-7f88a37d7f6d448eb35e03e10aa0e64d/WorkPackage_id-dd07b5c0a2b74ce78e00c000687f637e.xml +++ b/model/implementation_migration/id-7f88a37d7f6d448eb35e03e10aa0e64d/WorkPackage_id-dd07b5c0a2b74ce78e00c000687f637e.xml @@ -1,5 +1,5 @@ + documentation="Er bestaan mogelijkheden om gebruiksvoorwaarden om te zetten in autorisatieregels die geautomatiseerd gecontroleerd kunnen worden. Hiermee is verdergaande automatisering van uitwisseling tussen aanbieders en afnemers mogelijk. Er is onderzoek nodig om te bepalen in hoeverre dit een bredere behoefte is bij overheidsorganisaties, hoe ver dit soort controles zouden moeten gaan en hoe dit technisch kan worden ingericht. Zo is het bijvoorbeeld mogelijk om ook aan de kant van de afnemer en gebruiker dergelijke controles uit te voeren. Verder zijn er verschillende standaarden die kunnen worden gebruikt zoals de XACML standaard, de ODRL standaard, de Rego taal van de Open Policy Agent (OPA), MYDATA of de Usage Contract Language van de International Data Spaces Association."/> diff --git a/model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-26a67ab67a2345c59d5176c597443a38.xml b/model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-26a67ab67a2345c59d5176c597443a38.xml index 15b36131..51d84940 100644 --- a/model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-26a67ab67a2345c59d5176c597443a38.xml +++ b/model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-26a67ab67a2345c59d5176c597443a38.xml @@ -2,4 +2,4 @@ xmlns:archimate="http://www.archimatetool.com/archimate" name="Vertegenwoordigen werkt nog niet voor iedereen" id="id-26a67ab67a2345c59d5176c597443a38" - documentation="Professionele vertegenwoordigers van nabestaanden kunnen niet digitaal gemachtigd worden. Professionele dienstverleners zoals bewindvoerders kunnen ook nog niet overal digitaal als vertegenwoordiger optreden. Dat geldt ook voor ouders van minderjarige kinderen, curatoren, bewindvoerders en mentoren van volwassenen. "/> + documentation="Professionele vertegenwoordigers van nabestaanden kunnen niet digitaal gemachtigd worden. Professionele dienstverleners zoals bewindvoerders kunnen ook nog niet overal digitaal als vertegenwoordiger optreden. Dat geldt ook voor ouders van minderjarige kinderen, curatoren, bewindvoerders, mentoren van volwassenen en mensen die ouderlijk gezag hebben. "/> diff --git a/model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-3a7e254272734fc3a2fccc69a94232cc.xml b/model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-3a7e254272734fc3a2fccc69a94232cc.xml new file mode 100644 index 00000000..f36465bd --- /dev/null +++ b/model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-3a7e254272734fc3a2fccc69a94232cc.xml @@ -0,0 +1,5 @@ + diff --git a/model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-516315a21d3943c48d3859fd7c28308e.xml b/model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-516315a21d3943c48d3859fd7c28308e.xml new file mode 100644 index 00000000..44cfd9db --- /dev/null +++ b/model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-516315a21d3943c48d3859fd7c28308e.xml @@ -0,0 +1,5 @@ + diff --git a/model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-9e52332306d7404a9bc5432da3040f4b.xml b/model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-9e52332306d7404a9bc5432da3040f4b.xml new file mode 100644 index 00000000..d326e17d --- /dev/null +++ b/model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-9e52332306d7404a9bc5432da3040f4b.xml @@ -0,0 +1,5 @@ + diff --git a/model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-dcdf473919e14835becc91f9cd0ea123.xml b/model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-dcdf473919e14835becc91f9cd0ea123.xml index 2201b487..b67fb850 100644 --- a/model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-dcdf473919e14835becc91f9cd0ea123.xml +++ b/model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-dcdf473919e14835becc91f9cd0ea123.xml @@ -2,4 +2,4 @@ xmlns:archimate="http://www.archimatetool.com/archimate" name="Buitenlandse certificaten niet bruikbaar als identificatiemiddel" id="id-dcdf473919e14835becc91f9cd0ea123" - documentation="Buitenlandse PKI certificaten kunnen in Nederland niet als identificatiemiddel gebruikt worden omdat er geen OIN in staat."/> + documentation="Buitenlandse PKI certificaten kunnen in Nederland niet als identificatiemiddel gebruikt worden omdat er geen OIN in staat. Een OIN wordt vooralsnog alleen aan Nederlandse rechtspersonen toegekend. Daarmee sluiten deze voorzieningen het gebruik van bijvoorbeeld EU gekwalificeerde certificaten uit en ook het gebruik van goedkope standaard PKI-certificaten."/> diff --git a/model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-dcf64f87176748e19a4fbbcc16dd4f08.xml b/model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-dcf64f87176748e19a4fbbcc16dd4f08.xml index b5595ebd..1a27a23a 100644 --- a/model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-dcf64f87176748e19a4fbbcc16dd4f08.xml +++ b/model/motivation/id-4be76917b811420f9e35998fb301a3fd/Assessment_id-dcf64f87176748e19a4fbbcc16dd4f08.xml @@ -2,4 +2,4 @@ xmlns:archimate="http://www.archimatetool.com/archimate" name="Machtigingen verspreid over meerdere systemen" id="id-dcf64f87176748e19a4fbbcc16dd4f08" - documentation="Er is op dit moment sprake van een groot aantal plaatsen waar vrijwillige machtigingen verstrekt kunnen worden. Naast DigiD machtigen en de machtigingsvoorzieningen van eHerkenning zijn er ook in allerlei andere systemen functionaliteiten voor machtigingen gerealiseerd zoals bijvoorbeeld in Digipoort. Dit komt deels doordat er beperkte machtigingsfunctionaliteit aanwezig is in DigiD machtigen en eHerkenning (keten)machtigen. Zo is het bijvoorbeeld niet mogelijk om te machtigen voor zaken. Daarnaast is het betrouwbaarheidsniveau waarmee de machtigingen zijn geregistreerd niet vastgelegd bij de machtiging. Hierdoor moeten overheidsorganisaties op meerdere machtigingsregisters aansluiten en gebruikers op allerlei plaatsen machtigingen verstrekken of ontvangen, waardoor ze het overzicht verliezen. De machtigingsfunctionaliteit in Digipoort was bedoeld als tijdelijk en is niet goed geïmplementeerd, zeker niet voor inkomende berichten."/> + documentation="Er is op dit moment sprake van een groot aantal plaatsen waar vrijwillige machtigingen verstrekt kunnen worden. Naast DigiD machtigen en de machtigingsvoorzieningen van eHerkenning zijn er ook in allerlei andere systemen functionaliteiten voor machtigingen gerealiseerd zoals bijvoorbeeld in Digipoort. Dit komt deels doordat er beperkte machtigingsfunctionaliteit aanwezig is in DigiD machtigen en eHerkenning (keten)machtigen. Zo is het bijvoorbeeld niet mogelijk om te machtigen voor zaken. Hierdoor moeten overheidsorganisaties op meerdere machtigingsregisters aansluiten en gebruikers op allerlei plaatsen machtigingen verstrekken of ontvangen, waardoor ze het overzicht verliezen. De machtigingsfunctionaliteit in Digipoort was bedoeld als tijdelijk en is niet goed geïmplementeerd, zeker niet voor inkomende berichten."/> diff --git a/model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-77965a4ab86c43fb809656f759830dc1.xml b/model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-77965a4ab86c43fb809656f759830dc1.xml index 41282f20..247116ec 100644 --- a/model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-77965a4ab86c43fb809656f759830dc1.xml +++ b/model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-77965a4ab86c43fb809656f759830dc1.xml @@ -11,13 +11,13 @@ value="2. Dienstverleners registreren in de toegangsinfrastructuur welke attributen van entiteiten noodzakelijk zijn om de dienst uit te kunnen voeren."/> + value="3. De attributen die dienstverleners vragen zijn strikt noodzakelijk voor de doelbinding."/> + value="4. Gebruikers hebben voorafgaand aan hun handelen inzicht in de dienst gevraagde attributen (persoonsgegevens), die zijn gebaseerd op de wettelijke grondslag en doelbinding."/> + value="5. De toegangsinfrastructuur borgt dat alleen attributen worden verstrekt die eerder zijn geregistreerd door dienstverleners en waar gebruikers voorafgaand aan hun handelen inzicht in hebben kunnen krijgen."/> diff --git a/model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-b304c80b029c48498a32d80d14337ea3.xml b/model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-b304c80b029c48498a32d80d14337ea3.xml new file mode 100644 index 00000000..7ef43cea --- /dev/null +++ b/model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-b304c80b029c48498a32d80d14337ea3.xml @@ -0,0 +1,21 @@ + + + + + + + diff --git a/model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-b4dce57205fe4d48b888481350c6fae1.xml b/model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-b4dce57205fe4d48b888481350c6fae1.xml index 4f4f882f..a321c0d8 100644 --- a/model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-b4dce57205fe4d48b888481350c6fae1.xml +++ b/model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-b4dce57205fe4d48b888481350c6fae1.xml @@ -8,19 +8,19 @@ value="1. Vertrouwende partijen gebruiken verifieerbare verklaringen voor het verlenen van toegang."/> + value="2. Er is bewijs dat een verifieerbare verklaring hoort bij de gebruiker (of vertegenwoordigde)."/> + value="3. Een verklaring wordt alleen vertrouwd als deze valide, integer, authentiek en geldig is. "/> + value="4. De mate van vertrouwen in een verklaring is gebaseerd op onder meer het betrouwbaarheidsniveau, de geldigheid, de verstrekker, de actualiteit en of deze gekwalificeerd is."/> + value="5. Er kunnen verklaringen bij verschillende verklarende partijen worden opgehaald om voldoende vertrouwen te krijgen."/> + value="6. Gebruikers kunnen ook dingen over zichzelf verklaren en deze beschikbaar stellen als verifieerbare verklaring."/> diff --git a/model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-d1b6dbdd642f48b0b7c831258051bbc7.xml b/model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-d1b6dbdd642f48b0b7c831258051bbc7.xml index 82f6a60d..39b597f7 100644 --- a/model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-d1b6dbdd642f48b0b7c831258051bbc7.xml +++ b/model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-d1b6dbdd642f48b0b7c831258051bbc7.xml @@ -8,7 +8,7 @@ value="1. Het optimaliseren van de interne organisatie van toegangsprocessen bij overheidsorganisaties is minder belangrijk dan het bieden van een optimale klantreis."/> + value="2. Gebruikers hoeven maar één keer in te loggen (mogelijk wel met herbevestiging) voor een bepaald betrouwbaarheidsniveau om gebruik te maken van verschillende diensten die voldoende hebben aan dit niveau."/> diff --git a/model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-eaf013562885445e9b0263d9289a8800.xml b/model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-eaf013562885445e9b0263d9289a8800.xml deleted file mode 100644 index ce07d152..00000000 --- a/model/motivation/id-847f943839134845944b9e9eb7cb4c16/Principle_id-eaf013562885445e9b0263d9289a8800.xml +++ /dev/null @@ -1,30 +0,0 @@ - - - - - - - - - - diff --git a/model/relations/CompositionRelationship_id-52ba6cebed32469b91fc99ee8046c05a.xml b/model/relations/CompositionRelationship_id-a2e50ce89a764bdd9694cecb48431157.xml similarity index 72% rename from model/relations/CompositionRelationship_id-52ba6cebed32469b91fc99ee8046c05a.xml rename to model/relations/CompositionRelationship_id-a2e50ce89a764bdd9694cecb48431157.xml index 2b6d50b4..19345099 100644 --- a/model/relations/CompositionRelationship_id-52ba6cebed32469b91fc99ee8046c05a.xml +++ b/model/relations/CompositionRelationship_id-a2e50ce89a764bdd9694cecb48431157.xml @@ -1,11 +1,11 @@ + id="id-a2e50ce89a764bdd9694cecb48431157"> + href="BusinessFunction_id-96ff8c5d886f4013b003c77ee8907044.xml#id-96ff8c5d886f4013b003c77ee8907044"/> diff --git a/model/relations/InfluenceRelationship_id-422f62cd38e8492fa95bf2d57e82bd30.xml b/model/relations/InfluenceRelationship_id-422f62cd38e8492fa95bf2d57e82bd30.xml new file mode 100644 index 00000000..5e89afe8 --- /dev/null +++ b/model/relations/InfluenceRelationship_id-422f62cd38e8492fa95bf2d57e82bd30.xml @@ -0,0 +1,11 @@ + + + + diff --git a/model/relations/InfluenceRelationship_id-63c1a979dc9e41628bb9d3f57708ba30.xml b/model/relations/InfluenceRelationship_id-63c1a979dc9e41628bb9d3f57708ba30.xml new file mode 100644 index 00000000..6a4e8651 --- /dev/null +++ b/model/relations/InfluenceRelationship_id-63c1a979dc9e41628bb9d3f57708ba30.xml @@ -0,0 +1,11 @@ + + + + diff --git a/model/relations/InfluenceRelationship_id-f128220572384499aaecae01e1881fd8.xml b/model/relations/InfluenceRelationship_id-f128220572384499aaecae01e1881fd8.xml new file mode 100644 index 00000000..ae2abdac --- /dev/null +++ b/model/relations/InfluenceRelationship_id-f128220572384499aaecae01e1881fd8.xml @@ -0,0 +1,11 @@ + + + + diff --git a/model/relations/ServingRelationship_id-d5686691ddb64aa1916d220edf4d6009.xml b/model/relations/ServingRelationship_id-d5686691ddb64aa1916d220edf4d6009.xml index e2c9ca16..d0740681 100644 --- a/model/relations/ServingRelationship_id-d5686691ddb64aa1916d220edf4d6009.xml +++ b/model/relations/ServingRelationship_id-d5686691ddb64aa1916d220edf4d6009.xml @@ -7,5 +7,5 @@ href="ApplicationComponent_id-a59ea169cbdf49d8bcc1cf14a6eee959.xml#id-a59ea169cbdf49d8bcc1cf14a6eee959"/> + href="BusinessFunction_id-c89765631a7f4df58760c8fc9d6acea7.xml#id-c89765631a7f4df58760c8fc9d6acea7"/>