Op deze pagina kun je het totaaloverzicht vinden van alle kennis die we hebben ontwikkeld. Deze kennis is volop in ontwikkeling, dit betekent dat het dus nog niet af is. Daar hebben we jullie voor nodig!
Deze omgeving is speciaal ingericht om content met elkaar aan te passen en te vormen op basis van de laatste ontwikkelingen, als team federatief datastelsel hebben we daarom een 0.1 versie ontwikkeld die we vervolgens op verschillende manieren met jullie willen aanvullen en verscherpen. Deze documenten kennen daarmee nog geen formele status. Mocht dit wel al het geval zijn dan kunnen jullie dit op de pagina zelf ook zien.
Kortom, lees je iets waar je op wilt reageren of aan wilt bijdragen? Onder welkom vind je meer info over contributies aanleveren. Benieuwd waarom we hiervoor hebben gekozen? Lees hier de toelichting over deze werkomgeving.
1 - Capabilities
De capabilities (bekwaamheden) van het federatief datastelsel met relaties (verwijzingen) naar de bouwblokken die voor de realisatie nodig zijn
Een bekwaamheid, vaak aangeduid met de Engelse term ‘capability’, is een vermogen dat iets (bijv.
een systeem) in staat stelt om bepaalde doelstellingen te realiseren. Voor het realiseren van de
doelstellingen van het Federatief Datastelsel, zijn bepaalde bekwaamheden nodig bij de deelnemers in
het stelsel en er zijn algemene bekwaamheden die het stelsel als geheel laten functioneren. In deze
uitwerking ligt de focus bij het laatstgenoemde. De bekwaamheden die een individuele deelnemer nodig
heeft om effectief deel te kunnen nemen beschouwen we als voorwaarden die FDS stelt aan deelname.
Het stellen van die voorwaarden is dan weer een bekwaamheid van het stelsel. FDS benoemt vier basis
bekwaamheden. Deze vormen de kapstok voor het dieper uitwerken naar detailniveaus. Deze bekwaamheden
zijn afgeleid uit het OPEN DEI raamwerk, zoals beschreven in paragraaf 2.3. FDS onderscheidt de
volgende vier basis bekwaamheden:
Stelsel-governance: Het vermogen van het stelsel om gedragingen en activiteiten van de deelnemende
partijen te laten conformeren aan de geldende stelselafspraken.
Interoperabiliteit: Het vermogen van het stelsel om de deelnemende partijen data met elkaar te
laten delen en/of uit te wisselen.
Vertrouwen: Het vermogen van het stelsel om vertrouwen te genereren voor verantwoord gebruik van
data door de deelnemende partijen.
Data waarde: Het vermogen van het stelsel om data zichtbaar van waarde te laten zijn voor de
deelnemende partijen.
Elke hoofdbekwaamheid is verder onderverdeeld in deel-bekwaamheden. Hiervoor gebruiken we het model
dat we kort hebben toegelicht bij de beschrijving van de relatie met de Europese
datastrategie. Het model is
weergegeven in figuur 3.
Klik op de betreffende capability om te lezen waar deze over gaat, welke componenten,
afhankelijkheden en relaties deze heeft.
Bestuurlijke overeenkomsten en juridische constructen.
Alle deelnemers aan het federatief datastelsel of een dataspace moeten het eens zijn over bepaalde
functionele, technische, operationele en juridische aspecten. Hoewel sommige overeenkomsten op een
generieke of sectorspecifieke manier herbruikbaar zijn (bijv. Regelboeken), zijn anderen
gebruiksspecifiek.
Bouwblokken
[…]
1.1.2 - Operationeel
Governance | Operationeel: Operationele overeenkomsten en afspraken
Operationele overeenkomsten reguleren beleid dat wordt afgedwongen in de
operatie. Ze reguleren bijvoorbeeld de beschikbaarheid in een
dienstniveau-overeenkomst (DNO, ook wel servicelevelagreement of SLA,
zie in dit kader ook de handreiking servicekwaliteit.)
of bevatten voorwaarden als gevolg van de
AVG/GDPR
of de
Payment Services Directive 2 (PSD2).
Daarbij ondersteunen operationele processen van het FDS de dagelijkse werking, zoals
het aansluiten op aanbod of het melden van een storing.
Processen voor het inbrengen van datasets als aanbod (nog uit te werken)
Processen voor het transparant rapporteren van gebruik (nog uit te werken)
In Deelnemen aan het FDS wordt het deelnameproces om als
aanbieder deel te nemen toegelicht (inclusief het inbrengen van aanbod).
Standaarden
Er zijn geen aangewezen standaarden voor operationele processen. Een aantal best-practices om richting te geven aan
de inrichting van operationele processen is gebundeld in
ITIL.
1.1.3 - Beheer
Governance | Beheer: Continuïteit en doorontwikkeling van het stelsel
Continuïteit en doorontwikkeling van het stelsel … Regie van het stelsel, etc, etc
Het continuïteitsmodel beschrijft de processen voor het beheer van wijzigingen, versies en releases
voor normen en overeenkomsten. Dit omvat ook het bestuursorgaan voor besluitvorming en
conflictoplossing.
Elke deelnemer aan het stelsel kan deelnemen aan de beheer processen van het stelsel.
Beheer processen binnen het FDS
Binnen het FDS onderkennen we de volgende groepen beheer processen:
Processen voor het inbrengen van data-spaces / sub-stelsels (nog uit te werken)
Processen voor het inbrengen en tijdig oplossen van geschillen (nog uit te werken)
Processen voor het beheer van stelsel veranderingen (nog uit te werken)
Bouwblokken
[…]
1.2 - Interoperabiliteit
Gegevensinteroperabiliteit, met betrekking tot aspecten zoals gegevensuitwisseling API’s, formaten voor gegevensrepresentatie, evenals herkomst en traceerbaarheid
Data delen binnen FDS wordt mogelijk gemaakt door dat we afspraken vastleggen over hoe we data
beschrijven en hoe we data kunnen bereiken. Verder kunnen we de herkomst en het gebruik van data
inzichtelijk maken. We maken daarbij gebruik van gangbare standaarden, waarop we soms een specifiek
FDS profiel ontwikkelen. Dat laatste vormt het hart van de FDS-specifieke capability ‘ontwikkelen en
beheren meta-data standaarden’.
1.2.1 - Modellen
Interoperabiliteit | Modellen: Data- en informatiemodellen en -formaten
Deze capability stelt een gemeenschappelijk formaat vast voor specificaties voor gegevensmodel en
weergave van gegevens in de payloads van gegevensuitwisseling. Gecombineerd met de Interoperabiliteit | Dataservices,
zorgt dit voor volledige interoperabiliteit bij deelnemers.
Bouwblokken
[…]
1.2.2 - Dataservices
Interoperabiliteit | Dataservices: API’s voor data uitwisseling
Deze capability vergemakkelijkt het delen en uitwisselen van gegevens (d.w.z. gegevensvoorziening en
dataconsumptie/gebruik) tussen datastelsel/dataspace-deelnemers. Een voorbeeld van een bouwblok voor
data-interoperabiliteit die een gemeenschappelijke gegevensuitwisseling API biedt, is de
‘contextmakelaar’ van de Connecting Europe Facility (CEF), die door de Europese Commissie wordt
aanbevolen voor het delen van juiste gegevens over meerdere organisaties.
Deze capability biedt de middelen voor tracering en tracking in het proces van dataverstrekking en
dataverbruik/gebruik. Het biedt daardoor de basis voor een aantal belangrijke functies, van
identificatie van de lijn van gegevens tot auditbestendige logboekregistratie van transacties. Het
maakt ook de implementatie van een breed scala aan tracking use cases op applicatieniveau mogelijk,
zoals het volgen van producten of materiaalstromen in een supply chain.
Bouwblokken
[…]
1.3 - Vertrouwen
Gegevenssoevereiniteit, met betrekking tot aspecten zoals identiteitsbeheer, betrouwbaarheid van deelnemers, evenals gegevenstoegang en gebruikscontrole
De capability ‘identiteit’ betreft het vermogen om de identiteit van bijvoorbeeld een systeem,
persoon of organisatie met afdoende zekerheid vast te stellen. Dit vindt plaats door gebruik te
maken van identificerende kenmerken (zoals een identificatienummer) en een identificatiemiddel
(zoals een digitaal versleuteld certificaat). Identificatiemiddelen worden gebruikt om de identiteit
van iets of iemand met zekerheid vast te kunnen stellen.
Identificerende kenmerken en identificatiemiddelen kunnen worden beheerd in een Identity Management
(IM) oplossing. Voorbeelden van open-source oplossingen zijn de Keycloak-infrastructuur, het Apache
Syncope IM-platform, het open-source IM-platform van het Shibboleth Consortium en het Fiware
IM-framework.
Het binnen europa uitgeven van publieke identificatiemiddelen valt onder de
eIDAS regulering.
Binnen het FDS vindt uitwisseling van gegevens plaats tussen een aanbieder en een afnemer. Bij een
uitwisseling binnen het FDS zijn zowel de afnemer als de aanbieder deelnemer van het FDS. Een
deelnemer van het FDS is een organisatie met een publieke taak. Een organisatie kan als deelnemer
worden toegelaten tot het FDS als deze is ingeschreven in het handelsregister als publiekrechtelijk
of privaatrechtelijke rechtspersoon. Daarbij dient een privaatrechtelijke rechtspersoon een
expliciet benoemde wettelijke taak te hebben. Zowel publiekrechtelijke als privaatrechtelijke
rechtspersonen zijn ingeschreven in het handelsregister.
Binnen het FDS kan de deelnemer de daadwerkelijke uitwisseling plaats laten vinden door een
verwerker. Een verwerker is een door de deelnemer aan te wijzen organisatie die de daadwerkelijke
uitwisseling uitvoert. Een verwerker is een Nederlandse rechtspersoon, maar hoeft geen deelnemer te
zijn aan het FDS en hoeft geen publieke taak te vervullen. Een verwerker wordt door de deelnemer
aangewezen in een overeenkomst. Het aanwijzen vindt plaats door het benoemen van een uniek identificerend
kenmerk dat kan worden vastgesteld bij het leggen van de verbinding voor de gegevensuitwisseling.
Indien een verwerker voor meerdere deelnemers uitwissseling laat plaats vinden dan wordt er per deelnemer
verwerker relatie een uniek identificerend kenmerk vastgesteld en gebruikt.
Het deelnemen aan het FDS door een organisatie-onderdeel van een rechtspersoon is nog onderwerp van
onderzoek (bijvoorbeeld de Belastingdienst is een organisatie-onderdeel van de publiekrechtelijke
rechtspersoon Ministerie van Financiën).
Identificerende kenmerken
Binnen het FDS toepasbare identificerende kenmerken voor een deelnemer zijn:
In een overeenkomst kunnen andere identificerende kenmerken worden toegepast om de deelnemer of een
door de deelnemer aangewezen verwerker te identificeren, zoals een hostname, public-key thumbprint
of een certificaat-thumbprint.
Identificatiemiddelen binnen het FDS
Een deelnemer identificeert zich binnen het FDS met behulp van een identificatiemiddel.
Mogelijke identificatiemiddelen voor het ondertekenen van digitale (leverings)overeenkomsten:
een X.509 certificaat uit een andere
overeengekomen vertrouwde bron (alleen in combinatie met een hostname, public-key thumbprint of
een certificaat-thumbprint als identificerend kenmerk)
een overig (eventueel self-signed) X.509
certificaat (alleen in combinatie met
een certificaat-thumbprint als identificerend kenmerk)
een aanbiederspecifieke identificatiemethode (zie de documentatie van de aanbieder)
Een PKIoverheid Services certificaat tbv ondertekening van digitale documenten is ook een eIDAS
Qualified eSeal. Er worden overigens ook eIDAS Qualified eSeals uitgegeven die géén PKIoverheid
certificaat zijn. Een PKIoverheid Services certificaat tbv TLS wordt niet standaard vertrouwd door
de browser en is geen eIDAS QWAC certifciaat. Een eIDAS QWAC certificaat wordt wel vertrouwd door de
browser. Voor toepassing binnen het FDS is van belang dat het certificaat een geschikt
identificerend kenmerk (zoals het OIN) bevat.
Een veelbelovende identificatiemiddel vormt de Verifiable Credential
(VC) in eIDAS 2.0. De verwachting is dat VC’s in de
toekomstig ook kunnen worden toegepast als identificatiemiddel.
Deze capability bepaalt of, en in welke mate, toegang wordt verleend tot aangeboden
gegevens. Zowel de aanbieder als de afnemer implementeert mechanismen voor datatoegang
om misbruik van gegevens te voorkomen. Toegang vertrouwt op betrouwbaar
geïdentificeerde partijen zoals omschreven in de capabilities
Vertrouwen | Identiteit en Vertrouwen | Veiligheid.
De capability toegang ondersteunt de organisatorische stelselfunctie van
poortwachter.
Toegangsverlening kent beperkingen op verschillende niveau’s:
Het bepalen of een verbinding wordt aangegaan
Het bepalen of een gegevensvraag mag worden gesteld
Het bepalen of gegevens betreffende een entiteit worden geleverd
Het bepalen welke gegevens van een entiteit worden geleverd
Implementatie van deze beperkingen kan worden uitgedrukt
in bijvoorbeeld Policies.
Voor de FSC standaard is een extensie in ontwikkeling
om policies met FSC te combineren. Zowel de aanbieder
als de afnemer hebben een verantwoordelijkheid
bij een zorgvuldige levering. Beide partijen dienen daar waar
nodig beperkingen toe te passen. Wie welke beperkingen toepast
is onderhevig aan onderlinge en stelselbrede te maken afspraken.
In het bijzonder bij persoonsgegevens worden beperkingen dusdanig
ingericht dat alleen de minimaal ten behoeve van de grondslag benodigde
gegevens worden uitgewisseld (dataminimalisatie).
Er is een beperkt aantal standaarden met betrekking tot toegangsverlening,
bijvoorbeeld ODRL en
XACML.
Welke standaarden geschikt zijn in de context van FDS is
nog onderwerp van onderzoek. Zie in dit kader ook de resultaten van de projecten
Lock-Unlock en
Federatieve toegangsverlening.
Deze capability faciliteert de vertrouwde data-uitwisseling onder deelnemers, waardoor deelnemers in
een data-uitwisselingstransactie geruststellen dat die andere deelnemers echt zijn wie zij beweren
te zijn en dat zij voldoen aan gedefinieerde regels/overeenkomsten. Dit kan worden bereikt door
organisatorische maatregelen (bijv. certificering of geverifieerde referenties) of technische
maatregelen (bijvoorbeeld attestatie op afstand).
Binnen het FDS worden gegevens uitgewisseld over een beveiligde verbinding (zoals
HTTPS)
waarbij zowel de aanbieder als de ontvanger worden geïdentificeerd met behulp van
een betrouwbaar identificatiemiddel.
Voor zowel de aanbieder als de ontvanger geldt dat deze een verwerker de
daadwerkelijke uitwisseling kan laten uitvoeren. Deze verwerker dient in dat
geval een eigen identificatiemiddel
te gebruiken die betreffende verwerker identificeert. Een verwerker hoeft
geen deelnemer te zijn binnen FDS. Wel dient betrouwbaar navolgbaar te zijn
namens welke deelnemer de verwerker gegevens uitwisselt. Daarnaast dient
er een overeenkomst te bestaan waaruit onomstotelijk kan worden afgeleid
dat de deelnemer aangeeft dat de verwerker onder verantwoordelijkheid
van de deelnemer gegevens mag uitwisselen.
Of binnen het FDS ook informatie wordt uitgewisseld waarbij de afnemer
anoniem kan blijven (Open Data) is nog onderwerp van onderzoek. Indien
gegevens worden aangeboden aan zich identificerende afnemers, sluit
dit niet uit dat deze aanbieder de gegevens ook als
Open Data aanbiedt. Het is echter nog onderwerp van onderzoek of dit aanbod
als Open Data binnen het FDS kan vallen.
Het netwerk dat de aanbieder gebruikt om gegevens aan te bieden dient
inzichtelijk zijn in de metadata van het aanbod.
Een aanbieder kan binnen het FDS gegevens aanbieden via het internet,
via DigiNetwerk, of beide.
Veiligheid met FSC
Bij FSC worden zowel verzender als ontvanger geïdentificeerd
met een digitaal certificaat (mutual
TLS).
Daarbij vindt binnen FSC uitwisseling plaats onder een digitaal
contract. In dit contract zijn identificerende kenmerken van beide uitwisselende
partijen opgenomen, voor de aanroepende partij via een ‘public key thumbprint’ en
voor de aangeroepen partij via een ‘hostname’ van het API endpoint.
In de context van FDS wordt het FSC-contract digitaal ondertekend door zowel de
aanbieder als de afnemer. Dit identificeert de aanbieder en de afnemer op
een betrouwbare manier. In het contract zijn identificerende kenmerken opgenomen
die (via de gebruikte certificaten) leiden tot het betrouwbaar identificeren van
de feitelijk uitwisselende partijen. Dit betreft de aanbieder of afnemer
zelf of de door de aanbieder of afnemer ingeschakelde verwerker.
Gegevenswaardecreatie, met betrekking tot aspecten zoals publicatie van gegevensaanbiedingen, ontdekking van dergelijke aanbiedingen op basis van metadata en gegevenstoegang/gebruiksboekhouding, die essentieel zijn om gegevens als een economisch asset te verwerken
Om data effectief te kunnen gebruiken moet duidelijk zijn in welke context en met welk doel de data
is ontstaan en wat de betekenis ervan is. Om te kunnen weten en begrijpen wat bepaalde data
betekent, beschrijven we deze met metadata.
De NORA definieert metadata (metagegevens) als:
’Gegevens die context, inhoud, structuur en vorm van informatie en het beheer ervan door de tijd heen
beschrijven.‘ Metadata vormt een essentieel fundament onder de werking van het Federatief Datastelsel. De metadata beschrijft onder andere:
welke data binnen het stelsel beschikbaar zijn,
wat de betekenis (semantiek) van die data is,
wat de grondslag is voor het verzamelen van data,
voor welke context de data oorspronkelijk zijn bedoeld,
welke partijen betrokken zijn,
wat de rollen en verantwoordelijkheden zijn van de betrokken partijen,
hoe de data is vormgegeven (onder andere syntax),
hoe de data beschikbaar is (API’s bijvoorbeeld),
wat de kwaliteit van de data en datadiensten is (denk aan juistheid, actualiteit, etc.),
voor wie de data beschikbaar is en onder welke condities.
De metadata geeft potentiële afnemers inzicht in wat, voor wie en onder welke condities binnen
het stelsel beschikbaar is.
De publicatie van metadata in een catalogus is onderdeel van de capability
Datawaarde | Publicatie.
Binnen het FDS wordt metadata als Linked Data uitgewisseld. Linked data omvat een hele familie aan standaarden en
best practices. Om binnen het FDS effectief Linked Data toe te passen, worden binnen het FDS
Linked Data Design Rules gehanteerd.
Op de volgende vlakken beschrijft FDS de te hanteren structuur van metadata:
De begrippen gehanteerde binnen het aanbod (SKOS en NL-SBB)
De gegevensdefinitie gehanteerd binnen een aangeboden dataset (MIM of OWL)
De kwaliteitskenmerken van het aanbod binnen het FDS (DQV)
De datadeelrelaties die zijn gelegd binnen het FDS
FDS metadata overzicht
De uitwerking van metadata met betrekking tot (traceerbaarheid van) individuele gegevensleveringen
is onderdeel van de capability Interoperabiliteit | Traceerbaarheid.
De verantwoording tot en/of gebruik van gegevens door verschillende gebruikers. Dit ondersteunt op
zijn beurt belangrijke functies voor clearing, betaling en facturering (inclusief transacties voor
het delen van gegevens zonder tussenkomst van datamarktplaatsen).
Om het aanbod van databronnen en -diensten onder gedefinieerde voorwaarden te ondersteunen, moeten
inzichtelijk zijn wat beschikbaar is. Deze capability ondersteunt de publicatie van het aanbod
zodat een afnemer het aanbod kan vinden en kan beoordelen of het zinvol kan en mag worden afgenomen.
Het aanbod van het FDS wordt gepubliceerd in een catalogus. Er is één officiële FDS-catalogus
die het volledige aanbod binnen het FDS ter beschikking stelt aan geïnteresseerden. Daarnaast
kunnen er alternatieve catalogi zijn die (delen van) het FDS aanbod publiceren, zoals sectorale
en/of international catalogi die het FDS aanbod opgenomen hebben als onderdeel van een breder
(informatie)aanbod.
Een catalogus is niet zelf de bron van de gepubliceerde metadata, maar verzamelt het aanbod
vanuit door aanbieders gepubliceerde linked data bestanden met metadata zoals beschreven in
Aanbod (metadata). De aanbieder is verantwoordelijk voor
het aanbieden van het bestand met metadata volgens de richtlijnen van het FDS (self-description).
Deze bestanden vormen de bron voor catalogi.
De FDS-Catalogus
Via de FDS-catalogus is het aanbod inclusief de daarover beschikbare Metadata
publiek inzichtelijk voor geïnteresseerden (voor zover het geen individuele uitwisselingen
betreft). Dit betreft het doorzoekbaar en beschikbaar maken in een voor geïnteresseerden
passende vorm, zowel richting systemen als personen.
Ten behoeve van personen wordt een webapplicatie aangeboden. Informatie ontsloten naar personen
wordt ook machine-interpreteerbaar aangeboden (met behulp van
RDFa), naar behoefte al dan
niet aangevuld met alternatieve linked data formaten (zoals
Turtle, JSON-LD
en/of RDF-XML)
en een SPARQL API ten behoeve van het vrij
kunnen bevragen van de beschikbare metadata.
De FDS-catalogus is een vertrouwde vindplaats van FDS metadata. Dit impliceert onder
andere het toepassen van https en een binnen het FDS vertrouwd certificaat. Daarnaast
dient de catalogus alleen geverifieerde metadata ter beschikking te stellen vanuit
vertrouwde bronnen. De FDS-catalogus kan ander (niet-FDS) aanbod bevatten. Het onderscheid
met niet-FDS aanbod dient echter duidelijk aanwezig te zijn.
De FDS-catalogus is actueel en compleet. Binnen het FDS worden afspraken gemaakt welke
metadata via de catalogus wordt gepubliceerd. De catalogus publiceert alle volgens de
FDS-criteria valide metadata die binnen deze afspraken valt. Daarnaast worden
binnen het FDS afspraken gemaakt met betrekking tot de actualiteit van de gepubliceerde
metadata.
Het raamwerk welke de structuur vormt voor de capabilities en bouwblokken die deze realiseren.
Ter ondersteuning van onze strategie van samenwerken
helpt het om een eenvoudig en begrijpelijk raamwerk (framework) als kapstok te gebruiken. Het
raamwerk ondersteunt vooral de ontwikkeling van het federatief datastelsel door gericht te zijn op
samenwerking en verbinding. Het biedt structuur aan wat we doen, waar we aan werken en biedt
mogelijkheden om verbindingen met onze omgeving te maken.
Een belangrijke verbinding die we willen maken, is naar Europa en Europese ontwikkelingen. Daarom
maken we gebruik van het Position Paper: Design Principles for Data
Spaces. Hierin heeft de OpenDEI Workforce een
schema van ‘building blocks’ opgesteld dat door veel Europese initiatieven gebruikt wordt. Ook wij
willen deze gebruiken door deze ‘building blocks’ als ‘capabilities’ te zien die het federatief
datastelsel zou moeten ontwikkelen, hebben, zijn. Verdere overwegingen zijn te vinden in het besluit
00001 Basisstructuur. De uitwerking van de
capabilities is te vinden via het menu en/of in de documentatie.
Naast de verbinding naar Europa willen we ook graag verbinding kunnen maken naar andere
architecturen. Dat biedt ook structuur voor veel onderwerpen die ‘van verschillend niveau’ zijn.
Vrijwel alle architecturen onderkennen daarom verschillende lagen. Zo ook wij. In ons raamwerk
(basisstructuur) zien wij vijf lagen, waarbij de capabilities die hierboven genoemd worden zich
vooral in de bovenste laag bevinden. De vijflagen van ons raamwerk zijn te verbinden met
veelgebruikte lagenmodellen als NORA en Archimate.
De kern van het raamwerk is het capabilities model in combinatie met het vijf lagen model. Dit kan
beschouwd worden als de ’landkaart’ waarop alle activiteiten, aspecten, onderwerpen, technologieën
en ontwikkelingen te projecteren zijn. Je weet dan altijd waar het zich bevindt en hoe zich dat
verhoudt tot de rest.
Om de verbinding en relaties tot andere lagen modellen te maken, hebben we deze naar NORA en
Archimate al duidelijk ingetekend:
De kern van het raamwerk bevindt zich in een grotere context welke … behoorlijk omvangrijk en
indrukwekkend is:
Complexe maatschappelijke opgaven vragen steeds vaker om samenwerking binnen en tussen sectoren, in
ketens en netwerken waarin gegevens gezamenlijk worden gebruikt. De
Interbestuurlijke Datastrategie beschrijft een
strategie gericht op een beter gebruik van het datapotentieel van en door de Nederlandse overheid.
Niet alleen beter gebruik, maar ook juridisch en ethisch verantwoord gebruik. Een effectief
functionerend Federatief Datastelsel (FDS) wordt daarbij gezien als een essentieel middel op nationaal
niveau, ingebed in Europese kaders. Meer lezen over
het doel en de aanpak van FDS.
Het Federatief Datastelsel is een afsprakenstelsel ten behoeve van effectieve publieke
gegevensuitwisseling op nationaal niveau, ingebed in Europese kaders. Meer lezen over
de scope van FDS en de uitgangspunten van FDS.
De basis van het Federatief Datastelsel wordt gevormd door het basisconcept. Dit
is verder uitgewerkt tot de FDS doelarchitectuur. Onderstaand diagram toont het basisconcept:
FDS Basisconcept
Het basisconcept kent de volgende componenten:
Data-aanbod:
Het data-aanbod krijgt gestalte doordat Data in het stelsel wordt ingebracht. De
ingebrachte data moet (blijvend) voldoen aan de kwalitatieve voorwaarden die in het stelsel zijn
afgesproken. De aldus beschikbare data kan door een Data-aanbieder worden aangeboden in de
vorm van datadiensten. Meer lezen over stelseldata en
de stelselrol van aanbieder.
Data-vraag:
De vraag naar stelseldata wordt ingevuld doordat een Data-afnemer een of meer datadiensten
afneemt van een of meer data-aanbieders. Meer lezen over
de stelselrol van afnemer.
Stelselmechanismen
FDS heeft mechanismen om te borgen dat data betrouwbaar en vertrouwd in het stelsel kan worden
gedeeld en dat dit juridisch is toegestaan en ethisch is verantwoord. Dit wordt ingevuld
langs de ‘bekwaamheden (of capabilities)’ van het stelsel moet hebben,
die worden ingevuld door de ‘stelselfuncties’. Bij deze invulling
hanteren we architectuurprincipes.
Het basisconcept vervangt de zogenoemde ‘houtkoolschets’
die is gepubliceerd tijdens de stelseldag in november 2022.
4 - Wat is het FDS?
Beschrijving van wat FDS, het Federatief Datastelsel, inhoudt en betekent
Context
Het Federatief Datastelsel (FDS) is zowel de realisatie van het Toekomstbeeld Stelsel van
Basisregistraties (hier moet een link naar het document op fds.nl) als de realisatie van de
Interbestuurlijke Datastrategie (hier moet een link naar het document op fds.nl) waar het één van de
onderkende systeemfuncties is. De realisatie van beide beleidsvisies is belegd bij het programma
Realisatie Interbestuurlijke Datastrategie https://realisatieibds.nl/. Dit programma heeft de beide
visies samgengebracht onder het volgende gemeenschappelijke beleidsdoel: ‘Als overheid benutten we
het volle potentieel van data bij maatschappelijke opgaven, zowel binnen als tussen domeinen, op een
ambitieuze manier die vertrouwen wekt.” (Bron Meerjarenaanpak Interbestuurlijke
Datastrategie).
Voor het realiseren van dit doel zijn in de Meerjarenaanpak Interbestuurlijke Datastrategie op
globaal niveau een aantal functies onderkend (daar “systeemfuncties” genoemd). Eén van deze
systeemfuncties is het Federatief Datastelsel (afgekort “FDS”).
Algemene scope Federatief Datastelsel
Bij de realisatie van het Federatief Datastelsel (FDS) staan de volgende elementen uit het hiervoor
genoemde beleidsdoel centraal:
Overheid
Data
Zowel binnen als tussen domeinen
Vertrouwen
Dit maakt het FDS tot een publiek (= overheid) stelsel dat het datapotentieel van verschillende
sectorale datastelsels (= binnen en tussen domeinen) in overeenstemming met publieke waarden (=
vertrouwen) voor publieke doelen (= maatschappelijke opgaven) beschikbaar maakt. [Datastelsel] wordt
in dit verband als synoniem beschouwd voor de termen [data space] en [data ecosysteem].
Het FDS gaat uit van het ontsluiten en betekenisvol verbinden van decentrale databronnen zodat deze
volgens het principe van ‘data bij de bron’ op een verantwoorde manier voor
overheidsdienstverlening kunnen worden toegepast. Het principe heeft een sterke relatie met data
soevereiniteit. Door gebruikers, bijvoorbeeld via API’s, rechtstreeks toegang tot de data te geven
in plaats van ze als kopie uit te wisselen, houden de partijen die data via het stelsel aanbieden
zicht op deze data. Ze weten welke partijen toegang tot de data hebben en waarvoor ze deze willen
gebruiken. De op het stelsel aangesloten data-afnemende organisaties kunnen op hun beurt
rechtstreeks de aangeboden data consumeren en deze naar eigen behoefte met andere data combineren.
Dit uiteraard voor zover ze daartoe geautoriseerd zijn en dit ook
informatiekundig en ethisch verantwoord is.
Het FDS is dus een datastelsel dat datadeelrelaties van data-aanbieder rechtstreeks naar
data-afnemer faciliteert. Hiermee verschilt het FDS van datadeeloplossingen waarin data van
verschillende aanbieders fysiek, als kopie, wordt samengebracht in voorzieningen zoals [data
warehouses] en [data lakes] en waarbij een derde, intermediaire, partij tussen de [data-aanbieders]
en de [data-afnemers] is geplaatst.
Waarin verschilt het FDS van andere datastelsels
Een bijzonder kenmerk van het Federatief datastelsel is dat het andere datastelsels verbindt. Dit
maakt het mogelijk om data uit verschillende datadeelstelsels bij maatschappelijke opgaven te
gebruiken. Daarvoor vult FDS de generieke digitale infrastructuur van de overheid aan met
technische- en organisatorische stelselfuncties die het mogelijk maken om op een verantwoorde manier
het totale overheidsdatapotentieel beter te benutten. Om dit beheersbaar te houden geldt daarbij het
principe: decentraal wat kan, centraal wat moet. De functies van het FDS blijven beperkt tot wat
noodzakelijk is om effectief en efficiënt bovensectoraal data ‘vanuit de bron’ te delen, oftewel om
duurzaam technische, semantische en juridische interoperabiliteit tussen onder het FDS-regime
aangeboden datasets te realiseren. Het FDS biedt daarvoor meer dan interoperabiliteitsafspraken en –
standaarden. Het FDS-afsprakenkader bevat daarnaast afspraken over de minimaal te realiseren
inhoudelijke kwaliteit van (meta)data en datadiensten, net zoals bij het huidige stelsel van
basisregistraties. Deze inhoudelijke eisen leiden er toe dat niet alle overheidsdata geschikt is
voor opname in het FDS. Het FDS is bedoeld voor data die volgens het principe ’eenmalig inwinnen -
meervoudig gebruiken’ betrouwbaar een eigenschap (beschrijvend kenmerk) van iets of iemand
(identificerend kenmerk) vastlegt. Belangrijk zijn dus niet alleen de databronnen maar ook
betekenisvolle relaties tussen deze bronnen - de koppelingen. Ook hieraan stelt het FDS hoge
kwaliteitseisen.
Dit geheel zorgt ervoor dat afnemers goed kunnen bepalen of ze voor hun dienstverlening zonder nader
onderzoek op een FDS-compliant databron kunnen bouwen en wordt het zelfs mogelijk om dit gebruik
wettelijk te verplichten.
Naast het sectoraal/domeinoverstijgende aspect en de op meervoudig gebruik afgestemde hoge
datakwaliteitseisen, maakt het publieke karakter het FDS bijzonder. Bij het datadelen binnen de
FDS-context moeten de continuïteit van de publieke taakuitvoering en het in acht nemen van publieke
waarden zijn verzekerd. Daarvoor gelden specifieke normen zoals de algemene beginselen voor
behoorlijk bestuur. Het naleven daarvan moet niet alleen zijn geborgd, maar voor het maatschappelijk
vertrouwen in de werking van het FDS, moet dit ook kunnen worden aangetoond. Het FDS vereist daarom
niet alleen dat de toepassingsmogelijkheden en de kwaliteit van de data duidelijk zijn, maar ook dat
transparant kan worden gemaakt wat er in werkelijkheid is gebeurd: welke data, met wie, voor welk
doel, wanneer is gedeeld. Het kunnen borgen van de publieke waarden en het belang van de
continuïteit van de publieke dienstverlening, zal er bovendien toe leiden dat vanuit het FDS
specifieke aansluitvoorwaarden worden opgelegd die bepaalde datasets, al dan niet tijdelijk,
uitsluiten. Zo is er vooralsnog vanuit de Interbestuurlijke Datastrategie voor gekozen om alleen
organisaties, datasets en datadiensten tot het FDS toe te laten die verbonden zijn met een
wettelijke taak. Dit betekent dat het FDS geen zuiver private datasets1 ontsluit. Dit is
overigens geen verbod op delen. Partijen kunnen nog steeds via bilaterale of sectorale
arrangementen, los van het FDS-afsprakenkader, private data (blijven) delen of uitwisselen volgens
een eigen, sectoraal, afsprakenstelsel. Het FDS vervangt geen sectorale afsprakenstelsels, maar
levert het fundament dat het mogelijk maakt om eenvoudiger (want gestandaardiseerd) data met andere
sectoren te delen, zoals geïllustreerd in de hierna volgende figuur:
Bij het federatieve karakter van het FDS waarbij op basis van gelijkwaardigheid wordt gedeeld, hoort
ook dat er aan de aanbiedende kant eveneens specifieke eisen kunnen worden gesteld. Zo kunnen
aangesloten sectoren en organisaties er voor kiezen om een deel van hun aanbod niet via het FDS te
delen, bijvoorbeeld omdat deze data alleen binnen de sector of het eigen bedrijfsproces waarde
heeft, of omdat het zeer gevoelige data betreft die een hoger beveiligingsniveau nodig heeft dan het
FDS ondersteunt. De gekozen scope van het FDS vormt ook geen permanente, infrastructurele, barrière.
Via aanpassing van de aansluitvoorwaarden kan later alsnog de reikwijdte van het FDS worden
verruimd.
Wat gaat het FDS bieden
Het Federatief Datastelsel is nog in opbouw. Het project Realisatie Federatief Datastelsel (R-FDS)
ontwikkelt functies om data-aanbieders en data-afnemers uit verschillende domeinen op een
verantwoorde manier data te laten delen. Deze functies zijn ingebed in een afsprakenstelsel dat waar
nodig is aangevuld met standaarden en voorzieningen. Dit geheel maakt het mogelijk om
data-aanbieders, data-afnemers, datasets en datadiensten te certificeren (een ‘FDS label’) te geven
waarmee het duidelijk wordt dat deze aan het FDS-afsprakenkader (de FDS aansluitvoorwaarden )
voldoen. Dit is inclusief de afspraken over het toezicht op de naleving. Hiermee wordt een
vertrouwensbasis gecreëerd die het voor partij A in sector X mogelijk maakt om verantwoord data van
partij B in sector Z te gebruiken, zonder dat A daarvoor alle bijzonderheden van partij B en sector
Z hoeft te kennen. Het omgekeerde geldt ook. Voor beide volstaat dat ze deel uitmaken van het
overkoepelende FDS en ze er daarom op kunnen vertrouwen dat ze genoeg gemeenschappelijk hebben om
bilateraal data te gaan delen. Voor het eigenlijke delen kunnen ze hun eigen IT-voorzieningen
gebruiken, mits die de conform de daarvoor geldende afspraken de FDS-standaarden hebben
geïmplementeerd. Stelseldeelnemers kunnen daarbij gebruik maken van ondersteunende FDS-voorzieningen
zoals de FDS-stelselcatalogus, maar dit is niet verplicht. De verplichting beperkt zich tot het
naleven van de FDS-afspraken en het implementeren van de daaraan gekoppelde standaarden. Het FDS is
dus geen ICT-systeem of datapakhuis, maar het is ook geen volledig virtueel stelsel. Het is
opgebouwd uit op afspraken en standaarden gebaseerde organisatorische en technische
stelselfuncties die het volgende mogelijk maken:
Een overzicht van de inhoud van het FDS
Streven is dat alle elementen van het FDS (alle ‘assets’): datasets, dataset inhoud, datadiensten,
data-aanbieders, data-afnemers en de onderlinge relaties hiertussen in de vorm van metadata op een
gestandaardiseerde manier worden beschreven. Daarmee ontstaat er inzicht in de inhoud van het FDS en
kan dit overzichtelijk worden weergegeven. Deze in- en overzichtsfunctie wordt ook wel
‘catalogus’2 genoemd . De FDS-catalogus wordt opgebouwd uit de metadata die de stelselpartijen
zelf conform de stelselstandaarden hebben gepubliceerd. De metadata is dus op zichzelf ook weer een
FDS-dataset die als open data volgens de FDS-standaarden voor eenieder wordt ontsloten (open
metadata). Dit maakt de inhoud van het federatief stelsel transparant en biedt partijen de
mogelijkheid deze metadata naar eigen inzicht te gebruiken, bijvoorbeeld door ze te integreren in
een thematische catalogus gericht op een specifieke doelgroep. N.b. dat de metadata open is, wil
uiteraard niet zeggen dat dit ook geldt voor de data en datadiensten die m.b.v. die metadata worden
beschreven.
Het betekenisvol leggen van datadeelrelaties
Dit betreft de afspraak dat een tot het stelsel toegelaten databron in elk geval via één van dde
identificerende gegevens uit de kern van het stelsel benaderbaar is.
Deze kern bevat data voor de identificatie van natuurlijke personen, niet-natuurlijke personen en
locaties. Met behulp van deze data kunnen op een informatiekundige betrouwbare manier gegevens
kunnen worden gecombineerd (‘gekoppeld’) omdat door het toepassen van de tot de kern behorende
gestandaardiseerde id’s zoals het BSN, het KVK-nr en het BAG verblijfsobject-id, eenvoudig kan
worden vastgesteld dat het dezelfde burgers, bedrijven of locaties betreft waarvan kenmerken worden
gecombineerd. Onderdeel van deze afspraak is ook dat de betreffende datahouder de kwaliteit van de
gelegde koppelingen inzichtelijk maakt en een proces heeft ingericht om deze kwaliteit te bewaken.
Behalve met afspraken over het toepassen van gemeenschappelijke identificerende sleutels ondersteunt
het FDS het leggen van relaties met diensten die de noodzakelijke variëteit in het sleutelgebruik
makkelijker hanteerbaar maken. Dit betreft onder andere het beschikbaar maken van datadiensten voor
het wisselen van sleutels, zoals het omwisselen van identificatie op basis van BSN naar
identificatie op basis van familienaam, huidige voornaam en geboortedatum (en vice versa); diensten
die helpen om administratieve data aan coördinaat gebaseerde geo-data te relateren en eenduidige
afspraken over het omgaan met ‘restpopulaties’, zoals buitenlandse vastgoedeigenaren die niet in
BRP/RNI zijn opgenomen en situaties dat in de kern opgenomen sleutels niet kunnen worden toegepast
omdat de gebruikscontext teveel verschilt.
Het betrouwbaar identificeren van de stelseldeelnemers
Om de legitimiteit van datadeelrelaties te kunnen valideren, moeten de partijen in de relatie, de
data-aanbieder en de data-afnemer en de door hen gebruikte datadiensten, op een betrouwbare manier
geïdentificeerd kunnen worden. Binnen het FDS geldt de afspraak dat de identificatie beperkt blijft
tot het niveau van organisatie. Voor de implementatie wordt aangesloten op afspraken, standaarden en
voorzieningen die vanuit het GDI-domein Toegang beschikbaar worden gesteld. Deze worden zo nodig
aangevuld met afspraken die specifiek op datadelen vanuit de bron betrekking hebben.
Het autoriseren van datadeelrelaties
Dat een relatie informatiekundig betrouwbaar kan worden gelegd, betekent niet dat deze ook mag
worden gelegd. Binnen het FDS geldt de afspraak dat een data-aanbieder alleen data aan een
data-afnemer beschikbaar stelt als hij heeft vastgesteld dat deze daartoe gerechtigd is. Om dit
geautomatiseerd te kunnen vaststellen, moet de gestelde datavraag aan een aantal op FDS-niveau
vastgestelde voorwaarden voldoen. Deze, nog uit te werken, voorwaarden hebben zowel betrekking op de
vorm van de vraag (de technische standaard) als de inhoud (de inhoudelijke standaard). Deze
voorwaarden maken het mogelijk in samenhang met de hierna genoemde registratiefunctie (het ’loggen’)
achteraf te kunnen controleren of het gegevensdelen tussen de verschillende stelseldeelnemers
volgens de regels is verlopen en burgers inzicht te geven in wie waarvoor zijn gegevens binnen het
stelsel heeft gebruikt.
Het legitimeren van nieuwe datadeelrelaties
Voorwaarden voor datadeling zijn de uitkomst van een proces waarbij de belangen voor het wel en niet
delen zorgvuldig tegen elkaar zijn afgewogen. Deze afweging is tijdgebonden. Datadeling die eerst
noodzakelijk was, kan door nieuwe technische mogelijkheden overbodig worden als volstaan kan worden
met alleen een antwoord op een specifieke vraag (dataminimalisatie). Maar het is ook mogelijk dat
waar er eerst geen zwaarwegend belang voor datadeling was, dat er nu, al dan niet tijdelijk, wel is.
Het FDS voorziet in (organisatorische) functies om dit afwegingsproces te faciliteren en de
resultaten daarvan op een gestandaardiseerde manier in de ‘verwerkingenregisters’ van de
stelseldeelnemers vast te leggen. Deze stelselfunctie wordt de Poortwachter3 genoemd .
Het registreren (loggen) van datadeling
Dit betreft drie hoofdafspraken die bedoeld zijn om transparant te maken wat er werkelijk is gedeeld
en de legitimiteit daarvan te kunnen controleren:
De afspraak dat data-aanbieders op een gestandaardiseerde manier registreren (loggen) welke data,
wanneer, aan welke organisatie, op basis van welke geclaimde grondslag, op welke manier (via welke
dienst) beschikbaar is gesteld.
De afspraak dat data-afnemers eveneens op een gestandaardiseerde manier loggen welke data,
wanneer, van welke organisatie, op basis van welke grondslag, of welke manier (via welke dienst)
is afgenomen. Hierbij geldt voor data die niet als ‘open data’ is geclassificeerd binnen het FDS
de aanvullende afspraak dat afnemende organisaties ook op persoonsniveau inzichtelijk moeten
kunnen maken wie de betreffende informatie heeft gebruikt.
De afspraak dat bij een stelseldatabron die is opgebouwd uit data uit andere stelseldatabronnen er
in de logging ook de relatie naar die oorsprong kan worden gelegd zodat er een sluitende ‘audit
trail’ van het datagebruik kan worden opgebouwd: Het transparant maken van het datagebruik.
Het FDS voorziet in afspraken en standaarden die het mogelijk maken om de op de stelselmanier
gelogde datadelingen te aggregeren tot een virtuele dataset die op zich ook weer als een
stelseldatabron ontsloten kan worden voor monitoring ter ondersteuning van de stelselgovernance
(bijvoorbeeld in geval van doorbelasting), het stelseltoezicht, het stelselbeheer en de
stelselbeveiliging. Daarnaast maakt deze gestandaardiseerde wijze van logging het mogelijk om op
geaggregeerd en individueel niveau aan burgers, bedrijven en ‘de maatschappij’ het datagebruik
inzichtelijk te maken en het opbouwen en bijhouden van de door de AVG voorgeschreven
‘verwerkingenregisters’ deels te automatiseren.
Aansluitondersteuning, validatie en certificering
Data-aanbieders en data-afnemers sluiten aan op het FDS doordat ze zich aanmelden en daarbij zelf
verklaren dat ze zich conformeren aan het FDS-afsprakenkader en dat ze hierop ook kunnen worden
aangesproken. Bij de data-aanbieders geldt deze verklaring ook voor de kwaliteit van de binnen de
FDS aangeboden datasets en datadiensten. Het aangesloten zijn komt tot uiting in het verkrijgen van
een FDS-label. Dit label is onderdeel van de metadata en kent verschillende, nog uit te werken,
kwaliteitsklassen (rankings). Vertrekpunt is dat partijen zelf hun niveau van stelselconformiteit
beschrijven en verifiëren (self description en self assessment). Het stelsel biedt daarvoor kaders,
referentietoepassingen en validators. Het aansluiten zelf wordt ondersteund met testomgevingen,
testdata en testtools en met kennis (handleidingen, best practices, faq’s etc.) geleverd vanuit het
FDS Expertisecentrum .
Gebruikersondersteuning
Het FDS kent 3 nog in te vullen en in te richten functies om de stelseldeelnemers te ondersteunen:
De Marktmeester die ondersteunt bij het matchen van vraag en aanbod.
De Expertisefunctie, die kennis levert over de inhoud en het toepassen van de FDS-afspraken,
standaarden en voorzieningen.
De Helpdesk die ondersteuning biedt voor partijen die een ‘stelselprobleem’ hebben of die
gebruikers op weg helpt die niet zelfstandig de weg kunnen vinden naar de partij die voor de
betrokken data- en of datadienst verantwoordelijk is.
Besturing van het FDS
Er is een behoefte aan regie en hiervoor is in het ontwerp van het stelsel de functie van Regisseur
voorzien. Hoe deze functie in een federatief stelsel effectief kan worden ingevuld, moet nog worden
uitgezocht. Een belangrijk element daarbij wordt het scherp krijgen van de verhouding tussen
doorzettingsmacht op stelselniveau en de ministeriële verantwoordelijkheid voor de sectoren waaruit
via het FDS databronnen worden ontsloten. Onderdeel van de uitwerking van de stelselregie is ook het
zorgen voor een redelijk en praktisch hanteerbaar financieringsarrangement voor het gebruik, het
beheer en de doorontwikkeling van het FDS.
Beheer en exploitatie van het FDS
Het strategisch, tactisch en operationeel beheer van de componenten van het FDS zal goed geregeld
moeten worden, maar de exacte invulling moet nog worden uitgewerkt. Op strategisch en deels tactisch
niveau is het beheer van het stelsel onderdeel van de regisseurrol, maar op operationeel niveau zal
er ook beheer van de in projectfase ontwikkelde stelselfuncties nodig zijn.
Toezicht en handhaving
Het ontwerp van het FDS kent de functie Toezichthouder. Van deze functie staat vast dat hij nodig
is, maar ook hier geldt dat de invulling nog uitgewerkt moet worden. Een belangrijk uitzoekpunt is
of er behoefte is aan een daadkrachtige onafhankelijke FDS-toezichthouder: een toezichthouder die
het instrumentarium heeft om zelf een goed beeld van de naleving van afspraken te krijgen en in te
grijpen als dit niet naar behoren gebeurt. Dergelijk ’toezicht met tanden’ is mogelijk noodzakelijk
voor het borgen van de publieke waarden die het FDS moet dienen.
Het faciliteren van koppelingen tussen aangesloten stelsels /dataspaces
Het beeld bestaat dat het FDS functies moet gaan leveren om het leggen van deze koppelingen te
vereenvoudigen, maar welke dat zijn moet nog worden uitgewerkt. Aandachtspunten zijn onder andere
verschillende standaarden voor authenticatie en autorisatie binnen te koppelen datastelsels en het
gebruik van verschillende identificerende nummers. Daarnaast zijn er mogelijk functies nodig om de
kwaliteit en het gebruik van deze koppelingen te kunnen monitoren.
Conformiteit met algemene EU dataregelgeving
Deelnemers aan het FDS kunnen ervan uitgaan dat ze met het implementeren van de FDS-afspraken en
standaarden ook voldoen aan de algemene datadeeleisen die vanuit EU-regelgeving worden opgelegd. Ze
kunnen zich dus focussen op het uitwerken en implementeren van de EU-dataregelgeving die specifiek
voor hun sector/domein geldt. Deze zekerheid bieden is een doel bij de realisatie van het FDS, maar
het is nog niet duidelijk of dit een afzonderlijke stelselfunctie vergt of dat het een aspect is bij
de inrichting van de andere FDS-functies.
Het doel van FDS en de aanpak om dat doel te bereiken. Kort wordt ook ingegaan op de interpretatie van het begrip ‘federatief’.
Het Federatief Datastelsel is geënt op het volgende beleidsdoel uit de interbestuurlijke
datastrategie:
‘Als overheid benutten we het volle potentieel van data bij maatschappelijke opgaven, zowel binnen
als tussen domeinen, op een ambitieuze manier die vertrouwen wekt.’
Het hoofddoel van FDS is om het voornoemde beleidsdoel mogelijk te maken. Daarvoor faciliteert FDS
dat Nederlandse overheidsorganisaties op eenvoudige en verantwoorde wijze hun data met elkaar kunnen
delen ten bate van maatschappelijke vraagstukken en publieke dienstverlening. Hierdoor kan de
Nederlandse overheid meer maatschappelijke waarde genereren uit de (data)middelen waarover ze op
grond van haar wettelijke taken beschikt.
De hoofddoelstelling van FDS wordt in de realisatie- en implementatieplannen verder verdiept.
Federatief
Een federatie is feitelijk een samenwerking tussen de leden op basis van collectieve afspraken. De
leden zijn en blijven verantwoordelijk voor de kwaliteit van de data die ze inbrengen in het
stelsel. Ze stellen binnen die verantwoordelijkheid hun data beschikbaar voor hergebruik en
conformeren daarbij aan de collectieve stelselafspraken en relevante wetgeving. Ook kunnen ze zo
nodig aanvullende afspraken maken, waaraan zijzelf en de andere betrokkenen zich dienen te houden.
Stelselbekwaamheden (capabilities) zoals ‘Governance’ moeten dit waarborgen.
Het waarborgen van het functioneren van een federatie is in beginsel de verantwoordelijkheid van de
leden, doordat zij zich ieder afzonderlijk conformeren aan de collectieve afspraken. Een centraal
niveau is er als waarborg voor collectiviteit en de daarvoor essentiële functies die op het
decentrale niveau moeilijk zijn in te richten en/of daarvoor niet efficiënt zijn.
‘Het Federatief Datastelsel’ is een afsprakenstelsel in opbouw. Het project Realisatie Federatief
Datastelsel ontwikkelt functies om aanbieders en afnemers van data uit alle beleidsdomeinen op een
juridisch en ethisch verantwoorde manier data te laten delen. De functies zijn ingebed in een
afsprakenstelsel dat waar nodig is verankerd in wetgeving. Het afsprakenstelsel kan verder worden
aangevuld met concrete standaarden en voorzieningen. Data, data-aanbieders, data-afnemers en en
datadiensten in het stelsel, kunnen zo worden voorzien van een ‘FDS-label’ dat duidelijk maakt dat
zij voldoen aan het FDS-afsprakenkader (waaronder bijvoorbeeld FDS aansluitvoorwaarden).
Stelselfuncties zoals ‘toezicht houden’ zorgen ervoor dat deelnemers structureel conformeren, ook na
eventuele wijzigingen binnen het stelsel. Dit alles levert een vertrouwensbasis waarbinnen
deelnemers aan het stelsel verantwoord data kunnen delen met andere deelnemers.
Om data te delen maken stelseldeelnemers in de rol van data-aanbieder deze data binnen het stelsel
beschikbaar. Dat gebeurt door het leveren van datadiensten. De data-aanbieder publiceert de metadata
over de data en diensten die hij beschikbaar stelt, zodat een (potentiële) data-afnemer kan bepalen
of dit voor hem bruikbaar is.
Voor het feitelijke datadelen zorgen de deelnemers zelf dat ze kunnen beschikken over de benodigde
infrastructurele en functionele voorzieningen. Deze voorzieningen zijn zodanig ontwikkeld en
ingericht dat ze conformeren aan de relevante stelselafspraken en -standaarden. Gebruik van
eventuele generieke FDS-voorzieningen is geen verplichting, tenzij dat voor specifieke situaties
binnen het stelsel is afgesproken en als zodanig vastgelegd in FDS-afsprakenkader.
6 - Scope van FDS
De afbakening van FDS ten opzichte van andere ontwikkelingen binnen de Nederlandse en Europese digitale overheid.
Het Federatief Datastelsel (FDS) richt zich op publieke gegevensuitwisseling op nationaal niveau,
ingebed in Europese kaders.
Wettelijke grondslag
Uitgewisselde gegevens binnen FDS moeten juridisch en ethisch verantwoord gebruikt kunnen worden
in publiek belang. FDS borgt daarmee de publieke waarden en biedt tegelijk de data-afnemers het
vertrouwen en de zekerheid dat zij hun publieke dienstverlening op data uit het stelsel kunnen
en mogen baseren.
Het Federatief Datastelsel is (vooralsnog) gericht op publieke databronnen en hergebruik van de data
door organisaties met een wettelijke taak. Bronnen in het stelsel bevatten dus data die voortvloeien
uit een wettelijke taak van de bronhouder. Met het oog op dat hergebruik moet gezorgd worden dat
stelseldata door afnemers voor hún wettelijke taken gebruikt kunnen worden. Momenteel wordt
onderzocht hoe algemene wetgeving eruit moet zien om data tussen bronnen en afnemers te laten
‘stromen’ met inachtneming van eisen die de wetgeving (zoals de AVG) daaraan stelt. Bezien wordt ook
wat het betekent voor bestaande wetgeving zoals die voor de basisregistraties. Daarbij wordt er
vanuit gegaan dat voor het stelsel benodigde algemene wetgeving deel zal uitmaken van de Wet
digitale overheid.
Stelsel van stelsels
Binnen de Nederlandse overheid bestaan diverse initiatieven die zijn gericht op het delen van data
binnen specifieke sectoren. Figuur 1 toont hoe FDS en sectorale dataruimten met elkaar samenhangen.
Figuur 1: FDS als stelsel van stelsels
De sectoren beschikken over de kennis om sectorale data te verbinden, te delen en te gebruiken. FDS
heeft niet de taak en niet het vermogen om specifieke sectorale vraagstukken op te lossen. De voor
FDS ontwikkelde afspraken, standaarden en werkwijzen kunnen wel bijdragen aan sectorale
datastelsels. Maar de focus van FDS ligt vooral op het boven-sectoraal delen van data. Dat wil
zeggen dat data van de ene sector via FDS kan worden gedeeld met een andere sector. FDS vervult als
het ware een brugfunctie. FDS is daarmee het datastelsel dat datastelsels verbindt.
Dit specifieke kenmerk in combinatie met de doelstelling maakt FDS tot een publiek stelsel dat het
datapotentieel van verschillende sectorale datastelsels in overeenstemming met publieke waarden voor
publieke doelen beschikbaar maakt.
Samenwerking en afbakening binnen Nederland
FDS wordt onderdeel van de digitale overheid (DO) en zal daarin functioneren in relatie met andere
DO-onderdelen. Diverse programma’s en projecten werken (of hebben gewerkt) aan verbetering van de
organisatie en inrichting van de digitale overheid. Programma’s die allen beogen om door adequaat
digitaliseren van overheidstaken en -processen, de Nederlandse maatschappij te voorzien van een
uitstekende en toekomstbestendige overheidsdienstverlening.
Zo werken al deze programma’s evenals ‘Realisatie FDS‘ aan hetzelfde hoofddoel. Goede samenwerking
en afstemming zijn daarbij geboden. Dat gaat niet zonder een duidelijke afbakening van
ontwikkeldoelen en -activiteiten.
Figuur 2 schetst een globaal beeld van de afbakening van de ontwikkeling van FDS-functies ten
opzichte van andere functies voor de digitale overheid.
Figuur 2: Afbakening realisatie FDS
De figuur toont dat het programma Realisatie FDS zich bezighoudt met overheidsdata beschikbaar maken
voor meervoudig gebruik ten behoeve van enerzijds het kunnen uitwerken van specifieke beleidsopgaven
en anderzijds het uitvoeren van dienstverlening.
Andere DO-programma’s bemoeien zich met de inrichting van digitale overheidsdienstverlening. Onder
andere betreft dit het inzamelen, registreren en beheren van de data die nodig is om de diensten te
verrichten. Voor de inrichting van de digitale overheid maken DO-programma’s onder andere gebruik
van generieke referentiekaders zoals NORA en de Generieke Digitale Infrastructuur (GDI).
De FDS-kaders en de DO-kaders zijn uiteraard niet los van elkaar te zien. Ze zijn beiden onderdeel
van de digitale overheid. Ze overlappen en er is sprake van wederzijdse beïnvloeding. Goede
samenwerking en afstemming tussen de programma’s is derhalve een absolute noodzaak.
Sectoroverstijgend datadelen
FDS wil zich in het Nederlandse en Europese landschap van datastelsels (of data spaces) positioneren
als verbindende schakel tussen sectoraal ingerichte stelsels. De focus van FDS is daarmee gericht op
sectoroverstijgende datadeel-relaties, in de veronderstelling dat datadeel-relaties binnen een
sector de focus zijn van de sectorale partijen en/of datastelsels. Dat betekent niet dat
intra-sectorale datadeel-relaties niet mogelijk zijn binnen FDS. Maar FDS houdt geen rekening met
alle eisen en wensen die voor specifieke sectoren van toepassing zijn.
De sectoroverstijgende datadeel-relaties worden ondersteund door adequate beschrijving van de data
(de metadata) en door de zogenoemde Informatiekundige Kern (IK).
Samenwerking en afbakening binnen Europa
Met de Europese Datastrategie
streeft de EU naar veilig en vertrouwd dataverkeer zonder onnodige belemmeringen tussen publieke
en private organisaties binnen Europa als belangrijke voorwaarde en stimulans voor de eengemaakte
Europese markt. Hoewel de EU-ambitie vooral een
economisch motief lijkt te hebben, is het middel waarvoor men kiest vergelijkbaar met het middel
‘FDS’ dat als essentiële systeemfunctie wordt gezien in de Nederlandse Interbestuurlijke
Datastrategie. Onderdeel van EU datastrategie is de ontwikkeling van een aantal dataruimten (data
spaces). Als richtsnoer voor de ontwikkeling van deze dataruimten, verscheen vanuit het door de EU
gefinancierde programma ‘OPEN DEI’ een instructieve position paper, genaamd
‘Design Principles for Data Spaces’.
Deze paper beschrijft een aantal principes
en bouwstenen voor de ontwikkeling van dataruimten. De paper is gebaseerd op Europese
referentie-architecturen, in het bijzonder
‘International Dataspaces Reference Architecture’
en ‘GAIA-X Reference Architecture’.
Het OPEN DEI-raamwerk is vergelijkbaar met het hiervoor beschreven
stelsel-van-stelsels-model. Het raamwerk gaat uit van een generieke laag
met principes en bouwstenen. Bovenop de generieke laag worden de afzonderlijke dataruimten
ontwikkeld, die daarop hun specifieke principes en bouwstenen toepassen. Door consequent en
consistent gebruik van de generieke laag, ontstaat interoperabiliteit tussen de verschillende
dataruimten. Het aldus groeiende stelsel van interoperabele dataruimten noemt OPEN DEI het Europese
Data Ecosysteem.
FDS kunnen we in deze context beschouwen als het ‘Nederlandse Overheid Data Ecosysteem’. We laten de
FDS-architectuur daarom zo goed mogelijk aansluiten op de architectuur van het ‘EU Data ecosysteem’.
Als kapstok daarvoor gebruiken we het generieke bouwstenenmodel uit het OPEN DEI raamwerk. De
bouwstenen van het raamwerk beschouwen we binnen FDS als bekwaamheden (ook vaak ‘capabilities’
genoemd) waarover het stelsel moet beschikken. Zie Figuur 3.
Op hoofdlijnen beschrijving van data als begrip en de eisen die het stelsel aan het data- aanbod verbindt.
‘Data’ is afkomstig uit het Latijn en betekent zoveel als ‘gegevens’ of ‘feiten’. Het Latijnse
enkelvoud is ‘datum’. De verwarring die hierbij kan ontstaan met het welbekende tijdsbegrip is
evident. We gebruiken daarom de term ‘data’ voor zowel het enkelvoud als voor het meervoud van
‘gegeven’. Uit de context moet blijken of het om het meervoud gaat of om het enkelvoud.
Elke digitale weergave van handelingen, feiten of informatie en elke compilatie van dergelijke
handelingen, feiten of informatie, ook in de vorm van geluidsopnames of visuele of audiovisuele
opnames.
De datastrategie is gericht op het (beter) dienen van het publiek belang, door het datapotentieel
waar de overheid al over beschikt, breder in te zetten voor maatschappelijke opgaven. Stelseldata
(her)gebruiken voor verschillende doelen in verschillende contexten is daarom een belangrijk doel.
Om herbruikbaarheid te bevorderen, stelt FDS eisen aan de data die in het stelsel worden opgenomen.
Deze eisen hebben invloed op de inhoud van de datadiensten waarmee het data-aanbod in het stelsel
voor de data-afnemers wordt ontsloten. De belangrijkste eisen die FDS stelt aan stelseldata zijn:
In deze paragraaf gaat het om herbruikbaarheid in semantische zin. De beschrijvingen van data en
datadiensten moeten inzicht geven in de mogelijke herbruikbaarheid van de betreffende data. Om
verantwoord hergebruik van data in een andere context te kunnen bepalen, is minimaal inzicht vereist
in:
Betekenis, context en doel van de her te gebruiken data;
Condities voor (her)gebruik;
Context en doel van het nieuwe gebruik.
Zo moet bijvoorbeeld duidelijk zijn wat de betekenis is van de data en waarvoor deze oorspronkelijk
is ingezameld en gebruikt. Lees voor meer Metadata,
Metadata van aanbod en de
Publicatie van metadata.
Data zijn in betekenisvolle samenhang ontsluitbaar
Voor het betekenisvol combineren (of compileren) van data moet deze voorzien zijn van uniek
identificerende kenmerken, ook wel sleuteldata genoemd. Relaties tussen data worden gelegd via deze
sleuteldata. Met sector-overstijgend data delen als uitgangspunt is het noodzakelijk dat data uit
verschillende sectoren is voorzien van overeenkomstige sleuteldata. FDS onderhoudt een
afsprakenkader dat beschrijft welke sleuteldata minimaal aanwezig moet zijn, om te kunnen koppelen
met andere data. Dit afsprakenkader is bekend onder de naam ‘Informatiekundige Kern’ (IK). De
relaties tussen sectoren blijken vooral gelegd te kunnen worden op basis van ‘wie’ en/of ‘waar’,
ofwel de identificerend kenmerken van natuurlijke personen, organisaties en locaties. Binnen
sectoren zijn de onderwerpen en objecten waar de sector over gaat belangrijke factoren voor het
leggen van relaties. Denk aan voertuigen in de mobiliteitssector, studieprogramma’s in de
onderwijssector, etc. De IK bestaat uit afspraken over de identificatie van natuurlijke personen,
niet-natuurlijke personen en locaties. Dit betreft de identificerende eigenschappen van BRP, HR en
BAG. Doordat data-aanbieders in FDS conformeren aan de IK-afspraken kunnen ze datadiensten aanbieden
die op informatiekundig betrouwbare manier data combineren. Als twee verschillende datasets dezelfde
unieke sleutel gebruiken (bijv. BSN 999.99.999 van een persoon), is het simpel vast te stellen dat
het gaat om data over dezelfde persoon. De bij deze sleutel behorende datakenmerken uit beide
datasets zijn dan eenvoudig te combineren tot een samengesteld beeld over de betreffende persoon.
Naast afspraken over standaard identificerende sleutels voorziet FDS ook in afspraken over
alternatieve sleutels. Stel dat een data-aanbieder niet mag of kan beschikken over een BSN, maar de
data die hij wil aanbieden leent zich wel voor het leggen van relaties op persoonsniveau. In dat
geval kan wellicht een alternatieve sleutel worden toegepast. Denk aan postcode en huisnummer voor
een adres, of geboortedatum, voornamen en achternamen voor een persoon. Bij gebruik van alternatieve
sleutels kan altijd een risico bestaan dat een sleutel niet 100% uniek is. Ook over het mitigeren
van dit risico zijn afspraken nodig, evenals over hoe te handelen bij eventuele maatschappelijke
gevolgen bij ongewenst koppeling van data. De IK zal ook nog afspraken uitwerken over de invulling
van ondersteunende functies. Dergelijke functies moeten de implementatie van de afspraken
eenvoudiger maken. Te denken valt aan:
Opzoeken van sleutels;
Wisselen van sleutels naar alternatieve sleutels. Denk aan het omwisselen van identificatie op
basis van KVK-nummer naar identificatie op basis van RSIN voor een niet-natuurlijk persoon.
Gebruik van pseudoniemen bij persoonsgegevens.
8 - Stelselrollen
Op hoofdlijnen hoe de rollen m.b.t. het aanbieden en afnemen van data binnen het Federatief Datastelsel zijn ingericht.
Aanbod en vraag
FDS verbindt de vraag naar stelseldata met het aanbod ervan.
De vraag naar stelseldata heeft betrekking op data die is ingewonnen ten behoeve van de uitvoering
van een wettelijke taak. De inwinnende partij heeft in het huidige stelsel van basisregistraties de
rol van ‘bronhouder’. FDS heeft geen invloed op de organisatorische en procesmatige inrichting van
het inwinnen en bijhouden van de data. De rol van bronhouder is daarmee buiten scope van FDS (zie
ook scope samenwerking en afbakening binnen
Nederland ). Wel stelt FDS eisen
aan de data die onderdeel van het stelselaanbod zijn of worden.
De primaire rollen in FDS zijn de data-aanbieder en data-afnemer. Aan de primaire rollen koppelt FDS
rol-specifieke taken, verantwoordelijkheden en bevoegdheden. De toekenning hiervan is afgestemd op
de specifieke doelen van FDS en is alleen van toepassing op handelingen binnen het FDS
afsprakenkader. Een organisatie kan als deelnemer in het stelsel, zowel aanbieder zijn als afnemer.
FDS eist dat het altijd volkomen duidelijk is vanuit welke rol een stelseldeelnemer handelt.
Data-aanbieder
De data-aanbieder is een stelselrol die wordt ingevuld door een organisatie met een wettelijke taak
(zie ook eisen aan stelseldata). De data-aanbieder is
deelnemer in het stelsel. Hij maakt de data die tot het stelsel is toegelaten, beschikbaar en
bruikbaar door er dataservices op te ontwikkelen en aan te bieden, zodat data-afnemers ze kunnen
gebruiken. Deze rol is vergelijkbaar met de rol van ‘verstrekker’ in het huidige stelsel van
basisregistraties.
De organisatie die de rol vervult kan tegelijkertijd ook de rol van bronhouder hebben, maar het kan
ook een andere organisatie zijn. Voor FDS geldt het uitgangspunt dat de data-aanbieder
verantwoordelijk is voor een bepaald data-aanbod, ongeacht of hij wel of niet de bronhouder is. De
data-aanbieder staat garant voor het waarmaken van de opgegeven specificaties van de datadiensten
(en de daarin vrijkomende data) die hij aanbiedt.
De data-aanbieder biedt de data aan op grond van een wettelijke taak. Hiermee is het verantwoord
datadelen vanuit het publiek belang juridisch afdwingbaar.
Data-afnemer
De data-afnemer is een organisatie met een wettelijke taak, welke als deelnemer is aangesloten op
het stelsel. De data-afnemer creëert maatschappelijke waarde door het toepassen van FDS- en
niet-FDS-datadiensten voor het uitvoeren van zijn publieke taak: het leveren van digitale diensten
aan burgers, bedrijven en overheden.
De data-afnemer moet kunnen aantonen dat hij de af te nemen gegevens binnen de kaders van zijn
wettelijke taak gebruikt.
9 - Uitgangspunten van FDS
De uitgangspunten voor het basisconcept van het Federatief Datastelsel.
Grip op data
Een belangrijk uitgangspunt binnen de Europese kaders voor ontwikkelen van dataruimten, is de
zogenoemde ‘data soevereiniteit’. Ruwweg stelt dit uitgangspunt dat deelnemers aan datastelsels
zeggenschap behouden over hun eigen data en het delen ervan met andere deelnemers.
FDS beschouwen we als het Nederlandse publieke datastelsel. Het maatschappelijk belang is leidend
bij het datadelen via FDS. De publieke waarden dienen daarbij dus geborgd te zijn. Die waarden en de
daaruit voortvloeiende beginselen zijn in wet- en regelgeving en in overheidsbeleid verankerd. De
stelseldeelnemers hebben de plicht en verantwoordelijkheid om daarnaar te handelen. De
FDS-stelselmechanismen leveren de deelnemers aan het stelsel voldoende grip op de data om deze op
verantwoorde wijze met elkaar te kunnen delen.
Deze sturing vanuit het overkoepelende maatschappelijke belang, begrenst dus de autonomie van de
individuele stelseldeelnemers. Dit is een belangrijk verschil t.o.v. data-ecosystemen met een
private ‘datamarkt’, waarin deelnemers op basis van economische motieven zelf bepalen met wie en
onder welke condities zij data delen.
Decentraal wat kan en centraal wat moet
In het federale stelsel conformeren de leden zich aan collectieve afspraken, standaarden en
eventueel voorzieningen. Het uitgangspunt is om voorzieningen alleen verplicht te stellen als dat
functioneel noodzakelijk is om de doelen van FDS te realiseren. Verplicht te gebruiken zijn bepaalde
centrale voorzieningen alleen als dat in wetgeving of de collectieve afspraken zo is opgenomen.
Met collectieve afspraken wordt o.a. bedoeld de richtlijnen, convenanten en standaarden die worden
benoemd in een formeel vast te stellen en te onderhouden FDS-afsprakenkader.
Afspraken boven (open) standaarden boven voorzieningen
FDS gaat uit van het beginsel ‘afspraken gaan boven standaarden en standaarden gaan boven
voorzieningen’. De nadruk ligt niet op realisatie en beheer van (generieke) IT-voorzieningen, maar
op ontwikkelen en toepassen van generieke afsprakenkaders en standaarden.
Het principe houdt in dat voor stelseldoelen die volledig behaald kunnen worden met een of meer
bindende stelselafspraken, geen stelselstandaard of stelselvoorziening wordt ontwikkeld. Als
stelselafspraken alleen niet toereikend zijn, kan (ook) een stelselstandaard worden afgesproken. Pas
als ook een stelselstandaard niet toereikend is, kan een generiek toepasbare stelselvoorziening
worden ontwikkeld.
Voor standaarden hanteert FDS de eis dat dit open standaarden zijn.
Data bij de bron
Het werken conform ‘data bij de bron’ is een belangrijk beginsel bij de realisatie van de digitale
overheid en daarmee ook voor de realisatie van het Federatief Datastelsel.
De Nederlandse overheid streeft naar goed hergebruik van data. De hergebruikte data wordt door de
afnemer/gebruiker echter nog vaak als kopie opgeslagen. Veelal gebeurt dit omdat het voor bepaalde
functionaliteit of door in capaciteit beperkte infrastructuur, noodzakelijk is. De technologische
vooruitgang zorgt er inmiddels voor dat infrastructuur in veel mindere mate een beperkende factor
is. Daarnaast zijn er technologische paradigma’s die zich richten op het sturen van functionaliteit
naar de brondata om die daar uit te voeren en het resultaat retour te sturen. Dit opent
mogelijkheden om het kopiëren van data te beperken en deze direct bij de bron te gebruiken.
Data bij de bron leidt tot hogere datakwaliteit, meer veiligheid en betere bescherming van privacy;
Geen fouten door onnodige kopieerslagen;
Data op één plek is beter te beveiligen en biedt betere bescherming van privacy;
Makkelijker data kunnen corrigeren, omdat het maar één keer hoeft te gebeuren;
De overheid kan makkelijker inzicht geven in het gebruik van data;
De totale hoeveelheid data binnen de overheid vermindert (dataminimalisatie).
Naar verwachting zal distribueren en kopiëren van data om uiteenlopende redenen nooit helemaal
verdwijnen. Het streven is wel om het zoveel mogelijk te beperken. FDS zal daarom voorzien in de
mogelijkheid om gewaarmerkte kopieën in het stelsel onder te brengen. Er zijn twee situaties waarin
een kopie geldt als gewaarmerkt:
Als deze aantoonbaar onder controle is van de partij die ook de bron ontsluit;
Als deze noodzakelijk is voor het betrouwbaar genereren van afgeleide dataproducten.
Binnen FDS betekent werken volgens data bij de bron dat de bron rechtstreeks (via een API) wordt
bevraagd op de gegevens die nodig zijn voor de uit te voeren taken. Via de API ontvangt de afnemer,
het antwoord op de gestelde vraag. De afnemer krijgt (een kopie van) de data die nodig is of het
antwoord op een algoritmische bewerking van de data (bijvoorbeeld een ja op de vraag of iemand ouder
is dan 18 jaar). Dataminimalisatie is hierbij een belangrijk doel. Het verzenden van complete
kopie-datasets zoals in de huidige situatie nog gebeurt, zal daarmee zoveel mogelijk worden
voorkomen.
Het streven naar het principe ‘data bij de bron’ zal de nodige bereidheid tot verandering vergen van
de betrokken organisaties in het digitale overheidsdomein. Vanuit FDS sturen we o.a. op het geven
van inzicht in de wettelijke grondslag(en) en mogelijke gebruikscontexten van de data in het
stelsel. Verder stimuleren we door actieve promotie het concept en de toepassing ervan, in
samenwerking met het programma ‘Data bij de bron’.
FDS is gericht op het optimaal en vertrouwd kunnen delen van data. Hiervoor is een raamwerk nodig
dat vertrouwen creëert en waarborgt. Het fundament van het vertrouwensraamwerk is wetgeving, die de
verantwoordelijkheid en inrichting regelt voor functies en mechanismen in het stelsel die waarborgen
bieden voor de volgende aspecten:
veilig en verantwoord gebruik van data,
waarborgen van privacy,
rechtmatige en gerechtvaardigde toegang tot data,
transparantie over aanbod en gebruik van data,
faciliteren van certificeringen en audits,
toezicht en audits,
…
Deze mechanismen moeten het vertrouwen van de deelnemers in het stelsel vergroten. De uitwerkingen
van capabilities zoals onder andere ‘Vertrouwen’ zullen
resulteren in het vertrouwensraamwerk.
10 - Stelselfuncties
De stelselfuncties van FDS
Voor een goede werking van het stelsel onderscheiden we een beperkte set aan organisatorische en
technische stelselfuncties. Deze functies zorgen ervoor dat gebruikers het stelsel als een geheel
ervaren en dat ze het data-aanbod in FDS zo eenvoudig mogelijk kunnen gebruiken.
De stelselfuncties worden bij voorkeur decentraal ingevuld op basis van afspraken, standaarden en/of
voorzieningen, waarbij het uitgangspunt ‘Afspraken boven standaarden boven voorzieningen’ van
toepassing is.
Onderstaand diagram toont de verschillende stelselfuncties binnen FDS.
Doel Inzicht bieden in het aanbod van data en dataservices.
Status Er is een federatieve catalogus voorzien, om inzicht en overzicht te bieden in
beschikbare data en dataservices.
Achtergrond
De in- en overzichtfunctie is één van de stelselfuncties van het te realiseren Federatief
Datastelsel (FDS). Deze stelselfunctie maakt het mogelijk om vanuit verschillende perspectieven een
totaalbeeld te krijgen van de inhoud van het FDS: welke data conform het FDS-afsprakenkader wordt
gedeeld, waarvoor deze data kan worden gebruikt, welke partijen betrokken zijn bij dit gebruik en
hoe deze zich binnen de federatie tot elkaar verhouden.
FDS context & positionering
Dit wordt mogelijk omdat is afgesproken dat alle componenten van het FDS (deelnemers, datasets en
datadiensten) van betekenisvolle beschrijvende gegevens (metadata) worden voorzien die op een
gestandaardiseerde manier openbaar beschikbaar worden gesteld. Hiermee ontstaat een virtuele open
(meta)dataset, een ‘catalogus’, die op verschillende manieren kan worden ontsloten en doorzocht.
Zo kan bijvoorbeeld worden opgezocht welke gegevens er in de basisregistratie WOZ zijn opgenomen,
wat de betekenis en de kwaliteit daarvan is en met welke datadiensten dit aanbod is ontsloten.
Hoewel de in- en overzicht functie op zich alleen zaken passief toont (overzicht biedt), levert dit
wel het inzicht dat nodig is om op een verantwoorde manier actief met het datapotentieel aan de slag
te kunnen gaan.
Omdat de gekozen afspraken en standaarden het mogelijk maken om ‘alles met alles’ te verbinden en de
FDS-metadata zelf ook een volgens de FDS-standaarden ontsloten (virtuele) dataset is, kan iedereen
naar eigen behoefte met de open FDS-metadata aan de slag. Zo is het bijvoorbeeld mogelijk om een
catalogus te bouwen waarin wetgevingsjuristen eenvoudig kunnen zoeken of een bepaald begrip al in
bestaande FDS-data voorkomt, welke definitie het daar heeft en aan welke juridische grondslag (wet,
regeling) deze definitie is ontleend. Gebruikers die bijvoorbeeld met het thema energietransitie aan
de slag willen, kunnen op basis van daarmee verbonden trefwoorden zoeken welke data daarvoor in het
FDS beschikbaar is en of deze voor hen bruikbaar zijn (qua toegang, kwaliteit, betekenis etc.) Dat
zoeken kan in de eigen catalogus van het FDS, maar het is ook mogelijk om de FDS-metadatadiensten in
een eigen energiecatalogus te integreren die ook niet-FDS-data ontsluit om zo de gebruikers een
totaalbeeld van het energiedata-aanbod te geven. Omdat de FDS afspraken en standaarden voor het
ontsluiten van meta data het mogelijk maken om op begrippen te zoeken, ondersteunen ze ook het
oppakken van semantische harmonisatie en andere acties om verschillende databronnen beter op elkaar
te laten aansluiten en om wetgeving en data beter met elkaar te verbinden. Ze maken het namelijk
mogelijk om een overzicht te krijgen van begrippen met een verschillende naam, maar dezelfde
betekenis (synoniemen), van begrippen met dezelfde naam maar juist een verschillende betekenis
(homoniemen), of van begrippen die zijn opgebouwd uit een combinatie van een aantal andere begrippen
(concepten).
De in- en overzichtfunctie is daarmee een belangrijk instrument voor het creëren van waarde met de
in het FDS opgenomen data.
De in- en overzichtfunctie is ook vanuit een ander perspectief van belang. Omdat iedereen de
metadata kan raadplegen (het is immers open data), wordt de inhoud van het FDS volledig transparant,
waardoor dit ook onderwerp kan zijn van publiek debat. Dit is een bewuste keuze omdat bij het FDS de
publieke waarden centraal staan. Deze openheid betreft uiteraard alleen de beschrijvende data (de
metadata) en niet de data zelf. De individuele gegevens binnen de datasets zijn en blijven alleen
toegankelijk voor degenen die daartoe zijn geautoriseerd.
Beoogde werking
Voor het aanbieden van de metadata gelden dezelfde principes als voor andere FDS-data. Dit betekent
dat degene die data in het stelsel aanbiedt zelf de kenmerken van deze data beschrijft en zelf
diensten levert om deze metadata ‘bij de bron’ te kunnen bevragen. Door aan te sluiten bij gangbare
wereldwijde, Europese en nationale standaarden voor het generen, vastleggen en ontsluiten van
metadata wordt deze meervoudig bruikbaar. Data-aanbieders hoeven dit in principe slechts één keer te
doen om hun aanbod in alle voor hen relevante datastelsels (dataspaces) voor mensen en machines
vindbaar te maken. Het op het FDS toegesneden data-aanbod kan hieruit gedestilleerd worden door in
de metadata een ‘FDS-label’ op te nemen als in het aansluitproces is vastgesteld dat aan de
FDS-kwaliteitseisen wordt voldaan. Door voor dit labelen een stelseloverstijgende standaard af te
spreken, kunnen data-aanbieders op uniforme wijze in de metadata laten zien aan welke
afsprakenstelsels ze voldoen, dus in welke datastelsels hun data gebruikt kunnen worden. Met deze
aanpak wordt de variëteit in het datagebruik ondersteund en worden tevens groeipaden gefaciliteerd.
Open overheidsdata waarvan de metadata al wel op orde is, maar die bijvoorbeeld alleen nog maar als
download beschikbaar is, kan al meteen op data.overheid.nl worden aangeboden terwijl deze pas later,
nadat bijvoorbeeld door het toevoegen van een API het FDS-label is verdiend, ook in de FDS-catalogus
verschijnt.
Van visie naar werkelijkheid: het realisatietraject
In de kop van de vorige paragrafen werd het woord “beoogd” gebruikt. Dat illustreert dat er nog het
nodige te doen valt voordat we zover zijn. Soms betreft dit ontwikkeling omdat de benodigde metadata
standaarden er nog niet zijn, soms betreft dit het kiezen uit verschillende concurrerende
standaarden en soms is de standaard duidelijk maar moet deze nog op de Nederlandse situatie worden
toegespitst of moet er worden afgesproken hoe je de standaard precies gaat gebruiken.
Zelfs als dit alles achter de rug is, moet er nog ervaring worden opgedaan met het in onderlinge
samenhang toepassen van deze standaarden om het verlangde inzicht en overzicht op FDS-(totaal)niveau
te krijgen. Als elke FDS-deelnemer zelf het wiel uit moet vinden, zijn we vele jaren verder voordat
deze essentiële stelselfunctie voldoende bruikbaar is. Het FDS-realisatieproject zal daarom
ondersteuning bieden om de realisatie en implementatie te versnellen. Daarbij wordt de volgende
aanpak gehanteerd:
Vertrekpunt is het denkwerk dat al binnen de Nora-community is gedaan (zie de bijlage onderaan dit
hoofdstuk).
Het FDS-project onderneemt in samenwerking met de verantwoordelijke beheerders van bestaande
metadata voorzieningen en de (potentiële) data-aanbieders actie om de hierna genoemde
voorzieningen verder te ontwikkelen. Dit als tijdelijke overbrugging naar de uiteindelijke
oplossing van een op afspraken en standaarden gebaseerd federatief werkend virtueel geheel, met
voor het FDS mogelijk nog een eigen ‘catalogus’ ingang om eenvoudig een overzicht te krijgen van
het data aanbod dat aan de eisen van het FDS-afsprakenstelsel voldoet.
Voor het beschrijven van datasets is dit nu data.overheid.nl. De relevante standaard hiervoor is
DCAT.
Voor het beschrijven van de in data opgenomen gegevens is dit nu de stelselcatalogus. Relevante
standaarden hiervoor zijn SKOS, MIM en de standaard voor het beschrijven van begrippen (SBB).
Voor het beschrijven van dataservices (API’s) is dit developer.overheid.nl.
Voor nieuwe elementen zoals het beschrijven van de stelseldeelnemers en de kwaliteit van data en
-diensten (het inhoud geven aan het FDS-label) ontwikkelt het FDS-project in samenwerking met
kennisinstituten zoals Geonovum nieuwe standaarden die in het Digilab worden beproefd om te
verifiëren of ze praktisch werkbaar zijn.
Het FDS zorgt voor het ontwikkelen van afspraken en standaarden voor het betekenisvol verbinden
van de verschillende metadatabronnen, waarbij met in het Digilab te ontwikkelen
referentietoepassingen beproefd wordt of deze op een werkbare manier het beoogde totaalbeeld
opleveren. Hierbij wordt aansluiting gezocht bij proeven en pilots die voor de EU of sectorale
dataspaces worden gedaan.
Als is aangetoond dat het werkt en werkbaar is, worden koplopers gezocht die de componenten van de
FDS in- en overzichtfunctie voor (een deel van) hun aanbod willen implementeren. Hiermee wordt
duidelijk wat er nodig is om het samenhangend geheel van bestaande en nieuwe meta data standaarden
in de uitvoeringspraktijk toe te passen en komen er ervaringscijfers beschikbaar waarmee geraamd
kan worden hoeveel tijd en geld er nodig is om ze stelselbreed toe te gaan passen.
De opgedane praktijkervaring wordt vervolgens benut om de formele besluitvorming over de
opschaling in gang te zetten, met behandeling van de voorstellen in het Interbestuurlijk Data
Overleg (IDO) en het Overheidsbreed Beleidsoverleg Digitale Overheid (OBDO) en een openbare
consultatie van volgens de bestaande procedures van het Forum Standaardisatie.
Als de formele besluitvorming succesvol is afgerond zal het FDS-project de adoptie aanjagen door
de stelselpartijen te ondersteunen bij de implementatie van de (nieuwe) metadata-afspraken en
-standaarden. Hierbij kan gedacht worden aan het beschikbaar stellen van validators, het
faciliteren van proefimplementaties en het delen van voorbeelden en best practices.
Standaardisatie
In de NORA wordt gewerkt aan het beter in samenhang duiden van onderwerpen die nu afzonderlijk zijn
beschreven. Daartoe is in de NORA gebruikersraad van september 2023 een opzet besproken van
onderwerpen die raken aan het thema Semantiek en Gegevensmanagement.
10.2 - Monitoringsfunctie
Inzicht bieden in datavolume, datakwaliteit en service level.
Doel Inzicht bieden in datavolume, datakwaliteit en service level.
Status Deze wordt relevant tegen de tijd dat het huidige stelsel is uitgebreid met nieuwe
stelseldata. Deze functie wordt in het huidige stelsel per registratie anders ingericht. Bij
uitbreiding zal hier meer uniformiteit in worden gebracht.
Status Dit is een zeer belangrijke functie om Data bij de
bron te laten slagen. Want als vitale data
elders wordt beheerd, verliezen gebruikers het zicht op relevante mutaties in relatie tot hun
eigen proces. De notificatiefunctie zorgt ervoor dat gebruikers zicht en grip houden op mutaties
van relevante data bij een processtap.
Achtergrond
// TODO
FDS context & positionering
// TODO
Inhoudelijke verdieping
// TODO
Standaardisatie
// TODO
10.4 - Terugmeldfunctie
Digitaal melden van bevindingen mbt de datakwaliteit.
Doel Digitaal melden van bevindingen met betrekking tot de datakwaliteit
Status Een essentiële functie voor de kwaliteit van stelseldata: gebruikers hebben het beste
zicht op de juistheid van (hun) gegevens en moeten de mogelijkheid hebben om fouten en gerede
twijfel te melden. Uit de pilot Makkelijk Melden zijn waardevolle inzichten voortgekomen over deze
functie.
Doel Identificatie, authenticatie en logging. Het gaat om verantwoording datagebruik in
relatie tot de wettelijke grondslagen.
Status Dit is een technische subfunctie van de Poortwachtersfunctie en wordt binnen dat kader
(en via beproeving in het Digilab) ontwikkeld.
Achtergrond
Her en der zijn er diverse definities in gebruik voor de begrippen identificatie, authenticatie en
autorisatie. Voor het federatief datastelsel is ooit de technische functie identificatie,
authenticatie en logging (beveiligings- en veranwoordingsfunctie) benoemd.
FDS context & positionering
Voor het federatief datastelsel gaat het als stelselfunctie om
toegang tot data onder de juiste voorwaarden, de API van de service die data deelt met een
bevragende toepassing, client. Het federatief datastelsel voorziet ook op dit vlak in afspraken en
standaarden.
De voorwaarden die van toepassing zijn bestaan uit het FDS afsprakenkader dat eventueel is aangevuld
met (sector) specifieke voorwaarden. Hierin zijn voorwaarden beschreven bij het gebruiksdoel en de
technische voorwaarden. Met de [in- en overzicht stelselfunctie] (welke functie is dit precies?)
weten gebruikers wat deze voorwaarden zijn.
Aansluitend op de toegang zijn er technische functies voor monitoring en logging voorzien passend
bij de organisatorische functies van poortwachter en
toezichthouder in het federatieve stelsel. Toegang onder de juiste voorwaarden
qua beveiliging en verantwoording is hiermee mogelijk.
Voor het delen van data is identificatie van de aanbieder en afnemer nodig. Het digitale
identiteitenbeheer van personen en organisaties (natuurlijke en niet-natuurlijke personen) is een
vraagstuk op zich.
Voor het FDS gaan we er vanuit dat een partij beschikt over een middel dat een digitale identiteit
aantoont. De authenticatie betreft de verificatie hiervan. Vervolgens is het middel in te zetten om
te komen tot het wederzijds veilig opzetten van een verbinding voor de uitwisseling van data.
Delegatie
Het kan zijn dat een bevragende toepassing werkt met een gedelegeeerde toegangsfunctie. In een
dergelijk geval bevraagt de toepassing namens een bepaalde partij anders dan eigenaar een service.
Die partij verleent de toepassing de bevoegdheid voor de bevraging.
Autorisatie met verantwoording
Kernelement van het federatief datastelsel is dat datagebruik in overeenstemming is met publieke
waarden. Het stelsel voorziet in gecontroleerde toegang tot gevoelige data. Voor het toegang bieden
en afnemen van data die niet gevoelig zijn, volstaan veelal algemene toegangsregels, bijvoorbeeld
bij een aanbieder van open data.
Het bijpassende beleid dat bij een aanbieder en afnemer het gebruik bepaalt, de rechten van gebruik
toekent vormt de autorisatie. Dit is direct verbonden met de voorwaarden die van toepassing zijn
voor de betreffende data.
Logging die hier zo mogelijk een rol bij speelt met oog op verantwoording is bij zowel afnemer als
aanbieder aanwezig (afhankelijk van de voorwaarden, gevoeligheid van data).
Aan de kant van de afnemer ligt de verantwoordelijkheid om goed om te gaan met de data, bijvoorbeeld
om er voor te zorgen dat een eindgebruiker van een toepassing binnen een aangegeven doelbinding
blijft.
Inzicht bieden in gerealiseerde en geautoriseerde koppelingen.
Verantwoordingsfunctie
De Verantwoordingsfunctie is een technische stelselfunctie.
Doel Inzicht bieden in gerealiseerde en geautoriseerde koppelingen.
Status Dit is een technische subfunctie van de Poortwachtersfunctie en wordt binnen dat kader
(en via beproeving in het Digilab) ontwikkeld.
Achtergrond
// TODO
FDS context & positionering
// TODO
Inhoudelijke verdieping
// TODO
Standaardisatie
// TODO
11 - Uit betrouwbare bron
Onderzoek naar de capabilities van een ‘bron’ om een betrouwbare datadienst te zijn in een federatief datastelsel.
In een federatief datastelsel wordt data aangeboden en afgenomen / gebruikt. Over het gebruik van de
data dient verantwoording te worden afgelegd. Niet alleen dát het gebruikt is en waarvoor, maar ook
ter onderbouwing van genomen besluiten. Als een afnemer een besluit baseert op een ‘extern gegeven’
is het wenselijk (noodzakelijk?) dat nagegaan kan worden welk gegeven dat was, welke zekerheid er
aan dat gegeven hangt, dat deze te reproduceren is, dat de oorspronkelijke herkomst duidelijk is,
eventuele correcties, etc, etc. Dit vraagt om uitgebreide capabilities van de datadienst die als
bron wordt gebruikt. Dit dient een betrouwbare bron te zijn. Wat maakt dat een bron als
betrouwbaar gekenmerkt kan worden? Welke capabilities zijn dat?
Project Uit betrouwbare bron
Het Project Uit betrouwbare bron is een project van VNG Realisatie
om uit te vinden welke capabilities een betrouwbare bron nodig heeft en wanneer we dus kunnen
spreken van een betrouwbare bron. Capabilities als Modellen, Dataservices en Traceerbaarheid zullen
op een bepaalde manier ingevuld moeten worden om aan te sluiten op te verwachten bevindingen vanuit
betrouwbare bron. En dat zal ook inzicht geven in de richting waarin de capabilities van FDS
(datadiensten) zich het beste kunnen ontwikkelen om aan te sluiten bij behoeften van afnemers.
Daarom is nauwe samenwerking met en opnemen van de uitkomsten van het project Uit betrouwbare bron
van grote waarde voor de vorming van het FDS.
Relatie tot R-FDS
Nauwe samenwerking en volgen van het Project Uit betrouwbare bron door het R-FDS Team.
2024 Q3 Project Uit betrouwbare bron uitnodigen voor presentatie in inhoudelijk blok
2024 Q3/Q4 actieve samenwerking met Project Uit betrouwbare bron door kennisdeling en
gezamenlijke sessies (met name FDS Architectenteam)
2025 Q1/Q2 update van Project Uit betrouwbare bron in inhoudelijk blok
12 - Rol van private datasets
Wat is voor het FDS een private dataset
Het Federatief Datastelsel (FDS) ontsluit alleen publieke datasets en geen private datasets.
Hieronder wordt uitgelegd wat hiervoor de reden is en wat precies het verschil tussen beide is.
Algemeen kader
Het FDS is een afsprakenstelsel dat voor de overheid het domeinoverstijgend (cross sectoraal)
datadelen faciliteert. Het FDS biedt de aangesloten overheidsafnemers toegang tot de data die ze
nodig hebben voor het uitvoeren van hun wettelijke taken. Kortom een stelsel van en voor de
overheid. Het FDS verschilt daarin van de EU datastelsels / dataspaces die zijn gericht op het
creëren van economische waarde: het mogelijk maken van een “data markt”, of het vereenvoudigen van
het economisch verkeer. Het FDS ondersteunt bovendien alleen het toepassen van het FDS-aanbod. Het
FDS bevat geen afspraken over de totstandkoming van daarvan: de inrichting van de relaties tussen de
(keten)partijen die betrokken zijn bij de inwinning en bijhouding.
Vanwege deze kenmerken biedt het FDS alleen publieke datasets aan en valt het aanbieden van private
datasets buiten de scope van het FDS.
Zie voor een uitleg van het verschil tussen private en publieke datasets de volgende hoofdstukken en
voor meer informatie over het FDS-kader de pagina wat is het FDS.
Wat is in de FDS-context een private dataset?
Een private dataset is een verzameling gegevens die voor rekening en risico van een private partij
is ingewonnen en waarvan een private partij daarom het eigendomsrecht kan claimen. Deze
data-eigenaar moet zich aan algemene kaders zoals de AVG houden, maar kan verder helemaal zelf
bepalen wat hij met zijn data doet en dus ook hoe hij deze aanbiedt. Hij kan zijn data onder een
standaard gebruikslicentie beschikbaar stellen, of hij kan met afnemers specifieke afspraken over
het beschikbaar stellen van de data maken. Deze afspraken zijn bij een private dataset de uitkomst
van een onderhandelingsproces tussen in formele zin gelijkwaardige partijen. De aanbieder is niet
verplicht om zijn data aan te bieden, de afnemer is niet verplicht om deze af te nemen. Wat ze
onderling willen regelen bepalen ze zelf en leggen ze in een overeenkomst vast. Bij datastelsels
waarin private data tussen private partijen wordt gedeeld vormen privaatrechtelijke contracten
tussen de betrokken stelseldeelnemers het formele kader voor de rechten en plichten van
data-aanbieders en data-afnemers
Wat is in de FDS-context een publieke dataset?
In een publiek datadeelstelsel zoals het FDS werkt het anders. Als hoeder van het publieke belang
hebben we als overheid de wet als instrument om zeggenschap over het datadelen af te dwingen. Met
wetgeving kunnen we de private data die we nodig hebben in het publiek domein trekken. Een voorbeeld
hiervan is de wettelijke verplichting voor netwerkbeheerders om gegevens over de ligging van hun
netwerk aan de door het Kadaster beheerde kabel- en leidingenregistratie te leveren. Zo kunnen we
als overheid ook gegevens die we niet zelf hebben ingewonnen (private gegevens) onderdeel van bij
wet ingestelde registratie maken. Het zijn daarmee publieke gegevens geworden. Bij het ontwerp van
het het FDS is aangenomen dat we als overheid het wettelijk instrumentarium toepassen om relevante
data voor overheidsgebruik te verkrijgen. Via wet- en regelgeving kan vervolgens het delen worden
beperkt, of juist worden verruimd (aanmerken als open data) en kunnen er eisen worden gesteld aan in
de dataset opgenomen gegevens, zoals het verplicht toepassen van voor de overheid belangrijke
identifiers (zoals bsn’s, kvk’nrs, bag-id’s). Het FDS ontsluit dus datasets die op grond van een wet
worden ontsloten, waarbij in wetgeving de rechten en plichten van data-aanbieders en data-afnemers
zijn vastgelegd. Bij die datasets is er geen sprake van de voor private data zo kenmerkende
contractvrijheid.
Belangrijk hierbij is dat het FDS-afsprakenkader alleen het domeinoverstijgend, datadelen tussen
overheden reguleert en niet de inwinning en bijhouding van de onder het FDS-regime aangeboden
datasets. Het is heel gebruikelijk dat een FDS data-aanbieder voor het vullen van een vanuit zijn
wettelijke taak aangeboden publieke dataset gebruik maakt van door private partijen ingewonnen
gegevens. Het inrichten van de daarvoor benodigde gegevensuitwisseling tussen private bronhouders en
de overheidsorganisatie die als FDS-data aanbieder optreedt, valt echter buiten het
FDS-afsprakenkader aangezien het hier sector/domeinspecifieke ketenprocessen betreft. Het reguleren
daarvan is de taak van het voor het domein verantwoordelijke beleidsdepartement.
Rationale: waarom worden private, niet op grond van een wettelijke taak aangeboden, datasets buiten de FDS-scope gehouden?
Privaat aanbod faciliteren vergroot de complexiteit en leidt tot extra kosten:
Bij het ontbreken van een wettelijke taak kan het onder het FDS-afsprakenstelsel ontsluiten van de
private dataset als een marktactiviteit worden beschouwd waarvoor de gedragsregels uit de Wet
Markt en Overheid gelden. In dat geval is de FDS-data-aanbieder bijvoorbeeld verplicht om alle met
de datadienst gemoeide kosten,inclusief BTW, aan de FDS data-afnemers door te berekenen.
Bij datadelen op grond van een publieke taak kan conformiteit met het FDS-afsprakenkader vanuit de
overheid verplicht worden gesteld. Daarmee worden rechten en plichten van data-aanbieders en
data-afnemers overkoepelend geregeld. Bij een zuiver privaatrechtelijk aanbod zal elke
data-afnemer zelf een contract met de data-aanbieder moeten afsluiten om de betreffende data te
kunnen afnemen.
Vanuit governance perspectief is een privaatrechtelijk gereguleerde ontsluiting ook ingewikkeld.
Er zijn dan geen beleidsopdrachtgevers die als stelselregisseur sturend kunnen optreden en
gezamenlijk bindende generieke stelselafspraken kunnen maken, bijvoorbeeld over het toepassen van
een nieuwe standaard of over de verrekening van de kosten. Zonder wettelijk basis kunnen private
data-aanbieders ook niet aan het stelseltoezicht worden onderworpen.
Bij een privaat, niet wettelijk gereguleerd, aanbod, zijn er ook meer continuïteitsrisico’s.
Contracten zijn eindig en de aanbiedende partij kan er mee stoppen als het voor hem niet meer
aantrekkelijk is en als de private partij failliet gaat, houdt het sowieso op.
Er wordt vooralsnog van uitgegaan dat het meeste data-aanbod dat gekwalificeerd is voor verantwoord
meervoudig, cross sectoraal datadelen voor het uitvoeren van overheidstaken voortkomt uit een door
de overheid gereguleerde registratie en dat de restgroep van zuiver privaat aanbod te klein is om de
meerkosten van opname in het FDS te rechtvaardigen.
Deze scopebeperking heeft overigens alleen betrekking op het data-aanbod vanuit het FDS (de
datasets). De interoperabiliteitsafspraken en -standaarden die in het FDS worden toegepast zijn ook
bruikbaar voor het binnen sectoren/ketens delen van (private) datasets die niet aan de
FDS-deelnamevoorwaarden voldoen.
13 - IMX
IMX staat voor een crossdomain informatiemodel, model-mapping syntax en orkestratie engine
IMX, oorspronkelijk IMX-geo, of model-gedreven orkestratie, verbindt geo-basisregistraties zonder wijzigingen aan de bron te eisen. Het doel is gegevens te optimaliseren voor specifieke doelgroepen en deze in de taal van de gebruiker aan te bieden, terwijl de gegevens herleidbaar blijven naar hun authentieke bron(nen).
IMX maakt gebruik van een model-mapping concept, waarbij gegevens uit meerdere bronmodellen worden vertaald naar een productmodel. Dit gebeurt op een declaratieve manier, wat inhoudt dat de mappingregels en orkestratie “stapelbaar” zijn en machine-leesbaar worden gespecificeerd.
De IMX-beproeving in Digilab heeft aangetoond dat de technologie effectief is in het orkestreren van data uit verschillende bronnen zonder de noodzaak van data-kopieën.
Het vervolgonderzoek richt zich op de uitbreiding van de IMX-methodologie naar niet-geo-registraties. Doel is om door middel van model-gedreven orkestratie gegevens uit verschillende registraties te combineren zonder de noodzaak voor data-kopieën.
Belangrijke aspecten zijn het verbeteren van beveiligingsstandaarden (zoals authenticatie en autorisatie) en het aansluiten bij linked data. Dit onderzoek moet bijdragen aan bredere toepasbaarheid en draagvlak binnen de overheid, wat een toekomstbestendige oplossing biedt voor datadeling en integratie binnen het FDS.
Dit vervolgonderzoek dat loopt vanaf augustus ‘24 tot begin volgend jaar (2025), omvat onder andere een proof of concept om de beveiligingsarchitectuur te testen en om te bepalen hoe bestaande metadata-standaarden zoals DCAT en lineage modellen gebruikt kunnen worden voor niet-geo-registraties.
14 - Informatiekundige kern van het FDS
Uitleg concept informatiekundige kern
Uitleg van het doel en de inhoud van de informatiekundige kern van het FDS
Het onderkennen van een Informatiekundige kern is een belangrijk element binnen het ontwerp van het
Federatief Datastelsel (FDS). Het is echter ook een nieuw concept met het risico van
begripsverwarring en verkeerde toepassing. Hieronder wordt in verschillende stappen uitgelegd waarom
we een informatiekundige kern binnen het FDS onderkennen, wat het concreet inhoudt en hoe
stelselpartijen er mee om moeten gaan.
Wat maakt een stelsel tot stelsel?
Een setje losse datasets (registraties) wordt een datastelsel doordat gegevens in die datasets
betrouwbaar aan elkaar kunnen worden gerelateerd. Informatiekundig is het dan belangrijk dat je
zeker weet dat je het over hetzelfde of dezelfde hebt. Wat dan erg helpt is dat je afspreekt om
gebruik te maken van dezelfde identificerende gegevens. Het handigst zijn dan unieke nummers (‘id’s’
of ‘sleutels’). Er zijn immers heel veel Janssens, zelfs heel veel Jan Janssens en misschien zelfs
wel meerdere Jan Janssens die op 4 oktober 1956 zijn geboren, maar er is maar één Jan Janssen met
het BSN 123456789.
Hoe zit het nu? Identificerende nummers in het stelsel van basisregistraties
Binnen elk domein komen identificerende nummers voor van kadastrale object id’s tot kentekennummers
maar zoals de ‘Stelselplaat’ laat zien, worden vooral de identificerende nummers uit de
basisregistratie personen (BRP), het Handelsregister (HR) en de basisregistratie adressen en
gebouwen (BAG) gebruikt om relaties tussen registraties in verschillende domeinen te leggen. De
basisregistraties BRP, HR en BAG vormen daarmee in de praktijk de kern van het huidige stelsel.
Van veel gebruikte basisregistraties naar de informatiekundige kern van het FDS
Waarom zijn de BRP, BAG en HR ook de kern van het Federatief Datastelsel?
Bij het Federatief datastelsel (FDS), de opvolger van het stelsel van basisregistraties, willen we
meer data verbinden om die te gebruiken bij maatschappelijke opgaven. Daarvoor is het vrijwel
altijd nodig om te weten over wie het gaat en/of waar het zich afspeelt.
BRP en HR leveren de gegevens om eenduidig naar die ‘wie’ te verwijzen: de identificerende
gegevens van natuurlijke en niet-natuurlijke personen (organisaties).
De BAG levert de gegevens om eenduidig naar het ‘waar’ te verwijzen: de identificerende gegevens
van een locatie.
BRP, BAG en HR bevatten veel gegevens die wat zeggen over personen, organisaties en locaties, maar
slechts een beperkt deel daarvan is nodig om ze te kunnen identificeren. Die ‘identificerende
gegevens’, vormen de informatiekundige kern van het FDS.
Inhoud van de informatiekundige kern – de essentiële identificerende gegevens
De informatiekundige kern bestaat in elk geval uit de identificerende nummers die specifiek bedoeld
zijn om personen, organisaties en locaties te identificeren: BSN, KVK-nummer en het adresseerbaar
object-id. Deze vormen de essentiële inhoud van de informatiekundige kern. We bouwen een datastelsel
als we afspreken dat elke daarin op te nemen dataset (registratie) in elk geval één van deze nummers
gebruikt voor het vastleggen van gegevens over het wie en waar, oftewel een koppeling legt met de
informatiekundige kern. Binnen het huidige stelsel van basisregistraties is dit al de praktijk. Er
zijn echter meer dan 100 potentiële registraties met waardevolle gegevens over personen en locaties.
Dat zijn allemaal kandidaten voor het nieuwe Federatief Datastelsel. Maar deze registraties bevatten
nog niet allemaal deze identificerende nummers en kunnen of mogen die soms ook niet opnemen (geldt
voor het BSN). Hoe zorg je ervoor dat je ze dan toch al meteen in samenhang kunt gebruiken? Dit
kunnen we oplossen door een beperkt aantal andere gegevens toe te voegen die het mogelijk maken om
de inhoud van deze registraties toch al zinvol te verbinden terwijl ze de essentiële gegevens (nog)
niet kunnen toepassen.
De inhoud van de informatiekundige kern – aanvullende identificerende gegevens
Datasets (registraties) die niet de standaard identificerende nummers bevatten, bevatten vaak wel
andere gegevens uit de BRP, het HR en de BAG waarmee we personen, organisaties en locaties ook
betrouwbaar kunnen identificeren. Hier kunnen we gebruik van maken door deze gegevens ook toe te
passen om binnen het Federatief Datastelsel te koppelen. Je realiseert dan al waarde met deze data
zonder dat je hoeft te wachten tot overal ‘de essentie’ is geïmplementeerd. Om dit goed te laten
werken, moeten we wel duidelijk afspreken wat we precies willen gaan gebruiken: welke gegevens uit
BRP, HR en BAG vormen in eerste instantie samen vanuit informatiekundig perspectief de kern van
het Federatief Datastelsel?
Deze vraag is in 2023 opgepakt door de FDS-werkgroep Informatiekundige Kern. De volgende paragraaf
bevat hun voorstel voor de inhoud van deze kern.
Toepassing van de informatiekundige kern bij het realiseren en benutten van het FDS
Inhoudelijk vertrekpunt
De informatiekundige kern van het Federatief Datastelsel is dus in essentie een afspraak over een
set minimaal toe te passen identificerende gegevens. Daarbij wordt vooralsnog uitgegaan van de
volgende inhoud van deze set:
(Voorstel eind 2023 van de FDS-werkgroep Informatiekundige Kern)
Het werkend krijgen van het concept van de informatiekundige kern
Om te zorgen dat alle stelseldeelnemers de verplicht te gebruiken identificerende gegevens goed
kunnen benutten heeft de werkgroep een aantal ondersteunende functies benoemd.
Dit zijn in elk geval functies voor:
Het opzoeken van sleutels
Specifiek bij persoonsgegevens: het gebruik van pseudoniemen
En mogelijk ook functies voor het wisselen van sleutels, bijvoorbeeld van postcode/huisnummer naar
verblijfsobject-id en vice versa.
De afspraken over de invulling van deze ondersteunende functies moeten nog verder worden uitgewerkt.
Dat geldt ook voor enkele andere zaken die nodig zijn om de kern goed te kunnen toepassen
(bijvoorbeeld over de volledigheid en de kwaliteit van de daarin op te nemen gegevens). Hier gaat
het FDS-project de komende jaren verder mee aan de slag.
15 - Aanbod (metadata)
Registratie van het aanbod binnen het FDS met behulp van DCAT.
Mechanisme
Het aanbod beschrijft de aangeboden datasets en de dataservices die
toegang bieden tot deze datasets. Het aanbod is metadata en wordt
beschikbaar gesteld als linked data volgens de
DCAT standaard.
Hierbij zijn de Linked Data Design Rules
van toepassing.
Elke aanbieder publiceert via self-description zelf een bestand met
het aanbod van betreffende aanbieder. Dit bestand bevat een
DCAT
catalog met van daaruit verwezen alle door de aanbieder aangeboden
datasets en dataservices die voldoen aan de FDS criteria.
Elke deelname-administrateur publiceert een bestand met het volledige
aanbod binnen het FDS. Dit bestand bevat een
DCAT
catalog met van daaruit verwezen alle vanuit deelnemerkenmerken
verwezen DCAT
catalogs van aanbieders.
Indien beschikbaar worden vanuit de door de aanbieder beschreven
datasets en dataservices aanvullende metadata verwezen zoals
kwaliteitskenmerken (op basis van DQV),
begrippen (op basis van
SKOS en
NL-SBB)
en het gehanteerde informatiemodel (op basis van
MIM of
OWL).
Aanbod metadata via DCAT
Voorbeelden
Een voorbeeld van het volledige aanbod vanuit een administrateur
(in Turtle):
@prefix dcat: <http://www.w3.org/ns/dcat#>
@prefix dct: <http://purl.org/dc/terms/>
@prefix fds: <http://fds.example.org/ontology#>
@base <http://admin-a.example.org/fds/dcat/>
<fds-catalog>
dcat:contactPoint 'info@admin-a.example.org' ;
dct:title 'Het FDS aanbod'@nl-nl ;
dct:description 'Het volledige FDS aanbod van alle aanbieders binnen het FDS.'@nl-nl ;
dct:publisher <http://admin-a.example.org/fds/deelnemers/self#deelnemer> ;
dcat:catalog <http://deelnemer-x.example.org/fds/dcat#catalog> ,
<http://deelnemer-z.example.org/fds/dcat#catalog> .
Een voorbeeld van het het aanbod vanuit een aanbieder
(in Turtle):
@prefix dcat: <http://www.w3.org/ns/dcat#>
@prefix dct: <http://purl.org/dc/terms/>
@prefix fds: <http://fds.example.org/ontology#>
@base <http://deelnemer-x.example.org/fds/dcat#>
<catalog>
dcat:contactPoint 'info@deelnemer-x.example.org' ;
dct:title 'Het FDS aanbod van Deelnemer X.'@nl-nl ;
dct:description 'Het aanbod van Deelnemer X binnen het FDS.'@nl-nl ;
dct:publisher <http://admin-a.example.org/fds/deelnemers/organisatie-x#deelnemer> ;
dcat:service <service-a> ,
<service-b> ;
dcat:dataset <dataset-a> .
.... definitie van datasets en dataservices ....
Binnen FDS verwachten we gebruik te gaan maken van
DCAT-AP-NL 3.0. Op
basis van dit generieke applicatieprofiel wordt naar verwachting verder
aangescherpt in een FDS applicatieprofiel in de vorm van een aanvullende
OWL en/of
SHACL
definities.
De identificatie van een deelnemer binnen het FDS.
Identificatie van de deelnemer
Een deelnemer van het FDS heeft een Deelnemer-ID. Een deelnemer-ID kan als URL worden gebruikt om
een linked data (RDF) bestand op te
halen met deelnemerkenmerken zoals het KvK-nummer, RSIN en/of OIN.
Het Deelnemer-ID is een LinkedDataURI. Op de deelnemer-ID
zijn de Linked Data Design Rules van toepassing. Zie ook de
capability Vertrouwen | Identiteit.
Registratie van kenmerken van deelnemers aan het FDS.
Mechanisme
De deelnemerkenmerken bestaan uit voor het FDS relevante kenmerken van een deelnemer.
De deelnemerkenmerken worden door de deelname-administrateur bijgehouden bij het
uitvoeren van de deelnameprocessen. De deelnamelijst
is metadata en wordt beschikbaar gesteld als linked data. Hierbij zijn
de Linked Data Design Rules van toepassing.
De deelnemerkenmerken
De volgende deelnemerkenmerken worden geregistreerd:
Een verwijzing naar het aanbod binnen het FDS (als
DCAT catalog)
De deelnemer wordt binnen de resource geïdentificeerd op basis van een
deelnemer-Id.
Voor beide soorten lijsten wordt een versiehistorie bijgehouden.
De deelnemerkenmerken
De grondslag
De grondslag op basis waarvan de organisatie is toegelaten tot het FDS betreft de
wettelijke taak op grond waarvan de organisatie gegevens kan aanbieden of afnemen
binnen het FDS. Deze grondslag bestaat uit een of meer verwijzingen naar het
BWB.
Betrouwbaarheid
De deelnemerkenmerken worden beschikbaar gesteld door de administrateur die
betreffende deelnemer heeft toegelaten. Dit impliceert dat de ‘hostname’ binnen
het deelnemer-Id een hostname binnen een domein van deze
administrateur is. Door deelnemerkenmerken beschikbaar te stellen via een
domein van de administrateur verleent de administrateur autoriteit aan de
geleverde deelnemerkenmerken.
Een alternatief model is het door de deelnemer zelf ter beschikking stellen
van de deelnemerkenmerken. Dit vergt echter verdere uitwerking van de
deelnemerkenmerken tot
Verifiable Credentials (VC)
volgens eIDAS 2.0. Dit is vooralsnog onvoldoende uitgewerkt om concreet
toe te kunnen passen.
Voorbeelden
Een voorbeeld van een lijst met deelnemerkenmerken (in
Turtle):
Registratie van de deelnemers door de deelnameadministrateur(s).
Mechanisme
De deelnemerslijst bevat verwijzingen naar alle deelnemers van het FDS. De
deelnemerslijst wordt door de deelname-administrateur bijgehouden bij het
uitvoeren van de deelnameprocessen. De deelnamelijst
is metadata en wordt beschikbaar gesteld als linked data. Hierbij zijn
de Linked Data Design Rules van toepassing.
De deelnemerslijst bestaat uit twee delen:
alle wijzigingen (events) op de deelnemerslijst die hebben plaatsgevonden
de volledige lijst met deelnemers die uit deze wijzigingen voortvloeit
Elke administrateur houdt alle wijzigingen bij die deze administrateur doorvoert
(opname en verwijdering). Vervolgens stelt elke administrateur een resulterende
volledige lijst met deelnemers op gebaseerd op de lijsten met wijzigingen van
alle administrateurs in het stelsel.
Voor beide soorten lijsten wordt een versiehistorie bijgehouden.
Het mechanisme van de deelnemerslijst
Zowel de deelnamekenmerken van de administrateur verwijzen naar zowel de lijst met
deelnamewijzigingen als de deelnemerslijst.
De deelnamewijzigingen
Elke administrateur houdt bij welke deelnemers hij opneemt en verwijderd. Deze
wijzigingen worden toegevoegd aan een nieuwe versie van de lijst met
deelnamewijzigingen.
De allereerste wijziging bestaat uit het zichzelf toevoegen van de eerste
administrateur (bootstrapping). Deze eerste administrateur kan vervolgens
andere administrateurs en deelnemers (aanbieders en afnemers) toevoegen.
De deelnemerslijst
Uit de verschillende lijsten met deelnamewijzigingen van de verschillende
administrateurs wordt vervolgens de lijst met deelnemers samengesteld. De deelnemerslijst bevat verwijzingen naar de (versies) van de lijsten met
deelnamewijzigingen die zijn gebruikt om de deelnemerslijst samen te stellen.
Elke administrateur verzamelt periodiek de laatste versie(s) van de lijsten met
deelnamewijzigingen van alle administrateurs. Indien één van de lijsten
met deelnamewijzigingen is aangepast maakt elke administrateur
een nieuwe versie van de deelnemerslijst aan.
De deelnemerslijst
Welke organisatie(s) binnen het FDS deelnameadministrateur worden en of binnen
het FDS daadwerkelijk gebruik gemaakt gaat worden van meerdere administrateurs
is nog onderwerp van onderzoek.
Voorbeelden
Een voorbeeld van een lijst met deelnamewijzigingen (in
Turtle):
Design Rules voor het hanteren van Linked Data binnen het FDS.
Design Rules
Binnen het FDS wordt linked data gebruikt voor metadata. Voor de primaire data
kan linked data ook gebruikt worden. Linked data is een familie van standaarden
en best practices. Er zijn echter vele interpretatiemogelijkheden en vrijheden
die het effectief gebruik van linked data hinderen. Binnen het FDS hanteren
we daarom een aantal design rules voor het gebruik van Linked Data om de
uitwisseling van linked data binnen het FDS te harmoniseren.
De design rules dienen nog te worden uitgewerkt en betreffen bijvoorbeeld:
Follow your nose: een http-request met als url een object-id levert een
bestand met betekenisvolle kenmerken van het betreffende object (inclusief
relevante verwijzingen naar andere objecten).
Content negotiation: het http mechanisme voor content negotiation wordt
gebruikt om een bestand te bieden in een beschikbare gewenste syntax.
Nog te bepalen te hanteren syntaxes en bijbehorende http-content-types:
(zoals Turtle, JSON-LD,
RDF-XML en/of
RDFa)
Metadata wordt ontsloten via https.
Een http requests (op basis van een object-id) dient een redirect uit te
voeren naar eenzelfde request met alleen het protocol gewijzigd
in https.
Eventuele richtlijnen met betrekking tot versionering van bestanden.
Een object-id bevat http als protocol.
Een object-id bevat een #-tag en fragment-naam om onderscheid te maken
tussen het aan te wijzen object en het bestand waarin de triples van betreffend
object zijn opgenomen.
Een object-id bevat een hostname binnen een domein dat eigendom is van
een deelnemer van het FDS.
Een nog te bepalen lijst met standaard prefixes die kunnen worden gebruikt
binnen bestanden.
Aandachtspunten
Object-id’s worden gebruikt om entiteiten over organisaties heen te
verwijzen. Het is onwenselijk dat als gevolg van bijvoorbeeld een naamswijziging
van de registratie, de aanbiedende organisatie of het aangewezen object het
object-id zou moeten wijzigen. Bij het definiëren van object-id’s dient
hiermee rekening gehouden te worden. Indien het toch noodzakelijk is om
de object-id’s te wijzigen, kan de overgang worden gefaciliteerd door:
gebruik te maken van owl:sameAs
om aan te geven dat de oude en nieuwe object-id hetzelfde object betreffen.
bij een request op de oude object-id een redirect uit te voeren naar de
nieuwe object-id.
De administratie van de deelnemers aan het FDS als organisatie wordt ondersteund door de
operationele deelnameprocessen:
Toelaten tot het FDS als deelnemer
Wijzigen of corrigeren van deelnemerkenmerken
Beëindigen of intrekken van deelname
De deelnameprocessen borgen de beschikbaarheid van een actuele en vertrouwde lijst van deelnemers.
De uitvoering van de deelnameprocessen is de verantwoordelijkheid van een deelname-administrateur,
een deelfunctie van de stelselfunctie van regisseur.
Toelaten tot het FDS als deelnemer
Voordat een organisatie de rol van aanbieder of afnemer kan aannemen binnen het FDS,
dient een organisatie deelnemer te worden van het FDS. Om deel te kunnen nemen dient
een organisatie te voldoen aan de deelnamecriteria.
de organisatie onderschrijft de uitgangspunten van het afsprakenstelsel in de
intentieverklaring en volgt de afspraken die
daaruit voortvloeien.
De deelnamecriteria worden getoetst door een deelname-administrateur. Bij toelating
wordt een deelnemer met zijn deelnemerkenmerken opgenomen op de lijst met deelnemers.
De lijst met deelnemers en de deelnemerkenmerken zijn beschikbaar als
Metadata. Zowel aanbieders als afnemers kunnen de
metadata raadplegen om te verifiëren of de andere partij deelnemer is.
Nadat een aanbieder is toegelaten als deelnemer dient de aanbieder het proces te doorlopen
om een dataset als aanbod in te brengen.
Nadat een afnemer is toegelaten kan de afnemer een een verzoek tot datadelen indienen bij
een aanbieder. De aanbieder kan in de deelnemerslijst nagaan of de afnemer een vertrouwde
partij is.
Een aantal aspecten zijn nog onderwerp van onderzoek:
Eventuele aanvullende deelnamecriteria.
Het hanteren van één of van verschillende niveau’s van vertrouwen. Meerdere
niveaus van vertrouwen vergt criteria om een niveau op te baseren. Daarnaast zal een deelname-
administrateur moeten toetsen op deze criteria bij het toelaten van een deelnemer.
Wijzigen, corrigeren, beëindigen en intrekken
Naast het toelaten ondersteunt de deelname-administrateur de processen om deelnemerkenmerken
te wijzigen of corrigeren en om een deelname te kunnen beëindigen of in te trekken.
De deelname-administrateur
De deelname-administrateur ondersteunt de processen om de deelnemers binnen het FDS te administreren.
De deelname-administrateur is een deelfunctie van de stelselfunctie van
regisseur.
De registratie van deelnemers is zodanig opgezet dat het mogelijk is om deelnameprocessen door verschillende
deelname-administrateurs uit te laten voeren. Dit maakt het mogelijk om bijvoorbeeld voor bepaalde sectoren een
sectorspecifieke deelname-administrateur aan te wijzen. Een sectorspecifieke deelname-administrateur
kan beter ingericht zijn om vast te stellen of een organisatie een wettelijke taak heeft binnen betreffende
sector (bijvoorbeeld voor zorg- of onderwijsinstellingen). Of we binnen het FDS daadwerkelijk gebruik
gaan maken van meerdere deelname-administrateurs is nog onderwerp van onderzoek.
21 - Handreiking FDS-datadiensten
Deze handreiking ondersteunt bij het opstellen van gestandaardiseerde dienstenniveaubeschrijvingen voor FDS-datadiensten.
Deze handreiking ondersteunt bij het opstellen van gestandaardiseerde dienstenniveaubeschrijvingen
voor FDS-datadiensten. Deze inhoud is het resultaat van samenwerking met onze omgeving in de
praktijk tijdens de FDS-werkgroep servicekwaliteit, hierbij werkten we samen met deelnemers vanuit
het Kadaster, TNO, Logius en het FDS-projectteam.
Context
Bij het werken conform het principe ‘data bij de bron’ worden data-afnemers voor hun bedrijfsvoering
afhankelijk van de datadiensten van FDS-data-aanbieders. Afnemers zullen daarom willen weten welk
dienstenniveau (service level) zij mogen verwachten zodat ze kunnen inschatten of dat in hun geval
afdoende is. Omdat in dezelfde bedrijfstoepassing veelal datadiensten van verschillende
data-aanbieders worden gecombineerd, is het wenselijk dat data-aanbieders afspreken om hun
dienstenniveau op een uniforme manier te beschrijven. In eerste instantie gaat het daarbij om
standaardisatie van de inhoud van de dienstenniveau beschrijving. Dit bestaat uit een afspraak over
de dienstenniveau aspecten die minimaal moeten worden beschreven, aangevuld met afspraken over de
daarbij te hanteren begrippen. Dat laatste zorgt voor de noodzakelijke ’eenheid van taal’: dat we
binnen het FDS in dienstenniveaubeschrijvingen dezelfde begrippen gebruiken en we daar ook dezelfde
betekenis aan geven. Op een later moment kan deze handreiking worden uitgebreid met afspraken om het
dienstenniveau zelf te gaan standaardiseren door binnen het FDS standaard niveaus (serviceklassen)
te definiëren waarin het FDS data-aanbod kan worden ingedeeld (bijvoorbeeld basis, plus en vitaal).
Uitgangspunten voor het opstellen van een FDS-conforme dienstenniveaubeschrijving
Het beoogd toepassingsdomein van de deze handreiking is het opstellen van
dienstenniveaubeschrijvingen voor FDS-conforme datadiensten bestemd voor tot het FDS toegelaten
data-afnemers. Deze afnemers zijn de organisaties die de aangeboden dienst daadwerkelijk in hun
bedrijfsprocessen gaan toepassen. Deze handreiking is dus niet van toepassing op beschrijvingen
die bedoeld zijn om aan opdrachtgevers/financiers duidelijk te maken wat er geleverd gaat worden.
Uitgangspunt binnen het FDS is dat in de metadata die hoort bij een datadienst er een relatie
wordt gelegd (wordt gelinkt) met het van toepassing zijnde (standaard) dienstenniveau. Het is dus
niet nodig om in de dienstenniveau beschrijving zelf op te nemen op welke diensten deze van
toepassing is.
Zoals de titel aangeeft heeft de beschrijving van het dienstenniveau betrekking op het beschrijven
van kwaliteitsaspecten van de dienstverlening m.b.t. het afnemen van FDS-conforme datadiensten.
Deze beschrijving is aanvullend op algemene FDS-deelnamevoorwaarden (de toetredingseisen) die
gekoppeld zijn aan de rol die een stelseldeelnemer vervult. Deze deelnamevoorwaarden bevatten
stelselbrede afspraken over zaken als de te implementeren standaarden, het toe te passen
beveiligingsniveau en het in te richten kwaliteitsmanagement. Deze elementen hoeven in de
dienstenniveaubeschrijving dus niet (opnieuw) te worden benoemd.
Verplichte inhoud dienstenniveaubeschrijving voor FDS-datadiensten
Hierna worden de minimaal op te nemen onderdelen beschreven. De onderdelen waarbij de exacte
betekenis van belang is, zijn in een tabel opgenomen. Deze tabel bevat de definitie van het
betreffende onderwerp aangevuld met een toelichting en een voorbeeld.
Bereikbaarheid data-aanbieder
Een beschrijving van de kanalen (telefoonnummers, e-mailadressen, url’s webformulieren, url’s
chatbots/digitale assistenten, sociale media etc.) die data-afnemers kunnen gebruiken om met de
data-aanbieder contact op te nemen voor :
Algemene vragen.
Het melden van verstoringen in de dienstverlening.
Het rapporteren van data fouten (terugmeldingen).
Het indienen van klachten.
Actuele informatie over de dienstverlening
Een link naar één of meerdere webpagina’s waar de data-afnemers in elk geval informatie kunnen
vinden over:
Actuele verstoringen.
Gepland onderhoud / geplande onbeschikbaarheid.
Voorgenomen wijzigingen.
Het gerealiseerde dienstenniveau (de beschikbare dienstenniveaurapportage).
Het is de bedoeling om op termijn dit soort informatie te standaardiseren zodat het op FDS-niveau
kan worden gebundeld en data-afnemers eenvoudig kunnen nagaan hoe het stelsel als geheel presteert.
Beschikbaarheid
Onderwerp
Toelichting
Niveau
Openingstijd Tijdvenster waarbinnen de dienst kan worden afgenomen
Bijvoorbeeld 7*24 uur
Servicetijd Tijdvenster waarbinnen gebruikersondersteuning wordt aangeboden en het functioneren van de dienst actief wordt bewaakt
Buiten de servicetijd is sprake van passieve bewaking, d.w.z. alleen automatisch herstel verstoringen (voor zover mogelijk).
Bijvoorbeeld Ma-Vr 7.00-18.00
Onderhoudsvenster Tijdvenster dat beschikbaar is voor het uitvoeren van onderhoud dat kan leiden tot tijdelijke onbeschikbaarheid van de dienst
Van tevoren aangekondigde inperking van de openingstijd.
Organisaties kunnen vaste onderhoudsvensters hanteren, maar het is vaak praktischer om onderhoud in te plannen zodra dat nodig is. Afnemers kunnen dan toch zekerheid krijgen door af te spreken dat het minimaal x dagen van tevoren wordt aangekondigd.
Bijvoorbeeld: Elke 2e zaterdag van de maand van 9.00 uur tot 23.00 uur
Geplande onbeschikbaarheid (gebruik van het onderhoudsvenster) wordt uitgevoerd buiten de servicetijd en minimaal 10 werkdagen van tevoren aangekondigd.
Beschikbaarheid Tijd dat de dienst binnen de servicetijd kon worden afgenomen als percentage van de totale openingstijd binnen een kalendermaand.
Gemeten op het aanbiedingspunt van de datadienst en exclusief gepland onderhoud binnen het onderhoudsvenster.
Bijvoorbeeld: 95%
Robuustheid: maximale uitvalduur
Maximum totaal aantal minuten per kalendermaand dat de dienst gedurende de servicetijd onbeschikbaar mag zijn.
Bijvoorbeeld: 360 minuten
Robuustheid: maximaal aantal langdurige verstoringen
Maximaal aantal verstoringen per kalendermaand met meer dan X aangesloten minuten onbeschikbaarheid binnen de servicetijd
Bijvoorbeeld maximaal 2 verstoringen van meer dan 60 minuten
Versie- en wijzigingsbeheer
Het versiebeheer en het daarmee verbonden wijzigingsbeheer moeten ervoor zorgen dat afnemers
zekerheid krijgen over de impact van gewijzigde datadiensten op hun eigen IT-diensten en de tijd die
voor hen beschikbaar is om deze impact te verwerken. In de dienstenniveaubeschrijving moet worden
aangegeven of op de aangeboden dienst wel of geen formeel proces van toepassing is voor het
introduceren van gewijzigde versies van de aangeboden datadienst en wat daarvan de belangrijkste
kenmerken zijn. Hierbij moet onder andere gespecificeerd worden hoe ‘versioning’ wordt ingevuld en
hoeveel (majeure) versies er gelijktijdig worden ondersteund. Voor API-gebaseerde datadiensten moet
daarbij van onderstaande standaard voor versienummering worden uitgegaan:
Toepassing van dit model conform de Nederlandse API
Strategie is een
minimumvereiste om bij dit onderdeel een ‘ja’ te mogen invullen. Het model voorziet in
standaardisatie van de opbouw van het versienummer dat de afnemer inzicht geeft in de impact van de
wijziging en stelt aanvullende eisen aan het versiebeheer zoals het publiceren van een ‘change log’.
Optionele onderdelen
Dit zijn onderwerpen die in de dienstenniveaubeschrijving wel moeten worden benoemd, maar waarop FDS
data-aanbieders geen actief beheer hoeven te voeren. Er hoeft alleen te worden aangegeven of er wel
of niet sprake is van een gegarandeerd niveau. Oftewel of er sprake is van meer dan een
inspanningsverplichting (‘best effort’). Aan de claim van een gegarandeerd niveau worden soms wel
voorwaarden gesteld, maar het staat de organisatie verder vrij om dit niveau naar eigen inzicht te
beschrijven. Hier is voor gekozen omdat organisaties dit zo verschillend invullen dat
standaardisatie niet mogelijk is.
Performance- en capaciteitsbeheer
Het performancebeheer moet er voor zorgen dat de afnemers van een stabiele performance ervaren. In
de dienstenniveaubeschrijving moet worden gespecificeerd of de afnemers een gegarandeerde
performance kan worden geboden. Bij een positief antwoord is het belangrijk dat het voor de afnemer
duidelijk is wat het referentiepunt is (waar wordt er gemeten?) en of er randvoorwaarden gelden
zoals een maximale capaciteitsvraag. Verder is het van belang om te specificeren of er bij het
toekennen van capaciteit en het borgen van de performance prioritaire afnemers kunnen worden
onderkend. Dit is van belang voor afnemers die op dit gebied zekerheid zoeken, zoals de meldkamers
van politie en hulpdiensten.
Calamiteitenbeheer
Een beschrijving van eventuele specifieke voorzieningen die zijn getroffen om de gevolgen van
calamiteiten op te vangen. Een calamiteit wordt hierbij gedefinieerd als een zeldzaam voortkomende
gebeurtenis die kan leiden tot een omvangrijke en langdurige verstoring van de dienstverlening van
de data-aanbieder en waarvan niet van tevoren te voorspellen is of en wanneer deze gebeurtenis zich
zal voordoen. Van oorsprong waren het fysieke ‘rampen’ (in het Engels ‘acts of God’) zoals het
afbranden en overstromen van het rekencentrum met ‘uitwijk’ als maatregel, maar tegenwoordig kunnen
ook bepaalde succesvolle cyberaanvallen, zoals een ransomware attack, als een calamiteit worden
beschouwd.
In de dienstenniveaubeschrijving moet worden aangegeven of voor de aangeboden dienst wel of geen
maatregelen zijn getroffen om de gevolgen van calamiteiten op te vangen. Bij een positief antwoord
moet in de dienstbeschrijving worden toegelicht welk niveau er wordt geboden. Bijvoorbeeld wat de
maximale uitvalduur is, wat het maximale dataverlies is en wat na een calamiteit nog de maximaal
beschikbare capaciteit is. Om te kunnen claimen dat in calamiteitenbeheer is voorzien moet de
dienstaanbieder in elk geval een functionerende ‘consignatiedienst’ hebben ingericht.
Consignatiedienst (synoniem ‘piketdienst’ of ‘crisisdienst’)
Een permanent ingericht geheel van organisatorische en technische maatregelen om ook buiten de servicetijd te kunnen constateren dat er (waarschijnlijk) een calamiteit is opgetreden en direct de van toepassing zijnde beheerprocedure te kunnen starten.
De invulling is vrij. Organisaties kunnen bijvoorbeeld een specifieke IT-consignatiedienst instellen, maar kunnen ook een algemene bereikbaarheidsdienst voor noodgevallen instellen.
22 - Deelnemen aan het FDS
Hier lees je alles over hoe je kunt deelnemen aan het federatief datastelsel
Wees welkom en doe mee
We zijn blij dat je meer informatie wilt lezen over hoe je kunt deelnemen, want het succes van het
stelsel is een optelsom van de bijdragen van de deelnemers. Deelname aan het stelsel brengt ook
rechten en plichten met zich mee, zoals: aan de collectieve afspraken en standaarden voldoen, denk
hierbij aan beschrijven en monitoren van de data(kwaliteit). Niet alle afspraken en standaarden zijn
al allemaal uitgewerkt, maar hier bieden we inzicht hoe dit proces er tot nu toe uit ziet.
Meepraten en meedenken over de gezamenlijke koers, afspraken en standaarden is belangrijk, omdat zo
collectief kennis, templates en voorbeelden ontstaan om de stelseldeelnemers te faciliteren en te
ondersteunen. Transparantie over deelname, beschikbaarheid van data en behaalde resultaten staan
hierbij centraal.
Processtappen deelnemen data-aanbieders
Organisaties kunnen in 6 stappen participeren in het fds.
Voorverkenning
Als een organisatie een interessante dataset in beheer heeft en deze beschikbaar wil stellen via het
afsprakenstelsel is er in de meeste gevallen al contact geweest met vertegenwoordiging vanuit het
fds. Bijvoorbeeld met de marktmeester. Ook kunnen de deelnamevoorwaarden als test al eens (samen)
nagelopen zijn om te beoordelen of er voldoende aansluitingsmogelijkheden zijn.
Stap 1: Aanmelden
De organisatie meldt zich aan met één of meerdere datasets bij het fds en geeft daarbij aan wie het
aanspreekpunt vanuit de organisatie is voor het fds (veelal de CDO) en wie op het niveau van de
individuele dataset (contactgegevens). Fds registreert de aanmelding en zorgt voor verwerking in de
fds-deelnemersregistratie.
Stap 2: Deelname als organisatie
Wij nemen contact op met de contactpersoon ter tekening van de intentieverklaring
fds. Dit betekent dat er op bestuurlijk niveau commitment van de data-aanbieder
is op de (deels nog te vormen) afspraken, standaarden en voorzieningen van het fsd en dat de
data-aanbieder een actieve bijdrage wil leveren aan gestandaardiseerde overheidsbrede datadeling.
Fds registreert het tekenen van de intentieverklaring in de fds-deelnemersregistratie. Vanaf dit
moment is de organisatiedeelname inclusief de vervolgacties en -resultaten zichtbaar voor de
buitenwereld.
Stap 3: Deelname dataset
Wij nemen contact op met de contactpersoon van de dataset en maken afspraken over het invullen van
de deelnamevoorwaarden. De deelnamevoorwaarden zullen we hier zo snel mogelijk publiceren. Samen
concluderen we of de dataset als deelnemer of kandidaat-deelnemer aan het fds kan deelnemen, hier
zijn drie conclusies mogelijk:
deze dataset is geschikt voor deelname fds
deze dataset is kandidaat-deelnemer fds
óf deze dataset voldoet niet aan de fds-deelname voorwaarden
Wij zorgen voor registratie van de conclusie in de fds-deelnemersregistratie.
Stap 4: Maatwerkplan
Als de conclusie een kandidaat-deelnemer betreft, worden de acties voor het maatwerkplan gezamenlijk
opgesteld, inclusief de termijn. Er zijn twee opties mogelijk:
Uitvoering is conform plan verlopen: organisatie verklaart dat de werkzaamheden zijn afgerond en
verstrekt openbare informatie waarmee dat kan worden vastgesteld.
Uitvoering verloopt niet conform plan: organisatie geeft aan of ze kandidatuur intrekt of dat ze
in overleg met fds een nieuwe activiteit of termijn wil vaststellen.
Wij verifiëren of de eigen verklaring aan de maatwerkafspraak voldoet en leggen vast dat de
kandidaat-deelnemer volwaardig deelnemer is geworden. Vervolgens registreren we de dataset in de
fds-deelnemersregistratie.
Stap 5: Beschikbaar stellen van data
De organisatie publiceert de metadata van de dataset en de bijbehorende datadiensten conform de
daarvoor afgesproken metadata standaarden en ‘profielen’ in de fds-catalogus zodat het nieuwe aanbod
voor de fds-data-afnemers zichtbaar wordt.
Stap 6: In werking
De organisatie controleert en monitort periodiek en informeert fds over haar bevindingen. Deze
bevindingen worden gepubliceerd en geregistreerd.
Transparantie Deelnameproces
Alle stappen in het deelnameproces worden geregistreerd in de deelnemersregistratie voor zowel de
organisatie als de dataset. Na het tekenen van de intentieverklaring door de organisatie wordt de
status zichtbaar via een communicatiekanaal van het fds (nog te bepalen), inclusief eventuele
documentatie.
Deelname als organisatie en deelname per dataset
Het bovenstaande stappenplan beschrijft het proces per dataset voor data-aanbiedende organisaties.
Dit betekent dat een organisatie met verschillende datasets in verschillende stadia kan
participeren. Voor organisaties die al deelnemer zijn, verloopt een deel van het proces veel sneller
omdat zij zich al eerder gecommitteerd hebben aan de fds-afspraken.
Bronhouder of data-aanbieder
Per dataset kan de rol van de organisatie verschillen (bronhouder of data-aanbieder). Als de
data-aanbieder een andere organisatie is dan de bronhouder, dient deze de bronhouder(s) over de
voorgenomen deelname te hebben geïnformeerd voordat de data-aanbieder voor deze dataset het proces
kan doorlopen.
22.1 - Intentieverklaring
Hier lees je hoe de intentieverklaring eruit ziet als je wilt deelnemen aan het stelsel
Let op: als je de intentieverklaring ook daadwerkelijk wilt indienen, download deze dan hier op de
IBDS website. Dan kun je de gegevens invullen en mailen naar teamIBDS@ictu.nl.
Hieronder lees je alleen waartoe je je verplicht bij het indienen van de intentieverklaring.
Ja:
Wij willen als stelseldeelnemers data onze en voor het oplossen van maatschappelijke vragen. Zo kan
iedereen de vruchten plukken van de digitalisering van de samenleving. Wij geloven dat dit alleen
lukt als we bij het datadelen de publieke waarden centraal ze en. Daarom gaan we werken volgens de
uitgangspunten van het Federatief Datastelsel:
Datadelen doen we niet voor onszelf, maar voor de maatschappij. Wij baseren onze dienstverlening
op juiste, volledige en actuele gegevens die zijn afgestemd op de situatie. Daarbij realiseren
we ons dat de data waarop we ons handelen baseren een afspiegeling zijn van de realiteit. We
weten dat er al jd situaties kunnen voorkomen waarin de leefwereld van de individuele burger
niet past in het door ons gehanteerde databeeld. Daar houden we rekening mee. Als een burger
desondanks toch klem komt te zi en in de door ons geconstrueerde datawereld, dan zullen we als
stelseldeelnemers alles in het werk stellen om deze burger alsnog recht te doen. Daarbij vallen
we de burger niet lastig met de complexiteit van gegevensdeling binnen een stelsel. Dat is ons
probleem en niet dat van de burger.
Transparant data-aanbod
We beschrijven op eenduidige wijze de kenmerken van de in het stelsel aangeboden data. We zijn
open over de beoogde en gerealiseerde kwaliteit van onze data en onze datadiensten.
Transparant datagebruik
We maken zichtbaar met wie we waarvoor data delen en zijn in staat en bereid daarover
verantwoording af te leggen3. We zullen gestandaardiseerd de verwerking van stelseldata gaan
registreren zodat we altijd kunnen aantonen dat dit rechtmatig is gebeurd en we eenvoudig aan
burgers kunnen laten zien op welke data onze besluiten zijn gebaseerd en welke organisatie
wanneer en waarvoor zijn persoonlijke gegevens heeft geraadpleegd.
Transparante belangenafweging
Hoewel de letter en de geest van de wet een belangrijk kader voor het datadelen bieden, blijven
er altijd situaties bestaan waarin verschillende legitieme belangen kunnen botsen. Dan moet er
gekozen worden. We hanteren daarvoor een zorgvuldig openbaar proces met waarborgen dat aan alle
belangen recht wordt gedaan. We maken de uitkomst van dit proces openbaar zodat iedereen kan
nagaan waarop de uiteindelijke keuze is gebaseerd. We zijn ons ervan bewust dat dit aanleiding
kan geven voor maatschappelijk debat, maar we beschouwen dat juist als gewenst.
Waar het kan, werken we op dezelfde manier
We maken gebruik van de stelselfuncties (afspraken, standaarden en voorzieningen) om onze data
zo beschikbaar, bruikbaar en bestendig mogelijk te maken en in het datagebruik de publieke
waarden te borgen.
Iedereen draagt bij
Het Federatief Datastelsel maken we samen. We realiseren ons dat het succes van het stelsel een
optelsom is van de bijdragen van de deelnemers. We geven samen vorm aan de ontwikkeling van het
stelsel en stemmen onze eigen ontwikkelagenda daarop af. We zijn duidelijk over wat we van
elkaar verlangen en delen onze kennis en ervaring.
Open, verbonden en verantwoord
Wij zijn ambassadeur van het Federatief Datastelsel en dragen de kernwaarden open, verbonden en
verantwoord uit.
Geïnspireerd door het Manifest Netwerk Digitaal Erfgoed ↩︎
Burger wordt hier in ruime zin gebruikt. Hier vallen zowel natuurlijke als niet natuurlijke
personen (organisaties) onder. ↩︎
Natuurlijk gelden hierbij de gebruikelijke uitzonderingen voor inlichtingen- en
opsporingsdiensten. ↩︎
23 - Data bij de bron
Gebruik van transparante en actuele gegevens
Deze pagina is DRAFT. Het verzamelt de verschillende definities of interpretaties van Data bij
de bron. Dit uitgangspunt / principe / begrip wordt veelvuldig gebruikt … maar niet hetzelfde
geïnterpreteerd en gebruikt 😏
Het data bij de bron principe vormt een basis concept voor de digitalisatie van de
Rijksoverheid, en ook van FDS. We maken gebruik van data zoals deze actueel in de systemen van de
bronhouder beschikbaar zijn, en werken niet met aparte kopieën. Dat zorgt voor een betrouwbare
gegevensvoorziening.
Onderstaande zou (ook?) in een decision record kunnen staan?
Context en probleemstelling
Er is veel data binnen de overheid en deze wordt ook nog eens veelvuldig gedeeld en gekopieerd. Het
is onduidelijk waar welke data is, wat de actualiteit en betrouwbaarheid daarvan is, en ook niet
waar persoonsgegevens precies bij en voor gebruikt worden. Hoe kan dit geadresseerd worden?
Gekozen oplossing: “Grip op data”, omdat het onderliggende problematiek adresseert om data bij de
bron te ondersteunen cq mogelijk te maken en een voorwaarde is om regie op gegevens te kunnen
realiseren.
Positieve gevolgen
ongecontroleerde kopieën van data moeten worden opgeruimd
data bij de bron ophalen wordt aangejaagd
gecontroleerde kopieën van data worden expliciet gemaakt
hoe is in onderzoek
er zal ook grip verkregen moeten worden op historische data (kopieën uit het verleden)
bij het vastleggen van besluiten dient ook te worden vastgelegd op welke (kwaliteit van) data dit
besluit gebaseerd is; dit biedt ook mogelijkheden om correcties te (gaan) ondersteunen in geval
deze data achteraf anders blijkt dan bij het oorspronkelijk besluit
Negatieve Consequences
snelle en gemakkelijke kopieën van data worden opgeruimd,
waardoor processen mogelijk moeilijker en/of langzamer worden
wat zwaardere afhankelijkheden tussen organisaties op koppelingen legt
data-aanbieders zullen hogere beschikbaarheid en betrouwbaarheid moeten leveren voor hun
dataservices
systemen zullen (mogelijk?) anders opgebouwd moeten worden
tbv gecontroleerde kopieën
tbv historische data
Pros en Cons van de oplossingen
Digitale overheid
Data bij de bron is niet ondubbelzinnig duidelijk. Data bij de
Bron wordt als uitgangspunt genoemd bij de
Digitale Overheid:
Data bij de bron is een belangrijk uitgangspunt voor de digitale transformatie van de Nederlandse
overheid. Data hoort zo veel mogelijk op één logische plek te staan, bij de eigenaar van die
gegevens.
Eén logische plek is echter niet zo logisch als een basisregistratie een verzameling is van de
‘stukjes’ basisregistratie die bij elke gemeente ligt. Dat is namelijk niet één plek. Dat is wél de
eigenaar. Maar wat is er nu belangrijker bij dit uitgangspunt: ‘één logische plek’ of ‘bij de
eigenaar van die gegevens’?
Om hier een uitweg in te vinden, worden extra oplossingen ingebracht zoals Landelijke Voorzieningen.
Op zichzelf zijn deze ook nuttig en van toegevoegde waarde, maar in het kader van data bij de bron
zijn deze ingewikkeld.
Wat is nu de bron?
Wie is hier nu eigenaar van?
De oorspronkelijke gemeente? Die is in ieder geval niet ontslagen van haar verantwoordelijkheid op
de juistheid van de data
De uitvoeringsorganisatie? Die is in ieder geval niet direct verantwoordelijkheid voor de
juistheid, maar wel weer voor de beschikbaarheid e.d.
Dit uitgangspunt levert dan ook weer nieuwe vragen op:
Wat is ‘dé bron’?
Is dat altijd hetzelfde vanuit elk perspectief? Of mag dat ook anders zijn vanuit data-aanbieder,
bronhouder en data-afnemer?
FDS overwegingen
Goed, omdat het de oorsprong van data en informatie adresseert
Goed, omdat het zich richt op waar de verantwoordelijkheid ligt, in ieder geval wat betreft de
oorsprong van de data
Slecht, omdat geen uitsluitsel geeft over de nieuwe vragen die het opwerkt
Al deze principes zijn erop gericht om duidelijkheid en grip te kunnen verschaffen aan personen en
bedrijven daar waar het over hen gaat. Daarvoor is het noodzakelijk om te weten waar welke data is
en wordt gebruikt, zeker in geval van persoonsgegevens.
FDS overwegingen
Goed, omdat het aandacht vraagt voor verantwoord datagebruik
Goed, omdat het (indirect) vraagt naar grip op data
Slecht, omdat het ‘slechts’ indirect vraagt naar grip op data en niet expliciet; het stelt
meer een voorwaarde van grip op data
In een federatief datastelsel mag het niet zo zijn dat er ‘onbekende’ databronnen zijn. Van alle
data is bekend waar deze ontstaan is. Van alle data is bekend waar deze vandaan komt. Van alle
data is bekend waar deze gebruikt wordt. Op alle data is grip. Dus: grip op data.
Afgeleide en/of gevolgen daarvan zijn, dat er regie op gegevens gedaan kan worden. En minder data
betekent gemakkelijker en sneller grip. Dus zo min mogelijk kopieën van data en als er wel kopieën
zijn, dan zijn deze expliciet inclusief de voorzieningen om actualiteit, traceerbaarheid en gebruik
te volgen.
Goed, omdat het de kern raakt of voorwaarde is om regie op gegevens te kunnen doen
Goed, omdat het onbekende en onbeheerde kopieën van data tegengaat, zoals data bij de bron tracht
te bereiken
Goed, omdat het een meer onderliggende basis legt zodat data bij de bron beter of anders bereikt
kan worden
…
24 - Lock-Unlock
Onderzoek van Kadaster DataScience Team over autorisatie in en als Linked Data
Dit is de samenvatting van en perspectief vanuit het federatief datastelsel op het onderzoeksproject
Lock-Unlock. Deze samenvatting geeft een globaal beeld van de resultaten van het onderzoeksproject
en ligt de focus op de voor het FDS belangrijkste uitkomsten. Er is daarbij geprobeerd vakjargon te
vermijden. Het Lock-Unlock project heeft echter veel meer opgeleverd dan wat in deze
FDS-samenvatting aan bod komt. De hiernavolgende hoofdstukken bevatten de volledige
onderzoeksresultaten, met gebruik van de juiste vaktechnische termen.
In het Federatief Datastelsel (FDS) worden generieke functies ingericht met afspraken en standaarden
waarmee data eenvoudig in samenhang kan worden gedeeld tussen organisaties uit verschillende
sectoren. Linked Data standaarden zijn speciaal ontworpen om data in samenhang te ontsluiten. Daarin
zijn de Linked Data standaarden met name gericht op open data. Voor afgeschermde data zijn er geen
aangenomen standaarden en is er weinig onderzoek gaande. In het Lock-Unlock project heeft het Data
Science Team van het Kadaster onderzocht welke mogelijkheden er zijn om in deze lacune te voorzien,
zodat in het FDS ook afgeschermde Linked Data kan worden toegepast. Hiervoor is desk research
uitgevoerd en zijn de gevonden mogelijke oplossingen in de praktijk beproefd door een werkende
‘demonstrator’ te realiseren. Daarbij is voortgebouwd op het project Integrale Gebruiksoplossing
(IGO) waarmee in 2021 voor open data al
de toegevoegde waarde van het toepassen van Linked Data is verkend.
In het Lock-Unlock project is tevens aandacht besteed aan het met Linked Data implementeren van wat
in de visie van het FDS bekend staat als ‘informatiekundige
kern’,
het toepassen van identificerende gegevens (‘unieke sleutels’) om betrouwbaar data die betrekking
hebben op Wie (personen en organisaties) en Waar (locatie) te combineren.
Noodzakelijke afscherming
Bij een federatieve bevraging zijn diverse vormen van afscherming van belang. Autorisatie
oplossingen zouden de volgende afschermingspatronen moeten ondersteunen:
Verticale subsets (de ‘kolommen’ in een tabel): bepaalde kenmerken/attributen van de daarin
voorkomende objecten zijn afgeschermd. Voorbeeld: in een dataset met gegevens over kadastrale
percelen mag je van percelen wel de koopsom opvragen, maar niet de eigenaar.
Horizontale subsets (de ‘rijen’ in een tabel): bepaalde objecten (voorkomens) zijn afgeschermd,
maar van de objecten waar je wel toegang toe hebt, mag je alle beschikbare kenmerken/attributen
opvragen. Voorbeeld: je krijgt als Gemeente X wel alle perceelgegevens, maar alleen van die
percelen die binnen jouw gemeente liggen.
Afscherming relatie-richting: het opvragen van informatie in een bepaalde richting is mogelijk,
maar het opvragen van de omgekeerde richting is niet mogelijk. Voorbeeld: je mag van een perceel
de naam van de eigenaar opvragen, maar je mag niet op basis van de naam van een eigenaar opvragen
welke percelen deze allemaal bezit.
Aggregatie: gebruikers mogen geen toegang krijgen tot de gedetailleerde gegevens, maar mogen wel
geaggregeerde gegevens opvragen. Voorbeeld: niet de verkoopprijzen van een individueel perceel,
maar wel de gemiddelde verkoopprijs binnen een postcodegebied.
Vrije query mogelijkheden ondersteunen: de kracht van Linked Data is dat je zonder een vooraf
gedefinieerd inrichtingsschema de data kunt bevragen. Die optie van makkelijk ‘vrij’ door de data
kunnen zoeken, wil je blijven behouden.
De onderzochte oplossing: het toepassen van een Linked Data ‘autorisatietaal’
In het project is voor de verschillende manieren van afschermen een autorisatietaal ontwikkeld
waarmee op een gestandaardiseerde wijze de te implementeren autorisatie kan worden beschreven. Deze
beschrijving is eveneens machineleesbaar en voldoet aan de Linked Data standaarden. De in deze taal
opgeschreven autorisatieregels vormen daarmee zelf ook een Linked Data set die op de Linked Data
manier kan worden bevraagd. Vervolgens is ook beproefd of autorisaties op basis van deze
autorisatieregels daadwerkelijk afgedwongen zou kunnen worden. Werkt het ook echt?
Het is een innovatieve manier van het vastleggen van autorisaties die tot nu toe in de Linked Data
wereld niet bestond en die de potentie heeft om tot een toekomstige standaard uit te groeien.
Conclusies op basis van de uitgevoerde praktijkproef
Voor de ontwikkelde autorisatietaal is een praktijkproef (‘proof of concept’) uitgevoerd waarbij
deze taal in een lab-omgeving is toegepast om de hiervoor genoemde vormen van afscherming te
realiseren. Er zijn twee implementaties gemaakt die verschillende strategieën beproeven in het
toepassen van de autorisatieregels. Uiteraard gebruiken beiden dezelfde autorisatieregels in de
ontwikkelde autorisatietaal. In de lab-omgeving zijn daartoe met zelf gegenereerde (synthetische)
testdata en relevante onderdelen van de informatiekundige kern, het FDS gesimuleerd met een
federatieve bevraging over meerdere basisregistraties. Er is gekozen voor een testopstelling van de
basisregistraties BRK, de BRP, de BAG en het HR, aangevuld met een dataset die nog niet in het
stelsel is opgenomen, de ‘ANBI’ dataset van de Belastingdienst met gegevens over algemeen nut
beogende instellingen.
Vereenvoudigd Informatie Model als Linked Data (bron)
Op basis van deze praktijkproef kunnen de volgende conclusies worden getrokken:
De bedachte oplossing is uitvoerbaar. Het is in de praktijk mogelijk om (geavanceerde)
autorisatieregels vast te leggen in Linked Data met behulp van een autorisatietaal die aansluit op
al bestaande Linked Data concepten.
Met deze autorisatietaal en de twee implementatiestrategieën kunnen de horizontale en verticale
subsets afscherming gerealiseerd worden. (Voor het afschermen van de richting was te weinig tijd
beschikbaar.)
Als de gegevenscatalogus van een dataset volgens linked data standaarden is opgebouwd, kan deze
gebruikt worden om in de autorisatietaal de autorisatieregels te beschrijven direct gekoppeld aan
de elementen van de dataset(beschrijving) zelf.
Er zijn meerdere implementatie strategieën mogelijk die gebruik maken van de autorisatietaal om de
autorisatieregels af te dingen. Bij het onderzoek zijn er twee strategieën uitgewerkt en
geïmplementeerd. De verschillende strategieën hebben verschillende voor- en nadelen.
Ook in Linked Data is een goed gebruik van identificerende sleutels van belang om betrouwbare
relaties tussen data uit verschillende datasets te kunnen leggen. Door van de betreffende data
Linked Data te maken, is het toepassen van het concept van de informatiekundige kern wel veel
eenvoudiger. Zo heeft de proef aangetoond dat speciale diensten voor ‘sleutelwisselingen’
(bijvoorbeeld van KvK-nr naar RSIN) niet nodig zijn omdat het Linked Data concept hiervoor
standaard oplossingen biedt.
Bij de eerdere IGO-proef is al gedemonstreerd, dat het op de Linked Data manier ontsluiten het ook
voor niet professionele gebruikers mogelijk maakt om heel flexibele de data ‘te bevragen’. Hiermee
is het een goede aanvulling op de standaard (REST) API manier om data te ontsluiten, omdat daarbij
de vragen van tevoren gedefinieerd moeten zijn (ze zijn voorgeprogrammeerd). Met Lock-Unlock is
aangetoond dat de data-aanbieder de door Linked Data geboden flexibiliteit, ook kan inperken,
waardoor deze methode ook voor gesloten data kan worden toegepast.
Binnen de tijd die voor Lock-Unlock beschikbaar was, kon maar een
beperkte diepgang worden bereikt en was het ook niet mogelijk om na te gaan hoe de onderzochte
Linked Data manier past binnen de overige mogelijke FDS-standaarden. Voor de volgende onderwerpen is
daarom nader onderzoek gewenst:
Het is ook bij Linked Data mogelijk om het bevragen van de data gedetailleerd te loggen en de
logbestanden vervolgens voor analyse te gebruiken. Bijvoorbeeld om achteraf vast te stellen of een
bepaalde vraag wel legitiem was. Hoe deze manier van loggen zich verhoudt tot de beoogde manier om
in het FDS de verwerking van data te registreren (op basis van de ‘verwerkingenlogging standaard),
moet nader worden onderzocht.
Hetzelfde geldt voor de relatie tussen in Lock-Unlock ontwikkelde Linked Data autorisatietaal en
andere manieren om ‘policy based acces control’ te implementeren.
Er was geen tijd meer beschikbaar om de afscherming op relatie – richting te beproeven. Het is
wenselijk om hiervoor een vervolgonderzoek uit te voeren.
Hoewel voor de wel onderzochte afschermingspatronen de benodigde toegangsbeperking werd geboden,
is diepgaander onderzoek nodig om met meer zekerheid vast te stellen dat dit niet omzeild kan
worden. Dit is lastig te meten en ook daarvoor is meer onderzoek nodig. • De oplossingen zijn in
lab-condities beproefd op kleine test datasets. Aspecten die van belang zijn bij grootschalige
toepassing, zoals performance, vielen buiten de scope van het onderzoek. Hoewel er geen indicaties
zijn dat opschaling niet mogelijk is, zijn verdere beproevingen in een daarvoor geoptimaliseerde
proefomgeving nodig om ook hierover meer zekerheid te krijgen. Dit heeft vooral impact en relatie
tot performance van federatieve bevragingen én daar bovenop de toevoeging van de autorisaties
daarin en daarvan.
Het heeft voordelen om de relaties waaruit de informatiekundige kern is opgebouwd met behulp van
Linked Data te verduurzamen (als een ‘upper ontology’ in Linked Data vaktaal). Het lijkt de moeite
waard om de kosten en baten hiervan verder te verkennen.
Federatieve Service Connectiviteit (FSC) Standaard
Beschrijving
Federatieve Service Connectiviteit, FSC, biedt verbetering én optimalisatie in het beheer van
technische identiteiten van overheden. Daarnaast biedt FSC connectiviteit in koppelingen tussen
overheden met verbeterde beveiliging en mogelijkheden voor federatieve verbindingen. In de
beveiliging zitten mogelijkheden voor autorisatie en verwerkingenlogging.
Position paper Policy Based Access Control voor een Federatief Datastelsel
It’s PBAC-time
Belang en scope
Identity- and Access Management
Identity- and Access Management (IAM) is vrij vertaald het beheer om ervoor te zorgen dat de juiste
identiteiten, vooral personen of systemen, voor de juiste redenen en op het juiste moment toegang
krijgen tot de juiste faciliteiten. IAM is zowel nodig voor het kunnen leveren van diensten als om
te voorkomen dat er aan de verkeerde persoon wordt geleverd, en is van belang voor zowel de
dienstaanbieder als de -afnemer. IAM zorgt voor drie belangrijke voorwaarden voor digitale
dienstverlening1:
Identificatie zorgt er voor dat we weten wie je bent. Dit is je identiteit of een van je digitale
identiteiten (accounts);
Authenticatie zorgt er voor dat we met een bepaalde zekerheid weten dat je ook echt degene bent
die je zegt te zijn;
Autorisatie zorgt er voor dat we weten wat je dan mag (toegang) of juist niet mag. I n dit
document bespreken we Autorisatie.
Scope
Dit document focust op autorisatie en bespreekt de onderwerpen identificatie en authenticatie alleen
in context van autorisatie. Bijvoorbeeld wanneer het autorisatiemechanisme eisen stelt aan deze twee
onderwerpen. Voor uiteindelijke implementatie is een goede uitwerking van al deze onderwerpen in samenhang een
vereiste.
De scope van dit document is vastgesteld op datasamenwerking tussen overheden (overheidsorganen).
Voor deze position paper is dat voldoende. Bij uiteindelijke besluitvorming over autoriseren (en de
ander zaken omtrent identity- and access management) wordt ook de uitwisseling tussen private
partijen en tussen overheid en private partijen meegenomen.
Tot slot is de reikwijdte van dit paper datasamenwerking tussen overheidsorganen om datatoegang te
verlenen voor het uitvoeren van eigen werkzaamheden. De data-uitwisseling tussen een overheidsorgaan
en haar verwerker behandelen we niet. Hiermee bedoelen we: partij A kan zelf (om wat voor reden dan
ook) zelf geen data verwerken, geeft partij B toegang tot hun data en laat partij b deze verwerken.
De uitwisseling tussen deze partij en verwerker hoort niet bij dit autorisatiedeel.
Belang voor een Federatief Datastelsel
Het doel van deze position paper over Policy Based Access Control (PBAC) voor het Federatief
Datastelsel is om deze manier van autoriseren te onderzoeken en evalueren. Voor het Federatief
Datastelsel is een schaalbare, beheerbare en beheersbare wijze van toegang verlenen tot
data(-diensten) nodig. De traditionele methode en de manier waarop er momenteel wordt geautoriseerd,
voldoen niet aan de eisen en standaarden die het Federatief Datastelsel stelt, zoals het principe
dat Data bij de Bron blijft. Ook sluit PBAC beter dan andere
alternatieven aan bij het bestuursrecht en uitgangspunten die gelden voor de uitwisseling van
gegevens tussen overheden. PBAC lijkt daarom een kansrijke methode om datatoegang in een Federatief
Datastelsel te regelen.
Autorisatiemechanismen en PBAC
Verschillende autorisatiemechanismen
Toegangscontroles kunnen op meerdere manieren plaatsvinden. Het kiezen van de juiste methode is
afhankelijk van bijvoorbeeld de complexiteit van het I-landschap, de beheersbaarheid en de
schaalbaarheid. In alle gevallen geldt: een subject (medewerker, burger, organisatie) wil toegang
tot een object (databron, systeem, applicatie). Om een beeld te geven van verschillende manieren van
autoriseren worden hier kort de populairste methoden uitgelegd, op volgorde van simpel tot
geavanceerd:
Access Control List (ACL). Deze methode kun je vergelijken met een gastenlijst. Staat jouw
(digitale) identiteit op de controlelijst? Dan krijg je toegang, anders niet. Deze methode kost
weinig moeite om op te zetten (voor één databron of applicatie) en vraagt vooral een goed
identiteitenbeheer. Deze methode is moeilijk schaalbaar (want elke databron heeft een aparte
controlelijst nodig) en lastig beheersbaar. Daarnaast is er geen onderverdeling in soorten toegang
te maken: eenmaal binnen, kun je overal bij.
Figuur 1: Access Control List
Role Based Access Control (RBAC). Dit is de ‘klassieke’ manier van autoriseren waarbij
toegangsrechten worden gekoppeld aan rollen en aan deze rollen worden gebruikers toegewezen.
Meerdere toegangsrechten worden dus geclusterd tot 1 rol. De logica van het toekennen van rollen is
vooral gebaseerd op de functie van de medewerker. Een voorbeeld van een toegangsregel is: alle
medewerkers met de rol ‘Functioneel beheerder Sharepoint’ mogen bepaalde toegangsrechten in de
applicatie Sharepoint. Het beheer voor deze autorisatiemethode is op meerdere plaatsen belegd. Aan
de kant van de organisatie moeten de juiste mensen worden toegewezen aan de juiste rollen, en aan de
kant van de applicatie moeten de juiste rechten worden gekoppeld aan de juiste rollen. RBAC is veel
beter beheersbaar en schaalbaar dan ACL, en is een goed systeem voor toegang van medewerkers tot
applicaties en databronnen binnen dezelfde organisatie of hetzelfde I-landschap. Dit wordt lastiger
met identiteiten van buiten de organisatie. Daarnaast kan het aantal rollen enorm toenemen naarmate
de tijd vordert, en blijft het grootste gedeelte van deze methode handmatig werk (toevoegen van
medewerkers aan rollen).
Figuur 2: Role Based Access Control
Attribute Based Access Control (ABAC). Attributen zijn stukjes informatie over een persoon,
object of situatie. Gebruikersattributen geven context over een medewerker, zonder dat de volledige
identiteit wordt gegeven. Dit kunnen bijvoorbeeld haar afdeling, rang, rol, of afgeronde opleidingen
zijn. Bronattributen geven context over een databron, zoals wie de eigenaar is, het type bestand, of
rubriceringsniveau. Bij ABAC worden specifieke attributen van de medewerker gekoppeld aan specifieke
attributen van de databron of applicatie, en deze combinatie geeft wel of geen toegangsrechten.
Naast attributen van een persoon of object, bestaan er ook omgevingsattributen zoals tijd, locatie
en apparaattype, die gebruikt kunnen worden als extra restrictie in de toegangsregel. Je kunt
bijvoorbeeld de autorisatieregel krijgen: “elke medewerkers van afdeling X mag toegang tot data met
attribuut afdeling X, op werkdagen tussen 08.00 en 20.00 uur”. In vergelijking met RBAC is ABAC
flexibel, nog beter beheersbaar en schaalbaar, en daarnaast privacyvriendelijker, omdat alleen de
attributen van een medewerker gebruikt worden, die nodig zijn voor de toegangsregel. Ook neemt ABAC
handwerk weg: in plaats van handmatig medewerkers aan rollen toe te moeten voegen (RBAC), krijgt de
medewerker automatisch (proactief) toegang als deze de juiste attributen heeft. Voor ABAC is wel een
geavanceerder landschap nodig, met verschillende registraties voor de attributen, met goed geregeld
eigenaarschap en een geavanceerd autorisatieregelmechanisme.
Policy Based Access Control (PBAC)2. RBAC en ABAC maken gebruik van ‘statische’ elementen,
namelijk de rollen en attributen. Deze elementen staan in registraties in het landschap en worden
alleen veranderd als er iets wijzigt bij het subject (de medewerker) of het object (applicatie of
databron). PBAC gebruikt een dynamische, contextgebaseerde aanpak. Net als ABAC gebruikt PBAC ook
attributen voor het maken van toegangsregels, maar PBAC gaat hierbij nog een stap verder door deze
te combineren met policies, oftewel beleidsregels. Door het gebruik van policies wordt het systeem
dynamischer, omdat het sneller kan worden aangepast aan veranderende omstandigheden. Daarnaast
zorgt PBAC (specifiek: het gebruik van policies) ervoor dat het gemakkelijker is om
omgevingsattributen mee te nemen in de autorisatiebeslissing. Je krijgt bijvoorbeeld alleen toegang
als je via een geregistreerd device op een bepaalde manier toegang verzoekt. Naleving van
regelgeving wordt op deze manier ingebouwd. Het grootste voordeel van PBAC is dat het goed werkt in
een complexe structuur van verschillende organisaties. Zie hiervoor het hoofdstuk hierna Hoe werkt
PBAC.
PBAC maakt het mogelijk om alle voorwaarden voor toegang op één plaats inzichtelijk te hebben (in
het Policy Administration Point, afgekort PAP). Bij ABAC kan dat ook, maar implementaties zijn vaak
beperkt tot een beperkt aantal attributen. Bij RBAC is het vaak niet meer inzichtelijk of er nog
contextgerelateerde beperkingen zijn.
Kortom, het gebruik van PBAC in een samenwerking met meerdere organisaties biedt een gestroomlijnde,
veilige en goed beheerde aanpak voor het beheren van toegangsrechten en het handhaven van
beveiligingsstandaarden over alle organisatorische eenheden heen. Door deze afspraken te publiceren
wordt de samenwerking tevens transparant voor alle belanghebbenden gemaakt.
Hoe werkt PBAC
Figuur 3: Een autorisatieaanvraag in PBAC (XACML)
Datatoegang wordt via PBAC als volgt geregeld. Een gebruiker (het subject) wil graag toegang tot de
data (het object). Een autorisatieverzoek wordt ontvangen door het Policy Enforcement Point (PEP).
Dit punt is de slagboom van het systeem en verleent toegang of niet. Het PEP stuurt het verzoek naar
het Policy Decision Point (PDP). Dit punt neemt de uiteindelijke beslissing of het verzoek leidt tot
toegang of weigering. Om deze beslissing te maken heeft het punt informatie nodig: de
autorisatieregels die gelden voor deze situatie en de informatie over subject (wie doet het verzoek),
object (waartoe wordt toegang verzocht) en omgeving (onder welke omstandigheden wordt toegang
verzocht). Het PDP stuurt het verzoek door naar het PIP en het PAP. Het Policy Administration Point
(PAP) levert de juiste voorwaarden voor datatoegang en het Policy Information Point (PIP) de juiste
informatie over subject, object en omgeving. Het PDP clustert de informatie en maakt de beslissing
of de geleverde informatie volstaat om aan de voorwaarden van toegang tot de data te voldoen. Indien
ja, dan geeft het PDP een signaal aan het PEP om de toegang te verlenen. Zo nee, dan geeft het PDP
een signaal aan het PEP dat de slagboom dicht blijft. Zie bovenstaande figuur voor een schematische
weergave.
Samengevat:
Policy Enforcement Point (PEP)
Policy Decision Point (PDP)
Policy Administration Point (PAP)
Policy Information Point (PIP)
Hoe werkt PBAC over verschillende organisaties in een Federatief Datastelsel
Wanneer PBAC als autorisatiemechanisme wordt toegepast over verschillende organisaties ziet dat er
ongeveer zo uit als in figuur 4. Het verzoek tot data van het subject wordt eerst getoetst bij de
eigen organisatie. Deze bekijkt voor dit specifieke toegangsverzoek aan de hand van het vooraf
afgesproken afsprakenstelsel welke policies er gelden (PAP) en welke informatie van het subject en
de omgevingsfactoren van toepassing zijn (PIP). De PDP (nog steeds bij de datavragende organisatie)
bepaalt of het verzoek wordt goedgekeurd op basis van de beschikbare informatie en stuurt het
goedgekeurde verzoek door via de eigen PEP naar de PEP van de dataleverende partij3. In deze
goedkeuring staat beschreven dat er volgens de datavragende partij wordt voldaan aan de vooraf
opgestelde eisen voor datatoegang, en voor welke vooraf afgesproken data dit van toepassing is.
Wanneer de PDP van de datavragende partij het verzoek van het subject afkeurt, wordt er geen verzoek
naar de dataleverende partij gestuurd.
De PEP van de dataleverende partij ontvangt de informatie van de datavragende partij en bepaalt of
deze goedkeuring nog steeds geldt met de informatie die de datavragende partij zelf heeft. Het
verzoek gaat langs via de PEP naar de PDP en deze vult het verzoek aan met eigen informatie, vooral
informatie en context over de data. De PDP legt de vooraf afgesproken policies uit de PAP, de
(data)informatie uit de PIP naast het binnengekomen verzoek en besluit of de datatoegang wordt
toegekend. Indien ja, dan krijgt de PEP het signaal dat het subject van de datavragende partij
toegang mag krijgen tot het object van de dataleverende partij. Zo niet, dan wordt het
oorspronkelijke verzoek tot data alsnog afgekeurd en wordt er geen toegang verleend.
Zowel datavragende als dataleverende partij voeren policies uit om het verzoek goed of af te keuren.
Hoewel de policies onderdeel uit maken van het afsprakenstelsel tussen beiden partijen, zijn dit
doorgaans niet dezelfde policies. De datavragende partij voert de checks uit aan de subjectkant,
bijvoorbeeld: behoort de medewerker tot de mensen die data mag opvragen, of mag de organisatie deze
data bij de dataleverende partij opvragen? De dataleverende partij voert policies uit als check aan
de datakant, bijvoorbeeld: onder welke omstandigheden mag deze data worden opgevraagd, of: is deze
data gelabeld als data die gedeeld mag worden?
Hier ligt ook een sterke relatie met de andere onderdelen van IAM, voornamelijk Identity Management.
Welke gegevens moet een organisatie vastleggen om met dit stelsel te kunnen werken en welke gegevens
hiervan komen terug in de policies? Hoe de identiteit4 eruit komt te zien is een ander vraagstuk
dat verdere uitwerking vraagt.
Figuur 4: PBAC over meerdere organisaties
De poortwachter van het Federatief Datastelsel heeft ook een belangrijke rol in dit mechanisme.
Vanuit het Federatief Datastelsel worden de stelselpolicies gedeeld met de organisaties. Deze
stelselpolicies bestaan uit de standaarden vanuit het Federatief Datastelsel en de
samenwerkafspraken tussen de organisaties. Zie hoofdstuk [De poortwachter binnen het Federatief
Datastelsel](#de-poortwachterfunctie-binnen-het-Federatief Datastelsel) met meer informatie over
deze Poortwachter.
Tot slot, deze situatie beschrijft een tussenfase. Uiteindelijk, bij een goed opgezet en
functionerend stelsel, en bij bevraging tussen twee overheidsorganen, zal het zwaartepunt van het
uitvoeren van de checks met behulp van policies gaan liggen bij de datavragende partij.
Uitgangspunten
Eigenaarschap en verantwoordelijkheid op de juiste plaats
Wanneer datatoegang op de traditionele manier, zoals het veelgebruikte RBAC, is ingericht, wordt er
veel gevraagd van de aanbieders van data. Deze partij moet immers kunnen toetsen of degene die
toegang vraagt ook daadwerkelijk toegang mag krijgen, en moet daardoor allerlei checks doen op basis
van eigen objectinformatie (de informatie over de data) en de subjectinformatie van de aanvrager (de
informatie over degene die toegang wil, als deze al op de juiste manier wordt gedeeld). In de
praktijk betekent dit, dat een groot gedeelte van het werk om de data-aanvraag te toetsen voor
rekening van de dataleverende partij komt.
Door gebruik te maken van een generiek systeem, opgesteld vanuit het Federatief Datastelsel, op
basis van PBAC, is het mogelijk om de beheerlast te verschuiven naar de vrager van data. De
datavragende partij laat dan zien, op basis van eigen informatie en vooraf afgesproken informatie
van de data, dat deze voldoet aan de policy om toegang te krijgen tot de data van de dataleverende
partij.
Het lijkt dan misschien alsof er veel verantwoordelijkheid bij de afnemer gelegd wordt, maar de
dataleverende partij heeft de verantwoordelijkheid om te zorgen dat de voorwaarden compleet zijn.
PBAC heeft het voordeel dat het toegang verlenen beheersbaar, uitbreidbaar, en responsief houdt,
vanuit een dataeigenaar-perspectief. Op deze manier wordt de werklast voor datatoegang verdeeld over
de datavragende en dataleverende partij en ligt de verantwoordelijkheid voor het aantonen van
verschillende delen informatie bij de juiste partijen.
Kortom, door gebruik te maken van PBAC worden eigenaarschap en verantwoordelijkheid op de juiste
plek belegd.
Zero trust
PBAC voldoet aan het Zero trust5 principe, dat uitgaat van het grondbeginsel never trust, always
verify. Vroeger was de beveiliging primair gericht op het plaatsen van beveiligingsmaatregelen op
de “de buitenste” laag van de infrastructuur. Het zero trust principe gaat daarentegen uit van
segmentering. Er ontstaat dus een opdeling van bijvoorbeeld meerdere kleine beveiligde netwerken
genaamd implied trust zones. Deze implied trust zones helpen bij het structureren van een of
meerdere functionaliteiten door het implementeren van een set aan beveiligingseisen. Als eenmaal is
voldaan aan deze eisen, volgt toegangsverlening. Toegang tot deze implied trust zones gaat gepaard
met sterke authenticatie en autorisatie en het monitoren hierop. Door de structurering in PBAC is
dit autorisatiemechanisme een manier om aan deze autorisatie-eis te voldoen. Dit impliceert ook dat
er in dit systeem dezelfde controles worden gedaan bij zowel interne als externe bevragingen van
data, in plaats van alleen op externe bevragingen in traditionele niet-zero-trust-systemen.
Datasoevereiniteit
PBAC voldoet aan het principe Datasoevereiniteit. Doordat er met PBAC gebruik wordt gemaakt van een
afsprakenstelsel met geautomatiseerde besluitvorming, wordt er dus vooraf aan de samenwerking
besloten aan welke voorwaarden beide partijen moeten voldoen om data te kunnen uitwisselen. De
dataleverende partij hoeft op het moment van de aanvraag niet meer te besluiten of de
datavragende partij toegang krijgt of niet. Dit gebeurt namelijk aan de voorkant in plaats van op
het moment van data-aanvraag en de datatoegang wordt automatisch geregeld. Dit maakt het vooraf
transparant wanneer data tussen deze partijen mag worden gedeeld en biedt tegelijkertijd de vrijheid
om deze afspraken flexibel te wijzigen wanneer er een verandering in de samenwerking ontstaat.
Vooraf toetsen van afspraken gebeurt tegenwoordig al in veel gevallen waarin persoonsgegevens en de
AVG een rol spelen. Een afnemer kan bij een aanbieder persoonsgegevens aanvragen om te mogen
gebruiken, waarvoor de afnemer een wettelijke taak heeft als grondslag. De aanbieder toetst hierbij
ook vooraf of dit legitiem is en neemt een autorisatiebesluit. Het verschil tussen de huidige
situatie en de toekomstige situatie met PBAC, is dat er een structureel systeem wordt neergezet
waarbij er veel kan worden geautomatiseerd. Het handmatige werk van het checken van legitimiteit en
het nemen van een autorisatiebesluit, wordt door PBAC aan de voorkant goed geregeld zodat er
real-time geen lange doorlooptijden meer zijn en er minimaal handwerk is. Het autorisatiebesluit is
geen handmatig besluit meer, wat bijdraagt aan datasoevereiniteit.
Policies vooraf en audits achteraf
De datavragende partij controleert aan de hand van de policies (vooraf gemaakte afspraken) en de
context van de aanvraag of zij deze aanvraag moet goedkeuren of afkeuren. De dataleverende partij is
géén toezichthouder en zal niet checken of het subject aan alle eisen voor het aanvragen van data
voldoet (en mag dat ook vaak niet). De dataleverende partij ontvangt een goedgekeurd verzoek en
controleert vervolgens of de context van de data ook voldoet aan de gestelde policies. Dit betekent
niet dat de datavragende partij ‘zomaar’ al hun eigen dataverzoeken kan goedkeuren! Of de vooraf
gemaakte afspraken daadwerkelijk worden nageleefd kan achteraf worden gecontroleerd op elke plaats
waar keuzes worden gemaakt (zie paragraaf Zero Trust). Via een logboek
dataverwerkingen kan worden aangetoond of de datavragende partij correct heeft gehandeld. Deze audit
kan worden uitgevoerd in opdracht van een toezichthouder op dezelfde manier als dat momenteel al
wordt gedaan. De grondslag voor de datatoegang is de combinatie van de policies van beide partijen.
Door autorisatie op deze manier in te regelen wordt de focus van de standaarden (van het Federatief
Datastelsel) gericht op de datavragende partij: zij moeten kunnen verantwoorden waarom ze toegang
tot de data moeten krijgen. Het correct handelen van de datavragende partij is geen
verantwoordelijkheid van de dataleverende partij.
Privacy
Bij het gebruik van Role Based Access Control (RBAC) moet voor elke datatoegang een identiteit
gekoppeld worden aan een rol. Deze rol wordt vervolgens gekoppeld aan rechten voor datatoegang. Dit
betekent dat als een medewerker van partij A toegang wil tot data van partij B, er in de organisatie
van partij B een digitale identiteit (account) aangemaakt moet worden zodat deze gekoppeld kan
worden aan rollen. Voor partij B is dan precies inzichtelijk wie deze persoon is en dit voldoet niet
aan de vereiste van dataminimalisatie.
Bij het gebruik van Attribute Based Access Control (ABAC) wordt het besluit voor datatoegang gemaakt
door de autorisatieregels en bijbehorende attributen te vergelijken. Dit betekent dat als een
medewerker van partij a toegang wil tot data van partij b, dat de attributen van deze medewerker
(subjectattributen) moeten worden gedeeld met partij b. Hoewel dit minder informatie geeft dan de
volledige identiteit die wordt gedeeld bij RBAC, geven deze attributen nog steeds informatie over de
identiteit van de medewerker. Voor partij B is dan deels inzichtelijk wie deze persoon is en ook
dit voldoet niet aan de vereiste dataminimalisatie.
Bij PBAC worden geen identiteiten of attributen gedeeld met de partij B. Er wordt slechts gedeeld
aan welke policies het subject van partij A voldoet en voor welke data van partij B deze policies
van toepassing zijn. Op deze manier wordt er minimale informatie uitgewisseld over de
identiteit van de medewerker en voldoet de autorisatie aan het vereiste van dataminimalisatie.
PBAC is in lijn met kaderstellers
Diverse partijen binnen de overheid omarmen deze manier van autoriseren. De VNG geeft aan dat
gemeenten steeds meer op deze manier zouden moeten autoriseren. Ook de architecten vanuit CIO Rijk
bewegen in de richting van PBAC en stellen steeds meer standaarden op om hieraan op een goede manier
te voldoen. In het domein Zorg geeft Nictiz, het Nederlandse kenniscentrum voor landelijke
toepassingen van ICT in de zorg, ook aan dat PBAC de gewenste manier van autoriseren is. Daarnaast
werken er steeds meer Europese projecten met PBAC in plaats van de traditionele
autorisatiemechanismen en ook RVO geeft het signaal dat dit steeds meer de gewenste manier van
autoriseren is.
Implementatie
De poortwachterfunctie6 binnen het Federatief Datastelsel
De poortwachterfunctie zorgt voor een transparant beslisproces. Het toetst, autoriseert en
registreert koppelingsverzoeken tussen bronnen, toetst op conformiteit met de AVG en de aansluit- en
gebruiksvoorwaarden van het stelsel. De toetsing zal veelal neerkomen op het afwegen van strijdige
belangen, waarbij bijvoorbeeld noodzaak, privacy, ethiek en conformiteit met aansluit- en
gebruiksvoorwaarden van het Federatief Datastelsel een rol spelen. Vooral dat laatste heeft een
sterke relatie met PBAC. Het toetsen gebeurt in een transparant beslisproces met mogelijkheden voor
bezwaar en beroep. De uitkomst van dit proces wordt vastgelegd in een openbare registratie
(gegevensstroom-boekhouding). Deze registratie heeft de volgende functies. Per functie wordt de
relatie met PBAC uitgelegd:
Opname van een datadeelrelatie in het register legitimeert de datadeling door daarvoor een
juridische grondslag te bieden. Deze grondslag is een verwijzing naar een toepasselijk
wetsartikel of een positief besluit van het toetsingscomité.
PBAC: Voor elke autorisatieregel, dus een beperking op datadeling, geldt dat deze herleidbaar
moet zijn naar een juridische grondslag. Deze autorisatieregels inclusief grondslagen worden
vastgelegd in de policies van PBAC (zie Policy Administration Point (PAP)).
Het maakt op één plek inzichtelijk welke stelseldata, met welke partijen, voor welk doel mogen
worden gedeeld en wat daarvoor de juridische grondslag is. Hiermee kan ook periodiek worden
getoetst of eerder genomen beslissingen nog steeds valide zijn. Daarnaast ontstaat inzicht op
welke gebieden aanpassing van wetgeving nodig is om oordelen van het toetsingscomité juridisch
sterker te verankeren.
PBAC: De policies inclusief herleiding naar juridische grondslag worden vastgelegd in de Policy
Administration Point (PAP). Door deze transparant te publiceren en te zorgen dat die via één plek
inzichtelijk is, kan hieruit het inzicht verkregen worden op welke gebieden aanpassing van
wetgeving nodig is.
Op het Federatief Datastelsel aangesloten data-aanbieders kunnen op basis van de gegevens in het
register eenvoudig, geautomatiseerd, vaststellen of ze een datadeel-verzoek van een tot het
stelsel toegelaten afnemer mogen honoreren. Ze hoeven dus niet meer zelf een juridische toets uit
te voeren.
PBAC: Door voor het autoriseren het mechanisme PBAC te gebruiken, worden er voorafgaand aan de
datasamenwerking voorwaarden gesteld aan het delen van data. Het maken van het besluit of iemand
toegang krijgt tot data wordt geautomatiseerd gedaan door het Policy Decision Point (PDP) op
basis van de opgestelde policies. De juridische toets, maar ook afwegingen op het vlak van
ethiek, privacy, maatschappelijke wenselijkheid en belang, zijn vooraf al gedaan en hoeven niet
plaats te vinden tijdens het proces van datadelen.
Vastlegging in het centrale register van datadeelrelaties, in combinatie met de toelating tot
het stelsel (het voldoen aan de aansluitvoorwaarden) vervangt de bilaterale contracten die nu nog
vaak nodig zijn om de datadeling tussen partijen te legitimeren.
PBAC: Door PBAC als voorwaarde vanuit het Federatief Datastelsel te stellen wordt op een eenduidige en
gestructureerde manier datadeling geregeld. Een datavragende partij kan gestandaardiseerd toegang
verkrijgen en er hoeft dus geen bilateraal contract nodig te zijn.
Hoe PBAC precies een deel van de poortwachterfunctie kan invullen vereist een uitvoerige
vervolgstudie, bij voorkeur aan de hand van Use Cases.
Voorbeelden
SUWINET is een goed voorbeeld om te kunnen laten zien hoe het gebruik van PBAC uitdagingen kan
oplossen en verbeteren. Bij dit voorbeeld heeft de dataleverende kant veel verantwoordelijkheid en
daardoor wordt er informatie buiten het systeem om uitgewisseld. Dit is niet de gewenste situatie en
door het gebruik van PBAC kan dit worden verbeterd.
Vanuit CIO-Rijk zijn enkele voorbeelden aangeleverd van policies:
Deze dienst mag alleen via een door ons vertrouwd netwerk gebruikt worden.
De persoon moet geauthentiseerd zijn door een door ons vertrouwde IDP op het juiste niveau
De persoon moet handelen namens een door ons vertrouwd bedrijf.
De persoon mag alleen data zien voor het bedrijf namens welke de persoon werkt.
Uitdagingen
Naast de voordelen van het gebruik van PBAC bestaan er ook enkele uitdagingen in de huidige
context van het Federatief Datastelsel en de overheid:
Vooraf weet je niet precies door wie of waarom de data gebruikt gaat worden, dus bij het
aansluitproces van een afnemer zal er constant gecheckt moeten worden of de policies die er zijn
wel toereikend zijn én of ze geen gaten laten vallen bij de nieuw situatie. Dit hoort bij het
principe Zero Trust.
Binnen de overheid wordt PBAC (volgens CIO-Rijk) nog niet echt ergens geïmplementeerd. Bij grote
Tech bedrijven of financiële instellingen is het gebruikelijker.
Dit document geeft een eerste concept voor hoe de structuur van PBAC binnen een Federatief
Datastelsel eruit kan komen te zien. De technische implementatie kent echter nog veel
verschillende smaken. Hier zullen goede afwegingen in gemaakt moeten worden.
Complexiteit vanuit een landschapsperspectief: het overheidsorgaan is eigenaar van veel plekken
waar de data staat:
Er zijn meerdere plekken waar de data staat, want de data staat bij de bron;
Er zijn meerdere afnemers van de data;
Het hele landschap wijzigt ook voortdurend.
Daarnaast moet toegang tot data eenvoudig en snel toegekend te worden. Dit is waarom er vaak een
voorkeur is voor policies en niet een RBAC-model.
Stappen voor vervolg
Naast een discussiestuk (dit document) hebben het project Federatief Datastelsel en
Digilab het voornemen om PBAC in een concrete proefopstelling te
tonen, om tastbaar te maken wat policies zijn en wat ervoor ingeregeld moet worden. Vervolgstappen
worden in een separaat document uitgewerkt en zal de volgende onderwerpen bevatten:
Casusbeschrijving en uitwerking van een use case met concrete policies en attributen;
Onderzoek naar of XACML (of ODRL) nog steeds de standaard is;
Verhouding PBAC met mechanismen van iSHARE, en met andere technieken;
Uitwerking relatie PBAC en de poortwachterfunctie;
Onderzoek naar het maken van specifieke endpoints voor specifieke klanten;
Gebruik van FSC (VNG), verbinding moet verder worden uitgewerkt;
Noraonline.nl – Nederlandse Overheid Referentie Architectuur ↩︎
Stelselfunctie voor het onderhouden van de stelselarchitectuur en het faciliteren van de communities waarin kennis en ervaring over het stelsel wordt gedeeld. Het kennisnetwerk.
biedt eerstelijnsondersteuning van gebruikers en geregistreerden.
Status
Deze functie wordt samen met het kenniscentrum van de Interbestuurlijke Datastrategie (IBDS)
vormgegeven en groeit mee met de behoeften van aanbieders en gebruikers.
Achtergrond
// TODO
FDS context & positionering
// TODO
Inhoudelijke verdieping
// TODO
Standaardisatie
// TODO
29 - Marktmeester
Stelselfunctie voor het verbinden van vraag en aanbod. Ondersteunt bij het inzichtelijk maken van het potentieel en het realiseren van nieuwe gebruikerswensen.
verbindt vraag en aanbod van data voor sectoroverstijgend,
meervoudig gebruik.
Helpt het gebruikspotentieel van het Federatief Datastelsel inzichtelijk te maken en ondersteunt
stelselgebruikers bij het inbrengen van hun eisen en wensen omtrent data voor maatschappelijke
opgaven.
Status
Er is een inrichtingsvoorstel gemaakt voor de invulling van de Marktmeester functie tijdens de
projectfase waarbij er een centraal aanspreekpunt is. Dit voorstel is besproken in het Tactisch
Stelseloverleg van 30 mei
2023.
Met deze tijdelijke invulling wordt de komende tijd ervaring opgedaan in samenwerking met het
project Data in maatschappelijke opgaven. Deze praktijkervaring wordt gebruikt om later een
voorstel voor de definitieve inrichting van deze stelselfunctie te doen.
Achtergrond
// TODO
FDS context & positionering
// TODO
Inhoudelijke verdieping
// TODO
Standaardisatie
// TODO
30 - Poortwachter
Stelselfunctie voor toetsing, autorisatie en registratie van koppelingsverzoeken. Toetst op conformiteit met de AVG en de stelsel aansluit- en gebruiks-voorwaarden en zorgt daarbij voor een transparant beslisproces.
Toetst, autoriseert en registreert koppelingsverzoeken tussen bronnen. Toetst op conformiteit met
de AVG en de stelsel aansluit- en gebruiksvoorwaarden.
Zorgt voor een transparant beslisproces.
Status
Er is een startnotitie gemaakt.
In de tweede helft van 2023 is de beschrijving van de werking verdiept langs een aantal dimensies:
functies, standaarden, voorzieningen en wettelijk inbedding. Dit als opmaat naar demonstrators en
experimenten in het Digilab om de feitelijke werking zo concreet mogelijk te maken.
Achtergrond
// TODO
FDS context & positionering
Kernelement van het federatief datastelsel is dat datagebruik in overeenstemming is met publieke
waarden. Om dit waar te maken, is het nodig dat ontwerp en realisatie van het FDS vanuit dit
perspectief worden gestuurd. Daartoe zijn de volgende ontwerpelementen passend:
Poortwachtersfunctie.
Dataminimalisatie.
Regie op Gegevens.
Het stelsel voorziet in gecontroleerde toegang tot gevoelige data. Voor het toegang bieden en
afnemen van data die niet gevoelig zijn, volstaan veelal algemene toegangsregels, bijvoorbeeld bij
een bron die als open data is aangemerkt. Voor gevoelige stelseldata zoals persoonsgegevens, waarbij
gebruikt wordt gemaakt van het BSN als identificatie en koppelingssleutel, is meer nodig. Deze data
passeren eerst de stelselfunctie Poortwachter.
De poortwachters is de functie binnen het Federatief Datastelsel die op basis van een formeel
vastgesteld toetsingskader bepaalt of de combinatie data - gebruikersgroep - gebruiksdoel kan worden
toegestaan. Dit is een drempel om ervoor te zorgen dat er een zorgvuldige afweging wordt gemaakt
tussen de vaak tegenstrijdige maatschappelijke belangen bij nieuwe vormen van sector overstijgend
datagebruik.
Door de verantwoordelijkheid voor deze toetsing op stelselniveau te beleggen, kan kennis over
verantwoord datagebruik worden gebundeld en ontstaan er meer mogelijkheden om de afweging
transparant en controleerbaar te maken. Dit maakt het proces efficiënter doordat individuele
data-aanbieders worden ontzorgd omdat ze op uitvoeringsniveau geen belangenafweging meer hoeven te
maken die eigenlijk op het politieke niveau thuishoort.
Onderdeel van het toetsingskader is het benutten van de verschillende opties die het stelsel biedt
om verantwoord data te delen. Zo ondersteunt het toekomstig stelsel dataminimalisatie waarbij de
verstrekkers van stelseldata privacy enhancing technologies toepassen of intelligente
bevragingsdiensten leveren die gericht antwoord geven op een gestelde informatievraag (bijvoorbeeld
is deze persoon jonger dan 18?).
In een aantal gevallen is het dan niet meer nodig om (privacy)gevoelige data te delen. Een andere
mogelijkheid die het stelsel ondersteunt is het faciliteren dat de burger of het bedrijf zelf
toestemming geeft om persoonlijke of bedrijfsdata via het federatief datastelsel met anderen te
delen.
De Poortwachtersfunctie zorgt voor toetsing, autorisatie en registratie van verzoeken om data te
delen1 . De toetsing zal veelal neerkomen op het afwegen van strijdige belangen, waarbij de volgende
zaken een rol spelen:
Noodzaak (er zijn geen alternatieven, digitaal werken is nodig, het gaat om tot de persoon
herleidbare of concurrentiegevoelige gegevens).
Het maatschappelijke belang
Het recht op bescherming van de persoonlijke levenssfeer (bescherming privacy).
Juridische toelaatbaarheid.
Ethische toelaatbaarheid.
Maatschappelijke wenselijkheid.
Conformiteit met aansluit- en gebruiksvoorwaarden van het federatief datastelsel.
Dit gebeurt in een transparant beslisproces met mogelijkheden voor bezwaar en beroep. De uitkomst
van dit proces wordt vastgelegd in een openbare registratie (gegevensstroom boekhouding). Deze
registratie heeft de volgende functies:
Opname van een datadeelrelatie in het register legitimeert de datadeling door daarvoor een
juridische grondslag te bieden. Deze grondslag is een verwijzing naar een toepasselijk wetsartikel
of een positief besluit van het toetsingscomité.
Het maakt op één plek inzichtelijk welke stelseldata, met welke partijen, voor welk doel mogen
worden gedeeld en wat daarvoor de juridische grondslag is. Hiermee kan ook periodiek worden
getoetst of eerder genomen beslissingen nog steeds valide zijn. Daarnaast ontstaat inzicht op
welke gebieden aanpassing van wetgeving nodig is om oordelen van het toetsingscomité juridisch
sterker te verankeren.
Op het federatief datastelsel aangesloten data aanbieders kunnen op basis van de gegevens in het
register eenvoudig, geautomatiseerd, vaststellen of ze een datadeel verzoek van een tot het
stelsel toegelaten afnemer mogen honoreren. Ze hoeven dus niet meer zelf een juridische toets uit
te voeren.
Vastlegging in het centrale register van datadeel relaties, in combinatie met de toelating tot het
stelsel (het voldoen aan de aansluitvoorwaarden) vervangt de bilaterale contracten die nu nog vaak
nodig zijn om de datadeling tussen partijen te legitimeren.
De Poortwachtersfunctie is één van de structurele stelselfuncties die het project Federatief
Datastelsel de komende jaren zal realiseren. Bij de realisatie wordt gebruik gemaakt van de
resultaten van andere onderdelen van het programma Realisatie Interbestuurlijke Datastrategie
(Adviesfunctie verantwoord datagebruik, het organiseren van datadialogen) en de uitkomsten van
relevante externe trajecten zoals het wetgevingswerk van de Regeringscommissaris
Informatiehuishouding.
De eerste stap is het ontwerp van deze functie, vergelijkbaar met de wijze waarop de inrichting van
de Marktmeesterfunctie is beschreven. Daarna zal de feitelijke inrichting via use
cases / praktijksituaties plaatsvinden. Het tempo hangt daarmee af van de snelheid waarmee geschikte
use cases zich voordoen. Parallel wordt de technische functionaliteit van de Poortwachtersfunctie
beproefd (m.b.v. de Integrale Gebruiksoplossing, de IGO) in de Innovatiewerkplaats.
Standaardisatie
// TODO
31 - Regisseur
Stelselfunctie voor de coördinatie van beheer en (door)ontwikkeling van het stelsel.
Deze functie bestaat al in het huidige Stelsel van Basisregistraties. Deze rol wordt over het
algemeen ingevuld door de verantwoordelijk opdrachtgever voor de registratie. Dit wordt op termijn
en in samenspraak met omgevormd tot een passende toezichtfunctie voor het FDS.
Achtergrond
// TODO
FDS context & positionering
// TODO
Inhoudelijke verdieping
// TODO
Standaardisatie
// TODO
33 - Standaarden
Het programma realisatie FDS heeft een eerste lijst met standaarden opgesteld die partijen in eerste instantie moeten toepassen om federatief datadelen mogelijk te maken.
Deze notitie over standaarden in het federatief datastelsel is het vertrekpunt voor het gebruik van standaarden. Het federatief model laat opslag en beheer van data lokaal aan bronhouders, maar faciliteert datagebruik over bronnen heen, centraal door een interoperabel systeem van afspraken en oplossingen op ontsluiting, toegang, annotatie en koppeling.
Context
Op een federatieve manier data delen is alleen maar mogelijk als partijen dezelfde standaarden toepassen. Over de wijze waarop worden in het stelsel nadere afspraken gemaakt, alsook over de invulling van de benodigde organisatorische stelselfuncties, financiering, etc.
Het programma realisatie-FDS heeft een eerste lijst met standaarden opgesteld die partijen in eerste instantie moeten toepassen om federatief datadelen mogelijk te maken. deze lijst treft u aan in bijlage 1. dit is een combinatie van bestaande standaarden recent ontwikkelde standaarden en standaarden in ontwikkeling. er zijn meer standaarden nodig waar we in de loop van de tijd zicht op zullen krijgen. deze eerste lijst wordt gepubliceerd om onze omgeving al vroegtijdig inzicht te geven in relevante standaarden zodat men daar rekening mee kan houden.
hoe worden de standaarden vastgesteld?
Voor het vaststellen van standaarden wordt gebruik gemaakt van het bestaande besluitvormingsproces. Forum Standaardisatie toetst open standaarden en adviseert het Overheids-breed Beleidsoverleg Digitale Overheid (OBDO) over het voorschrijven ervan aan publieke organisaties. Dit kan als aanbeveling of volgens een ‘Pas toe of leg uit’-verplichting. Standaarden met een ‘Pas toe of leg uit’-verplichting kunnen verzwaard worden met een streefbeeldafspraak of tot wettelijke verplichting.
Standaarden worden vastgesteld via de bestaande procedure van het Forum;
De voor FDS relevante standaarden zijn ook (bestaande of beoogde) GDI-standaarden, daarvoor wordt de bestaande governance van de GDI gebruikt;
De architectuurraad GDI adviseert de PGDI en IDO;
Bespreking van gebruik van standaarden voor FDS vindt plaats in het Tactisch Overleg FDS. Indien relevant voor de CDO’s dan ook in de CDO-raad.
Het IDO fungeert als ‘voorportaal’ van het OBDO op het gebied van datavraagstukken en heeft een regisserende en stimulerende rol (sponsor). Het IDO is geen besluitvormend overleg. Het OBDO bekrachtigt de standaarden;
In het OBDO kunnen afspraken gemaakt worden over implementatie(ondersteuning) van standaarden.
Is er meer nodig dan opname van de standaarden op de ‘pas toe of leg uit’-lijst?
Het gebruik van standaarden is essentieel voor de werking van het FDS. Afnemers van data kunnen deze alleen gebruiken als aanbieders en afnemers voldoen aan de afspraken die in het stelsel zijn gemaakt. In veel gevallen zullen partijen zelf de meerwaarde van de toepassing van standaarden in de eigen context zien en zullen deze in de loop der tijd gebruikt worden.
Dit zal echter niet opgaan voor standaarden waarvan de meerwaarde van het gebruik vooral tot uiting komt op stelselniveau. Bovendien laat het verleden zien dat zonder flankerend beleid de adoptie van dergelijke standaarden minstens 10 jaar duurt.
Voor het slagen van FDS is het van belang dat de prioriteit van het toepassen van de noodzakelijke standaarden voor aanbieders en afnemers hoog is. Dat kan door een combinatie van maatregelen:
Gestructureerd, aan de hand van een meerjaren implementatie agenda, afspraken maken over ontwikkeling en adoptie van standaarden;
Implementatie-ondersteuning voor deelnemers in het stelsel;
Het monitoren van de voortgang;
Het op termijn verplichten van de minimaal noodzakelijke standaarden in de Wet Digitale overheid.
FDS standaarden: de basis
Hieronder staan de standaarden beschreven die partijen in eerste instantie moeten toepassen om op de FDS-manier te gaan werken. Daarnaast is een aantal standaarden benoemd die op dit moment ontwikkeld wordt zodat daar nu al rekening mee kan worden gehouden en meegedaan kan worden bij de totstandkoming als dat gewenst is. Standaarden die ook toegepast moeten worden maar meer generiek van aard zijn (informatiebeveiliging) of zeer specifiek zijn (bijvoorbeeld geo-standaarden), zijn niet opgenomen in dit document omdat die niet FDS-specifiek zijn.
Doel: Inzicht in het data-aanbod
Wat omvat de standaard
Standaard
Status van de standaard
Standaard voor het beschrijven van datasets: Welke datasets (gegevensverzamelingen) zijn beschikbaar, welk licentietype, toegangsregime is daarop van toepassing, wie biedt de dataset aan? Welke dataservices worden bij een dataset aangeboden?
DCAT 2.0
Aanbevolen standaard
Nederlands profiel DCAT
In ontwikkeling
Standaard voor het beschrijven van dataservices (gegevensdiensten): welke dataservices zijn beschikbaar, welk licentietype, toegangsregime is daarop van toepassing, wie biedt de dataservice aan? Op welke datasets opereert de dataservice?
Inzicht in de betekenis van begrippen en relaties met andere begrippen (bijv. uit andere sectoren)
SBB
Consultatie afgerond
SKOS
Verplicht (pas toe of leg uit)
Doel: Ontsluiten van data
Wat omvat de standaard
Standaard
Status van de standaard
API’s waarmee data direct kan worden bevraagd (dataservices) of waarmee functionaliteit wordt ontsloten (services)
REST API Design Rules
Verplicht (pas toe of leg uit)
Uitwisselen van berichten tussen applicaties over plaatsgevonden gebeurtenissen (notificaties)
CloudEvents
Internationale standaard
NL Gov CloudEvents
In ontwikkeling
Het veilig en geautomatiseerd kunnen koppelen van services tussen verschillende organisaties
Digikoppeling REST API
Verplicht (pas toe of leg uit)
FSC
In consultatie
Data uit verschillende bronnen in samenhang bevragen
IMX
In ontwikkeling
Doel: Verantwoord datagebruik
Wat omvat de standaard
Standaard
Status van de standaard
API-standaard voor het vastleggen en ontsluiten van metagegevens behorend bij vastgelegde (gelogde) verwerkingen.
Verwerkingenlogging
In ontwikkeling
‘Pas toe of leg uit’-beleid
Sommige belangrijke open standaarden worden te weinig gebruikt, waardoor onze digitale samenleving kwetsbaar, inefficiënt of niet toegankelijk is voor iedereen. Daarom geldt voor deze standaarden het ‘Pas toe of leg uit’-beleid. De verplichting geldt voor gemeenten, provincies, rijk, waterschappen en alle uitvoeringsorganisaties. Voor alle andere organisaties in de publieke sector geldt het gebruik van de ‘Pas toe of leg uit’-standaarden als een dringend advies.
Pas toe
‘Pas toe’ betekent dat op het moment dat u ICT aanschaft (een dienst of en product), u de ‘Pas toe of leg uit’-lijst moet raadplegen. Wanneer de aanschaf valt onder een toepassingsgebied dat voorkomt op deze lijst, moet u de standaard(en) toepassen.
Leg uit
Afwijken van het gebruik van de voorgeschreven standaarden mag alleen als een dergelijke dienst of product in onvoldoende mate wordt aangeboden, onvoldoende veilig of zeker functioneert of om een andere reden die van bijzonder gewicht is. De afwijking en de reden daarvan moeten beschreven worden in de bedrijfsvoeringparagraaf van het jaarverslag. Dit is de betekenis van ‘leg uit’.
Streefbeeldafspraken en wettelijke verplichting
Voor sommige standaarden duurt het moment van een volgende aanschaf te lang, waardoor de publieke dienstverlening te veel risico loopt. Er worden dan Streefbeeldafspraken gemaakt om de adoptie te versnellen. En leiden ook deze afspraken tot onvoldoende resultaat, dan kan een standaard in aanmerking komen voor wettelijke verplichting op grond van de Wet digitale overheid.
