Overleg:Begrippen IAM: verschil tussen versies

Uit NORA Online
Naar navigatie springen Naar zoeken springen
(Suggesties voor verbetering toegevoegd.)
(gedachtenspinsel)
 
(7 tussenliggende versies door dezelfde gebruiker niet weergegeven)
Regel 1: Regel 1:
111111Deze pagina is voor overleg en opmerkingen/review voor de pagina Begrippen IAM, het object- en gedragsmodel
Deze pagina is voor overleg en opmerkingen/review voor de pagina Begrippen IAM, het object- en gedragsmodel


Uit de eerste reviews zijn de volgende discussiepunten naar voren gekomen waarover nog een knoop moet worden doorgehakt.
Uit de eerste reviews zijn de volgende discussiepunten naar voren gekomen waarover nog een knoop moet worden doorgehakt.
== Losse constateringen ==
# In de bollenplaat ontbreekt een lijntje. Zie de overlegpagina van het plaatje. --[[Gebruiker:Harro Kremer|Harro Kremer]] ([[Overleg gebruiker:Harro Kremer|overleg]]) 28 jan 2021 10:09 (CET)
# In de modellen komt nog onvoldoende naar voren dat resources ook een digitale identiteit hebben en dat die ook gebruikt wordt in het vastleggen van bevoegdheden. --[[Gebruiker:Harro Kremer|Harro Kremer]] ([[Overleg gebruiker:Harro Kremer|overleg]]) 2 feb 2021 11:00 (CET)
# Alleen nederlandse niet-natuurlijke personen staan in het NHR. De zin daarover is heel NL-specifiek. In toenemende mate worden buitenlandse identiteiten steeds relevanter voor de NL overheid; eIDAS2 is een aankomende Europese standaard. --[[Gebruiker:Harro Kremer|Harro Kremer]] ([[Overleg gebruiker:Harro Kremer|overleg]]) 1 aug 2022 15:57 (CEST)
# Ik zit nu en een werkgroep binnen GDI over eIDAS2, Wallet en DBI. Dit (en de uitkomsten van het GO-traject) naar deze begrippenpagina ontbreekt.--[[Gebruiker:Harro Kremer|Harro Kremer]] ([[Overleg gebruiker:Harro Kremer|overleg]]) 1 aug 2022 16:10 (CEST)
== Mailwisseling met André Batenburg <-> Harro Kremer januari 2021) ==
Dan nog enkele opmerkingen bij de begripsdefinities:
AB: Device (Technische component): Een fysiek apparaat, software, of de draaiende geautomatiseerde processen.
<<< Een device zie ik toch meer als apparat en minder als software. Betrek je er ook software bij dan km ik meer op het begrip Systeem uit.
HK: We hebben de beschrijving op Technopedia als uitgangspunt genomen en daarbij onderkent dat vanuit een technisch optiek je niet de toegang aan functies geeft, maar aan processen. Op een device houden we open dat er meerdere processen naast elkaar draaien die elk een eigen authenticatie doen.  Om een Ring Doorbel als systeem te beschouwen voelt persoonlijk ook niet zo goed. Persoonlijk zou ik hem nu formuleren als “Een fysiek apparaat dat een of meer functies vervult en digitaal communiceert met haar omgeving".
AB: Zaak (case, dossier, …): (concept) Aanduiding voor digitale object binnen een dienst waarop bevoegdheden worden vastgelegd.
<<< Zaakgericht werken heeft een breed geaccepteerde definitie hiervoor. Maar zaak is ook een juridisch begrip, en daar heeft het Bwb een gangbare definitie voor. Welke sta je voor? Gebruik dan de gangbare definitie.
HK: Ik heb even wat opgezocht. Als ik dit naast https://www.noraonline.nl/wiki/Zaak leg dan komt ik uit op 2 gerelateerde begrippen (wat er nu staat is onvoldoende helder). Het gebruiken van Zaak als aanduiding voor de fysieke en digitale wereld is niet zo handig.
• Zaak (als iets in de fysieke wereld)
• Zaaksinformatie (als informatieobject)
• De relatie tussen Zaak en Zaaksinformatie wordt daarmee dezelfde als tussen Entiteit en Digitale Identiteit
AB: Bevoegdheid (Toegangsrecht, Autorisatie): Een toestemming van een Entiteit of danwel zelf, danwel als vertegenwoordiger van een belanghebbende, om toegang te krijgen tot een Resource waarbij voorwaarden kunnen worden gedefinieerd op de attributen van de Digitale Identiteit.
<<< De zin is wat moeilijk leesbaar.
HK: De zin moet opgeknipt worden; de schrijfstijl is beroerd. Ik neig naar
: Een toestemming van een Entiteit om toegang te krijgen tot een Resource. Een bevoegdheid kan de Entiteit zelf betreffen of een andere Entiteit betreffen. In het laatste geval spreken we van een vertegenwoordiger en een belanghebbende. Bij een bevoegdheid kunnen voorwaarden gedefinieerd worden op de attributen van de Digitale Identiteit.
AB: Machtiging (Vertegenwoordiging) (concept)Een bevoegdheid van een Entiteit om namens een Andere Identiteit toegang te krijgen tot een resource (en daar handelingen op te verrichten).
<<< Gaat het nu om een vertegenwoordiging van de ene Entiteit door een andere Entiteit? Of om de vertegenwoordiging van de ene Identiteit door een andere Identiteit?
HK: Machtigingen is een onderwerp waar nog veel beweging in zit, dus hebben we daar vrij weinig aandacht aan besteed en hebben we de definities als “concept” gemarkeerd.
: Het kan hier alleen om een relatie gaan tussen Entiteiten. Immers, als wettelijk vertegenwoordiger van mijn kinderen maakt het niet uit welke authenticatiemiddel is gebruik (paspoort, ID kaart); beide bevatten een verschillende identiteit (want de attributenset is niet 100% gelijk).
Een betere formulering zou zijn: Een bevoegdheid in het bezit van een Entiteit (de vertegenwoordiger) om namens een andere Entiteit (de belanghebbende) toegang te krijgen tot een Resource.


