-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathtoegang.archimate
5721 lines (5721 loc) · 725 KB
/
toegang.archimate
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="UTF-8"?>
<archimate:model xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:archimate="http://www.archimatetool.com/archimate" name="Toegang" id="id-3b66eec68cbc4ed8a552deca4e788391" version="5.0.0">
<folder name="Strategy" id="id-475adfc1ef674f5d9b13aa132b7e56e4" type="strategy">
<folder name="Capability's" id="id-221d6a0855da4133b962005cdf889b37">
<element xsi:type="archimate:Capability" name="Toegang verlenen" id="id-062e48b86e134f92ada7536886294d4b">
<documentation>Het controleren van de authenticiteit en bevoegdheden van identiteiten om toegang te kunnen geven tot diensten.
</documentation>
</element>
<element xsi:type="archimate:Capability" name="Identiteitsfraude bestrijden" id="id-22edde5e860846c9aa8a3a95e6a11200">
<documentation>Het voorkomen, detecteren, opvolgen en herstellen van fraude met identificatiemiddelen.</documentation>
</element>
<element xsi:type="archimate:Capability" name="Identificatiemiddelen bieden" id="id-2df7f9f8018a4f68bd26df33d6116964">
<documentation>Partijen laten beschikken over betrouwbare identificatiemiddelen waarmee ze hun identiteit kunnen aantonen.</documentation>
</element>
<element xsi:type="archimate:Capability" name="Vertegenwoordigingsbevoegdheden beheren" id="id-5eeb988b69a24628b5ff0a6d03a24be3">
<documentation>Het definiëren en toekennen van bevoegdheden waarmee partijen namens anderen gebruik kunnen maken van diensten.
</documentation>
</element>
<element xsi:type="archimate:Capability" name="Vertrouwen borgen" id="id-eddd27a419c54f9689d991991d8788c6">
<documentation>Het waarborgen van de veiligheid, betrouwbaarheid en juridische erkenning van digitale transacties.</documentation>
</element>
</folder>
</folder>
<folder name="Business" id="id-18d3d3102a5d46808f48412c7c38fcc7" type="business">
<folder name="Bedrijfsobjecten" id="id-1ca7f5222bf94a9ba45bfebd9ff8d6e4">
<element xsi:type="archimate:BusinessObject" name="Autorisatiebeslissing" id="id-0e6a68545b2d470d841b82aa5e05d4a5">
<documentation>Het resultaat van het evalueren van autorisatieregels.</documentation>
</element>
<element xsi:type="archimate:BusinessObject" name="Vertegenwoordigingsbevoegdheid" id="id-19881848ccce47c9974cf7bc005393e8">
<documentation>Een machtiging of wettelijke vertegenwoordiging.</documentation>
</element>
<element xsi:type="archimate:BusinessObject" name="Bevoegdheidsverklaring" id="id-1cb3ac18cb83432ebe33dacfbd3d2832">
<documentation>Een verifieerbare verklaring over dat een identiteit een bepaalde bevoegdheid heeft.</documentation>
</element>
<element xsi:type="archimate:BusinessObject" name="Wettelijke vertegenwoordiging" id="id-1e41484c18bb4fdba146f33bee3f1979">
<documentation>De bevoegdheid van een natuurlijk persoon of organisatie op grond van de wet of een rechtelijke uitspraak om te handelen namens een andere natuurlijke persoon.</documentation>
</element>
<element xsi:type="archimate:BusinessObject" name="Resource" id="id-276320a6bad14e10a39ac2bcfcd13178">
<documentation>Een dienst, gegevens of functionaliteit waartoe een entiteit met een bepaalde identiteit toegang zou kunnen krijgen.</documentation>
</element>
<element xsi:type="archimate:BusinessObject" name="Identificatiemiddel" id="id-4145089decc343f1b8a35540703eb738">
<documentation>Een middel dat verifieerbare verklaringen over identiteitsgegevens kan verstrekken.</documentation>
</element>
<element xsi:type="archimate:BusinessObject" name="Rol" id="id-4d32e4b7ef9c4a85acfa2c562ad218d2">
<documentation>Een set van taken, bevoegdheden en verantwoordelijkheden die door een identiteit ingevuld kan worden.</documentation>
</element>
<element xsi:type="archimate:BusinessObject" name="Entiteit" id="id-532a8fb36d024c0da03b4890db4de4d8">
<documentation>Een object dat gedrag kan vertonen.</documentation>
</element>
<element xsi:type="archimate:BusinessObject" name="Bevoegdheid" id="id-6ed7f3d944764c60a45fe6780a041a42">
<documentation>Het bezitten van toestemming om gebruik te maken van een resource.</documentation>
</element>
<element xsi:type="archimate:BusinessObject" name="Attribuutsoort" id="id-7417b19f5c21447d8bf281baf4315b20">
<documentation>De definitie van een categorie van attributen.</documentation>
</element>
<element xsi:type="archimate:BusinessObject" name="Autorisatieregel" id="id-7a15da44f51b45d0b7b2d1449ea8def3">
<documentation>Een regel die is gesteld voor toegang tot een resource en waaraan moet worden voldaan voordat een entiteit met een bepaalde identiteit toegang krijgt tot die resource.</documentation>
</element>
<element xsi:type="archimate:BusinessObject" name="Machtiging" id="id-906f182647604ffc90107fdb1c8d46de">
<documentation>De uitdrukking van de verlening van een bevoegdheid aan een natuurlijk persoon om namens een andere natuurlijk persoon of namens een organisatie handelingen te verrichten.</documentation>
<property key="Alternatieve term" value="Vrijwillige machtiging"/>
</element>
<element xsi:type="archimate:BusinessObject" name="Identiteit" id="id-9e14841bf7a34845a4465fb9aa96cc53">
<documentation>Een verzameling van kenmerkende eigenschappen van een object.</documentation>
</element>
<element xsi:type="archimate:BusinessObject" name="Verklarende partij" id="id-9f8c3a76be074fb791acb27cd1335fbb">
<documentation>Een organisatie die verifieerbare verklaringen uitgeeft.</documentation>
</element>
<element xsi:type="archimate:BusinessObject" name="Verifieerbare verklaring" id="id-a6805c3d0daa4690a04d2f2251c65cc0">
<documentation>Een verzameling van identiteitsgegevens, vergezeld van een bewijs dat deze afkomstig zijn van een specifieke verklarende partij.</documentation>
</element>
<element xsi:type="archimate:BusinessObject" name="Dienstverlener" id="id-c266e0540ad64714932a780fe9e74037">
<documentation>Een entiteit die een dienst levert.</documentation>
</element>
<element xsi:type="archimate:BusinessObject" name="Dienst" id="id-d128055e2a98447ea02185273849dac9">
<documentation>Een geheel van handelingen die een dienstverlener beschikbaar stelt.</documentation>
</element>
<element xsi:type="archimate:BusinessObject" name="Identiteitsgegeven" id="id-d766d65c0ea14ecc9e01f99938d0b61b">
<documentation>Een gegeven dat een kenmerk van een identiteit representeert.</documentation>
</element>
<element xsi:type="archimate:BusinessObject" name="Authenticatieverklaring" id="id-f51d4497b87b4751842effe518b903d5">
<documentation>Een verifeerbare verklaring over de uitkomst van een authenticatie.</documentation>
</element>
</folder>
<folder name="Teksten" id="id-3cd2cc8bd47a4442bb045fa63af162b2">
<element xsi:type="archimate:Representation" name="Architectuurprincipes" id="id-1064b8991eb64f4e8adc8f35fc1396ea" profiles="id-b5e689fa75694829b24cf22fd76eacee">
<documentation><p>Architectuurprincipes zijn richtinggevende uitspraken die vooral uiting geven aan een streven. Ze bestaan uit een stelling die uiting geeft aan de overtuiging die eraan ten grondslag ligt, een rationale die meer informatie geeft over de drijfveren en implicaties die de consequenties beschrijven. Architectuurprincipes moeten als argument worden meegenomen in het maken van keuzes. De architectuurprincipes zijn in de domeinarchitectuur gekoppeld aan de relevante wet- en regelgeving waar ze invulling aan geven en aan de bedrijfsfuncties die ingericht moeten zijn om ze te implementeren. Er is ook een <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-2ce199487e094f099863995e07a7e605.html">mapping van deze architectuurprincipes</a> op de uitgangspunten in de Architectuur Digitale Overheid 2030 en de principes en implicaties in NORA. Deze geeft een verdere onderbouwing en verdieping van de architectuurprincipes.</p></documentation>
<property key="elementType" value="principle"/>
</element>
<element xsi:type="archimate:Representation" name="Inhoudsopgave" id="id-2a183383b93c4065a1366d3266b50780" profiles="id-b5e689fa75694829b24cf22fd76eacee">
<documentation><p>
<table class="table">
<tr><td width =40>1</td><td><b>Inleiding</b></td></tr>
<tr><td>1.1</td><td>Aanleiding</td></tr>
<tr><td>1.2</td><td>Dit document</td></tr>
<tr><td>1.3</td><td>Documentstructuur</td></tr>
<tr><td>1.4</td><td>Relatie met andere architecturen</td></tr>
<tr><td>1.5</td><td>Relatie met andere initiatieven</td></tr>
<tr><td>2</td><td><b>Kernbegrippen</b></td></tr>
<tr><td>2.1</td><td>Algemeen</td></tr>
<tr><td>2.2</td><td>Rollen</td></tr>
<tr><td>2.3</td><td>Functies</td></tr>
<tr><td>3</td><td><b>Veranderfactoren</b></td></tr>
<tr><td>3.1</td><td>Beleid</td></tr>
<tr><td>3.2</td><td>Wet- en regelgeving</td></tr>
<tr><td>4.3</td><td>Ontwikkelingen</td></tr>
<tr><td>4.4</td><td>Knelpunten</td></tr>
<tr><td>4</td><td><b>Doelarchitectuur</b></td></tr>
<tr><td>4.1</td><td>Architectuurvisie</td></tr>
<tr><td>4.2</td><td>Architectuurprincipes</td></tr>
<tr><td>4.3</td><td>Verdieping thema rolverdeling</td></tr>
<tr><td>4.4</td><td>Verdieping thema systeem naar systeem toegang<br>
<tr><td>4.5</td><td>Veranderinitiatieven<br>
<tr><td>5</td><td><b>Doelarchitectuur</b></td></tr>
<tr><td>5.1</td><td>Functies</td></tr>
<tr><td>5.2</td><td>Bedrijfsobjecten en begrippen</td></tr>
<tr><td>5.3</td><td>Rollen<br>
<tr><td>5.4</td><td>Huidige voorzieningen<br>
<tr><td>5.5</td><td>Standaarden<br>
<tr><td>5.6</td><td>Relatie van architectuurprincipes met ADO en NORA<br>
<tr><td>5.7</td><td>Betrokkenen<br>
</table>
</p>
</documentation>
</element>
<element xsi:type="archimate:Representation" name="Relatie van architectuurprincipes met ADO en NORA" id="id-2ce199487e094f099863995e07a7e605" profiles="id-b5e689fa75694829b24cf22fd76eacee">
<documentation><p>Deze bijlage relateert de architectuurprincipes zoals beschreven in deze domeinarchitectuur aan de uitgangspunten in de Architectuur Digitale Overheid 2030 en de principes en implicaties in NORA. Het levert daarmee een verdere onderbouwing en verdieping van de architectuurprincipes.</p>
<table class="table table-striped"><tbody>
<tr><td><b>Architectuurprincipe</b></td><td><b>Uitgangspunt in Architectuur Digitale Overheid 2030</b></td><td><b>Principe of implicatie in NORA</b></td></tr>
<tr><td><a href="..\elements\id-8149432665a347bba7f3d97a5f506193.html">1. Iedereen kan toegang krijgen tot diensten</a></td><td><ul><li>Gebruikersvriendelijk, begrijpelijk, transparant en toegankelijk voor iedereen</li></ul></td><td><ul><li>Verplaats je in de gebruiker</li><li>Maak de dienst toegankelijk voor alle gebruikers</li><li>Maak de dienst toegankelijk voor anderstaligen</li></ul></td></tr>
<tr><td><a href="..\elements\id-b4dce57205fe4d48b888481350c6fae1.html">2. Toegang is gebaseerd op verifieerbare verklaringen</a></td><td></td><td><ul><li>Maak stelselafspraken over identificatie en authenticatie</li></ul></td></tr>
<tr><td><a href="..\elements\id-77965a4ab86c43fb809656f759830dc1.html">3. Organisaties wisselen alleen strikt noodzakelijke gegevens uit</a></td><td><ul><li>Overheden mogen alleen persoonsgegevens verwerken als het niet anders kan. Dus: als zij zonder deze gegevens hun doel niet kunt bereiken.</li></ul></td><td><ul><li>Pas doelbinding toe</li></ul></td></tr>
<tr><td><a href="..\elements\id-05cd71c3758c4182878ba143b870582f.html">4. De Nederlandse toegangsinfrastructuur ontzorgt dienstverleners</a></td><td></td><td><ul><li>Bied één contactpunt (Single point of contact)</li></ul></td></tr>
<tr><td><a href="..\elements\id-d1b6dbdd642f48b0b7c831258051bbc7.html">5. Toegang tot diensten en gegevens is zo laagdrempelig als mogelijk voor het gevraagde betrouwbaarheidsniveau</a></td><td><ul><li>Kanalen dienen – waar nodig – ook via machtigen en vertegenwoordigen toegankelijk te zijn.</li></ul></td><td><ul><li>Verplaats je in de gebruiker</li><li>Maak beveiligingsmaatregelen zo gebruiksvriendelijk mogelijk</li><li>Maak toegang tot applicaties en gegevens afhankelijk van authenticatieniveau</li></ul></td></tr>
<tr><td><a href="..\elements\id-b304c80b029c48498a32d80d14337ea3.html">6. Toegang is beperkt tot wat noodzakelijk is</a></td><td></td><td><ul><li>Verleen alleen strikt noodzakelijke toegangsrechten</li></ul></td></tr><tr><td><a href="..\elements\id-4532a251a8ba490298dc08824ef4799a.html">7. Er zijn extra waarborgen bij overheidsorganisaties voor risico's rondom privacy en informatiebeveiliging</a></td><td></td><td><ul><li>Beheers risico's voortdurend</li><li>Borg de vertrouwelijkheid van gegevens in maatregelen</li></ul></td></tr>
<tr><td><a href="..\elements\id-b4d6dca9b88d4f5da8a409f492280af1.html">8. Systemen in de keten autoriseren op basis van de digitale identiteit en de bevoegdheden van de gebruiker die de interactie start</a></td><td></td><td></td></tr>
</table>
</p>
</documentation>
</element>
<element xsi:type="archimate:Representation" name="Wet- en regelgeving" id="id-3901960cf6bc43669f04f6aa4baaf73e" profiles="id-b5e689fa75694829b24cf22fd76eacee">
<documentation><p>De domeinarchitectuur beschrijft de belangrijkste wet- en regelgeving die van toepassing is op toegang. Dat betreft met name nieuwe wet- en regelgeving vanuit Europa, inclusief de Nederlandse invulling daarvan, gegeven dat dit een belangrijke bron voor verandering is voor toegang. De wet- en regelgeving is in de architectuur gekoppeld aan de architectuurprincipes die een belangrijke bijdrage leveren aan het implementeren van deze wet- en regelgeving. Er heeft nadrukkelijk geen detailanalyse van de wet- en regelgeving plaatsgevonden. Daarmee kan er ook geen garantie worden gegeven dat het volgen van deze architectuur automatisch leidt tot het voldoen aan de wet- en regelgeving.</p></documentation>
<property key="elementType" value="driverWetgeving"/>
</element>
<element xsi:type="archimate:Representation" name="Bijlagen" id="id-4ae1e3c208314746b2825716ed62a606" profiles="id-b5e689fa75694829b24cf22fd76eacee"/>
<element xsi:type="archimate:Representation" name="Ontwikkelingen" id="id-52b5d4fc77444fafaf55f7ea2df98e32" profiles="id-b5e689fa75694829b24cf22fd76eacee">
<documentation><p>In deze architectuur beschrijven we een aantal belangrijke (vooral technische) ontwikkelingen op het gebied van toegang. De impact van deze ontwikkelingen is meegenomen in de beschrijving van de architectuur.</p></documentation>
<property key="elementType" value="driverOntwikkeling"/>
</element>
<element xsi:type="archimate:Representation" name="Architectuurvisie" id="id-57896b8c4e854e7b92ed667986aa09ee" profiles="id-b5e689fa75694829b24cf22fd76eacee">
<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 publieke diensten. Dit vraagt dat de identiteit van een gebruiker wordt vastgesteld en dat zonodig wordt bepaald of deze ook namens iemand anders mag handelen. Voor burgers is hiervoor de landelijke voorziening DigiD beschikbaar en wordt ook machtigen ondersteund. Voor bedrijven en andere organisaties is het eHerkenning (Afsprakenstelsel Elektronische Toegangsdiensten) ingericht, waarbij marktpartijen zich kunnen aanbieden als makelaar, machtigingsregister, authenticatiedienst en/of middelenverstrekker. Het is ook mogelijk om grensoverstijgend toegang te krijgen tot digitale diensten van Europese lidstaten. Wet- en regelgeving is een belangrijke drijfveer voor verandering. Dat gaat met name over de herziene verordening <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-3d6bbaf27b0c44bf84e270f33ac5ed6a.html">"Electronic Identification And Trust Services" (eIDAS)</a>, de <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-face061e1c374e6c8b15e048c9f41d1d.html">Wet digitale overheid (Wdo)</a> en de bijbehorende Regeling Betrouwbaarheidsniveaus.
</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. 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 attributen behorende bij de identiteit valide, integer, authentiek en geldig zijn. Voor het bouwen van vertrouwen kunnen partijen gebruik maken van vertrouwensnetwerken, waarin zij onderling afspraken hebben gemaakt. Het doel van de herziene eIDAS verordening is om EU-breed vertrouwen te creëren en daarmee de condities voor een veilige digitale ruimte, voor zowel burgers als bedrijven. 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. Op basis van het antwoord kan bijvoorbeeld toegang tot een dienst worden geweigerd. Het experiment besluit BRP (2024) sorteert hier op voor door uitwisseling van informatieproducten in plaats van alle (onderliggende) gegevens mogelijk te maken. Voor toegang betekent dit bijvoorbeeld dat <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>. Een andere manier om bij het publiek vertrouwen te creëren in de toegangsinfrastructuur is door van delen ervan de broncode publiek beschikbaar te stellen.
</p>
<p>
Self Sovereign Identity (SSI) is een visie op toegang en gegevensuitwisseling waar inspiratie voor verbetering uit kan worden gehaald Het is specifiek gericht op het beschermen van de privacy van gebruikers en het ondersteunen van autonomie. Het idee is dat gebruikers zelf meer in controle zijn en zelf bepalen wie hun persoonsgegevens mag gebruiken. Het voorkomt ook afhankelijkheid van centrale partijen. Gebruikers creëren zelf een digitale representatie van hun identiteit, verzamelen verklaringen van verklarende partijen en verstrekken ze zelf aan 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 de identiteitsgegevens of een verklaring die een gebruiker verstrekt kloppen en nog geldig is kan gebruik maken van een registratie van verifieerbare gegevens. Deze registratie bevat ook gegevens over de (decentrale) identiteiten die gebruikers zelf hebben aangemaakt. Overigens kan een gebruiker ook besluiten een verklaring niet volledig door te geven aan een dienstverlener, maar alleen een subset of afgeleid gegeven (zoals dat deze ouder dan 18 jaar is). Dit heet ook wel een verifieerbare presentatie. Een gebruiker hoeft ook niet per definitie de eigen identiteit 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 volgende figuur geeft een overzicht van de rollen en gegevensstromen. De scope van SSI is nadrukkelijk breder dan toegang; veel van de verklaringen zullen over gegevens gaan die voor toegang niet relevant zijn. Er zijn al allerlei oplossingen om SSI te ondersteunen, in de vorm van personal data management oplossingen (ook wel: wallets).</p>
<p><center><img src="https://minbzk.github.io/gdi-toegang/images/vc.svg"></center></p>
<p>
De European Digital Identity Wallet zoals voorgesteld in de eIDAS 2.0 verordening biedt een Europees gestandaardiseerde manier om verifieerbare verklaringen uit te wisselen, op basis van specifieke standaarden. De EDI-wallet is bruikbaar als identificatiemiddel (op betrouwbaarheidsniveau hoog), maakt het mogelijk om transacties en documenten te ondertekenen en ondersteunt het delen van gegevens. Gebruikers kunnen zelf verifieerbare verklaringen ophalen en bepalen zelf aan wie ze deze verklaringen verstrekken. Hiermee wordt het voor burgers en organisaties mogelijk om meer zelf in controle te komen van de gegevens die ze delen met dienstverleners. Het sluit daarmee voor een belangrijk deel aan bij de SSI visie. In tegenstelling tot de SSI visie wordt daarbij vooral gebruik gemaakt van door de overheid uitgegeven identiteitsgegevens die ook in andere Europese lidstaten kan worden gebruikt. Het is wel mogelijk om bij het gebruik van de EDI-wallet als identificatiemiddel een pseudoniem te gebruiken. 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 identiteitsgegevens waarmee de persoon zichzelf kan identificeren en toegang kan krijgen tot zowel publieke als private diensten.</p>
<p>
De eIDAS verordening onderkent dat er onderscheid is in gekwalificeerde en niet gekwalificeerde verklaringen. Gekwalificeerde verklaringen voldoen aan extra eisen en zijn uitgegeven door toegelaten vertrouwensdienstverleners die aan gestelde eisen voldoen, waardoor ze extra zekerheden bieden. Om vertrouwen te creëren tussen partijen zijn er vertrouwensdiensten nodig die hierin kunnen ondersteunen. De eIDAS verordening beschrijft deze vertrouwensdiensten. Het gaat onder meer om diensten voor het zetten van elektronische handtekeningen (door mensen), het elektronisch verzegelen van gegevens (door een organisatie), het creëren van elektronische verifieerbare verklaringen, het creëren van elektronische tijdstempels en het beschermen en bewijzen van elektronische uitwisseling van gegevens. Deze diensten worden aangeboden of ondersteund door leveranciers in de markt en zijn voor organisaties inzetbaar voor het ondersteunen van het verstrekken van toegang en het uitwisselen van gegevens. 
</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 toegang kan krijgen tot diensten</a>, waarbij toegang tot digitale diensten speciale aandacht vraagt. Iedereen moet mee kunnen doen in het digitale tijdperk. Er moet specifiek rekening worden gehouden met mensen die digitaal minder vaardig zijn of die om een andere redenen specifieke aandacht vragen. Het onderscheid tussen digitale en niet-digitale kanalen is in zekere zin ook niet zo relevant meer. Mensen willen op allerlei momenten bepaalde diensten afnemen, gebruiken het kanaal dat ze op dat moment handig vinden en schakelen op een later moment ook weer net zo makkelijk naar een ander kanaal. Toegang moet worden ondersteund door gebruiksvriendelijke voorzieningen en met voldoende instructies door mensen die dat nodig hebben. Het is bekend dat bestaande identificatiemiddelen niet optimaal toegankelijk zijn voor minder digitaal vaardigen. 
</p>
<p>
Naast toegankelijkheid is ook veiligheid belangrijk. 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. Het vaststellen van het juiste betrouwbaarheidsniveau voor toegang tot een bepaalde dienst is daarbij essentieel. Er is een nieuwe versie van de handreiking <a href="https://www.forumstandaardisatie.nl/onderwerpen/veilig-internet/betrouwbaarheidsniveaus">betrouwbaarheidsniveaus</a>, die aanvullend is op de Wdo en de Regeling betrouwbaarheidsniveaus. De EDI-wallet maakt het mogelijk om een gebruiker te authenticeren op niveau hoog.
</p>
<p>
Organisaties moeten voldoende beveiligingsmaatregelen nemen om de impact van mensen met kwade bedoelingen zoveel mogelijk te beperken. Het toepassen van een zero-trust beveiligingsmodel 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. Het betekent ook dat <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-b304c80b029c48498a32d80d14337ea3.html">toegang wordt beperkt tot dat wat strikt noodzakelijk is voor het uitvoeren van taken (least privilege)</a>. Als er sprake is van een inbraak of ander ernstig incident dan moet snel kunnen worden ingegrepen, en gecompromitteerde partijen moeten snel kunnen worden ontkoppeld van de toegangsinfrastructuur. Het is belangrijk dat organisaties de streefbeeldafspraken voor de informatieveiligheidsstandaarden van Forum Standaardisatie naleven en de verplichte standaarden uitvragen en implementeren. Er is ook specifieke aandacht nodig voor de impact van quantum computing om er voor te zorgen dat versleutelde gegevens onleesbaar blijven. Dit vraagt om post-quantum cryptografische oplossingen. Het NCSC adviseert organisaties om een actieplan op te stellen.
</p>
<p>
Organisaties zullen verder specifiek aandacht moeten geven aan allerlei nieuwe cyberdreigingen en een deel van de (overheids)organisaties wordt daar door de Europese NIS2-richtlijn ook toe gedwongen. Er geldt een zorg-, melding- en registratieplicht en organisaties vallen onder toezicht. Dit betekent bijvoorbeeld dat zij expliciet een risicobeoordeling moeten uitvoeren, gebruik moeten maken van sterke authenticatie en dat ze een plicht hebben om incidenten binnen 24 uur te melden. Dit laatste vraagt om detectie en monitoring van security-relevante gebeurtenissen. Overheidsorganisaties hebben daarin een bijzondere positie omdat ze vaak als essentiële entiteiten worden beschouwd. Dit betekent dat ze een cruciale rol spelen in de continuïteit van essentiële diensten en dat een verstoring van hun netwerk- en informatiesystemen aanzienlijke gevolgen kan hebben voor de samenleving en de economie. De impact van beslissingen van de overheid op het leven van mensen kan ook heel groot zijn. Overheden kunnen net als bedrijven echter op voorhand niet zomaar vertrouwd worden. De overheid bestaat ook gewooon uit mensen is daarmee inherent gevoelig voor fouten en verkeerde intenties. Daarom zouden er <a href="https://minbzk.github.io/gdi-toegang/content/elements/id-4532a251a8ba490298dc08824ef4799a.html">extra waarborgen voor overheidsorganisaties moeten zijn voor risico's met betrekking tot privacy en informatiebeveiliging</a>.
</p>
<h2>Doorontwikkeling nationale toegangsinfrastructuur</h2>
<p>De toegangsinfrastructuur moet partijen <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 <a href="https://pgdi.nl/files/view/82435cdb-9861-4a46-8152-288f666dc32f/gdi-meerjarenvisie.pdf">meerjarenvisie</a>. Een goed gedefinieerd en toekomstvast koppelvlak dat door allerlei partijen kan worden ondersteund, is in veel gevallen waardevoller en flexibeler dan een centrale voorziening. Het is bijvoorbeeld niet haalbaar om alle vormen van machtiging in één centrale voorziening vast te leggen. Verifieerbare verklaringen kunnen ook vanuit decentrale bronnen worden verstrekt. De beschikbaarheid van een verifieerbare verklaring is voldoende om vertrouwen te krijgen in de validiteit, integriteit, authenticiteit en geldigheid van identiteiten, hun attributen en bevoegdheden.
</p>
<p>
Het gebruik van verifieerbare verklaringen in de context van SSI en als gevolg van de nieuwe EDI-wallets vervaagt het onderscheid tussen toegang en gegevensuitwisseling. Verifieerbare verklaringen kunnen gaan over attributen die relevant zijn voor toegang alsook voor het verlenen van de diensten zelf. De standaarden en richtlijnen die daarbij worden voorgeschreven vanuit de eIDAS verordening en de daaruit voortvloeiende uitvoeringsverordeningen zijn daarbij sterk bepalend en hebben dus ook voor gegevensuitwisseling veel impact. Er is synergie gewenst tussen de afspraken, standaarden en voorzieningen voor gegevensuitwisseling en voor toegang.
</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 om de Wdo te ondersteunen. Het integreert de huidige toegangsinfrastructuren (stelsels) voor burgers en bedrijven en zorgt voor de beschikbaarheid van identificatiemiddelen op hogere betrouwbaarheidsniveaus. 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. De politiek heeft ook aangegeven dat er een publiek (gratis) zakelijk identificatiemiddel beschikbaar zal worden gesteld (<a href="https://zoek.officielebekendmakingen.nl/kst-35570-VII-16.html">motie van der Molen</a>). 
</p>
<p>
Er zijn ook een aantal andere zaken die doorontwikkeling van de nationale toegangsinfrastructuur vragen. Zo zouden een aantal groepen die op dit moment niet overheidsbreed identificeerbaar zijn omdat ze niet in landelijke registraties staan (ook wel: restgroepen) beter ondersteund moeten worden. Daarnaast is het op dit moment ook niet mogelijk om mensen digitaal wettelijk te laten vertegenwoordigen door bewindvoerders, curatoren, mentoren en mensen die ouderlijk gezag hebben. 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 dan ook standaard met machtigen en wettelijke vertegenwoordiging rekening worden gehouden. Gebruikers die inloggen hebben naast hun eigen bevoegdheden mogelijk ook bevoegdheden die horen bij de partijen die ze vertegenwoordigen. 
</p>
<p>
Voor toegang van systemen tot andere systemen is het PKIoverheid afsprakenstelsel ingericht. Voor toegang van systemen tot andere systemen is het PKIoverheid afsprakenstelsel ingericht. Dit stelsel is afgestemd op Europese en wereldwijde afspraken en standaarden. De Federated Service Connectivity standaard, zoals ontwikkeld in de context van het Common Ground programma, biedt waardevolle mogelijkheden voor toegang zoals het kunnen autoriseren en 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>
<h2>Schets van gewenste informatievoorziening</h2>
<p>
De volgende figuur geeft een schets van de informatievoorziening in de gewenste situatie. De blokken met gestreepte omlijning zijn nieuw of vragen wijziging. Een beschrijving van de bestaande voorzieningen is opgenomen in de bijlagen (paragraaf 5.4). De toegangsinfrastructuur zal gebruik maken van een aantal generieke bronnen, maar zal zelf ook een aantal eigen bronregistraties bevatten. Er zal een entiteitenregister zijn waarin restgroepen worden vastgelegd en die het huidige Tijdelijke Register Restgroepen vervangt. Mogelijk kunnen er daarnaast nog specifieke registers nodig zijn voor restgroepen die te specifiek van aard zijn om in het restgroepen register vast te leggen. De DigiD en eHerkenning machtigingsregisters zullen alle generieke vormen van machtiging ondersteunen. Machtigingen die te specifiek zijn om in deze generieke voorzieningen te worden vastgelegd zullen in een specifiek machtigingsregister worden vastgelegd. Er zal een meer gestandaardiseerde catalogus van overheidsdiensten nodig zijn, gebaseerd op de Uniforme Productennamenlijst (UPL). 
</p>
<p>
Er zullen in de gewenste situatie een aantal nieuwe identificatiemiddelen ontstaan. Naast de EDI wallet kunnen ook private middelen worden toegelaten. Er zal ook een publiek zakelijk identificatiemiddel zakelijk zijn, die in ieder geval bij de Belastingdienst kan worden gebruikt. Hiervoor wordt op dit moment een dienst ontwikkeld, die strikt genomen geen identificatiemiddel is maar een combinatie van DigiD en een verklaring uit het Handelsregister. Er zullen brokers beschikbaar moeten zijn die ervoor zorgen dat dienstverleners kunnen worden ontlast in het ontsluiten van authenticatiediensten, machtingsdiensten en andere bronnen van identiteitsgegevens. Er zullen namelijk verifieerbare verklaringen van allerlei partijen komen om te kunnen bepalen welke identiteit handelt, namens wie en met welke bevoegdheden.
</p>
<p><center><img src="https://minbzk.github.io/gdi-toegang/images/gewenste_situatie.png"></center></p>
</documentation>
</element>
<element xsi:type="archimate:Representation" name="Verdieping" id="id-5c41c1e562644d3dac34f20476569d06" profiles="id-b5e689fa75694829b24cf22fd76eacee">
<documentation><p>Dit hoofdstuk beschrijft een verdieping op de architectuurvisie en de architectuurprincipes op de onderwerpen rolverdeling en systeem naar systeem toegang.</p></documentation>
</element>
<element xsi:type="archimate:Representation" name="Kernbegrippen" id="id-62a0afc676e04f8280ed2271dd61cd44" profiles="id-b5e689fa75694829b24cf22fd76eacee">
<documentation><p>Dit hoofdstuk is bedoeld om de belangrijkste terminologie zoals gebruikt in dit document te verduidelijken. Een is een samenvatting en meer toegankelijke beschrijving van informatie die ook aanwezig is in de begrippenlijst, het functiemodel, het bedrijfsobjectmodel en de rollen. Voor een meer uitgebreide lijst van begrippen wordt dan ook naar de bijlage verwezen.</p>
<h2>2.1 Algemeen</h2>
<p>
Dit document gaat over het verstrekken van toegang aan mensen, organisaties, applicaties en apparaten. Dat noemen we in dit document <b>entiteiten</b>. Daarbij geldt dat applicaties en apparaten altijd handelen namens een andere entiteit. Een entiteit krijgt toegang met een bepaalde <b>identiteit</b>. Dat is een verzameling van eigenschappen die kenmerkend zijn voor een entiteit. Entiteiten hebben in een specifieke gebruikscontext een specifieke identiteit (ook wel: deelidentiteit), waarin alleen de eigenschappen zitten die in die context relevant zijn. Praktisch worden eigenschappen uitgewisseld in de vorm van <b>identiteitsgegevens</b>. Dit soort gegevens over entiteiten heten in de context van toegang ook wel <b>attributen</b>. Deze gegevens worden verkregen uit <b>gezaghebbende bronnen</b>. Dat zijn bronnen waarvan kan worden verwacht dat deze nauwkeurige gegevens bieden.
</p>
<p>
Entiteiten krijgen toegang door gebruik te maken van een <b>identificatiemiddel</b> om mee te authenticeren. Daarmee is het identificatiemiddel een authenticatiemiddel. Een dergelijk identiteitsmiddel vraagt een vorm van bewijs van een gebruiker, zoals een wachtwoord en geeft vervolgens een <b>authenticatieverklaring</b> waarmee toegang kan worden gegeven. Een authenticatieverklaring is een specifiek soort <b>verifieerbare verklaring</b>. Dat zijn verklaringen over identiteiten, die vergezeld van een bewijs waarmee hun validiteit, integriteit, authenticiteit en geldigheid kan worden geverifieerd. Verifieerbare verklaringen kunnen gebruikt worden om allerlei gegevens uit te wisselen. In de context van het domein toegang zijn verklaringen belangrijk die iets zeggen over attributen die worden gebruikt om te bepalen of iemand toegang krijgt.
</p>
<p>
Toegang wordt verstrekt tot <b>resources</b>: <b>diensten</b> en de daaronder liggende gegevens en functionaliteiten. Welke diensten, gegevens en functionaliteiten toegang toe wordt verstrekt wordt bepaald door de <b>bevoegdheden</b> (ook wel: autorisaties) die aan een identiteit zijn gekoppeld. Entiteiten kunnen ook bevoegdheden krijgen doordat ze van iemand anders een <b>machtiging</b> hebben gekregen of omdat een door een <b>wettelijke vertegenwoordiging</b> formeel namens iemand anders mogen optreden. Dit leidt tot vertegenwoordigingsbevoegdheden, die net als bevoegdheden in meer algemene zin worden gebruikt om te bepalen of een entiteit toegang kan krijgen. Merk op dat we de term “machtiging” in dit document alleen gebruiken voor vrijwillig verstrekte vertegenwoordigingsbevoegdheden.
</p>
<p>
Het controleren van de bevoegdheden van een identiteit heet <b>autoriseren</b>. Daarbij wordt gebruik gemaakt van <b>autorisatieregels</b> die beschrijven waaraan moet worden voldaan om toegang te verkrijgen. Dit soort regels gebruiken de identiteitsgegevens uit verifieerbare verklaringen, maar kunnen ook naar contextuele eigenschappen kijken zoals de tijdstip, de plaats en het apparaat dat gebruikt wordt om toegang te krijgen. Uiteindelijk leidt dit tot een <b>autorisatiebeslissing</b> die aangeeft of wel of geen toegang wordt verstrekt.
<h2>2.2 Rollen</h2>
<p>
Toegang gaat voor een belangrijk deel over het uitwisselen van verifieerbare verklaringen. Aan de ene kant zijn er partijen die verklaringen kunnen verstrekken. Dat noemen we dan ook <b>verklarende partijen</b>. Denk daarbij aan <b>authenticatiediensten</b> die kunnen verklaren of een entiteit succesvol is geauthenticeerd of aan <b>machtigingsdiensten</b> die kunnen verklaren of een entiteit iemand anders mag vertegenwoordigen. Daarnaast zijn er <b>aanbieders van identiteitsgegevens</a> uit gezaghebbende bronnen die deze beschikbaar kunnen stellen in de vorm van verifieerbare verklaren. Brokers kunnen de verklaringen van deze verklarende partijen routeren, vertalen, bundelen en als één geïntegreerde dienst beschikbaar stellen. Overigens kunnen entiteiten ook dingen over zichzelf verklaren, en zijn zij dus in potentie ook een verklarende partij. Merk op dat niet al deze rollen altijd relevant zijn. In de context van de EDI wallet spreken we niet over rollen als authenticatiedienst en broker omdat verantwoordelijkheden daarbij anders zijn belegd.
</p>
<p>
Aan de andere kant zijn er <b>vertrouwende partijen</b>. Dat zijn typisch dienstverleners die diensten aanbieden waartoe toegang moet worden verstrekt aan entiteiten. Zij moeten kunnen vertrouwen op de verifieerbare verklaringen van verklarende partijen. Merk op dat in de context van de eIDAS verordening de term ook breder wordt gebruikt.
</p>
<p>
Om dit geheel te laten werken zijn er ook andere rollen nodig. Zo zijn er ook <b>middelenuitgevers</b> nodig die ervoor zorgen dat er erkende <b>identificatiemiddelen</b> kunnen worden uitgegeven. Er wordt ook gebruik gemaakt van <b>leveranciers van vertrouwensdiensten</b>, die bijvoorbeeld verifieerbare verklaringen kunnen maken of certificaten kunnen uitgeven die verklarende partijen kunnen verstrekken.
<p>
<h2>2.3 Functies</h2>
<p>
In deze domeinarchitectuur hebben we functies benoemd die in het algemeen relevant zijn voor toegang. In deze paragraaf beschrijven we de hoofdfuncties, die activiteiten op organisatieniveau beschrijven (het zijn bedrijfsfuncties). Deze functies worden gebruikt om andere zaken op te plotten en aan te relateren. Figuur 1 geeft een overzicht van deze functies. In de bijlage zijn ook de meer gedetailleerde functies beschreven. 
</p>
<p>
Het is door organisaties zelf te bepalen aan welke partijen en afdelingen zij de functies in hun context toekennen. Er zijn wel een aantal functies specifiek gekoppeld aan rollen zoals beschreven in deze domeinarchitectuur. Zo hoort de hoofdfunctie "Beheren identificatiemiddelen" bij de rol middelenuitgever, de hoofdfunctie "authenticeren" bij de rol authenticatiedienst en de rol “beheren vertegenwoordigingsbevoegdheden” bij de rol machtigingsdienst. Het beheren van eigen bevoegdheden en het autoriseren zijn verantwoordelijkheden die bij vertrouwende partijen zelf ligt. 
</p>
<p>
<p><center><img src="https://minbzk.github.io/gdi-toegang/images/functiemodel_hoofdlijnen.svg"></center></p>
<p>
<ul>
<li>Organiseren toegang: Het organisatorisch inregelen van afspraken voor toegang.</li>
<li>Creëren vertrouwen: Het creëren van vertrouwen in de identiteit van natuurlijke en niet-natuurlijke personen en gegevens middels cryptografische technieken.</li>
<li>Beheren identiteiten: Het creëren, vastleggen, beschikbaarstellen, wijzigen en (logisch) verwijderen van (gegevens over) identiteiten.</li>
<li>Beheren identificatiemiddelen: Het verstrekken en intrekken van identificatiemiddelen en het administreren van de daarvoor benodigde gegevens.</li>
<li>Beheren eigen bevoegdheden: Het toekennen en intrekken van bevoegdheden (anders dan vertegenwoordigingsbevoegdheden) en het administreren van de daarvoor benodigde gegevens.</li>
<li>Beheren vertegenwoordigingsbevoegdheden: Het toekennen en intrekken van vertegenwoordigingsbevoegheden en het administreren van de daarvoor benodigde gegevens.</li>
<li>Auditing en monitoring: Het vastleggen van relevante gebeurtenissen rondom toegang en het uitvoeren van controlerende activiteiten om misbruik of fraude vast te stellen.</li>
<li>Authenticeren: Het bepalen of er voldoende vertrouwen is dat iemand een digitale identiteit heeft en het creëren, controleren, vertalen en vernietigen van daarbij behorende authenticatieverklaringen.</li>
<li>Autoriseren: Het bepalen op basis van autorisatieregels bepalen of een digitale identiteit beschikt over de bevoegdheden voor toegang tot diensten of informatieobjecten.</li>
</ul>
</p>





