Overleg:Begrippen IAM

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.

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?

Entiteit / Resource of Subject/Object

• Voorstel van John Zwart: Object,
  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.
  Voorbeelden: een computer, telefoon, een app op een smartphone, OS, applicatie of een digitale deurbel met camera functie
  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?

Samenhang identiteiten

• Gedachte van Harro Kremer: Ik zie in de praktijk ketens ontstaan van identiteiten die van elkaar afhangen, bijv. voor een medewerker
  -Digitale Identiteit als nederlandsburger (vastgelegd in GBA)
  - Digitale Identiteit op authenticatiemiddel (zoals rijbewijs en paspoort), deze kan met NFC lezer worden ontsloten
  - Digitaal Authenticatiemiddel (zoals DigID)
  - HRM registratie bij een organisatie
  - AD account (één of meer, ontwikkelaars / beheerders hebben vaak meerdere AD accounts)
  - Gebruikersprofielen binnen een applicatie
  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.

Verbeteren omschrijvingen van Machtigingen

Onderstaande teksten komen uit "Visiemachtigingsvraagstuk 20200714 (Louis) en kunnen onze definities verbeteren.

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:

1. 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).
2. 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 .
3. Machtigen is gericht op wie niet voor zijn eigen dienstverlening met de overheid wil, kan en/of mag zorgen.
4. 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).
5. 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.

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
• 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.

• Wil je vanuit deze centrale modellen nu een spade dieper gaan met uitmodelleren? I.e., is het model Binnendijk niet iets te globaal?
  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.
• Toegangsgebruik blijft een lastig lastig begrip. Authenticatiemanagement = Authenticatiemiddelen management.
  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.
• 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 objectdefintiemodel werkt de samenhang uit.
• Toegangsafspraken management kent invulling in de vorm van toegangsafsprakenstelsels.

Nederlandse Overheid Referentie Architectuur.

Een beschrijving van een complex geheel, en van de principes die van toepassing zijn op de ontwikkeling van het geheel en zijn onderdelen.