== Vergelijking met IDPro ==
== Vergelijking met IDPro ==
Regel 21: Regel 57:
# Bij gedragsmodel authenticatie:<br>A: gevalideerd identiteitsbewijs is iets wat voor de interactie tussen overheid en maatschappij (=NORA scope) een gegeven is. In andere domeinen zou ook een trustless identiteit (bijvoorbeeld een SSI) gebruikt kunnen worden.  
# Bij gedragsmodel authenticatie:<br>A: gevalideerd identiteitsbewijs is iets wat voor de interactie tussen overheid en maatschappij (=NORA scope) een gegeven is. In andere domeinen zou ook een trustless identiteit (bijvoorbeeld een SSI) gebruikt kunnen worden.  
# diagram bevoegdhedenbeheer: A: misschien een korte paragraaf toevoegen over verschil tussen bevoegdheid (en de 3 varianten) en autorisatie nog een keer helder uitleggen. Metafoor: bezoeker in kasteel. Heeft brief met toestemming namens kasteelheer tot binnenhof ( bevoegdheid); schildwacht beslist tot open poort (autorisatie)
# diagram bevoegdhedenbeheer: A: misschien een korte paragraaf toevoegen over verschil tussen bevoegdheid (en de 3 varianten) en autorisatie nog een keer helder uitleggen. Metafoor: bezoeker in kasteel. Heeft brief met toestemming namens kasteelheer tot binnenhof ( bevoegdheid); schildwacht beslist tot open poort (autorisatie)
== Experimenten ==
Hieronder staat een uitvouwbare tekst.
<div class="mw-collapsible mw-collapsed"> '''Details'''
<div class="mw-collapsible-content">Deze tekst zie je alleen als je geklikt hebt op "Details". Het is mogelijk om de link naar links te verplaatsen (vlg "bewerken" bij secties), dit is een configuratie aanpassing die door technisch beheer moet worden uitgevoerd. <!-- meer info op https://www.mediawiki.org/wiki/Manual:Collapsible_elements --> </div>
Hieronder staat een clickabele plaatje. We kunnen daarmee zelf de plaatjes doorklikbaar maken.
<imagemap>
File:IAM afbeedling.png|150px|alt=Alt text
default [[Main Page|Go to main page]]
</imagemap>
==Vereenvoudigen object model ==
* Voorstel van John Zwart: ''het object “Entiteit” leidt tot dubbel opslaan van gegevens en  levert het samenvoegen, mij inziens, geen extra toegevoegde waarde op. Verder heb ik authenicatiemiddel gekoppeld aan de  objecten “Persoon” en “Object” omdat authenicatie van een persoon, anders verloopt, dan authenicatie van een server of een OS (object).''       
* Reactie Harro Kremer: De aanwezigheid van Entiteit is overgenomen uit de ISO 24760.  Een reductie van het huidige model is mogelijk, al zou ik zelf dan eerder “persoon” er tussenuit halen (zodat Entiteit dan 3 specialisaties krijgt) en Niet-natuurlijk persoons hernoemen naar Rechtspersoon.
'''Vraag aan alle reviewers:''' Als we het model zouden vereenvoudigen, wat is dan het model dat we het gemakkelijkst kunnen uitdragen naar al onze afnemers?
Reactie werkgroep: Persoon is verwijderd, vereenvoudigd/bestuurlijk model is toegevoegd.
== Entiteit / Resource of Subject/Object ==
* Voorstel van John Zwart: Object, <br>''Is een fysiek apparaat, software of een daarop draaiend geautomatiseerd proces waarbij een Digitale Identiteit kan behoren en kan zowel een fysieke als digitale vorm hebben. <br>Voorbeelden: een computer, telefoon, een app op een smartphone, OS, applicatie of een digitale deurbel met camera functie <br>Objecten hebben een Digitale Identiteit nodig voor Informatiebeveiligingsfuncties''
'''Vraag aan alle reviewers:''' Welk begrip is het meest intuitief en geeft de minste verwarring? Device, Object, Technische Component?
Reactie werkgroep: uit de discussie bleek een voorkeur voor device, omdat objecten b.v. een gebouw wel een resource kunnen zijn, maar zelf niet zullen aankloppen voor autorisatie. Devices, zeker in de toekomst wel. Geen wijziging  Omschrijving van device is op basis van voorstel iets aangepast.
== Samenhang identiteiten ==
* Gedachte van Harro Kremer: ''Ik zie in de praktijk ketens ontstaan van identiteiten die van elkaar afhangen, bijv. voor een medewerker<br>-Digitale Identiteit als nederlandsburger (vastgelegd in GBA)<br>- Digitale Identiteit op authenticatiemiddel (zoals rijbewijs en paspoort), deze kan met NFC lezer worden ontsloten<br>- Digitaal Authenticatiemiddel (zoals DigID)<br>- HRM registratie bij een organisatie<br>- AD account (één of meer, ontwikkelaars / beheerders hebben vaak meerdere AD accounts)<br>- Gebruikersprofielen binnen een applicatie<br>Omdat binnen de GO pressure cooker ook een onderscheid is gemaakt gaan worden tussen de eerste 3 denk ik dat we hier nog iets moeten toevoegen.''
Reactie werkgroep: Harro maakt een voorstel, is gecirculeerd per mail binnen de werkgroep.
== Verbeteren omschrijvingen van Machtigingen ==
Onderstaande teksten komen uit "Visiemachtigingsvraagstuk 20200714 (Louis) en kunnen onze definities verbeteren.
<i>De overkoepelende term "machtigen" staat hier zowel voor vrijwillig machtigen als wettelijke vertegenwoordiging. Deze term wordt ook in beleidsstukken, wetteksten (Wdo) en programma¬documenten gebruikt. Elders wordt ook wel de term "vertegenwoordiging" gebruikt.
De scope van deze visie is:
#Het gaat om machtigen voor publieke diensten, dat wil zeggen diensten "ter uitoefening van een publieke taak of in het algemeen belang" die worden uitgevoerd door een bestuurs¬orgaan zoals bedoeld in de Awb of andere, in de Wdo aangewezen organisaties (zoals op dit moment o.a. zorg¬instellingen).
# De doelgroep voor machtigen zijn zowel natuurlijke personen als niet-natuurlijke personen: beide kunnen binnen de machtigingsrelatie (in principe) zowel als belanghebbende of gemachtigde optreden .
# Machtigen is gericht op wie niet voor zijn eigen dienstverlening met de overheid wil, kan en/of mag zorgen.
# Er worden twee hoofdvormen van machtigen onderscheiden:
#* vrijwillig machtigen: een burger of organisatie wijst zelf, uit eigen vrije wil, een andere persoon of organisatie aan als gemachtigde (b.v. omdat hij zelf niet digivaardig is of van een belasting¬consulent gebruik wil maken);
#* wettelijke vertegenwoordiging: de wetgever, een rechter of de nabestaanden wijzen een persoon of organisatie aan als gemachtigde voor een burger of organisatie die handelings¬onbekwaam of -onbevoegd is, of die is overleden (b.v. samenhangend met ouderlijk gezag, bewindvoering, curatele of nabestaandenmachtiging: zie bijlage x voor een overzicht).
# Machtiging en authenticatie zijn onderscheiden functies, waarbij o.m. geldt dat een dienst¬aanbieder een machtiging weliswaar moet accepteren, maar uiteindelijk zelf verantwoordelijk blijft om de gemachtigde al dan niet toegang te verlenen.
</i>
Reactie werkgroep: Deze wijziging wordt doorgevoerd nadat duidelijkheid is over de status van de opbrengsten van de pressure cooker. Marijke laat dit Harro weten per 16 september.
== Opmerkingen uit afstemming met Edwin Strijland ==
* Centraal begrip "Toegang" is goed begrip, maar ontbeert nog een zelfstandige omschrijving
Vanuit focus op "het gebruik" gaat het om de attributen van de entiteit en is er minder behoefte aan een tussenniveau als persoon. Identiteiten samenhang komt nog weinig aan bod. Dat komt meer bij de uitwerkende pagina's aan bod (bijvoorbeeld identiteiten keten
Reactie werkgroep: Harro komt met een voorstel.
* Vanuit pagina Anne/Harro zouden we de technische kant verder kunnen uitwerken in termen van bijv. patroon voor federatie van identiteiten
Over het model dat afkomstig is vanuit Ben Binnendijk. Model is een heel krachtig model dat top-level best simpel is. Doel is startpunt voor in archimate uitgewerkte modellen. Dit model vormt handvat voor verduidelijken / systematiseren van de bollenplaten.
Reactie werkgroep: De relatie wordt gelegd tussen de bollenplaat en de gedragsmodellen.
* Wil je vanuit deze centrale modellen nu een spade dieper gaan met uitmodelleren? I.e., is het model Binnendijk niet iets te globaal?
Resultaat bespreking werkgroep: Op dit moment wordt dit niet verder uitgewerkt <br>Gaat over over ambitie binnen de NORA IAM werkgroep om bijv. "authenticatiemanagement' op te delen in "standaard" functies in plaats van dat alle organisaties hun eigen opdelen maken. Waar houdt de scope van "referentie architectuur" op. Resultaat bespreking werkgroep: Dit is een referentie architectuur gaat niet verder.
Reactie werkgroep: Na enige discussie is besloten dat vanwege het karakter van een referentie architectuur deze pagina niet verder wordt uitgediept.
* Toegangsgebruik blijft een lastig lastig begrip. Authenticatiemanagement = Authenticatiemiddelen management. <br>Waar plaats je de verrijkingsfunctie (advocatenpas casus Justid)? Dit is meer een identiteiten functie dan authenticatiefunctie. NB: Bij Intune zie je dat resource-identiteiten niet meer in AD opneemt maar in een Intune identiteit.
Resultaat bespreking werkgroep: Harro maakt voorstel. Deze is reeds opgenomen op de pagina.
* geolocatie en time zijn typisch aspecten voor toegangsgebruik (en niet identiteiten). ABAC is toegangsgebruik.
* De meeste begrippen van het model hebben we al. middenkolom: authenticatiemiddelenbeheer hebben we al, op gebruiksniveau heb je het middel zelf (!!) en het authenticeren (als proces). Hoe zit het dan met de "runtime" factoren op de rechter kolom in gebruikslaag?
* Model moet als eerste op de pagina komen met daaronder de kerndefinities, het objectdefinitiemodel werkt de samenhang uit.
* Toegangsafspraken management kent invulling in de vorm van toegangsafsprakenstelsels.
Reactie werkgroep op de afbeelding na discussie: deze is een mooie toevoeging, en zal gepubliceerd worden, maar wordt niet de nieuwe kapstok.
[[Afbeelding:vereenvoudigde_plaat.jpg|thumb|none|750px|Voorstel vereenvoudigd model|alt=”Voorstel vereenvoudigd model Edwin”]]
===toelichting===
<br>Voor de begrippen kan het gebruiken van een dergelijk model impact hebben:
* Het woord ‘toegang’ staat centraal en behoeft meer verduidelijking in begrippen.
* De individuele services / nuances verdienen een eigen verduidelijking.
* Het creëert onderscheid op niveau van beheersing/besturing, beheer en uitvoering/gebruik.
Hiernaast zorgt een dergelijk model voor categorisering en een hiërarchie van begrippen als je dit model gaat gebruiken als paraplu naar een model met subservices, informatieobjecten en actoren waarvoor je (vanzelfsprekend) andere archimate objecten en relaties gaat gebruiken.
Voor het modelleren van voorbeeld patronen (bijvoorbeeld: burger, medewerker, identiteiten federatie, identiteiten en/of toegegansprovisionin, machtigingen etc) lijkt het me wel noodzakelijk om één uitwerkingsniveau dieper te gaan en subservices toe te voegen voor herkenbare subservices. Ik denk hier aan subservices voor (niet uitputtend en let nog niet op taalgebruik): provisioning, federaties, identity stores, access control varianten/services (RBAC, ABAC, DBAC, etc), attestatie, multi-factor, etc etc.
Ik heb hier zelf al een poging gedaan en hier (op dit moment) wel geconstateerd dat het, door de grote diversiteit in subservices, een uitdaging is om dezelfde mate van eenduidigheid/consistentie aan te brengen in taal, maar ben er zelf van overtuigd dat dit ons gaat helpen om de informatieobjecten in de eerder in de mail verstpreide modellen te gaan gebruiken (en vertalen naar andere lagen) in patroonuitwerkingen.
<br>
Reactie werkgroep: Nadere uitwerking van Toegang als belangrijkste punt volgt door middel van voorstel Harro. HKr: Deze heb ik op genomen in de sectie context.
= opmerkingen René =
<br>Er worden veel termen gebruikt die overlappend zijn.  Bij voorkeur een keuze maken en synoniemen benoemen.
* Toegangsbeheer
* Bevoegdhedenbeheer
* Autorisatiemanagement
* Accessmanagement
Waar mogelijk een duidelijk onderscheid maken tussen:
* het beheren van de identiteiten, rechten etc.
* het daadwerkelijk controleren en verlenen van identiteiten, rechten etc.
Wellicht is te hanteren:
* Identity management
* Authenticatie (controle van de identiteit)
* Accessmanagement (synoniemen: toegangsbeheer, bevoegdhedenbeheer, autorisatiemanagement)
* Autorisatie (controleren en verlenen toegang)
===Verder=== 
Binnen het Rijk wordt er ook nog onderscheid gemaakt tussen personeelsbeheer en Identitymanagement
Personeelsbeheer
* Organisatiestructuur
* Functies
* Persoon
* Etc.
===Identity management===
* Identiteit
* Etc.
===Autorisatiemanagement===
* Voorzieningen (ICT-voorzieningen en overige voorzieningen)
* Rollen
* Etc.
<br>
Reactie werkgroep: De begrippen worden in samenhang verbeterd, voorstel Harro. In lijn met het voorstel van de SVB.
=opmerking Marijke=
<br> Vraag: Hierboven wordt het onderscheid van beheer en gebruik gemaakt, is daarbij het onderscheid tussen onboarding en gebruik ook nog relevant, of hoort onboarding bij beheer?
<br>
Reactie werkgroep: Geen actie is voldoende verwerkt
=opmerkingen Eric=
1. Vanuit GO / pressure coocker is een Excel-overzicht van Rob Post (RvIG) verkregen met IAM-begrippen met daarbij ook de bronnen van de definities.
Harro heeft dat overzicht helemaal doorlopen en verwerkt.
Maar kan in ons overzicht dan aub ook per begrip de bron worden vermeld?
En als er meer bronnen waren met verschillende omschrijvingen, kan dan aub worden aangeven hoe wij zijn omgegaan met die verschillen?
Als we dat doen zal dit overzicht enorm aan kracht winnen: het wordt voor lezers dan duidelijk dat we uitgaan van de bestaande wettelijke bronnen, eventuele strijdigheden toelichten en soms aanvullingen doen ter verduidelijking.
NB. Ook bij de stukken die BZK nu aan het opmaken is voor Digitale Bron Identiteiten speelt dit vraagstuk van definities weer een rol.
Ik heb er daarom voor gezorgd dat er vanuit DBI een linkje is opgenomen naar deze NORA pagina met Begrippen IAM :-)
2. De relatie tussen het gedragsmodel en de uitwerking van het kader IAM is te verbeteren door het kader over het gedragsmodel te plotten en doorklikbaar te maken.
Werkgroepreactie: Als we dat willen, dan kan ik NORA Beheer vragen om dat op te pakken.
== Nakomer Harro ==
Esther Mackaay heeft begin dit jaar een presentatie gegeven. Daar kan misschien ook nog informatie uit worden gehaald.
== Korte reactie Wim ==
Ik zie dat het begrip autoriseren nog tweeledig wordt gebruikt: zowel voor het vastleggen van een bevoegdheid (zie begrippen) als voor het vaststellen van een bevoegdheid in toegangsverlening (zie objectmodel).
Reactie werkgroep: Deze opmerking wordt verwerkt in de uitwerking van autoriseren/autorisatie. <br>HKR: teksten zijn nagelopen, komt alleen binnen een synoniem voor.
== Nakomer Eric UWV==
De excel met begrippen IAM, zoals gebruikt bij de GO zullen ook verwerkt moeten zijn in de begrippen bij IAM.
Reactie werkgroep: Deze begrippen staan onderaan de pagina en moeten opgeschoond worden en gerelateerd worden aan de platen. Actie Frans en Marijke
== Nakomer Eric NORA==
Dit gaat uit van een verplichte opdeling in rollen en ID’s.
Maar wat als die persoon dat NIET wil, en 1 ID voor al die domeinen wil gebruiken?
Mag en kan dat dan ook?
Reactie werkgroep (Harro):  Dat is afhankelijk van de situatie. Aspecten die meespelen
- Soms moeten mensen tegen zichzelf beschermd worden en moet uitgelegd kunnen worden waarom dat NIET verstandig is
- Of het mag wordt vooral door wet- en regelgeving bepaald. Denk bijv. aan het BSN.