</documentation>
</element>
<element xsi:type="archimate:Representation" name="Beleid" id="id-77f44709a232443f943f54fe68f3af8d" profiles="id-b5e689fa75694829b24cf22fd76eacee">
<documentation><p>De domeinarchitectuur beschrijft een aantal belangrijke beleidsdocumenten die invloed hebben op gegevensuitwisseling. Overheidsorganisaties zouden zich bewust moeten zijn van dit beleid en van het feit dat dit directe invloed heeft op hun eigen beleidsvorming.</p></documentation>
<property key="elementType" value="driverBeleid"/>
</element>
<element xsi:type="archimate:Representation" name="Veranderfactoren" id="id-78b449aaa3e5492da0ec6d38975e9e8c" profiles="id-b5e689fa75694829b24cf22fd76eacee">
<documentation><p>Dit hoofdstuk geeft een overzicht van de veranderfactoren die richting geven aan de architectuur. Het beschrijft de belangrijkste beleid en wet- en regelgeving die van toepassing zijn, de ontwikkelingen die spelen en de knelpunten die er op dit moment bestaan. </p></documentation>
</element>
<element xsi:type="archimate:Representation" name="Veranderinitiatieven" id="id-7a3c760780f84b49aae60cc45cbeb885" profiles="id-b5e689fa75694829b24cf22fd76eacee">
<documentation><p>De domeinarchitectuur beschrijft veranderinitiatieven die worden voorgesteld omdat ze nodig zijn om ervoor te zorgen dat de digitale overheid kan voldoen aan de beschreven architectuur. Het zijn in eerste instantie alleen voorstellen en ze zijn ook nog niet voorzien van informatie over kosten en baten. Ze zijn vooral input voor nog op te stellen vernieuwingsvoorstellen, in het kader waarvan kosten en baten kunnen worden uitgewerkt. Er is ook bewust voor gekozen om niet alle initiatieven die al deel uitmaken van lopende programma’s of projecten te benoemen, omdat dat weinig meerwaarde heeft. Een deel van de voorgestelde initiatieven loopt reeds, zoals die m.b.t. vertegenwoordigen en meervoudig inloggen. De volgende figuur plot de voorgestelde veranderinitiatieven op de meest passende functie in het functiemodel. De figuur die daarop volgt laat zien hoe de veranderinitiatieven gekoppeld zijn aan de eerder beschreven knelpunten.</p>
<p><center><img src="https://minbzk.github.io/gdi-toegang/images/veranderinitiatieven.svg"></center></p>
<p><center><img src="https://minbzk.github.io/gdi-toegang/images/veranderinitiatieven_knelpunten.svg"></center></p></documentation>
<property key="elementType" value="work-package"/>
</element>
<element xsi:type="archimate:Representation" name="Verdieping: systeem naar systeem toegang" id="id-7af4783895fc4fb6b4cb8e96e8708e85" profiles="id-b5e689fa75694829b24cf22fd76eacee">
<documentation><p>Dit hoofdstuk gaat dieper in op hoe systemen toegang kunnen krijgen tot andere systemen. Het is een onderwerp waarvoor relatief weinig aandacht is, maar dat steeds relevanter wordt door toenemende uitwisseling van gegevens tussen organisaties. Het beschrijft een aantal standaarden en technische mogelijkheden die daarbij gebruikt kunnen worden. Het beschrijft zowel huidige standaarden als een aantal nieuwe standaarden die gebruikt zouden moeten worden. Het geeft ook in meer algemene zin uitleg aan gegevensruimtes, de EDI wallets en het EDI-stelsel NL.</p>
<h3>Public Key Infrastructure</h3>
<p>
Voor de veilige uitwisseling van gegevens tussen systemen wordt gebruik gemaakt van certificaten. Een certificaat is een combinatie van een identiteit en een openbare sleutel die gewaarmerkt is door de uitgever, een certificaatautoriteit. Met deze openbare sleutel kan een ontvanger de identiteit van de zender vaststellen. Certificaten zijn dus gebaseerd op asymetrische cryptografie, waarbij alleen de eigenaar van het certificaat beschikt over een privésleutel en de openbare sleutel wordt gedeeld met anderen. De certificaatautoriteit waarborgt de integriteit en authenticiteit van het certificaat en staat dus in voor de identiteit van de certificaatbezitter. Een public key infrastructure (PKI) is een systeem waarmee uitgiften en beheer van digitale certificaten kan worden gerealiseerd. 
</p>
<p>
PKIoverheid is de public key infrastructure (PKI) van de Nederlandse overheid, waarbij de Staat der Nederlanden de certificaatautoriteit is en verantwoordelijk is voor het stamcertificaat. Hierdoor is PKIoverheid niet afhankelijk van (buitenlandse) commerciële partijen. Dit stelsel is afgestemd op Europese en wereldwijde afspraken en standaarden. PKIoverheid wordt beheerd door Logius. Logius geeft zelf geen certificaten uit; hiervoor zijn commerciële partijen als qualified trust service provider benoemd. PKIoverheid stelt eisen aan de uitgifte van certificaten. Zo moet bijvoorbeeld naar organisaties in een PKIoverheid certificaat worden verwezen met een OIN. Deze OIN systematiek maakt het mogelijk om organisaties te voorzien van een unieke identificatie, ook als ze niet zijn opgenomen in het Handelsregister. Op dit moment zijn er echter bepaalde organisaties (restgroepen) die geen OIN kunnen krijgen en dus ook geen gebruik kunnen maken van PKIoverheid certificaten, zoals buitenlandse bedrijven.
</p>
<p>De herziene eIDAS verordening onderkent verschillende soorten PKI certificaten, los van het onderscheid tussen wel of niet gekwalificeerde certificaten. Een Electronic Signature certificaat kan door een persoon gebruikt worden voor het ondertekenen van documenten. Een Electronic Seal (eSeal) certificaat kan door organisaties gebruikt worden voor het verzegelen van documenten. Een Qualified Website Authentication Certificate (QWAC) is bedoeld voor het aantonen van de authenticiteit van een website. Deze QWAC-certificaten zouden ook gebruikt kunnen worden voor het beschermen van communicatie tussen systemen. Er zijn op dit moment echter onvoldoende afspraken tussen lidstaten over organisatie-identificaties om dit praktisch uit te kunnen voeren.</p>
<p>
In het algemeen kost het (tijdig) aanvragen en configureren van certificaten relatief veel aandacht van organisaties. Het Automatic Certificate Management Environment (ACME) is een protocol voor het geautomatiseerd uitgeven en vernieuwen van beveiligingscertificaten en kan de gevraagde beheerslast verminderen. Deze standaard is aangemeld bij het Forum Standaardisatie en er zal onderzocht worden of deze standaard formeel onderdeel zou moeten zijn van één van de lijsten van het forum. Het NCSC raadt het gebruik van de standaard reeds aan.
</p>
<p>
PKIoverheid is ook een belangrijke basis onder de Digikoppeling standaard. Deze richt zich specifiek op beveiligde uitwisseling van gegevens. Onderdeel daarvan zijn afspraken over hoe wordt omgegaan met authenticatie bij gegevensuitwisseling. Daarbij vooral wordt verwezen naar het gebruik van PKIoverheid certificaten en het tweezijdig gebruik van TLS. Dat betekent dat zowel het zendende systeem als het ontvangende systeem moet beschikken over een PKIoverheid certificaat. Er zijn ook afspraken en standaarden voor het inhoudelijk versleutelen en ondertekenen van berichten die worden uitgewisseld, als aanvullende beveiligingsmaatregelen nodig zijn.
</p>
<h3>OpenID Connect en OAuth</h3>
<p>
De OpenID Connect en OAuth standaarden worden tegenwoordig veel gebruikt om namens een gebruiker een ander systeem te benaderen. Dat is dus altijd in de context van een interactie die is gestart door en gebruiker. OpenID Connect is een protocol dat specifiek gericht is op authenticatie en gezien kan worden als een extensie van OAuth. OAuth is een protocol voor autorisatie en specifiek gericht op het autoriseren van het systeem waarmee een gebruiker interacteert, om namens die gebruiker gegevens van die gebruiker op te halen bij een ander systeem.
</p>
<p>
Er zijn Nederlandse profielen opgesteld voor OpenID Connect en OAuth: OpenID.NLGov en NL GOV Assurance profile for OAuth 2.0. Beiden staan op de "pas toe of leg uit" lijst van Forum Standaardisatie. Het Overheidsbreed Beleidsoverleg Digitale Overheid (OBDO) heeft besloten dat er een transitie van SAML naar OpenID.NLGov moet worden ingezet. Het OAuth profiel wordt op dit moment doorontwikkeld, waardoor het beter zal aansluiten op de FSC standaard (zie verderop) en ondersteuning zal bieden voor token exchange waarmee identiteiten van eindgebruikers kunnen worden doorgegeven in de keten. 
</p>
<p>
Het gebruik van OpenID Connect en OAuth werkt ongeveer als volgt. Een gebruiker voert gebruikersnaam en wachtwoord in en deze worden gecontroleerd bij een OpenID Connect Provider. Na succesvolle authenticatie met OpenID Connect ontstaan er drie tokens: een ID-token dat een beschrijving geeft van de ingelogde gebruiker, een access token dat gezien kan worden als de authenticatieverklaring en een refresh token dat gebruikt kan worden om het access token te vernieuwen als het is verlopen. De tokens worden door het systeem dat ze heeft verkregen doorgegeven aan het systeem dat wordt aangeroepen. Deze heeft daarmee toegang tot gegevens over de identiteit van de eindgebruiker en weet dat persoonsgegevens die daarbij horen kunnen worden geleverd aan het aanroepende systeem.
</p>
<p>
Op dit moment ondersteunen DigiD en eHerkenning nog geen OpenID Connect, maar de SAML standaard. Dat betekent dat het gebruik van OpenID Connect en OAuth vooralsnog alleen gebruikt kan worden in scenario’s waarin geen DigiD of eHerkenning wordt gebruikt. Denk daarbij bijvoorbeeld aan scenario’s om toegang te geven aan medewerkers voor het gebruik van systemen van de werkgever van deze medewerker (en daarmee de daaronder liggende systemen). 
</p>
<h3>Federated Service Connectivity</h3>
<p>
De Federated Service Connectivity (FSC) standaard is ontwikkeld in de context van het Common Ground programma voor gemeenten. Het standaardiseert de werking van tussenliggende componenten dat het gebruik van API’s vereenvoudigt. De standaard wordt inmiddels ondersteund door verschillende leveranciers en is gepositioneerd als een brede standaard die door alle overheidsorganisaties kan worden gebruikt. Het is voorgesteld als onderdeel van het Digikoppeling profiel voor REST API’s, maar kan in bredere zin worden gebruikt voor gegevensuitwisseling tussen systemen over HTTP.
</p>
<p>
De kern van de FSC standaard is dat het een vertrouwensnetwerk kan creëren tussen systemen door het creëren van contracten tussen partijen. De API's die worden aangeboden en de bijbehorende contracten worden geregistreerd in een directory, waarvan er meerdere kunnen zijn. In een directory kunnen API's worden gezocht en op basis daarvan kunnen ze worden aangeroepen door systemen, waarbij het resulterende berichtenverkeer verloopt over tussenliggende FSC componenten. Er is een tussenliggend componenten bij het zendende systeem (outway) en een tussenliggend component bij het ontvangende systeem (inway). In deze componenten kan ook extra functionaliteit worden aangeroepen, zoals het loggen van de berichten. Hiervoor wordt een transactie-identificatie gegenereerd, die bij elkaar behorende berichten kan correleren. Daarnaast zijn er manager componenten die vooral verantwoordelijk zijn voor de contractafhandeling. Vanuit het perspectief van toegang is met name relevant dat authenticatie en autorisatie van afnemers door aanbieders een integraal onderdeel is van de standaard. Verder is het mogelijk om machtigingen tussen systemen toe te kennen. Hierdoor kan een systeem van een derde partij (bijvoorbeeld een SaaS leverancier) een machtiging ontvangen om namens een overheidsorganisatie gebruik te maken van een ander systeem. Dit voorkomt dat er certificaten en/of sleutels aan deze derde partij moeten worden verstrekt, wat vanuit beveiligingsperspectief onwenselijk is. FSC gaat zelf ook uit van het gebruik van certificaten, waarbij voor de communicatie over organisatiegrenzen gebruik moet worden gemaakt van PKIoverheid certificaten. Het gaat ervan uit dat er een eenduidig vertrouwensraamwerk van certificaten bestaat. Het maakt verder gebruik van de OAuth standaard voor authenticatie van verzoeken.</p>
<p><img src="https://minbzk.github.io/gdi-toegang/images/fsc.svg"></p>
<h3>Gegevensruimtes</h3>
<p>
Gedreven vanuit de Europese datastrategie is er veel aandacht voor gegevensruimtes (data spaces). Er moet een Europese gegevensruimte komen, een interne markt voor data, waar zowel overheidsorganisaties als bedrijven gebruik van kunnen maken. Binnen deze Europese gegevensruimte ziet de Europese Commissie negen gemeenschappelijke gegevensruimtes ontstaan voor specifieke sectoren. De precieze inrichting van veel van deze gegevensruimtes is nog onduidelijk. Veel van de ideeën en ontwikkelingen rondom gegevensruimtes kunnen we breder omarmen. Je kunt gegevensruimtes zien als afsprakenstelsels en vertrouwensnetwerken waarbinnen gegevens tussen systemen kunnen worden uitgewisseld. Er zijn inmiddels allerlei referentie-architecturen voor gegevensruimtes beschikbaar van bijvoorbeeld <a href="https://www.opendei.eu/">OpenDEI</a>, de <a href="https://docs.internationaldataspaces.org/ids-knowledgebase/v/ids-ram-4/">International Data Spaces Association (IDSA)</a>, en het <a href="https://dssc.eu/page/knowledge-base">Data Spaces Support Center (DSSC)</a>. Er zijn verschillende partijen die hierop zijn ingesprongen en die oplossingen bieden om gegevensruimtes te ondersteunen. De referentie-architectuur van IDSA wordt ondersteund door generieke softwarecomponenten en een uitwisselprotocol. Daarnaast zijn er andere initiatieven zoals iShare en GAIA-X die oplossingen bieden. Een <a href="https://docs.geostandaarden.nl/eu/VerkenningDataspaces/">uitgebreider overzicht</a> van dit soort initiatieven is beschikbaar in de verkenning die Geonovum heeft uitgevoerd. 
</p>
<p>
Een gemeenschappelijk vertrekpunt bij al deze initiatieven is datasoevereiniteit, wat betekent dat gegevenseigenaren zelf willen kunnen beslissen over het beschikbaar stellen van hun gegevens. Als gevolg daarvan bieden ze allemaal gemeenschappelijke diensten voor toegang, waarbij vooral gebruik wordt gemaakt van (profielen op) internationale standaarden. Uitgangspunt daarbij is dat voorwaarden en regels van data-aanbieders zoveel mogelijk geautomatiseerd worden gecontroleerd als een afnemer om gegevens vraagt. Een aantal initiatieven biedt daarbij ondersteuning voor Policy Based Access Control, waarbij voorwaarden zoveel mogelijk in machineleesbare vorm als autorisatieregels zijn beschreven zodat ze geautomatiseerd kunnen worden getoetst. Het is daarmee te zien als een uitbreiding op attribute based access control, waarbij er autorisatieregels worden toegepast op de beschikbare attributen. In onderstaande figuur is de essentie van Policy Based Access Control beschreven aan de hand van de begrippen in de veelgebruikte XACML standaard. Naast de XACML standaard bestaat ook de ODRL standaard, die meer vanuit Digital Rights Management komt maar erg vergelijkbaar is met XACML en die ook breder wordt omarmd. Policy Based Access Control is ook een belangrijk aspect van een Zero Trust architectuur. 
</p>
<p><img src="https://minbzk.github.io/gdi-toegang/images/xacml.svg"></p>
<p>
In Policy Based Access Control zijn er verschillende componenten. De autorisatieregels (policies) worden beheerd in een Policy Administration Point (PAP). Ze worden gebruikt in een Policy Decision Point (PDP) die ze interpreteert om er een autorisatiebeslissing op te baseren. Deze beslissing wordt afgedwongen in een Policy Enforcement Point (PEP) naar aanleiding van een verzoek dat wordt gesteld door een systeem. Het Policy Information Point (PIP) stelt hiervoor identiteitsgegevens beschikbaar. Naast een autorisatiebeslissing levert het PDP ook verplichtingen (obligations) op, die leiden tot specifieke acties die randvoorwaardelijk zijn om toegang te kunnen krijgen. Voorgaande begrippen worden vaak ook breder gebruikt in de context van toegang. Ze vormen een soort referentie-architectuur voor toegang. Wat verder belangrijk is in de context van Policy Based Access Control is dat er ook allerlei eigenschappen van de identiteit, de actie, de resource en de context kunnen worden gebruikt om autorisatiebeslissingen op te baseren. Denk bijvoorbeeld aan de tijd waarop de beslissing wordt genomen of de locatie van de identiteit. Het ondersteunt daarmee contextuele en adaptieve toegangscontrole.
</p>
<p>
In de <a href="https://docs.internationaldataspaces.org/ids-knowledgebase/v/ids-ram-4">IDS RAM</a> wordt aanvullend op access control gesproken over usage control. Dit is een uitgebreidere vorm van toegangscontrole waarbij controles ook aan de kant van de afnemer plaats vinden. Deze verregaande vorm van controle stelt dus allerlei eisen aan de afnemer. Deze worden in die architectuur voor een belangrijk deel geborgd in de connector van de afnemer. Connectoren zijn een kernonderdeel van die architectuur en de plaats waar aan de kant van aanbieder en afnemer allerlei functionaliteit zoals controles kunnen worden ingebouwd. Naar verwachting zal usage control alleen in hele specifieke contexten relevant zijn, waarin hele hoge eisen worden gesteld aan de beveiliging van gegevens.
</p> 
<h3>EDI Wallet</h3>
<p>
European Digital Identity wallets zullen in de toekomst ook gebruikt kunnen worden door organisaties. Hoe dit precies zal werken is nog niet duidelijk, maar naar verwachting zal dat grotendeels analoog werken aan hoe deze wallets door burgers gebruikt zullen worden. De vraag is of zij ook gebruikt kunnen worden voor communicatie tussen systemen van organisaties. Dat is op dit moment ook nog niet duidelijk.
</p>
<p>
Het EDI-stelsel NL dient toe te groeien naar een stelsel waarin in ieder geval de uit de eIDAS-revisie voortvloeiende rollen en voorzieningen functioneren. Het betreft onder meer: 
<ul>
<li>id-wallets die door Nederland zijn toegelaten en gecertificeerd,</li>
<li>id-wallets die door andere lidstaten zijn toegelaten en gecertificeerd,</li>
<li>publieke en private (authentieke) bronnen,</li>
<li>publieke en private dienstverleners die voor dienstverlening vertrouwen op (gegevens uit) id-wallets,</li>
<li>gekwalificeerde verleners van vertrouwensdiensten voor het uitgeven van verifieerbare verklaringen, elektronisch ondertekenen en verzegelen,</li>
<li>registraties van leveranciers van identiteiten, leveranciers van wallets en vertrouwende partijen,</li>
<li>validatie- en authenticatiemechanismen voor dienstverleners, id-wallets, digitale identiteiten en gekwalificeerde verifieerbare verklaringen.</li>
</ul>
Er is voor de borging van de veiligheid en betrouwbaarheid nodig dat er geaccrediteerde conformiteitsbeoordelingsinstanties zijn voor de certificering van id-wallets (en vertrouwensdiensten) en dat er één of meerdere toezichthouders worden aangewezen om toezicht te houden op de veiligheid en betrouwbaarheid in het stelsel. 
</p>
<p>
Ook reeds bestaande (nationale) voorzieningen zijn van belang voor het stelsel. Er moet gezocht worden naar samenhang tussen het EDI-stelsel NL en wat er onder de Wdo en in het stelsel toegang is voorzien.
</p>
<p>De EDI wallet maakt geen gebruik van de OpenID Connect standaard, maar van de OpenID for Veriable Credentials standaard. Dit is een uitbreiding op de OpenID Connect standaard, en biedt expliciete ondersteuning voor het uitgeven en verifiëren van verifieerbare verklaringen. Het is net als OpenID Connect gebaseerd op de OAuth standaard. Het biedt ondersteuning voor verschillende formaten, zoals ISO 18013-5 (mDL), SD-JWT en het W3C Verifiable Credentials datamodel. Daarnaast biedt het ondersteuning voor verschillende cryptografische suites, soorten identifiers en schema’s. Er is inmiddels voor een aantal standaard OpenID Connect oplossingen ondersteuning beschikbaar voor de OpenID for Verifiable Presentations standaard. </p></documentation>
</element>
<element xsi:type="archimate:Representation" name="Huidige voorzieningen" id="id-9592d4808efb4be9aa2751e0019b4771" profiles="id-b5e689fa75694829b24cf22fd76eacee">
<documentation><p>De Generieke Digitale Infrastructuur bestaat uit een aantal generieke voorzieningen, die breed gebruikt kunnen worden door overheidsorganisaties. In deze paragraaf wordt een overzicht gegeven van de belangrijkste voorzieningen met betrekking tot toegang die we onder de aandacht willen brengen. Deze voorzieningen zijn gerelateerd aan de functies om inzicht te geven in hun functionaliteit. Ze zijn ook voorzien van eigenschappen die beschrijven wie verantwoordelijk is voor het beheer en waar meer informatie over de voorziening kan worden gevonden. De beschrijvingen en modellen zijn gebaseerd op informatie van Logius over de huidige situatie zoals die bestond in mei 2024. Daarmee zijn ze een specifieke momentopname en kan deze afwijken van de situatie zoals die bestaat op het moment van lezen van dit document.</p>
<p> In de volgende diagrammen wordt een overzicht gegeven van de voorzieningen en hun samenhang. De eerste laat zien welke gegevensstromen met name relevant zijn voorafgaand aan een specifiek authenticatieverzoek. Het diagram erna laat met name zien wat er gebeurt tijdens het uitvoeren van een authenticatieverzoek. Er zijn bepaalde gegevensstromen die niet zo eenvoudig in één van deze twee categorieën in te delen zijn, bijvoorbeeld omdat ze in beide situaties afhankelijk van de omstandigheden kunnen plaatsvinden. Die zijn dan in het meest logische diagram geplaatst.</p>
<h3>Gegevensstromen voorafgaand aan een authenticatieverzoek</h3>
<p><center><img src="https://minbzk.github.io/gdi-toegang/images/huidig1.svg"></center></p>
<h3>Gegevensstromen tijdens een authenticatieverzoek</h3>
<p><center><img src="https://minbzk.github.io/gdi-toegang/images/huidig2.svg"></center></p>

