Stelsel componenten
Hieronder een eerste uitreksel aan de hand van de eerste architectuurworkshop. De resultaten van de vervolg workshops zullen hier verwerkt worden.
Toegang (IAM)[bewerken]
Authenticatie[bewerken]
Onderwerpen waar we ons op richten:
- - organisatietoegang
- - burgertoegang - Waarom? Het ging toch over een federatie van overheidsorganisaties waarvoor je specifiek toegelaten wordt?
- - Mandatering
Toegang waarbij de ene partij toegang verleend aan een andere andere partij om namens de verlener te interacteren met een service.
Technische oplossingen & standaarden
- - OAuth (https://www.forumstandaardisatie.nl/open-standaarden/nl-gov-assurance-profile-oauth-20)
- - WebID - Is dat OpenID Connect?
- - iShare - (speelt mogelijk ook ooit een rol, behalve als we zeker kunnen stellen dat er nooit partijen van buiten mee gaan doen)
Autorisatie[bewerken]
Technische oplossingen:
- - SAML (https://www.forumstandaardisatie.nl/open-standaarden/saml)
- - PKI overheid
Klopt dat? KPI is toch geen autorisatie mechanisme?
Data[bewerken]
Deling[bewerken]
Een basis vormt de GDI uitwisseling.
Classificatie[bewerken]
In overeenstemming met wat in het toekomstbeeld basisregistraties is opgenomen?
Kwaliteit[bewerken]
Dat is min of meer opgenomen in de het toekomstbeeld. Een verder aspect is de aansluiting van sleutels. Daar ben je er niet mee als je alleen zegt dat nummertjes uniek moeten zijn en moeten aansluiten: dan bestaat de kans op overlap. Hier zou het werk van de UOiD werkgroep mogelijk toegepast kunnen/moeten worden (zie het BZk project dat hiervoor gelopen heeft).
Compliance test[bewerken]
Dat vraagt om een mechanisme om gewenste datakwaliteit te beschrijven. Maar dat lijkt er nog niet te zijn, tenminste niet als machine readable standaard. En een tweede element zijn AVG regels (dit is ook het herleidbaarheidsaspect van de mindmap). We komen er waarschijnlijk niet onderuit daar voortdurend op te testen, de risico's zijn te groot. Is er een standaard mechanisme om te testen op de aanwezigheid van persoonsgegevens als namen, adressen en telefoonnummers?
Metadata[bewerken]
De basis voor het beschrijven van data is de DCAT standaard. Deze wordt al veel toegepast. Waar de standaard te kost schiet is het beschrijven van de elementen in een catalogus. Hiervoor maken we gebruik van een extensie van de standaard, de class DataElement (zie https://vocab.belgif.be/ns/authsrc#), waar ofwel een beschrijving van het data element gegeven wordt, of waar een verwijzing opgenomen wordt naar en SKOS concept dat het element beschrijft.
- MIM als standaard
De vraag is of, gegeven de scope van FDS, MIM een relevant onderwerp is. FDS ontsluit datasources, maar beschrijft eigenlijk geen datamodel. Dat betekent ook dat het importeren van modellen uit andere domeinen niet zal plaatsvinden. Wanneer op basis van regelgeving de MIM standaard gehanteerd wordt, moet daarbij altijd de OWL/RDF equivalente classificatie toegevoegd worden, om de interoperabiliteit binnen de Europese registraties te waarborgen.
- Historie
Wanneer historie van data (dus de herkomst van gegevens, zoals door welke gebeurtenis door wie een bepaald nieuw feit opgenomen is, maken we gebruik van het PROV-O vocabulaire.
- Beschrijven van begrippen
Daarvoor gebruiken we de SKOS vocabulaire. Zie https://profielstelselcatalogus.pldn.nl/.
- Semantische data
Dit is sterk afhankelijk van hoe we data willen ontsluiten, en wat we daar als standaard aangegeven. Wat in ieder geval safe lijkt: ontsluiting als semantische data als _optie_ geven (en dan via een TRIG file en/of via een Endpoint).
Gegevensbescherming[bewerken]
PET
API[bewerken]
Genoemd zijn functional / Non-functional en daarbij: peroformance. Dit onderwerp dient verder uitgediept te worden. De DCAT catalogus records geven tekstueel informatie over een API van een bron. De API zelf dient de documentatie over gebruik zelf te leveren.
Poortwachter[bewerken]
Marktmeester[bewerken]
Essentieel voor het kunnen uitvoeren van de marktmeester functie is de vindbaarheid van gegevens. Die wordt via een catalogusfunctie gerealiseerd. Voor de catalogus gebruiken we DCAT en de uitbreiding daarop zoals aangegeven bij Metadata.
Traceerbaarheid[bewerken]
- - AVG logging
- - Tijdreizen - (is dat nog nodig als we van immutable datasets uitgaan? Eea afhankelijk van de discussie die we hierover nog moeten hebben: wat is de data 'inhoud'? alleen Eventsourced data, of ook gewoon losse sets?
Veiligheid[bewerken]
Genoemde aspecten zijn Quantumproof en een zero-trust principe. De vraag is echter wel of _wij_ daar apart iets voor moeten opnemen, of dat we hier er van uit gaan dat 'omgevings' principes dit voldoende regelen.
PDO (persoonlijke data omgeving)[bewerken]
Dit lijkt op het POD idee van SOLID. Maar, gegeven de scope, van Overheidsorganisaties die lid zijn van de Federatie, is dit dan nog wel een onderwerp?
Integratie[bewerken]
Hier wordt veel aandacht gegeven aan orchestratie. Dat is alleen maar relevant als FDS ook informatieproducten produceert van brondata. Als dat niet zo is (en daar lijkt het wel op, want je kan alleen producten leveren als je ook voorzieningen hebt die daar voor zorgen), dan is de vraag wat je generiek kan vastleggen over integratie/orchestratie.
Notificeren / abonneren[bewerken]
Hier speelt bijvoorbeeld event stream processing als integratie mechanisme. Ook dit punt is afhankelijk van de uitkomst van de discussie wat we als data aanbieden.