== Nakomer Frans ==
De opmerkingen ten tijde van de initiele totstandkoming van de pagina zijn na te lezen in]
Met een XACML plaat illustreert Frans het veld. Daarbij geeft hij aan dat duidelijk moet zijn dat de verantwoordelijkheid voor toegang altijd bij de aanbieder ligt
[https://www.noraonline.nl/index.php?title=Overleg:Begrippen_IAM&oldid=45449 de geschiedenis van deze overlegpagina]
Reactie werkgroep: In de voorstel voor het uitwerken van het begrip Autorisatie/Autoriseren zal Harro deze kennis meenemen en de verantwoordelijkheid duidelijk accentueren.

Huidige versie van 1 aug 2022 om 16:10

Deze pagina is voor overleg en opmerkingen/review voor de pagina Begrippen IAM, het object- en gedragsmodel

Uit de eerste reviews zijn de volgende discussiepunten naar voren gekomen waarover nog een knoop moet worden doorgehakt.

Losse constateringen[bewerken]

  1. In de bollenplaat ontbreekt een lijntje. Zie de overlegpagina van het plaatje. --Harro Kremer (overleg) 28 jan 2021 10:09 (CET)
  2. In de modellen komt nog onvoldoende naar voren dat resources ook een digitale identiteit hebben en dat die ook gebruikt wordt in het vastleggen van bevoegdheden. --Harro Kremer (overleg) 2 feb 2021 11:00 (CET)
  3. Alleen nederlandse niet-natuurlijke personen staan in het NHR. De zin daarover is heel NL-specifiek. In toenemende mate worden buitenlandse identiteiten steeds relevanter voor de NL overheid; eIDAS2 is een aankomende Europese standaard. --Harro Kremer (overleg) 1 aug 2022 15:57 (CEST)
  4. Ik zit nu en een werkgroep binnen GDI over eIDAS2, Wallet en DBI. Dit (en de uitkomsten van het GO-traject) naar deze begrippenpagina ontbreekt.--Harro Kremer (overleg) 1 aug 2022 16:10 (CEST)

Mailwisseling met André Batenburg <-> Harro Kremer januari 2021)[bewerken]