</documentation>
<property key="elementType" value="application-componentHuidige voorziening"/>
</element>
<element xsi:type="archimate:Representation" name="Inleiding" id="id-9704fa59cc7b4b5e9daa53f1b32ec98d" profiles="id-b5e689fa75694829b24cf22fd76eacee">
<documentation><h2>1.1 Aanleiding</h2>
<p>De overheid digitaliseert en dat roept vragen op over hoe overheidsorganisaties hun processen, gegevens en systemen moeten inrichten. De Generieke Digitale Infrastructuur (GDI) ondersteunt de digitale overheid met afspraken, standaarden en voorzieningen. In de governancestructuur van het Meerjarenprogramma Infrastructuur Digitale Overheid (MIDO) werken overheidsorganisaties samen aan de doorontwikkeling van de digitale overheid en de GDI. Er is vanuit deze governance een <a href="https://pgdi.nl/files/view/82435cdb-9861-4a46-8152-288f666dc32f/gdi-meerjarenvisie.pdf">meerjarenvisie</a> en een <a href ="https://pgdi.nl/ado">Architectuur Digitale Overheid 2030</a> opgesteld die op hoofdlijnen beschrijft hoe de digitale overheid zich de komende jaren zou moeten doorontwikkelen. De Architectuur Digitale Overheid wordt nader uitgewerkt in vier domeinarchitecturen op het gebied van interactie, toegang, gegevensuitwisseling en infrastructuur.</p>
Domein toegang gaat over beveiligde toegang tot diensten, gegevens en functionaliteit. Deze gegevens en functionaliteit worden richting gebruikers ontsloten in de context van het domein interactie. Gegevensuitwisseling is het domein dat gaat over het uitwisselen van gegevens tussen de informatiesystemen van overheidsorganisaties en met andere organisaties. Domein infrastructuur ondersteunt de andere domeinen met infrastructurele voorzieningen, zowel software- als hardwarematig.</p>
<p>Het domein toegang omvat alles dat nodig is om mensen, organisaties, applicaties en apparaten op een veilige en rechtmatige manier toegang te geven. Dit vraagt om het nemen van maatregelen, die voor een belangrijk deel ook relevant zijn in het kader van informatiebeveiliging. Domein toegang is grotendeels synoniem met wat ook wel "identity & access management" wordt genoemd. Dit is iets dat zowel binnen organisaties als over organisatiegrenzen heen aandacht vraagt. In de context van de GDI gaat het over toegang tot digitale publieke diensten. Dit staat los van hoe organisaties hun eigen medewerkers toegang verlenen, alhoewel het ook gebruikt kan worden om medewerkers van overheidsorganisaties toegang te geven tot digitale publieke diensten van andere overheidsorganisaties.</p>
<p>De toegangsinfrastructuur is de verzameling van gemeenschappelijke afspraken, standaarden en voorzieningen die nodig zijn om toegang te faciliteren. Er zijn meerdere toegangsinfrastructuren, zoals het Afsprakenstelsel Elektronische Toegangsdiensten (behorende bij eHerkenning), het nieuwe stelsel toegang en het EDI-stelsel NL (dat tevens een infrastructuur voor gegevensuitwisseling is). Landelijke voorzieningen zoals DigiD en eHerkenning zijn belangrijke onderwerpen van gesprek, maar het toegangslandschap is tevens aan het veranderen. Zo zullen er in de toekomst ook private middelen worden toegelaten om toegang te verkrijgen tot overheidsdiensten. Daarnaast worden er in het kader van de herziene eIDAS verordening European Digital Identity Wallets geïntroduceerd die ook als identificatiemiddel kunnen worden ingezet. In meer algemene zin hebben ontwikkelingen zoals Self Sovereign Identity grote impact op hoe idealiter met toegang wordt omgegaan.</p>
<h2>Dit document</h2>
<p>Dit document beschrijft de domeinarchitectuur voor toegang, als onderdeel van de GDI. Het gaat vooral in op toegang tot publieke digitale diensten, alhoewel een deel van de principes en modellen ook gebruikt kunnen worden voor toegang binnen overheidsorganisaties. Het betreft de huidige en gewenste afspraken, standaarden en voorzieningen voor toegang in de GDI. Het document is opgesteld in een interbestuurlijke architectuurwerkgroep met vertegenwoordigers van verschillende overheidsorganisaties. Deze werkgroep is ondersteund door bureau MIDO van het ministerie van BZK. Het document beschrijft relevant beleid, wet- & regelgeving en ontwikkelingen, en vertaalt deze naar een visie en richting voor de inrichting van toegang tot digitale publieke diensten. </p>
<p>
Deze architectuur geeft richting aan ontwerpkeuzes die worden gemaakt bij het doorontwikkelen van de GDI of bij het aansluiten op de GDI. Het is input voor programmering en kan gebruikt worden om nieuwe programma’s en projecten te definiëren en initiëren. Het speelt een formele rol in de kaderstelling, toezicht en monitoring van programma’s en projecten die gefinancierd worden vanuit de MIDO governancestructuur. Het kan in de MIDO governancestructuur worden gebruikt om afwijkingen van de gewenste situatie te signaleren in programma’s en projecten. Het document is ook in meer algemene zin te gebruiken door overheidsorganisaties. Het bevat meer algemene kennis over wat er van overheidsorganisaties wordt verwacht met betrekking tot toegang. Daarnaast is het voor een belangrijk deel ook toe te passen als referentiekader voor de inrichting van toegang binnen individuele overheidsorganisties.
</p>
<p>
Het document is vooral gericht op enterprise-, informatie- en security-architecten bij overheidsorganisaties en op architecten die werken aan de vernieuwing van de toegangsinfrastructuur. Daarnaast kan het ook interessant zijn voor informatie-analisten, ontwerpers en product owners om te gebruiken als basis voor requirements en ontwerp. Het document is een doorontwikkeling van de eerdere domeinarchitecturen voor identificatie & authenticatie en machtigen & vertegenwoordigen maar kent een andere structuur en opzet. De voorgaande documenten komen met dit document te vervallen.</p>
<p>Er is voor gekozen om de architectuur in de modelleertaal ArchiMate uit te werken en de details ervan alleen <a href="https://github.com/minbzk/gdi-toegang">online</a> beschikbaar te stellen. Dit document is daarmee een samenvatting en verwijzing naar details die online te vinden zijn. Het bevat dan ook allerlei links die toegang geven tot meer informatie. De architectuur wordt online ook doorontwikkeld en beheerd in <a href="https://github.com/minbzk/gdi-toegang">GitHub</a>, waardoor de meest actuele versie daar te vinden is. Daar zijn ook bestanden te vinden die direct kunnen worden ingelezen in het Open Source modelleertool Archi.
</p>
<p>
We hebben ervoor gekozen om de terminologie in dit document af te stemmen op de begrippen van de NORA IAM werkgroep. We hebben ook actief meegewerkt aan de doorontwikkeling van laatstgenoemd begrippenkader, dat onderdeel zal gaan uitmaken van een nieuwe NORA begrippenlijst. Er is daarom ook geen begrippenlijst opgenomen in dit document. We adviseren om de NORA IAM begrippenlijst te raadplegen. De kernbegrippen zijn wel onderdeel van het bedrijfsobjectenmodel, die dus ook als een begrippenlijst gezien kan worden. 
</p>
<h3>1.3 Documentstructuur</h3>
<p>
De architectuur is ingedeeld in vijf onderdelen: 
</p>
<p>
<ul>
<li>De <b>kernbegrippen</b> zijn de kern van de taal zoals deze gehanteerd wordt in dit document en de bijbehorende tekst is een samenvatting van zaken die zijn beschreven in de bijlagen. </li>
<li>De <b>veranderfactoren</b> geven richting aan de architectuur, en bestaan uit beleid, wet- en regelgeving, ontwikkelingen en knelpunten.</li>
<li>De <b>gewenste situatie</b> beschrijft een architectuurvisie, architectuurprincipes en voorgestelde veranderinitiatieven. De architectuurprincipes zijn de overtuigingen die het hart van de architectuur vormen en die als richtinggevende uitspraken zijn opgeschreven.</p>
<li>De <b>verdieping</b> beschrijft een uitwerking van de architectuurvisie en architectuurprincipes op de voorgestelde rolverdeling en op het gebied van toegang tussen systemen. Het geeft aanvullende inzichten en handreikingen. </li>
<li> In de <b>bijlagen</b> zijn meer algemene modellen en beschrijvingen opgenomen van de functies, objecten, voorzieningen, standaarden en begrippen die van toepassing zijn op toegang. Het beschrijft ook de relatie van de architectuurprincipes met de Architectuur Digitale Overheid en NORA en de betrokkenen bij de totstandkoming van dit document. 
</ul>
<h2>1.4 Relatie met andere architecturen</h2>
<p>
Deze domeinarchitectuur is sterk gerelateerd aan de domeinarchitectuur gegevensuitwisseling. Dat komt enerzijds omdat het uitwisselen van gegevens in veel gevallen om toegang vraagt en anderzijds omdat er gegevens moeten worden uitgewisseld om te bepalen of toegang kan worden verstrekt. Er is bewust voor gekozen om geen grote delen uit de domeinarchitectuur gegevensuitwisseling in te kopiëren in deze architectuur, zodat er één duidelijke bron van informatie over gegevensuitwisseling is. De consequentie hiervan is dat lezers wordt gevraagd om de <a href="https://github.com/minbzk/gdi-gegevensuitwisseling">domeinarchitectuur gegevensuitwisseling</a> ook te lezen om een volledig beeld van toegang te krijgen. De belangrijkste relaties tussen de beide domeinarchitecturen zijn:
</p>
<p>
<ul>
<li>De functie “verlenen toegang” in domeinarchitectuur gegevensuitwisseling is te beschouwen als een samenvoeging van de functies “authenticeren”, “autoriseren” en “auditing en monitoring” in de domeinarchitectuur toegang.</li>
<li>Functies voor het maken van verifieerbare verklaringen en het gebruik van verifieerbare verklaringen voor het verstrekken van toegang zijn onderdeel van de domeinarchitectuur toegang. Functies voor het beschikbaar stellen en valideren van verifieerbare verklaringen zijn onderdeel van de domeinarchitectuur gegevensuitwisseling.</li>
<li>Regie op gegevens, Self Sovereign Identity en de EDI wallet zijn sterk aan elkaar gerelateerd. De domeinarchitectuur gegevensuitwisseling beschrijft de ontwikkeling en een principe m.b.t. regie op gegevens. De domeinarchitectuur toegang beschrijft de ontwikkeling en geeft toelichting op Self Sovereign Identity. De EDI wallet wordt in beide domeinarchitecturen beschreven.</li>
<li>Gegevensruimtes zijn te zien als een meer geavanceerde vorm van gegevensuitwisseling waarbij datasoevereiniteit en vertrouwen centraal staan. Dat vraagt vooral mechanismen voor toegang. Gegevensruimtes worden daarom in beide domeinarchitecturen beschreven en domeinarchitectuur toegang gaat dieper in op de toegangsaspecten, waarbij vooral Policy Based Access Control relevant is.</li>
</ul>
</p>
<p>Er is ook een relatie met de domeinarchitectuur interactie:
</p>
<p>
<ul>
<li>De domeinarchitectuur interactie stelt dat iedereen recht heeft op kwalitatief goede overheidsdiensten. In de domeinarchitectuur toegang wordt de impact hiervan op het kunnen verstrekken van toegang beschreven.</li>
<li>De domeinarchitectuur interactie stelt dat er een één-overheidsbeleving is met een eenvormige interactie. Een belangrijk aspect ervan is dat daarbij een gemeenschappelijke set van identificatiemiddelen wordt ondersteund, en dat de klantreis die wordt geboden voor inloggen uniform is.</li>
<li>De domeinarchitectuur interactie stelt dat interacties via meerdere kanalen mogelijk moet zijn. Dat betekent dat identiteiten via al deze kanalen bruikbaar moeten zijn.</li>
</ul>
</p>
<p>
Deze domeinarchitectuur is afgestemd op de <a href ="https://pgdi.nl/ado">Architectuur Digitale Overheid 2030</a> en de <a href="https://www.noraonline.nl">NORA</a>. Hierdoor is de domeinarchitectuur te beschouwen als een doorvertaling en concretisering van deze overkoepelende architecturen.</p>
<h3>1.5 Relatie met andere initiatieven</h3>
<p>Er zijn andere initiatieven die zijn gerelateerd aan toegang. De belangrijkste programma’s die er op het moment van schrijven van dit document lopen zijn het programma/stelsel toegang en het programma EDI-stelsel NL. Deze domeinarchitectuur geeft context en kaders aan de architecturen die zijn of worden opgesteld in deze programma’s. Het programma/stelsel toegang heeft een “doelarchitectuur ICT-voorzieningen en werking stelsel toegang” opgesteld die met name inzicht geeft in welke ICT-voorzieningen nodig zijn voor het ondersteunen van de <a href="https://wetten.overheid.nl/BWBR0048156/2023-07-01">Wet digitale overheid (Wdo)</a>. Er heeft een review plaatsgevonden op deze doelarchitectuur door de architectuurwerkgroep. Het programma EDI-stelsel NL geeft aandacht aan de implementatie van de herziene eIDAS verordening, richt hiervoor een stelsel in en geeft daarbij specifieke aandacht aan het gebruik van European Digital Identity Wallets. Er is afgestemd met dit programma om dat wat hierover duidelijk is in de architectuur een plek te geven. Er loopt ook een project Federatieve Toegangs Verlening (FTV) dat onderzoekt hoe toegang tot gegevens in de context van gegevensuitwisseling kan worden gestandaardiseerd. Daarbij wordt expliciet gekeken naar de inzet van Policy Based Access Control.</p> </documentation>
</element>
<element xsi:type="archimate:Representation" name="Functies" id="id-99cbfb6171e24415a2d555ae897ba9d6" profiles="id-b5e689fa75694829b24cf22fd76eacee">
<documentation><p>
In deze domeinarchitectuur hebben we functies benoemd die in het algemeen relevant zijn voor toegang. De functies beschrijven vooral activiteiten op organisatieniveau (bedrijfsfuncties), maar ze zijn ook te zien als functies van informatiesystemen (applicatiefuncties). Het onderscheid is op dit niveau lastig te maken, mede doordat het afhankelijk is van de mate waarin activiteiten zijn geautomatiseerd. Organisaties zullen zelf moeten bepalen in hoeverre deze functies worden uitgevoerd door mensen en/of informatiesystemen. Daarbij kunnen ze ervoor kiezen om ze door andere organisaties te laten uitvoeren zoals aanbieders of andere soorten intermediairs of dienstverleners. Op landelijk niveau zijn er ook generieke voorzieningen beschikbaar die invulling geven aan een aantal van deze functies. We hebben ervoor gekozen om bij een aantal functies de hoofdactiviteit als naam van de functie te gebruiken, maar de volledige lading van deze functies is dus eigenlijk breder en is beschreven in de definitie ervan. De lijst van functies kan gebruikt worden om inzicht te geven in de huidige en gewenste inrichting van organisatie, processen en informatiesystemen. In de domeinarchitectuur zijn ze gekoppeld aan de architectuurprincipes, bedrijfsobjecten, rollen, voorzieningen en standaarden. 
</p>
<p>
<img src="https://minbzk.github.io/gdi-toegang/images/functiemodel.svg">
</p></documentation>
<property key="elementType" value="business-function"/>
</element>
<element xsi:type="archimate:Representation" name="Rollen" id="id-beae3c7f591a4525a89ff0ce63d003fb" profiles="id-b5e689fa75694829b24cf22fd76eacee">
<documentation><p>Rollen zijn een clustering van taken, bevoegheden en verantwoordelijkheden. De architectuur benoemt de belangrijkste rollen in de context van toegang en verbindt ze aan de functies om de belangrijkste verantwoordelijkheden duidelijk te maken.<p></documentation>
<property key="elementType" value="business-role"/>
</element>
<element xsi:type="archimate:Representation" name="Standaarden" id="id-c01f60f9719f4ef2bfcb8cf050cc36d2" profiles="id-b5e689fa75694829b24cf22fd76eacee">
<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. We hebben ervoor gekozen om alleen de generieke standaarden op te nemen en niet de toepassingspecifieke standaarden. Deze standaarden zijn aangevuld met andere standaarden die breder worden gebruikt of relevant zijn. Deze aanvullende standaarden zijn te beschouwen als aanbeveling vanuit deze architectuur. De aanbeveling is vooral om deze standaarden te bestuderen en hun inzet te overwegen bij het inrichten of aanpassen van gegevensuitwisseling. De standaarden zijn voorzien van een aantal standaard eigenschappen zoals de beheerorganisatie en een URL naar meer informatie. Ze zijn ook gekoppeld aan functies en bedrijfsobjecten zodat hun toepassingsgebied duidelijk is. Bij de standaarden van Forum Standaardisatie zijn ook de status en het functioneel toepassingsgebied overgenomen. De volgende figuur geeft een overzicht van de standaarden geplot op de meest passende functie in het functiemodel.</p>
<p><center><img src="https://minbzk.github.io/gdi-toegang/images/standaarden.svg"></center></p>
</documentation>
<property key="elementType" value="constraintStandaard"/>
</element>
<element xsi:type="archimate:Representation" name="Betrokkenen" id="id-db058829d6194cd59fd9d78182fb6933" profiles="id-b5e689fa75694829b24cf22fd76eacee">
<documentation><p>De volgende mensen waren onderdeel van de architectuurwerkgroep toegang en hebben bijgedragen aan de totstandkoming van dit document.
<ul>
<li>Bert-Jan Geveke, sponsor (DUO)</li>
<li>Ron Beemster, voorzitter (IenW)</li>
<li>Danny Greefhorst, secretaris en redacteur (BZK/Bureau MIDO)</li>
<li>Catelijne de Koning (KvK)</li>
<li>Harro Kremer (JIO)</li>
<li>Sheila Ghosh (ICTU)</li>
<li>Guy Rutten (Logius)</li>
<li>Eric Nijenhuis (UWV)</li>
<li>Johann Schreurs (DUO)</li>
<li>Marco Eikenaar (Belastingdienst)</li>
<li>Fokke Rispens (NICTIZ)</li>
<li>Alexander Bielowski (ICTU)</li>
<li>Michel de Winter (RvIG)</li>
</ul>
</p>
<p>
De volgende organisaties hebben reviewcommentaar geleverd op een concept versie van deze domeinarchitectuur:
<ul>
<li> Ministerie van Binnenlandse Zaken en Koninkrijksrelaties, inclusief Logius, Bureau Forum Standaardisatie, de Rijksdienst voor Identiteitsgegevens, Programma Federatief Data Stelsel, Programma EDI-stelsel NL</li>
<li>Ministerie van Volksgezondheid, Welzijn en Sport</li>
<li>Ministerie van Economische Zaken en Landbouw, inclusief de Rijksdienst voor Ondernemend Nederland</li>
<li>Belastingdienst</li>
<li>Kamer van Koophandel</li>
<li>Interprovinciaal Overleg</li>
<li>Provincie Overijssel</li>
<li>Unie van Waterschappen</li>
<li>NORA IAM expertgroep</li>
<li>UWV</li>
<li>DUO</li>
<li>SURF</li>
</ul>
</p></documentation>
</element>
<element xsi:type="archimate:Representation" name="Verdieping: rolverdeling" id="id-df84c34285474bdebefd163a965d6403" profiles="id-b5e689fa75694829b24cf22fd76eacee">
<documentation><p>Dit hoofdstuk beschrijft de belangrijkste interactiepatronen die een rol spelen bij toegang en gaat vervolgens in op de belangrijkste rollen, hun verantwoordelijkheden en onderlinge samenhang. Het geeft ook richtlijnen voor deze rollen.</p>
<h3>Interactiepatronen</h3>
<p>
De volgende figuur geeft een overzicht van de belangrijkste interactiepatronen die relevant zijn in het kader van toegang. Het gewenste interactiepatroon voor de toekomst is het patroon waarbij de gebruiker centraal staat omdat deze de privacy maximaal beschermt en de gebruiker maximaal zelf laat bepalen. De overige patronen zijn alleen nodig door beperkingen en keuzes in de huidige situatie.
</p>
<p><center><img src="https://minbzk.github.io/gdi-toegang/images/interactiepatronen.svg"></center></p>
<h4>Interactiepatroon 1: Gebruiker centraal</h4>
<p>
Het interactiepatroon “gebruiker centraal” komt overeen met de rolverdeling zoals voorgesteld in de context van Self Sovereign Identity en de EDI wallet. Bij dit patroon hebben gebruikers regie op hun eigen gegevens en bepalen ze zelf welke identiteitsgegevens worden verstrekt aan dienstverleners. Aanbieders van identiteitsgegevens hebben ook geen zicht op welke dienstverleners de identiteitsgegevens gebruiken. Daarmee is privacy maximaal beschermd. De gebruiker wordt daarbij dus ondersteund door een wallet, die je kunt zien als een soort authenticatiedienst. Het werkt alleen anders dan een authenticatiedienst. De gebruiker is al eerder geauthenticeerd door aanbieders van identiteitsgegevens bij het laden van verifieerbare verklaringen in de wallet. Bij het verzoek om een dienst kan de gebruiker alle relevante verklaringen verstrekken aan een dienstverlener, inclusief een verklaring over zijn/haar identiteit. Merk op dat machtigingsdiensten ook kunnen worden gezien als een bijzondere vorm van aanbieders van identiteitsgegevens, en in die zin ook niet anders behandeld hoeven te worden.
</p>
<h4>Interactiepatroon 2: Traditioneel</h4>
<p>
In meer traditionele interactiepatronen speelt de authenticatiedienst een meer centrale rol. Deze wordt aangeroepen door de dienstverlener en ontvangt bewijs van de identiteit van de gebruiker, bijvoorbeeld in de vorm van een wachtwoord. Als er aanvullende identiteitsgegevens nodig zijn, die niet worden verstrekt door de authenticatiedienst, dan dient de dienstverlener deze zelf op te halen bij andere aanbieders van identiteitsgegevens. Daarmee ligt er veel complexiteit bij de dienstverlener. Daarnaast worden er hoge eisen gesteld aan de beschikbaarheid van de authenticatiedienst en aanbieders van identiteitsgegevens. Dit is het patroon dat ook de kern vormt van DigiD en eHerkenning en dat ook in de toekomst nog veel gebruikt zal worden. Een belangrijke reden daarvoor is dat er niet vanuit kan worden gegaan dat iedereen een wallet heeft, deze is immers niet verplicht. Daarnaast moeten ook andere authenticatiemiddelen kunnen worden ondersteund in de context van de Wet digitale overheid.
</p>
<h4>Interactiepatroon 3: Ontzorgd door broker(s)</h4>
<p>
Om dienstverleners te ontzorgen kunnen dienstverleners gebruik maken van brokers, die complexiteit afschermen doordat ze verklaringen van één of meer verklarende partijen kunnen routeren, vertalen en aggregeren. Er bestaan brokers op meerdere niveaus. Zo is een makelaar een standaard rol in de context van eHerkenning en is CombiConnect onderdeel van DigiD. Deze laatste zorgt dat verklaringen over machtigingen worden teruggegeven bij het resultaat van authenticatie met DigiD. Ook de bevoegdhedenverklaringsdienst is een broker; deze aggregeert verklaringen over wettelijke vertegenwoordigingen. Daarnaast kunnen dienstverleners ook andere brokers inzetten, zoals TVS of een commerciële broker. Dit soort brokers zijn in staat om over meerdere soorten authenticatiedienst heen te aggregeren en zorgen dus voor maximale ontzorging. Ze zouden echter niet verplicht moeten zijn voor dienstverleners. Extra schakels in een keten leiden ook tot extra risico’s m.b.t. informatiebeveiliging.
</p>
<p>
In de volgende paragrafen worden de kernrollen verder beschreven. Bij elke rol worden functies benoemd, gebaseerd op het functiemodel. Er worden ook richtlijnen beschreven, die zijn gebaseerd op onder meer de architectuurprincipes en knelpunten, alsook op van toepassing zijnde wet- en regelgeving. Daarnaast staan er voorbeelden van partijen of voorzieningen die bij deze rol horen. Strikt genomen zijn de beheerpartijen van de voorzieningen de verantwoordelijke voor de rol, maar om redenen van herkenbaarheid staat er de naam van de voorziening.
</p>
<h4>Gebruiker</h4>
<p>
Een gebruiker is natuurlijk persoon die gegevens en/of functionaliteit gebruikt voor het uitvoeren van werkzaamheden.
</p>
<p>
Een gebruiker is bij meer traditionele interactiepatronen de partij die de interactie start door een verzoek te doen bij een dienstverlener en bewijs (zoals een wachtwoord) te verstrekken aan een authenticatiedienst. Bij het interactiepatroon waarbij de gebruiker centraal staat gebruikt deze gebruiker een wallet. Die wallet geeft ook invulling aan de rol authenticatiedienst en heeft daarmee ook de daarbij behorende verantwoordelijkheden. Tegelijkertijd doet de term authenticatiedienst eigenlijk geen recht aan de fundamenteel andere interactie die een wallet ondersteunt. Een wallet lijkt ook in zekere zin op een broker, omdat het in staat is om verklaringen te vertalen en te aggregeren. Tegelijkertijd doet ook die term geen recht aan wat een wallet is..
</p>
<h4>Aanbieder van identiteitsgegevens</h4>
<p>
Een aanbieder is verantwoordelijk voor het aanbieden van gegevens van bronhouders op een manier die aansluit bij de behoeften en het gebruik van afnemers. In de context van toegang zijn dat identiteitsgegevens. Een aanbieder van identiteitsgegevens is een verlener van vertrouwensdiensten, omdat deze ook in staat moet zijn om verifieerbare verklaringen te kunnen leveren.
</p>
<p>Functies:
<ul>
<li>Elektronisch verklaren;</li>
<li>Verstrekken identiteitsgegevens.</li>
</ul>
</p>
<p>Voorbeelden: RvIG, KvK, RDW, QTSP.</p>
<p>
Een aanbieder van identiteitsgegevens:
<ul>
<li> biedt identiteitsgegevens aan in de vorm van verifieerbare verklaringen;</li>
<li> kan verifieerbare verklaringen aanbieden die voldoen aan de standaarden voor de EDI wallet (OpenID for Verifiable Credentials en NEN-ISO/IEC 18013-5).</li>
</ul>
</p>
<h4>Authenticatiedienst</h4>
<p>Een authenticatiedienst geeft authenticatieverklaringen af op basis van een identificatiemiddel.</p>
<p>Voorbeelden: Logius (voor DigiD), eHerkenning authenticatiedienst, EDI Wallet.</p>
<p>Functies:
<ul>
<li>Uitvoeren authenticatie;</li>
<li>Vastleggen auditlog;</li>
<li>Vastleggen gebruik identificatiemiddel;/li>
<li>Uitloggen;</li>
<li>Bestrijden fraude en misbruik./li>
</ul>
</p>
<p>
Een authenticatiedienst:
<ul>
<li>controleert bij een authenticatieverzoek de authenticiteit en geldigheid van het gebruikte identificatiemiddel bij de verantwoordelijke middelenuitgever;</li>
<li>registreert authenticatieverzoeken en hun resultaat in een auditlog;</li>
<li>registreert metagegevens over authenticatieverzoeken en hun resultaat in een inzageregister dat inzichtelijk is voor gebruikers;</li>
<li>ondersteunt de OpenID Connect standaard conform het Nederlands profiel OpenID.NLGov (geldt niet voor EDI Wallet);</li>
<li>ondersteunt het uitloggen van entiteiten met een bepaalde identiteit;</li>
<li>is verantwoordelijk voor het voorkomen, detecteren, opvolgen en herstellen van fraude met identificatiemiddelen;/li>
<li>stuurt metagegevens over authenticatieverzoeken en hun resultaat door naar centrale misbruikbestrijding./li>
</ul>
</p>
<h4>Broker</h4>
<p>Een broker biedt één ingangspunt voor het routeren, vertalen en aggregeren van verklaringen van één of meer verklarende partijen.</p>
<p>Voorbeelden: Logius (voor CombiConnect, bevoegdhedenverklaringsdienst en eIDAS koppelpunt), DICTU (voor TVS), eHerkenning makelaar.</p>
<p>Functies:
<ul>
<li>Orkestreren login;</li>
<li>Vertalen authenticatieverklaring;</li>
<li>Vertalen identifier.</li>
</ul>
</p>
<p>
Een broker:
<ul>
<li>kan het inlogproces richting een eindgebruiker orkestreren;</li>
<li>kan vertalingen uitvoeren op verifieerbare verklaringen;</li>
<li>kan gebruik maken van andere brokers.</li>
</ul>
<p>
Een broker die het inlogproces orkestreert:
<ul>
<li> biedt gebruikers een klantreis die voldoet aan de afspraken voor het inlogproces;</li>
<li>maakt het standaard mogelijk om iemand te vertegenwoordigen bij het inloggen;</li>
<li>ontzorgt dienstverleners in het verkrijgen van veelvoorkomende (voor toegang relevante) attributen;</li>
<li>ondersteunt de OpenID Connect standaard conform het Nederlands profiel OpenID.NLGov (geldt niet voor EDI Wallet).</li>
</ul>
</p>
<h4>Dienstverlener</h4>
<p>Een dienstverlener levert volgens afspraken diensten aan een klant. Een dienstverlener is een vertrouwende partij.</p>
<p>Voorbeelden: rijksoverheden, uitvoeringsorganisaties, gemeenten, provincies, waterschappen, commerciële dienstverleners.</p>
<p>Functies:
<li>Auditing, monitoring en misbruikbestrijding;</li>
<li>Autoriseren;</li>
<li>Beheren eigen bevoegdheden.</li>
</ul>
</p>
<p>Een dienstverlener:
<ul>
<li>biedt diensten die zijn afgestemd op de specifieke soorten gebruikers en hun specifieke taken;</li>
<li>bepaalt voor elke dienst een noodzakelijk betrouwbaarheidsniveau;</li>
<li>eist geen hoger betrouwbaarheidsniveau dan wat nodig is voor het verkrijgen van toegang tot een dienst; </li>
<li>accepteert alle erkende publieke en private identificatiemiddelen;</li>
<li>registreert de attributen die nodig zijn voor het verstrekken van toegang tot een dienst in de toegangsinfrastructuur;</li>
<li>maakt duidelijk welke wettelijke grondslag en doelbinding ten grondslag liggen aan de attributen die worden gevraagd;</li>
<li>maakt duidelijk aan welke derde partijen attributen worden doorgegeven en op basis van welke wettelijke grondslag en doelbinding;</li>
<li>vraagt niet meer attributen dan wat strikt noodzakelijk is voor het leveren van een dienst;</li>
<li>geeft gebruikers voorafgaand aan hun handelen inzicht in de voor een dienst gevraagde attributen;</li>
<li>kan zelf kiezen of deze gebruik maakt van een broker of verifieerbare verklaringen direct haalt bij een authenticatiedienst, machtigingsdienst of andere aanbieder van identiteitsgegevens;</li>
<li>controleert of verifieerbare verklaringen valide, integer, authentiek en geldig zijn;</li>
<li>kan omgaan met gebruikers die andere entiteiten vertegenwoordigen;</li>
<li>minimaliseert het aantal keer dat gebruikers wordt gevraagd om in te loggen;</li>
<li>is zelf verantwoordelijk voor het autoriseren van entiteiten met een bepaalde identiteit;</li>
<li>biedt alleen toegang tot diensten, functionaliteiten en gegevens die passen bij de aangeleverde verklaringen en bijbehorende attributen;</li>
<li>baseert autorisaties in achterliggende systemen op de identiteit van de gebruiker;</li>
<li>registreert gevoelige verwerkingen die een entiteit uitvoert in een auditlog.</li>
</ul>
</p>
<h4>Machtigingsdienst</h4>
<p>Een machtigingsdienst kan machtigingen vastleggen en op basis daarvan bevoegdheids-verklaringen afgeven. Een machtigingsdienst kan worden gezien als een leverancier van identiteitsgegevens en zou dan ook de daarbij behorende verantwoordelijkheden moeten hebben.</p>
<p>Voorbeelden: Logius (voor DigiD machtigen), eHerkenning machtigingsdienst.</p>
<p>Een machtigingsdienst:
<ul>
<li>registreert metagegevens over machtigingen, wijzigingen daarin en bevoegdheidsverklaringen die deze afgeeft in een inzageregister dat inzichtelijk is voor gebruikers;</li>
<li>registreert het betrouwbaarheidsniveau waarop een machtiging is afgegeven;</li>
<li>maakt het mogelijk om het betrouwbaarheidsniveau van een machtiging op te hogen;</li>
<li>notificeert vertegenwoordigden en vertegenwoordigers over wijzigingen in machtigingen;</li>
<li>stuurt metagegevens over afgegeven bevoegdheidsverklaringen door naar centrale misbruikbestrijding./li>
</ul>
<h4>Middelenuitgever</h4>
<p>Een middelenuitgever draagt zorg voor de uitgifte van erkende identificatiemiddelen aan natuurlijke personen of niet-natuurlijke personen.</p>
<p>Voorbeelden: RvIG (voor paspoort), RDW (voor rijbewijs), Logius (voor DigiD), eHerkenning middelenuitgever, EDI wallet aanbieder.</p>
<p>Functies:
<ul>
<li>Beheren identificatiemiddelen</li>
</ul>
</p>
<p>Een middelenuitgever:
<ul>
<li>registreert het uitgeven en intrekken van identificatiemiddelen in een inzageregister dat inzichtelijk is voor gebruikers;</li>
<li>ondersteunt het intrekken van een identificatiemiddel.</li>
</ul>
</p></documentation>
</element>
<element xsi:type="archimate:Representation" name="Gewenste situatie" id="id-e572700165f84f9783f1b3d0e3162a5c" profiles="id-b5e689fa75694829b24cf22fd76eacee">
<documentation><p>Dit hoofdstuk geeft een overzicht van de gewenste situatie met betrekking tot toegang. Het start met een architectuurvisie die een overkoepelende beschrijving geeft van de gewenste situatie. Vervolgens worden architectuurprincipes beschreven die deze meer concreet maken. Op basis hiervan worden veranderinitiatieven voorgesteld, die aangeven welke nieuwe afspraken, standaarden of voorzieningen of wijzigingen daarin wenselijk zijn. </p></documentation>
</element>
<element xsi:type="archimate:Representation" name="Bedrijfsobjecten en begrippen" id="id-ec079e908ff84941a103d1e0bc024faa" profiles="id-b5e689fa75694829b24cf22fd76eacee">
<documentation><p>
Bedrijfsobjecten zijn dingen in de werkelijkheid waarover gegevens worden vastgelegd. Een model van bedrijfsobjecten is te zien als een hoog niveau gegevensmodel. Het geeft een overzicht van de belangrijkste begrippen die leiden tot gegevens die organisaties moeten vastleggen. Het is ook bruikbaar als checklist om verantwoordelijkheden van organisaties, mensen, processen en informatiesystemen toe te wijzen. In de domeinarchitectuur zijn ze gekoppeld aan de functies en standaarden.
</p>
<p>
<img src="https://minbzk.github.io/gdi-toegang/images/bedrijfsobjectenmodel.svg">
</p>
<p>
De begrippen zoals gebruikt in het bedrijfsobjectenmodel zijn onderdeel van de bredere lijst van begrippen zoals gebruikt in dit document. Deze begrippenlijst is waar mogelijk afgestemd met de nieuwe algemene NORA begrippenlijst, die nog in ontwikkeling is. Soms is ervoor gekozen een iets meer specifieke betekenis te hanteren om de rol van het begrip in de context van toegang duidelijker te maken. De toelichtingen zijn ook beperkt en specifiek gemaakt voor wat relevant is in dit document. Voor een meer uitgebreide toelichting wordt verwezen naar de NORA begrippenlijst.
</p>
</documentation>
<property key="elementType" value="meaning"/>
</element>
<element xsi:type="archimate:Representation" name="Knelpunten" id="id-ec62f6503d6e4ebbbc1e8f7da58048ac" profiles="id-b5e689fa75694829b24cf22fd76eacee">
<documentation><p>Knelpunten zijn omstandigheden in de huidige situatie die ertoe leiden dat organisaties niet kunnen voldoen aan beleid of wet- en regelgeving. Er heeft in het kader van de domeinarchitectuur een globale analyse van knelpunten plaatsgevonden. De resultaten van de analyse zijn samengevat en opgenomen in de architectuur. We zijn ons bewust van het feit dat dit slechts een subset is van de volledige set van knelpunten en dat de knelpunten niet voor alle overheidsorganisaties in gelijke mate gelden of van toepassing is. Een deel van deze knelpunten heeft betrekking op de toegangsinfrastructuur, maar nadere analyse is nodig of dat daadwerkelijk het geval is. Voor een deel van deze knelpunten geldt dat ook reeds aan oplossingen wordt gewerkt, zoals de knelpunten m.b.t. vertegenwoordigen en meervoudig inloggen. De volgende figuur plot de knelpunten op de meest passende functie in het bedrijfsfunctiemodel.</p>
<p><center><img src="https://minbzk.github.io/gdi-toegang/images/knelpunten.svg"></center></p>
</documentation>
<property key="elementType" value="assessment"/>
</element>
</folder>
<folder name="Rollen" id="id-5bc281f1925b46e7841f1d216e37a79e">
<element xsi:type="archimate:BusinessRole" name="Bronhouder" id="id-0bd68e9ba1e244aeaa10f633eb302c0e">
<documentation>Een rol die verantwoordelijk is voor het inwinnen, beheren en het verbeteren van de kwaliteit van gegevens.</documentation>
</element>
<element xsi:type="archimate:BusinessRole" name="Gebruiker" id="id-160cbce0ebb8400189fb751b0dbde669">
<documentation>Een natuurlijk persoon die gegevens en/of functionaliteit gebruikt voor het uitvoeren van werkzaamheden.</documentation>
</element>
<element xsi:type="archimate:BusinessRole" name="Vertrouwende partij" id="id-34ae37bf77034fd991d6de0c776dc643">
<documentation>Een rol die vertrouwt op verifieerbare verklaringen van een verklarende partij.</documentation>
</element>
<element xsi:type="archimate:BusinessRole" name="Dienstverlener" id="id-43ff9aa71f9d42f6b923887431c90bfc">
<documentation>Een rol die volgens afspraken diensten levert aan een klant.</documentation>
</element>
<element xsi:type="archimate:BusinessRole" name="Broker" id="id-573203ed1c8b4c37841226848f98a089">
<documentation>Een rol die één ingangspunt biedt voor het routeren, vertalen en aggregeren van verklaringen van één of meer verklarende partijen.</documentation>
</element>
<element xsi:type="archimate:BusinessRole" name="Verlener van vertrouwensdiensten" id="id-64294694c5484d4693e67a05359d6a12">
<documentation>Een natuurlijke persoon of niet-natuurlijke persoon die een of meer vertrouwensdiensten verleent als een gekwalificeerde of als een niet-gekwalificeerde verlener van vertrouwensdiensten.</documentation>
</element>
<element xsi:type="archimate:BusinessRole" name="Machtigingsdienst" id="id-716262df16c04d2eab3f45cf6f107af5">
<documentation>Een rol die machtigingen kan vastleggen en op basis daarvan bevoegdheidsverklaringen kan afgeven. </documentation>
</element>
<element xsi:type="archimate:BusinessRole" name="Aanbieder van identiteitsgegevens" id="id-7704adc1f92441d0b314f1d05a716b04">
<documentation>Een rol die verantwoordelijk is voor het aanbieden van identiteitsgegevens van bronhouders op een manier die aansluit bij de behoeften en het gebruik van afnemers.</documentation>
</element>
<element xsi:type="archimate:BusinessRole" name="Verklarende partij" id="id-8d2556e7d06240a9b05e03cff58fe696">
<documentation>Een organisatie die verifieerbare verklaringen uitgeeft.</documentation>
</element>
<element xsi:type="archimate:BusinessRole" name="Authenticatiedienst" id="id-9675a33d1c104ef4960db2634f60d9ac">
<documentation>Een rol die op basis van een identificatiemiddel een authenticatieverklaring afgeeft (bron: Wet digitale overheid).</documentation>
<property key="Toelichting" value="Een authenticatieverklaring is wat in de domeinarchitectuur een identiteitsverklaring heet."/>
</element>
<element xsi:type="archimate:BusinessRole" name="Middelenuitgever" id="id-9eb924f84a7e479d95a5ea99984a277e">
<documentation>Een rol die zorg draagt voor de uitgifte van erkende identificatiemiddelen aan natuurlijke personen of niet-natuurlijke personen.</documentation>
</element>
<element xsi:type="archimate:BusinessRole" name="Toezichthouder" id="id-a172ca968e54411981680e782674df85">
<documentation>Een rol die vanuit een onafhankelijke positie controleert of de toegangsinfrastructuur werkt en voldoende waarde oplevert.</documentation>
</element>
<element xsi:type="archimate:BusinessRole" name="Regisseur toegangsinfrastructuur" id="id-b388d510985b436b936e59ead4860ec5">
<documentation>Een rol die verantwoordelijk is voor het inrichten en besturen van een toegangsinfrastructuur.</documentation>
</element>
<element xsi:type="archimate:BusinessRole" name="Centrale misbruikbestrijding" id="id-cd4216b658324e39925728e61320ae4c">
<documentation>Een rol die verantwoordelijk is voor het detecteren van fraude en misbruik met meerdere identificatiemiddelen of bij meerdere dienstverleners.</documentation>
</element>
</folder>
<folder name="Functies" id="id-9cf74dde1b46462398225462cac533db">
<element xsi:type="archimate:BusinessFunction" name="Beheren identiteiten" id="id-079caeb56ec2440cad449a57741e2837">
<documentation>Het vastleggen, verstrekken, wijzigen en (logisch) verwijderen van (gegevens over) identiteiten.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Elektronisch ondertekenen" id="id-10a0a2782ace495b9bf996fc485bd031">
<documentation>Het creëren, verifiëren en valideren van een bewijs dat bepaalde gegevens afkomstig zijn van een specifiek natuurlijk persoon.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Vertalen identifier" id="id-121061d0dfc74da48a428a108e57b9d2">
<documentation>Het vertalen van een identifier van en naar een andere identifier, zoals van een landspecifieke identifier naar een eIDAS Unique Identifier en vice versa.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Inzage geven in vertegenwoordigingsbevoegdheden" id="id-1e240322fbec495f9895c2f7cb22f552">
<documentation>Het ontsluiten van informatie over machtigingen en wettelijke vertegenwoordigingen, inclusief het gebruik.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Evalueren en bijstellen toegangsinfrastructuur" id="id-20a30272b6464b84ae24506f19a31d74">
<documentation>Het bepalen in welke mate een toegangsinfrastructuur werkt en voldoende waarde oplevert en het aanpassen van afspraken, standaarden en voorzieningen aan nieuwe inzichten.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Autoriseren voor gegevens" id="id-2284caddd8094fd3b974678a31502f9f">
<documentation>Het bepalen of een identiteit geautoriseerd is voor toegang tot specifieke gegevens.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Organiseren toegang" id="id-256454e9e1434b858b4214c65b1cb3ab">
<documentation>Het organisatorisch inregelen van afspraken voor toegang.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Identificeren" id="id-2980fa7cd93e40608ccf46e879fea5e0">
<documentation>Het bepalen van de entiteit die behoort bij een identiteit op basis van een verzameling identiteitsgegevens.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Autoriseren voor dienst" id="id-3099a3491bf542f084b6b3defa72ef68">
<documentation>Het bepalen of een identiteit geautoriseerd is voor toegang tot een dienst.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Versleutelen pseudoniem" id="id-3be2a0b7c4e74b64a89ab048535de88d">
<documentation>Het encrypten van een pseudoniem in de context van een identifcatiemiddel om de privacy of vertrouwelijkheid te beschermen.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Elektronisch verzegelen" id="id-3d7ba1fff4e94615b2b0fcb46d08480e">
<documentation>Het creëren, verifiëren en valideren van een bewijs dat bepaalde gegevens afkomstig zijn van een specifiek niet-natuurlijk persoon.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Bestrijden fraude en misbruik" id="id-40c81c1087394f71aa0ad0c1775a97fb">
<documentation>Het voorkomen, detecteren, opvolgen en herstellen van fraude en misbruik met identificatiemiddelen.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Beheren gegevens over diensten" id="id-4a798952a1ce4c129980061149b0a6c9">
<documentation>Het creëren, vastleggen, verstrekken, wijzigen en (logisch) verwijderen van gegevens over diensten.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Beheren autorisatieregels" id="id-4c5fe57ec2ab485c9cb8bdef64d7d4d9">
<documentation>Het creëren, vastleggen, verstrekken, wijzigen en (logisch) verwijderen van gegevens over autorisatieregels, die aangeven onder welke condities identiteiten toegang hebben tot welke resources.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Ontsleutelen pseudoniem" id="id-4ea810315dc14f11b115cef01338dca5">
<documentation>Het terugvertalen van een versleuteld pseudoniem naar het pseudoniem waar het op gebaseerd is.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Creëren vertegenwoordigingsbevoegdheidsverklaring" id="id-522b1467667646ccb017e52455f0af44">
<documentation>Het creëren en intrekken van een bewijs dat een identiteit behorende bij een bepaalde vertegenwoordiger een bepaalde vertegenwoordigingsbevoegdheid heeft.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Uitloggen" id="id-52aa4858c63d46faa3fa7c4b92716e53">
<documentation>Het ervoor zorgen dat gecreëerde authenticatieverklaringen niet meer gebruikt kunnen worden om toegang te krijgen tot resources.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Autoriseren voor functionaliteit" id="id-5396e150e23f4a438e224778e1f1eaae">
<documentation>Het bepalen of een identiteit geautoriseerd is voor toegang tot specifieke functionaliteit.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Organiseren toegangsinfrastructuur" id="id-55c7b8c858794843993b05b87c34fe1d">
<documentation>Het creëren van afspraken, het bepalen van standaarden en het inrichten van voorzieningen voor toegang.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Toelaten identificatiemiddelen" id="id-5bfb606ab33b47a2967d91a3e1f9fa36">
<documentation>Het toelaten van identificatiemiddelen tot een toegangsinfrastructuur en het administreren van de daarvoor noodzakelijke gegevens.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Vastleggen gebruik identificatiemiddel" id="id-6297e4b66d844a9fb8c054238841b313">
<documentation>Het vastleggen welk identificatiemiddel is gebruikt bij een authenticatie, zodat daar op een later moment inzicht in kan worden gegeven.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Vertalen authenticatieverklaring" id="id-6542c5c440084cb8a856e2c30ecad892">
<documentation>Het vertalen van een authenticatieverklaring naar een andere vorm, zodat deze breder gebruikt kan worden. </documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Elektronisch verklaren" id="id-6627523870a84b19817156bd7c6db45b">
<documentation>Het creëren, verifiëren en valideren van een verifieerbare verklaring over bepaalde eigenschappen van een entiteit.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Elektronisch dateren" id="id-6b88f79abff5456cb62409784a7b81e1">
<documentation>Het creëren, verifiëren en valideren van een bewijs dat bepaalde gegevens op een specifiek moment bestaan.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Authenticeren" id="id-71518055a4194c55844b0ed040dacbe2">
<documentation>Het vaststellen van de identiteit van een entiteit en het verstrekken van een authenticatieverklaring hierover.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Borgen vertrouwen" id="id-715ea15b4b9146498e9e88e3cee41494">
<documentation>Het waarborgen van de veiligheid, betrouwbaarheid en juridische erkenning van digitale transacties.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Toekennen rollen" id="id-7cf7d264e6a84c85a50d8feefc8eae67">
<documentation>Het creëren, wijzigen en verwijderen van relaties tussen identiteiten en rollen en het beheren van de daarvoor noodzakelijke gegevens over rollen.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Beheren machtigingen" id="id-7f4acb54b45f4d77bbec4f16ea8d52a8">
<documentation>Het creëren, vastleggen, verstrekken, wijzigen en (logisch) verwijderen van gegevens over machtigingen.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Creëren bevoegdheidsverklaring" id="id-8216e6a7ee624f5d9772f879da9fc81c">
<documentation>Het creëren en intrekken van een bewijs dat een identiteit een bepaalde bevoegdheid heeft.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Beheren eigen bevoegdheden" id="id-83db5a52a2914474a04a7152fa9d12e0">
<documentation>Het toekennen en intrekken van bevoegdheden (anders dan vertegenwoordigingsbevoegdheden) en de daarvoor randvoorwaardelijke activiteiten.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Controleren conflicterende bevoegdheden" id="id-85f7280d5d3649bfb0b8cb60dada3eca">
<documentation>Het controleren van en rapporteren over bevoegdheden van identiteiten die met elkaar kunnen conflicteren.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Vastleggen identiteitsgegevens" id="id-87d20390ad9b43eea623acd8193d0428">
<documentation>Het vastleggen van gegevens die horen bij een identiteit.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Orkestreren inloggen" id="id-87efb23dd060485693d5d93dc857dbf4">
<documentation>Het ontvangen en routeren van een verzoek tot authenticatie naar de benodigde verklarende partijen en het verstrekken van een authenticatieverklaring.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Auditing, monitoring en misbruikbestrijding" id="id-89cae607ed114aa9b258920260a4499c">
<documentation>Het vastleggen van relevante gebeurtenissen rondom toegang om de integere werking aan te kunnen tonen, zo snel mogelijk in te grijpen als de (integere) werking niet gegarandeerd lijkt en om fraude en misbruik te bestrijden.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Uitgeven identificatiemiddel" id="id-8addb4bcb26c46019bd5ad035a87d236">
<documentation>Het overhandigen van gegevens en middelen die behoren bij een identificatiemiddel aan de entiteit met de bijbehorende identiteit, volgens een proces dat voldoet aan de normen van een specifiek betrouwbaarheidsniveau.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Uitvoeren authenticatie" id="id-920f614c629f45e196645b1744dc91b6">
<documentation>Het bepalen of er voldoende bewijs is aangeleverd om zeker te stellen dat iemand daadwerkelijk de geclaimde identiteit heeft. </documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Registreren identificatiemiddel" id="id-9492a75502d04a89a9be90b4db9975fa">
<documentation>Het creëren en vastleggen van gegevens over een identificatiemiddel en de bijbehorende authenticatiefactoren, inclusief een koppeling met de identiteit.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Uitvoeren assessment op aansluiting" id="id-96ff8c5d886f4013b003c77ee8907044">
<documentation>Het uitvoeren van een assessment voor de aansluiting van partijen op de toegangsinfrastructuur om de veiligheid ervan te bewaken.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Vastleggen auditlog" id="id-9fbbb392461f46a0b24c5cdc58a01ee8">
<documentation>Het vastleggen van relevante gebeurtenissen in een auditlog.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Inzage geven in bevoegdheden" id="id-a6d25074ed4746d78e7b3002de2175dc">
<documentation>Het ontsluiten van informatie over bevoegdheden, inclusief de koppeling met diensten, dienstverleners, resources en identiteiten.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Beheren wettelijke vertegenwoordiging" id="id-aacf5c4d48204c23922b68521c7999b2">
<documentation>Het creëren, vastleggen, verstrekken, wijzigen en (logisch) verwijderen van gegevens over wettelijke vertegenwoordigingsbevoegdheden.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Autoriseren" id="id-b750feb34d9c40588f9443c33145b59e">
<documentation>Het op basis van autorisatieregels bepalen of een identiteit beschikt over de benodigde bevoegdheden voor toegang tot resources.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Verstrekken gegevens over identificatiemiddelen" id="id-bbb53fd3512e4e3e84c8e3059b832164">
<documentation>Het beschikbaar stellen van gegevens over identificatiemiddelen en hun gebruik.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Controleren verschil tussen huidige en gewenste autorisaties" id="id-c07b09ed9fcd46d98cd4efd9700d2c4c">
<documentation>Het bepalen of de daadwerkelijk in systemen aanwezige autorisaties overeenkomen met de gewenste autorisaties en het inzichtelijk maken van de verschillen.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Beheren vertegenwoordigingsbevoegdheden" id="id-c5998016874b4a3f9a80d62f09af3f33">
<documentation>Het toekennen en intrekken van vertegenwoordigingsbevoegheden en de daarvoor randvoorwaardelijke activiteiten.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Aansluiten partij" id="id-c89765631a7f4df58760c8fc9d6acea7">
<documentation>Het toelaten van een dienstverlener, verklarende partij of gebruikersorganisatie tot de toegangsinfrastructuurm, het toetsen of deze kan voldoen aan de bijbehorende afspraken en het intrekken van een eerdere toelating.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Beheren resources" id="id-cd9ce254e1e445b58e7c6e44f9d7084e">
<documentation>Het creëren, vastleggen, verstrekken, wijzigen en (logisch) verwijderen van gegevens over gegevens en functionaliteiten waartoe toegang kan worden verstrekt als resource.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Wijzigen en beëindigen identificatiemiddel" id="id-d763571d80f54f8892724832e27eed3e">
<documentation>Het wijzigen van gegevens behorend bij een identificatiemiddel, inclusief het blokkeren en het beëindigen van de geldigheid van een identificatiemiddel.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Wijzigen en beëindigen identiteit" id="id-d99f5610425448249b780d45cd71af5f">
<documentation>Het wijzigen van de gegevens die horen bij een identiteit, inclusief het beëindigen van de geldigheid van een identiteit.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Toezicht houden op toegangsinfrastructuur" id="id-d9cb79ae0cd64f30a7213037af6280fe">
<documentation>Het vanuit een onafhankelijke rol controleren of de toegangsinfrastructuur werkt en voldoende waarde oplevert.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Toekennen bevoegdheden" id="id-dfa93a7f2bf64bcf8dd828eb7f754b4e">
<documentation>Het creëren, wijzigen en verwijderen van relaties van identiteiten of rollen naar bevoegdheden.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Informeren over vertegenwoordigingsbevoegdheden" id="id-f5ed40da3592429082e7f978de22be46">
<documentation>Het actief attenderen van belanghebbenden en vertegenwoordigers over (wijzigingen in) vertegenwoordigingsbevoegdheden, en het gebruik van vertegenwoordigingsbevoegdheden.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Creëren pseudoniem" id="id-fa4be6b66e8d4eb68c946f1f59cad1b1">
<documentation>Het creëren en vastleggen van een pseudoniem die een entiteit identificeert.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Beheren identificatiemiddelen" id="id-fe587c1bae3c453285eccb764194ced3">
<documentation>Het verstrekken en intrekken van identificatiemiddelen en de daarvoor randvoorwaardelijke activiteiten.</documentation>
</element>
<element xsi:type="archimate:BusinessFunction" name="Verstrekken identiteitsgegevens" id="id-ffeb84e839934d419c4ca4ee9aa6f136">
<documentation>Het beschikbaar stellen van identiteitsgegevens.</documentation>
</element>
</folder>
<folder name="Documenten" id="id-b4606bbaac7c45d8b33d1f9eeb537942">
<element xsi:type="archimate:Representation" name="Domeinarchitectuur toegang" id="id-5290881708d14046854ed00cf901874e" profiles="id-26aa96f7f0c547e2861d4f2c24cf8ea7"/>
</folder>
<folder name="GDI-bouwstenen" id="id-f7d133cd0c0d47ab8e77e096a324e0e2">
<element xsi:type="archimate:Product" name="Machtigen" id="id-045a4575e8744777b97e18d8e5bda6d1" profiles="id-cae440e3ddfb4d20986f23c30a163ca7">
<documentation>Een voorziening voor het verstrekken van vrijwilige machtigingen die gebruikt kunnen worden als onderdeel van DigiD.</documentation>
<property key="Beheerorganisatie" value="Logius"/>
<property key="URL" value="https://www.digid.nl/aanvragen-en-activeren/machtigen"/>
</element>
<element xsi:type="archimate:Product" name="eHerkenning" id="id-4154a89dfdf84ffe958de98a06935941" profiles="id-cae440e3ddfb4d20986f23c30a163ca7">
<documentation>Een authenticatiedienst voor organisaties.</documentation>
<property key="Beheerorganisatie" value="Logius"/>
<property key="URL" value="https://afsprakenstelsel.etoegang.nl/"/>
</element>
<element xsi:type="archimate:Product" name="DigiD" id="id-7d3b09e815e44c8fb2c3339286d2b41c" profiles="id-cae440e3ddfb4d20986f23c30a163ca7">
<documentation>Een authenticatiedienst gericht op burgers.</documentation>
<property key="Beheerorganisatie" value="Logius"/>
<property key="URL" value="https://www.digid.nl/"/>
</element>
<element xsi:type="archimate:Product" name="eIDAS" id="id-7e86f18658114d58a7bac9a3d0400b55" profiles="id-cae440e3ddfb4d20986f23c30a163ca7">
<documentation>Het ondersteunen van de authenticatie van grensoverschrijdende gebruikers.</documentation>
<property key="Beheerorganisatie" value="RVO"/>
<property key="URL" value="https://www.logius.nl/domeinen/toegang/eidas/documentatie"/>
</element>
<element xsi:type="archimate:Product" name="PKIoverheid" id="id-b774a58eb37c469496166f14bd4d1cf3" profiles="id-cae440e3ddfb4d20986f23c30a163ca7">
<documentation>PKI voor de overheid (PKIoverheid), is een afsprakenstelsel voor een veilige gegevensuitwisseling en verbinding tussen overheid, burgers en bedrijfsleven en tussen overheden onderling.</documentation>
<property key="Beheerorganisatie" value="Logius"/>
<property key="URL" value="https://www.logius.nl/domeinen/toegang/pkioverheid"/>
</element>
</folder>
</folder>
<folder name="Application" id="id-d5193e4c1cd54a91a0fdac31884b93b3" type="application">
<folder name="Gewenste situatie" id="id-c430bd08faaf4ff09cf34436557dd161">
<element xsi:type="archimate:ApplicationComponent" name="Dienstencatalogus" id="id-43e810d2d45042ff8bc6192d6b05c2e1" profiles="id-c2173c4b545e4543808dcf704eb7825b">
<documentation>Een voorziening die diensten registreert waartoe entiteiten met een bepaalde identiteit toegang kunnen krijgen en/of een machtiging toe kunnen verstrekken, alsook welke dienstverleners deze diensten verlenen. </documentation>
</element>
<element xsi:type="archimate:ApplicationComponent" name="Inzageregister" id="id-7202f8ec02f644fb805e68388799f37f" profiles="id-c2173c4b545e4543808dcf704eb7825b">
<documentation>Een generieke voorziening die gebruikers in staat stelt om inzage te krijgen in al hun identificatiemiddelen, machtigingen waar ze bij zijn betrokken en de toegang die op basis hiervan is verschaft.</documentation>
</element>
</folder>
<folder name="Huidige situatie" id="id-e6ce5350f95043279eea0d7e12dd80de">
<element xsi:type="archimate:ApplicationComponent" name="BSNk-Transformatie" id="id-01049568026845549513722ef5e8079b" profiles="id-bab9074d446642cd95786422c8deba50">
<documentation>Een voorziening die een geactiveerde polymorfe identiteit (PI) en polymorf pseudoniem (PP) vertaalt naar een versleutelde identiteit (VI) en versleuteld pseudoniem (VP).</documentation>
<property key="Beheerorganisatie" value="Logius"/>
<property key="URL" value="https://www.logius.nl/domeinen/toegang/bsnk-pp"/>
</element>
<element xsi:type="archimate:ApplicationComponent" name="BRP koppelpunt" id="id-0298e208c5304d6cb188fa4ae8c25a1d" profiles="id-bab9074d446642cd95786422c8deba50">
<documentation>Een voorziening die zorgt voor het vaststellen of een burger die met een buitenlands middel inlogt al in de BRP bekend is. Het BRP koppelpunt is een departementsverantwoordelijkheid van het ministerie van BZK. Het BRP koppelpunt geeft invulling aan de BZK verantwoordelijkheid voor registratie van natuurlijke personen. Het BRP koppelpunt registreert de koppeling tussen de uniqueness id en het BSN.</documentation>
<property key="Beheerorganisatie" value="RvIG"/>
</element>
<element xsi:type="archimate:ApplicationComponent" name="BRP" id="id-06be8dd9e8c645d6bb482b05c9185e03" profiles="id-bab9074d446642cd95786422c8deba50">
<documentation>De Landelijke Voorzienig van de Basisregistratie Personen (BRP) bevat persoonsgegevens van inwoners van Nederland (ingezetenen) en van personen die Nederland hebben verlaten (niet-ingezetenen).</documentation>
<property key="exclude"/>
</element>
<element xsi:type="archimate:ApplicationComponent" name="Handelsregister" id="id-15f0c458430247b1a8a349cda72a5848" profiles="id-bab9074d446642cd95786422c8deba50">
<documentation>Het Handelsregister van de Kamer van Koophandel waarin alle rechtspersonen en ondernemingen in Nederland zijn geregistreerd.</documentation>
<property key="exclude"/>
</element>
<element xsi:type="archimate:ApplicationComponent" name="DigiD dienstencatalogus" id="id-1c827b9387274ffe83285328a7e60046" profiles="id-bab9074d446642cd95786422c8deba50">
<documentation>Een registratie van de diensten voor DigiD en DigiD machtigen.</documentation>
<property key="Beheerorganisatie" value="Logius"/>
<property key="URL" value="https://www.digid.nl/aanvragen-en-activeren/machtigen"/>
</element>
<element xsi:type="archimate:ApplicationComponent" name="Centrale OIN Raadpleegvoorziening" id="id-2b79a5d9125346ee970a03e2f88c0fda" profiles="id-bab9074d446642cd95786422c8deba50">
<documentation>De Centrale OIN Raadpleegvoorziening (COR) is de voorziening die de uitgegeven openbare Organisatie-identificatienummers (OIN) beheert. </documentation>
<property key="Beheerorganisatie" value="Logius"/>
<property key="URL" value="https://www.logius.nl/domeinen/toegang/centrale-oin-raadpleegvoorziening"/>
</element>
<element xsi:type="archimate:ApplicationComponent" name="PROBAS" id="id-2c07431cc7424fb48ec82c197cb2aa5f" profiles="id-bab9074d446642cd95786422c8deba50">
<documentation>De protocollaire basisadministratie die gegevens beheert over ambassades.</documentation>
<property key="Beheerorganisatie" value="Belastingdienst"/>
</element>
<element xsi:type="archimate:ApplicationComponent" name="Register wettelijke vertegenwoordiging rechtspraak" id="id-420875d965504da3935e02241a65c925" profiles="id-bab9074d446642cd95786422c8deba50">
<documentation>Het wettelijk vertegenwoordigingsregister van de Raad voor de Rechtspraak.</documentation>
</element>
<element xsi:type="archimate:ApplicationComponent" name="Bevoegdheidsverklaringsdienst" id="id-4e14f612fda64d97ad15c9e7e10fe7d3" profiles="id-bab9074d446642cd95786422c8deba50">
<documentation>Een voorziening die bevoegdheidsverklaringen opstelt voor een reeds geauthenticeerde identiteit op basis van gezagsverklaringen en bewindsverklaringen.</documentation>
<property key="Beheerorganisatie" value="Logius"/>
<property key="URL" value="https://www.logius.nl/diensten/digid/hoe-werkt-de-bevoegdheidsverklaringsdienst"/>
</element>
<element xsi:type="archimate:ApplicationComponent" name="Dienstencatalogus wettelijk vertegenwoordigen" id="id-4f74f314b75c46acb11bf9987f66fae2" profiles="id-bab9074d446642cd95786422c8deba50">
<documentation>Een registratie van de diensten waarvoor belanghebbenden zich kunnen laten vertegenwoordigen door een wettelijk vertegenwoordiger.</documentation>
<property key="Beheerorganisatie" value="Logius"/>
<property key="URL" value="https://www.logius.nl/diensten/digid/hoe-werkt-de-bevoegdheidsverklaringsdienst"/>
</element>
<element xsi:type="archimate:ApplicationComponent" name="Bewind" id="id-53323e6bf2be41b1a4d9a4571262a74c" profiles="id-bab9074d446642cd95786422c8deba50">
<documentation>Een voorziening die de bewindsrelatie (bewindvoering, curatele, mentorschap) voor professionele en particuliere vertegenwoordigers bepaalt op basis van actuele gegevens in het wettelijk vertegenwoordigingsregister van de Raad voor de Rechtspraak en hiervoor bewindsverklaring opstelt.</documentation>
<property key="Beheerorganisatie" value="Logius"/>
<property key="URL" value="https://www.logius.nl/diensten/digid/hoe-werkt-de-bevoegdheidsverklaringsdienst"/>
</element>
<element xsi:type="archimate:ApplicationComponent" name="BSNk-Sleutelbeheer" id="id-5730a811d02540318bd5939dbf387d8a" profiles="id-bab9074d446642cd95786422c8deba50">
<documentation>Een voorziening die de sleutels beheert en verstrekt die gebruikt kunnen worden om een versleutelde identiteit (VI) en versleuteld pseudoniem (VP) terug te vertalen naar een polymorfe identiteit (PI) en polymorf pseudoniem (PP).</documentation>
<property key="Beheerorganisatie" value="Logius"/>
<property key="URL" value="https://www.logius.nl/domeinen/toegang/bsnk-pp"/>
</element>
<element xsi:type="archimate:ApplicationComponent" name="Gezag" id="id-650355fdbfa444e68ba4c49d13eb3613" profiles="id-bab9074d446642cd95786422c8deba50">
<documentation>Een voorziening die ouderlijk gezag bepaalt op basis van de actuele gegevens in de BRP en hiervoor een gezagsverklaring opstelt.</documentation>
<property key="Beheerorganisatie" value="Logius"/>
<property key="URL" value="https://www.logius.nl/diensten/digid/hoe-werkt-de-bevoegdheidsverklaringsdienst"/>
</element>
<element xsi:type="archimate:ApplicationComponent" name="DigiD machtigen" id="id-67a39e2cf1274f5c9340308f07a77152" profiles="id-bab9074d446642cd95786422c8deba50">
<documentation>Een voorziening voor het verstrekken van vrijwilige machtigingen die gebruikt kunnen worden als onderdeel van DigiD.</documentation>
<property key="Beheerorganisatie" value="Logius"/>
<property key="URL" value="https://www.digid.nl/aanvragen-en-activeren/machtigen"/>
</element>
<element xsi:type="archimate:ApplicationComponent" name="eHerkenning machtigingsregister" id="id-796d8d20bc8947d29a2838fdb0886cfe" profiles="id-bab9074d446642cd95786422c8deba50">
<documentation>Een rol binnen het eHerkenning stelsel die de verantwoordelijkheid heeft voor het registreren, beheren, controleren van machtigingen en andere bevoegdheden en het afleggen van verklaringen over bevoegdheden.</documentation>
<property key="Beheerorganisatie" value="Logius"/>
<property key="URL" value="https://afsprakenstelsel.etoegang.nl/"/>
</element>
<element xsi:type="archimate:ApplicationComponent" name="Autorisatielijst BSN-gerechtigden" id="id-7a16034297c64f98ac840c5d6897d749" profiles="id-bab9074d446642cd95786422c8deba50">
<documentation>Op de Autorisatielijst BSN-gerechtigden (ALB) staan de organisaties waarvan RvIG heeft vastgesteld dat ze voor hun publieke taken het burgerservicenummer (BSN) mogen gebruiken.</documentation>
<property key="Beheerorganisatie" value="RvIG"/>
<property key="URL" value="https://www.rvig.nl/autorisatielijst-bsn-gerechtigden"/>
</element>
<element xsi:type="archimate:ApplicationComponent" name="eIDAS koppelpunt" id="id-8263de75e16b4b5189e83635d262aca6" profiles="id-bab9074d446642cd95786422c8deba50">
<documentation>Het Nederlandse eIDAS Koppelpunt faciliteert de interoperabiliteit tussen het Nederlandse stelsel Toegang en de buitenlandse eIDAS koppelpunten. eIDAS koppelpunt houdt een registratie bij van de handelende personen en registreert per persoon de PP/PI.</documentation>
<property key="Beheerorganisatie" value="RVO"/>
<property key="URL" value="https://www.logius.nl/domeinen/toegang/eidas/documentatie"/>
</element>
<element xsi:type="archimate:ApplicationComponent" name="eHerkenning makelaar" id="id-92b61d714b7f4ed6a2ffed3d71bc34be" profiles="id-bab9074d446642cd95786422c8deba50">
<documentation>Een rol binnen het eHerkenning stelsel die het single point of contact vormt waarlangs dienstverleners eHerkenningsdiensten afnemen, die het berichtenverkeer van en naar de dienstverleners ontkoppelt van de interne berichten binnen het netwerk en die optreedt als routeerder naar alle deelnemende authenticatiediensten en machtigingenregisters.</documentation>
<property key="Beheerorganisatie" value="Logius"/>
<property key="URL" value="https://afsprakenstelsel.etoegang.nl/"/>
</element>
<element xsi:type="archimate:ApplicationComponent" name="eHerkenning authenticatiedienst" id="id-93a1371d1b704ef9b0d88e433f3ab319" profiles="id-bab9074d446642cd95786422c8deba50">
<documentation>Een rol binnen het eHerkenning stelsel die de verantwoordelijkheid heeft voor het authenticeren van entiteiten of hun vertegenwoordigers. </documentation>
<property key="Beheerorganisatie" value="Logius"/>
<property key="URL" value="https://afsprakenstelsel.etoegang.nl/"/>
</element>
<element xsi:type="archimate:ApplicationComponent" name="eHerkenning stelsel metadata" id="id-a59ea169cbdf49d8bcc1cf14a6eee959" profiles="id-bab9074d446642cd95786422c8deba50">
<documentation>De registratie van gegevens over verklarende partijen.</documentation>
<property key="Beheerorganisatie" value="Logius"/>
<property key="URL" value="https://afsprakenstelsel.etoegang.nl/"/>
</element>
<element xsi:type="archimate:ApplicationComponent" name="DigiD" id="id-a999c3ee595a4b95b7260d9689934bcc" profiles="id-bab9074d446642cd95786422c8deba50">
<documentation>Een authenticatiedienst gericht op burgers.</documentation>
<property key="Beheerorganisatie" value="Logius"/>
<property key="URL" value="https://www.digid.nl/"/>
</element>
<element xsi:type="archimate:ApplicationComponent" name="Webportaal" id="id-baa0a1a458e54436813047815a6a1ac6" profiles="id-bab9074d446642cd95786422c8deba50">
<documentation>De implemementatie van de dienst zoals deze beschikbaar wordt gesteld door de dienstverlener, inclusief alle achterliggende functionaliteit die daarbij nodig is.</documentation>
<property key="exclude"/>
<property/>