Dan nog enkele opmerkingen bij de begripsdefinities:

AB: Device (Technische component): Een fysiek apparaat, software, of de draaiende geautomatiseerde processen. <<< Een device zie ik toch meer als apparat en minder als software. Betrek je er ook software bij dan km ik meer op het begrip Systeem uit.

HK: We hebben de beschrijving op Technopedia als uitgangspunt genomen en daarbij onderkent dat vanuit een technisch optiek je niet de toegang aan functies geeft, maar aan processen. Op een device houden we open dat er meerdere processen naast elkaar draaien die elk een eigen authenticatie doen. Om een Ring Doorbel als systeem te beschouwen voelt persoonlijk ook niet zo goed. Persoonlijk zou ik hem nu formuleren als “Een fysiek apparaat dat een of meer functies vervult en digitaal communiceert met haar omgeving".

AB: Zaak (case, dossier, …): (concept) Aanduiding voor digitale object binnen een dienst waarop bevoegdheden worden vastgelegd. <<< Zaakgericht werken heeft een breed geaccepteerde definitie hiervoor. Maar zaak is ook een juridisch begrip, en daar heeft het Bwb een gangbare definitie voor. Welke sta je voor? Gebruik dan de gangbare definitie.

HK: Ik heb even wat opgezocht. Als ik dit naast https://www.noraonline.nl/wiki/Zaak leg dan komt ik uit op 2 gerelateerde begrippen (wat er nu staat is onvoldoende helder). Het gebruiken van Zaak als aanduiding voor de fysieke en digitale wereld is niet zo handig. • Zaak (als iets in de fysieke wereld) • Zaaksinformatie (als informatieobject) • De relatie tussen Zaak en Zaaksinformatie wordt daarmee dezelfde als tussen Entiteit en Digitale Identiteit

AB: Bevoegdheid (Toegangsrecht, Autorisatie): Een toestemming van een Entiteit of danwel zelf, danwel als vertegenwoordiger van een belanghebbende, om toegang te krijgen tot een Resource waarbij voorwaarden kunnen worden gedefinieerd op de attributen van de Digitale Identiteit. <<< De zin is wat moeilijk leesbaar.

HK: De zin moet opgeknipt worden; de schrijfstijl is beroerd. Ik neig naar

Een toestemming van een Entiteit om toegang te krijgen tot een Resource. Een bevoegdheid kan de Entiteit zelf betreffen of een andere Entiteit betreffen. In het laatste geval spreken we van een vertegenwoordiger en een belanghebbende. Bij een bevoegdheid kunnen voorwaarden gedefinieerd worden op de attributen van de Digitale Identiteit.

AB: Machtiging (Vertegenwoordiging) (concept)Een bevoegdheid van een Entiteit om namens een Andere Identiteit toegang te krijgen tot een resource (en daar handelingen op te verrichten). <<< Gaat het nu om een vertegenwoordiging van de ene Entiteit door een andere Entiteit? Of om de vertegenwoordiging van de ene Identiteit door een andere Identiteit?

HK: Machtigingen is een onderwerp waar nog veel beweging in zit, dus hebben we daar vrij weinig aandacht aan besteed en hebben we de definities als “concept” gemarkeerd.

Het kan hier alleen om een relatie gaan tussen Entiteiten. Immers, als wettelijk vertegenwoordiger van mijn kinderen maakt het niet uit welke authenticatiemiddel is gebruik (paspoort, ID kaart); beide bevatten een verschillende identiteit (want de attributenset is niet 100% gelijk).

Een betere formulering zou zijn: Een bevoegdheid in het bezit van een Entiteit (de vertegenwoordiger) om namens een andere Entiteit (de belanghebbende) toegang te krijgen tot een Resource.


Vergelijking met IDPro[bewerken]

Via Andre Koot de lijst met definities van IDPro [1] gekregen Inhoudelijke vergelijking met onze begrippen levert de volgende kleine verbetermogelijkheden op:

  1. Een dienst is ook een vorm van identiteit
  2. fys.ruimte ontbreekt in het object diagram.
  3. Kandidaten om later toe te voegen:
    1. IAM Governance gerelateerde begrippen toevoegen
    2. Single Sign On
    3. Self Sovereign Identity
    4. Step up authentication

Uit de bespreking op 30 september[bewerken]

Tijdens de bespreking op 30 september zijn een aantal vragen gesteld en mondeling toegelicht. Hieronder een beknopte vastlegging ervan. Nader te bepalen of deze tot kleine correcties op de pagina leiden.

  1. Bij diagram "entiteiten relatie"(onder gedragsmodel Identiteiten)
    Q: Was is verschil tussen identiteit midden en rechts
    A: de relatie tussen beide 111.+

0vvvvvvvvvvvvvvvvvvvvvcwordt niet in het model weergegeven. De identiteit rechts ontstaat uit de functie Identiteiten Informatie die de linkeridentiteit als input heeft. Dit impliceert dat de rechter identiteit alleen een subset is van de linker identiteit.

  1. Algemeen
    Q: Het gebruik van Functie versus dienst
    A: Dit is een eerste aanzet op te denken in functies in plaats van diensten. Functie is hier veel generieker, lijkt eerder op het TOGAF begrip Capability dan functie zoals we dat binnen ontwerpen gebruiken.
  2. Bij Gedragmodel identiteiten:
    Q: ontstaat hier een kopie?
    A: er ontstaan een nieuw logisch informatieobject. Hoe deze technisch ontsloten wordt (als kopie of als toegangsrecht) is een implementatie aspect.
  3. Bij gedragsmodel authenticatie:
    A: gevalideerd identiteitsbewijs is iets wat voor de interactie tussen overheid en maatschappij (=NORA scope) een gegeven is. In andere domeinen zou ook een trustless identiteit (bijvoorbeeld een SSI) gebruikt kunnen worden.
  4. diagram bevoegdhedenbeheer: A: misschien een korte paragraaf toevoegen over verschil tussen bevoegdheid (en de 3 varianten) en autorisatie nog een keer helder uitleggen. Metafoor: bezoeker in kasteel. Heeft brief met toestemming namens kasteelheer tot binnenhof ( bevoegdheid); schildwacht beslist tot open poort (autorisatie)

De opmerkingen ten tijde van de initiele totstandkoming van de pagina zijn na te lezen in] de geschiedenis van deze overlegpagina