Dit is de multi-page printable view van deze sectie. Klik hier om te printen.

Terug naar normale view van deze pagina.

Werkbank

Welkom!

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.

Het federatief datastelsel gebruikt een Raamwerk voor ontwikkeling in samenwerking. Hieronder is de uitwerking van de capabilities die daar benoemd worden.

Voor meer informatie over Capabilities en de context van het federatief datastelsel, lees onze Strategie van samenwerken en het Raamwerk voor ontwikkeling in samenwerking. In de Werkomgeving kun je lezen hoe je kunt bijdragen en hoe de samenwerkomgeving is opgezet. Wil je meer lezen over achterliggende overwegingen (besluiten), lees onze DR 00001 Basisstructuur en DR 0004 Capabilities NL.

1.1.1 - Bestuurlijk

Governance | Bestuurlijk: Bestuurlijke overeenkomsten en juridische constructen

Beschrijving

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

Beschrijving

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.

Meer lezen

De capability Operationeel is gebaseerd op het Organisational/Operational Management building block zoals beschreven in het OPEN DEI design principles position paper on Resources.

In de Blueprint van het Data Spaces Support Centre zijn de Governance Building Blocks aangepast ten opzichte van Open DEI. In de context van operationele processen is het Building Block Participation Management opgenomen.

Operationele processen binnen het FDS

Binnen het FDS onderkennen we de volgende groepen operationele processen:

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

Beschrijving

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

Hoofdcategorie bouwblokken, namelijk Interoperabiliteit!

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

Beschrijving

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

Beschrijving

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.

Bouwblokken

1.2.3 - Traceerbaarheid

Interoperabiliteit | Traceerbaarheid: Traceerbaarheid en herleidbaarheid

Beschrijving

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

1.3.1 - Identiteit

Vertrouwen | Identiteit

Beschrijving

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.

Meer lezen

De capability Identiteit is gebaseerd op het Identity Management building block zoals beschreven in het OPEN DEI design principles position paper on Resources.

In de Blueprint van het Data Spaces Support Centre wordt het bewijzen van de identiteit met een Verifiable Credential (VC) beschreven in het Building Block Identity and Attestation Management. Dit houdt verband met het toegekende vertrouwen aan een beweerde identiteit in het Building Block Trust Framework.

Identiteit binnen het FDS

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:

Mogelijke identificatiemiddelen bij het leggen van een verbinding waarbij de deelnemer rechtstreeks wordt geidentificeerd:

Mogelijke identificatiemiddelen bij het leggen van een verbinding waarbij de deelnemer of een verwerker in een leveringsovereenkomst is aangewezen:

  • een eIDAS QWAC X.509 certificaat met een OIN of KvK-nummer
  • een PKIoverheid Services X.509 certificaat met een OIN tbv TLS
  • 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.

Standaarden

1.3.2 - Toegang

Vertrouwen | Toegang: Toegangscontrole en gebruikscontrole

Beschrijving

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.

Meer lezen

De capability Identiteit is gebaseerd op het Access and Usage Control/Policies building block zoals beschreven in het OPEN DEI design principles position paper on Resources. In de Blueprint van het Data Spaces Support Centre wordt toegang beschreven in het Building Block Access and Usage Policies Enforcement.

Meer informatie over het toepassen over policies is beschreven in het Position paper Policy Based Access Control en de resultaten van de projecten Lock-Unlock en Federatieve toegangsverlening.

Toegang binnen het FDS

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.

Standaarden

1.3.3 - Veiligheid

Vertrouwen | Veiligheid: Vertrouwde uitwisseling

Beschrijving

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

Meer lezen

De capability Veiligheid is gebaseerd op het Trusted Exchange building block zoals beschreven in het OPEN DEI design principles position paper on Resources.

In de Blueprint van het Data Spaces Support Centre wordt het bewijzen van de identiteit met een Verifiable Credential (VC) beschreven in het Building Block Identity and Attestation Management. Dit houdt verband met het toegekende vertrouwen aan een beweerde identiteit in het Building Block Trust Framework.

Er zijn daarnaast diverse bronnen die informatie geven over eisen en maatregelen met betrekking tot veilige uitwisseling van gegevens, bijvoorbeeld:

Veiligheid binnen FDS

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.

Veiligheid binnen FDS met FSC
Veiligheid binnen FDS met FSC

Standaarden

1.4 - Datawaarde

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

1.4.1 - Metadata

Datawaarde | Metadata: Metadata in brede zin met beschrijvingen, verwijzingen en meer

Beschrijving

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.

Meer lezen

De capability Metadata is gebaseerd op het Metadata and Discovery Protocol zoals beschreven in het OPEN DEI design principles position paper on Resources.

In de Blueprint van het Data Spaces Support Centre wordt metadata beschreven in het building block Data, Services and Offerings Descriptions. Binnen de blueprint is ‘discovery’ ten opzichte van OpenDEI verplaatst naar Publication and Discovery.

De NORA biedt kennis over metadata in Wat zijn metadata en metadatamanagement en de relatie tussen metadata en modellen (semantiek) in Nationaal Semantisch Vlak.

Metadata binnen het FDS

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 deelnemerslijst van het FDS
  • De deelnemerkenmerken van de verschillende deelnemers binnen het FDS
  • Het aanbod binnen het FDS (DCAT)
  • 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
FDS metadata overzicht

De uitwerking van metadata met betrekking tot (traceerbaarheid van) individuele gegevensleveringen is onderdeel van de capability Interoperabiliteit | Traceerbaarheid.

Standaarden

1.4.2 - Verantwoording

Datawaarde | Verantwoording : Verantwoording van datagebruik

Beschrijving

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

Bouwblokken

  • [Verwerkingenlogging] (met integratie met FSC)
  • [Verwerkingsactiviteit]
  • […]

1.4.3 - Publicatie

Datawaarde | Publicatie: Publicatie- en marktplaatsdiensten

Beschrijving

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.

Meer lezen

De capability Metadata is gebaseerd op het Publication and Marketplace Services zoals beschreven in het OPEN DEI design principles position paper on Resources.

In de Blueprint van het Data Spaces Support Centre wordt publicatie beschreven in het building block Publication and Discovery. Binnen OpenDEI is Discovery echter bij de capability Metadata ondergebracht.

Publicatie van het FDS aanbod

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.

Publicatie via de FDS catalogus
Publicatie via de FDS catalogus

Standaarden

2 - Raamwerk

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.

Basisstructuur Kern

Om de verbinding en relaties tot andere lagen modellen te maken, hebben we deze naar NORA en Archimate al duidelijk ingetekend:

Basisstructuur Kern

De kern van het raamwerk bevindt zich in een grotere context welke … behoorlijk omvangrijk en indrukwekkend is:

Basisstructuur Volledig

3 - Basisconcept

Het basisconcept van het Federatief Datastelsel

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
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 ‘houtskoolschets’ 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:

alt text

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:

  1. De Marktmeester die ondersteunt bij het matchen van vraag en aanbod.
  2. De Expertisefunctie, die kennis levert over de inhoud en het toepassen van de FDS-afspraken, standaarden en voorzieningen.
  3. 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.

5 - Doel en aanpak van FDS

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

Bron: Meerjarenaanpak Interbestuurlijke Datastrategie.

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.

Aanpak project ‘Realisatie Federatief Datastelsel’

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

Figuur 3: FDS capabilities diagram

7 - Stelseldata

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.

Om data als begrip te omschrijven gebruiken we de definitie zoals omschreven in artikel 2 lid 1 van de Europese Data Governance Act:

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:

Data zijn adequaat beschreven

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:

  1. Als deze aantoonbaar onder controle is van de partij die ook de bron ontsluit;
  2. 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’.

Zie ook Data bij de bron.

Vertrouwensraamwerk

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.

 

10.1 - Catalogusfunctie

Inzicht bieden in het aanbod van data en dataservices.

Catalogusfunctie

De Catalogusfunctie is een technische stelselfunctie.

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

Monitoringsfunctie

De Monitoringsfunctie is een technische stelselfunctie.

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

Achtergrond

// TODO

FDS context & positionering

// TODO

Inhoudelijke verdieping

// TODO

Standaardisatie

// TODO

10.3 - Notificatiefunctie

Inzicht bieden in gebeurtenissen.

Notificatiefunctie

De Notificatiefunctie is een technische stelselfunctie.

  • Doel Inzicht bieden in gebeurtenissen
  • 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.

Terugmeldfunctie

De Terugmeldfunctie is een technische stelselfunctie.

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

Achtergrond

// TODO

FDS context & positionering

// TODO

Inhoudelijke verdieping

// TODO

Standaardisatie

// TODO

10.5 - Toegang

Identificatie, authenticatie en logging.

Toegang

Toegang is een technische stelselfunctie.

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

Zie ook Position paper Policy Based Access Control.

Inhoudelijke verdieping

Identificatie en authenticatie

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.

Standaardisatie

Een standaard waarmee in het FDS toegang langs deze route is in te regelen is de Federatieve Service Connectiviteit Standaard.

10.6 - Verantwoordingsfunctie

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 - Concept data-ecosysteem Nederlandse overheid

Conceptuele beschrijving van data-ecosysteem voor de Nederlandse overheid

Inleiding

Deze pagina beschrijft een algemeen concept van het data-ecosysteem voor de Nederlandse overheid.

Afhankelijk van de beschrijvingscontext gebruiken we in deze beschrijving de term ‘data’ of de term ‘gegevens’. Qua betekenis maakt het geen verschil, de termen zijn uitwisselbaar.

Met de term ‘organisatie’ bedoelen we op deze pagina een publieke organisatie van de overheid. Private organisaties duiden we aan met de term ‘bedrijf’.

Data-ecosysteem omschrijven we in deze context als een samenwerkend geheel van actoren, technologieën en processen om data te verzamelen, op te slaan, te verwerken, te analyseren en te delen, met het doel om waarde te creëren uit data ten behoeve van de Nederlandse maatschappij.

De Nederlandse overheid vraagt een data-ecosysteem dat optimaal is afgestemd op de wijze waarop zij is ingericht en functioneert. De inrichting in bestuurslagen volgens het ‘huis van Thorbecke’ is de organisatorische basis. De bestuurslagen, het Rijk, de Provincies, de Waterschappen en de Gemeenten, hebben ieder hun eigen verantwoordelijkheden. Gezamenlijk vormen ze echter het geheel van de Nederlandse overheid. De functionele basis komt voort uit de beleidscycli waar de bestuurslagen individueel en gezamenlijk invulling aan geven, van beleidsontwikkeling en -vaststelling tot beleidsuitvoering en -evaluatie.

Naar analogie hiervan vraagt de digitale overheid een digitale basis die alle bestuurslagen en alle beleidssectoren dient. Die gezamenlijke basis is federatief opgebouwd. Elke organisatie is verantwoordelijk voor de eigen digitale informatievoorziening en conformeert tegelijkertijd aan generieke afspraken en standaarden.

Op hoofdlijnen bestaat de digitale basis uit:

  • Een zachte infrastructuur van afspraken en standaarden waar elke organisatie, indien van toepassing, aan conformeert;
  • Een generieke architectuur, i.c. de NORA-familie en de Generieke Digitale Infrastructuur (GDI);
  • Systemen en datastelsels die zich federatief kunnen ontwikkelen binnen ketens en domeinen;
  • Een algemeen verbindend stelsel van stelsels, dat specifieke domeinstelsels in samenhang kan koppelen.

Zo functioneert een ecosysteem dat de beleidscyclus optimaal ondersteunt door vertrouwd delen en gebruiken van data. Dit resulterend in effectief beleid op complexe maatschappelijke vraagstukken en voor adequate publieke dienstverlening die daarmee annex is.

Zonder data geen beleid en geen uitvoering

Afbeelding A
Afbeelding A: Datastromen Nederlandse overheid

De afbeelding ‘Datastromen Nederlandse overheid’ is afgeleid van een klassieke overheidsbeleidscyclus en aangevuld met typering en herkomst van de daarin voorkomende data en datastromen.

De Nederlandse overheid heeft data nodig om invulling te kunnen geven aan haar taken. Dit betreft zowel data voor beleidsvorming bij complexe maatschappelijke vraagstukken als data die nodig is om uitvoering te geven aan beleid door middel van concrete dienstverlening aan de burgers en bedrijven in de maatschappij.

Data voor uitvoering en dienstverlening is ‘operationeel’ van aard en heeft betrekking op zaken waarin specifieke personen, bedrijven en/of objecten een rol spelen. Bijvoorbeeld data die nodig is om een rijbewijs af te geven, of om een door iemand aangekochte auto over te schrijven op diens naam. Voor dergelijke operationele diensten bestaat altijd een wettelijke grondslag.

Voor beleidsvorming is data nodig over (grootschalige) populaties die een rol spelen in het betreffende maatschappelijke beleidsvraagstuk. Denk aan data over uitstoot van bepaalde stoffen door gemotoriseerd verkeer binnen Nederland. Het spreekt voor zich dat statistische analyses daarin belangrijk zijn. De data voor dergelijke analyses komen enerzijds voort uit de maatschappij, waarin bijvoorbeeld een organisatie als CBS een belangrijke bijdrage levert. Anderzijds vormen de eerder genoemde operationele data een belangrijke bron. De wettelijke kaders voor beleidsvorming zijn onder andere opgetekend in de Grondwet, institutionele wetten, de Algemene Wet Bestuursrecht, Ministeriële regelingen en Koninklijke besluiten. Een belangrijk principe bij gebruik van data voor beleidsvorming, is beleidsmatige rechtvaardiging en proportionaliteit.

De operationele data die de overheid verzamelt en produceert bij de uitvoerende taken kunnen dus een belangrijke bron van informatie vormen voor maatschappelijke vraagstukken. Tegelijkertijd kunnen operationele data die voortkomen uit dienstverlening ook heel bruikbaar zijn bij andere vormen van dienstverlening. De Nederlandse Overheid ReferentieArchitectuur (NORA) stelt expliciet bij de (implicaties van) architectuurprincipes:

Maak zo veel mogelijk gebruik van gegevens die reeds beschikbaar zijn in plaats van deze gegevens opnieuw te verzamelen of te creëren.

In bepaalde gevallen is zelfs sprake van verplichting. Voor efficiënte en effectieve uitvoering van haar taken is de Nederlandse overheid derhalve enorm gebaat bij het eenvoudig en verantwoord kunnen delen van ‘haar eigen’ informatie.

Gegevens interpreteren en gebruiken in context

Organisaties gebruiken gegevens voor uitvoering van hun publieke taak. Die gegevens ontstaan door registratie van handelingen en besluiten van de organisatie zelf en door inwinning. Inwinnen gebeurt door gegevens op te vragen bij betrokken personen en bedrijven, of door situaties waar te nemen en die te registreren. Maar ook kan een organisatie gegevens voor hergebruik verkrijgen van een of meer collega-organisaties.

Het verkrijgen en gebruiken van gegevens gebeurt altijd binnen een bepaalde context. Omstandigheden zoals doel, achtergrond, plaats en tijd van inwinning en gebruik, zijn van invloed op hoe de gegevens begrepen moeten worden.

De context van een gegeven kan heel specifiek zijn, maar kan ook algemener van aard zijn. Zo worden binnen het zorgdomein gegevens gebruikt over patiënten. Binnen het onderwijsdomein gebruikt men gegevens over studenten. In beide gevallen gaat het om gegevens over personen. Eenzelfde persoon kan een rol spelen in beide domeinen, bijvoorbeeld als hij student is en ziek wordt, waardoor hij als patiënt een behandeling moet ondergaan. De gegevens van de persoon als student en tevens patiënt hebben een meer algemene context als het gaat om kenmerken als naam, adres en leeftijd. Een meer specifieke context geldt voor kenmerken als ‘genoten vooropleiding’ en ‘bloeddruk gemeten voor behandeling’.

De gegevenskenmerken met de algemenere context kunnen in beide domeinen worden gebruikt. Ze kunnen (indien toegestaan) worden verkregen uit een domein met een algemenere context. Het stelsel van basisregistraties kan gezien worden als een meer ‘algemeen domein’. Gegevenskenmerken met specifieke context worden aanvullend geregistreerd binnen het betreffende specifiekere domein.

Gegevens met een specifieke context zijn vooral of voornamelijk relevant binnen een specifiek domein of keten, terwijl gegevens met een algemenere context eerder geschikt zijn voor (her)gebruik in andere contexten. De algemenere gegevens kunnen daardoor ook geschikt zijn als basisgegeven en breed gedeeld worden.

 

Afbeelding B
Afbeelding B: Voorbeeld datagebruik in sectoren

Zoals hiervoor al aangegeven, kan een organisatie gegevens ook voor hergebruik verkrijgen van een collega-organisatie. Het is een belangrijk beginsel dat organisaties van de overheid gebruik maken van gegevens die al binnen de overheid bekend zijn. In het algemeen wordt dit aangeduid als hergebruik of gezamenlijk gebruik.

Hiervoor is het echter wel noodzakelijk om de context van gegevens te kennen. Zowel de context van waaruit een gegeven is ingewonnen als de context waarin het gegeven gebruikt gaat worden. In de algemene kenmerken van een persoon kunnen bij de inwinning bijvoorbeeld formele aanschrijftitels zijn opgenomen. Maar in correspondentie met die persoon kunnen afhankelijk van de omstandigheden (context) andere minder formele aanschrijftitels wenselijk zijn. Zonder kennis van de context kan het bijvoorbeeld gebeuren dat bij hergebruik van het gegeven in een informele context, de persoon ongewenst wordt aangeschreven met zijn formele titulatuur.

De context plaatst een gegeven dus in het juiste perspectief waardoor het mogelijk wordt de (her)bruikbaarheid ervan te interpreteren in een andere context. Bij het bepalen van de herbruikbaarheid gaat het op hoofdlijnen om drie vragen:

  • Is het gegeven in semantische zin bruikbaar in de nieuwe context?
  • Is het juridisch toegestaan om het gegeven in de nieuwe context te gebruiken?
  • Is het ethisch verantwoord om het gegeven in de nieuwe context te gebruiken?

Patronen van gegevens delen

Bij gezamenlijk gebruik worden doorgaans gegevens uit verschillende bronnen gebundeld tot een bruikbaar geheel. Herkenbare patronen daarbij zijn cumulatie, consolidatie en compilatie.

Cumulatie en consolidatie

Cumulatie en consolidatie komen voor als organisaties dezelfde type gegevens verzamelen. Ze leggen deelverzamelingen aan die elkaar aanvullen maar elkaar misschien ook overlappen. Dit zien we bijvoorbeeld bij lokale of regionale organisaties. Elke lokale organisatie beheert een deelverzameling van het landelijke totaal.

Cumulatie is het samenbrengen of optellen van afzonderlijke deelverzamelingen. Het benadrukt de ‘opeenstapeling van data’ zonder dat er een specifieke nadruk ligt op consistentie of integratie.

Consolidatie gaat verder dan cumulatie, omdat het niet alleen gaat om het samenvoegen van data, maar ook om het creëren van een ‘geïntegreerd en consistent geheel’. Bij consolidatie worden deelverzamelingen samengevoegd, ontdubbeld, schoongemaakt en gestructureerd om een uniforme verzameling te vormen. Dit proces zorgt voor consistentie en integriteit van de data en verbetert daarmee de bruikbaarheid ervan. Inconsistenties kunnen ook achteraf tijdens gebruik van de data nog worden opgemerkt. Het signaleren daarvan (terugmelden) kan eveneens onderdeel zijn van het consolidatieproces.

Compilatie

Bij compilatie gaat het om samenbrengen van data uit verschillende bronnen voor een specifiek doel, bijvoorbeeld het maken van een rapport of het voorbereiden van een analyse. Afhankelijk van de noodzaak om data samen te brengen, te structureren en/of te verrijken, kan het proces van compilatie gebruikmaken van cumulatie en consolidatie, naast aanvullende regels voor het afleiden van gegevens. Bij compilatie ligt de nadruk vaak op het ‘organiseren en verrijken van de data in een samenhangende vorm’ die kan worden gepresenteerd of verder geanalyseerd.

Een gecompileerde verzameling bestaat vaak uit data van verschillende soorten, welke aan de hand van overeenkomstige sleutelgegevens worden samengevoegd en vaak verrijkt met afgeleide gegevens. Binnen ketens is dit een veel toegepast patroon voor operationele data in de uitvoering van publieke dienstverlening.

Een andere belangrijke vorm van compilatie betreft statistische data ten behoeve van beleidsontwikkeling. Hiervoor worden gegevens over bepaalde populaties samengevoegd, geaggregeerd en voorzien van gemeten eenheden. Bijvoorbeeld aggregatie van voertuigdata op het kenmerk ‘soort voertuig’. Daar kan vervolgens het aantal voorkomens per soort voertuig aan worden toegevoegd.

Samenhang patronen voor gezamenlijk gebruik van data

Samenvattend vormen cumulatie, consolidatie en compilatie een logische volgorde in de patronen bij gezamenlijk gebruik van data:

  • Cumulatie kan de eerste stap zijn waarbij gegevens uit meerdere bronnen worden verzameld.
  • Consolidatie zorgt ervoor dat de gecumuleerde gegevens worden geïntegreerd in een consistent en bruikbaar geheel, waarbij inconsistenties worden opgelost.
  • Compilatie komt vaak na consolidatie en houdt in dat de gestructureerde gegevens worden samengesteld voor een specifieke toepassing, zoals gebruik in een andere context of voor analyse en rapportage.

Datadomeinstelsel

Delen van data vergt afspraken tussen aanbieders en afnemers. Vaak begint dat met een paar organisaties die samen willen werken. Er ontstaat een klein afsprakenstelseltje. Meer organisaties krijgen interesse en sluiten aan op het afsprakenstelseltje. Verdere uitbreiding gepaard met professionalisering op gebied van interoperabiliteit, standaardisatie, organisatorische inrichting, generieke functies en anderszins, laten prille datadeelrelaties zo uitgroeien tot een datadomeinstelsel (DDS).

De afbeelding toont in samenhang de procesmatige en organisatorische componenten van een datadomeinstelsel in het algemeen.

Afbeelding C
Afbeelding C: Concept datadomeinstelsel

Het datadomein bestaat bij de gratie van organisaties die de data inzamelen, produceren en bewaren. Deze hebben de taak of rol van ‘houder’ van data. De houder is ook degene die de data beschikbaar stelt voor gebruik. Elke dataverzameling valt onder de verantwoordelijkheid van de houder binnen wiens context de verzameling is/wordt opgebouwd en onderhouden.

Organisaties met de taak of rol van ‘aanbieder’ zorgen ervoor dat data die houders beschikbaar stellen, worden verwerkt tot informatieproducten waar concrete behoefte aan bestaat. De aanbieder is verantwoordelijk voor het cumuleren, consolideren en/of compileren van gegevens tot een dataproduct binnen het domein. De aanbieder is eveneens verantwoordelijk voor het maken, publiceren en aanbieden van de datadiensten waarmee het dataproduct kan worden afgenomen.

Organisaties met de taak of rol van ‘afnemer’ zijn verantwoordelijk voor het aansluiten op de datadienst en de onderhavige data op verantwoorde wijze binnen de eigen context te (laten) gebruiken. Merk op dat houder, aanbieder en afnemer rollen zijn waar organisaties invulling aan kunnen geven. Een organisatie kan een of meerdere rollen vervullen m.b.t. zowel dezelfde data als verschillende data.

Over de totaalverantwoordelijkheid voor het datadomein worden generieke afspraken gemaakt die zullen leiden tot een formele inrichting ervan. Deze inrichting kan ook bij wet worden bestendigd, zoals dat bij landelijke voorzieningen wel het geval is.

Stelsel van stelsels

Een datadomeinstelsel is, zoals de term het al aangeeft, bedoeld voor de deelnemers in het betreffende datadomein. Om data te kunnen delen tussen domeinen, moeten de datadomeinstelsels interoperabel zijn met elkaar. Deze interoperabiliteit is echter niet vanzelfsprekend. Er is een stelsel nodig dat de datadomeinstelsels met elkaar verbindt.

Afbeelding D
Afbeelding D: Concept Stelsel van Datadomeinstelsels

De datadomeinen beschikken over de kennis om data binnen het domein te verbinden, te delen en te gebruiken. Een verbindend stelsel heeft niet de taak en niet het vermogen om specifieke sector- of domeinvraagstukken op te lossen. Het zorgt in plaats daarvan voor een generieke zachte infrastructuur, bestaande uit afspraken en standaarden die datadomeinstelsels kunnen toepassen om onderling vertrouwd data te kunnen delen. Het stelsel van stelsels ondersteunt dit met generieke besturingsfuncties en eventueel generiek toepasbare voorzieningen. Zo maakt het domein- en sector-overstijgend delen van data mogelijk en vervult daarmee een brugfunctie.

De huidige bij wet bepaalde basisregistraties vormen al een verbindende factor tussen verschillende overheidstaken, -processen en -registraties. Ze kennen elk een ingericht stelsel van partijen en afspraken over inwinnen, vastleggen, kwaliteit, toezicht, rolverdeling, beschikbaar stellen, etc. Ze vormen daarmee een ‘algemeen’ datadomeinstelsel, zie ook afbeelding B op deze pagina.

De ontwikkeling van een ‘stelsel van stelsels’ kan daarmee zeker voortgaan op wat reeds voorhanden is binnen het stelsel van basisregistraties, maar het zal zich daar niet toe beperken. De basisregistraties vormen een belangrijke basis bij het benutten van het datapotentieel voor maatschappelijke opgaven. Maar daarnaast is er nog veel onbenut potentieel in sector- en ketenregistraties. De NORA beschrijft sowieso al zo’n 145 sectorregistraties. Om de potentie van deze data ook te benutten zal veel meer over sectoren en domeinen heen ontsloten moeten worden.

12 - 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 Aanbevolen standaard
Nederlands profiel DCAT In goedkeuring
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 In goedkeuring
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 goedkeuring
Het veilig en geautomatiseerd kunnen koppelen van services tussen verschillende organisaties Digikoppeling REST API Verplicht (pas toe of leg uit)
FSC Consultatie afgerond
Data uit verschillende bronnen in samenhang bevragen IMX In ontwikkeling

Doel: Verantwoord datagebruik

Wat omvat de standaard Standaard Status van de standaard
Standaard om dataverwerkingen te loggen waarmee organisaties het datagebruik kunnen verantwoorden. Logboek dataverwerkingen 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.

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

  1. 2024 Q3 Project Uit betrouwbare bron uitnodigen voor presentatie in inhoudelijk blok
  2. 2024 Q3/Q4 actieve samenwerking met Project Uit betrouwbare bron door kennisdeling en gezamenlijke sessies (met name FDS Architectenteam)
  3. 2025 Q1/Q2 update van Project Uit betrouwbare bron in inhoudelijk blok

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

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

16 - 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​

Stelselplaat 2020 met realiteit van koppelingen

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)

Tabel met FDS 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.

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

Standaarden

18 - Deelnemer-ID

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 LinkedData URI. Op de deelnemer-ID zijn de Linked Data Design Rules van toepassing. Zie ook de capability Vertrouwen | Identiteit.

Deze structuur maakt het mogelijk om de Deelnemer-ID te gebruiken als decentralized identifier (DID) bij een [Verifiable Credential (VC)] (https://www.w3.org/TR/vc-data-model-2.0/) volgens eIDAS 2.0.

Standaarden

19 - Deelnemerkenmerken

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 naam (label) van de organisatie
  • Aanvullende identificerende kenmerken van de organisatie (zoals het OIN, KvK-nummer en het RSIN)
  • De grondslag waarop de organisatie is toegelaten tot het FDS.
  • De administrateur die de deelnemer heeft opgenomen op de Deelnemerslijst

Indien het een aanbieder betreft, een verwijzing naar:

  • Het aanbod van de deelnemer (als DCAT catalog)

Indien het een administrateur betreft, de volgende verwijzingen:

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 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):

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
@prefix fds: <http://fds.example.org/ontology#>
@base <http://admin-a.example.org/fds/deelnemers/>

<organisatie-x>
   fds:versionInfo 'v8' ;
   fds:priorVersion <organisatie-x/v7> .

<organisatie-x#deelnemer>
   rdfs:label 'Deelnemer-X'@nl-nl ;
   fds:kvk '50200097' ;
   fds:oin '00000003502000970000' ;
   fds:admitted-by <http://admin-a.example.org/fds/deelnemers/self#deelnemer> ;
   fds:catalog <http://deelnemer-x.example.org/fds/dcat/#catalog> .

Standaarden

20 - Deelnemerslijst

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.

Deelnemerslijst mechanisme
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
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):

@prefix fds: <http://fds.example.org/ontology#>
@base <http://admin-a.example.org/fds/>

<deelnamewijzigingen>
   fds:versionInfo 'v4' ;
   fds:priorVersion <deelnamewijzigingen/v3> .

(
  [ a fds:participant-addition ;
    fds:of-participant <deelnemers/self#deelnemer> ; 
    fds:by-admin <deelnemers/self#deelnemer> ; 
    fds:at-timestamp "2025-04-09T10:00:00"^^xsd:dateTime ; 
    fds:in-version <deelnamewijzigingen/v1> 
  ]

  [ a fds:participant-addition ;
    fds:of-participant <http://admin-b.example.org/fds/deelnemers/self#deelnemer> ; 
    fds:by-admin <deelnemers/self#deelnemer> ; 
    fds:at-timestamp "2025-04-09T10:00:00"^^xsd:dateTime ; 
    fds:in-version <deelnamewijzigingen/v1> 
  ]

  [ a fds:participant-addition ;
    fds:of-participant <deelnemers/organisatie-x/#deelnemer> ; 
    fds:by-admin <deelnemers/self#deelnemer> ; 
    fds:at-timestamp "2025-04-09T10:00:00"^^xsd:dateTime ; 
    fds:in-version <deelnamewijzigingen/v1> 
  ]

  [ a fds:participant-addition ;
    fds:of-participant <deelnemers/organisatie-y/#deelnemer>; 
    fds:by-admin <deelnemers/self#deelnemer> ; 
    fds:at-timestamp "2025-05-12T10:00:00"^^xsd:dateTime; 
    fds:in-version <deelnamewijzigingen/v2> ]

  [ a fds:participant-addition
    fds:of-participant <deelnemers/organisatie-z/#deelnemer> ; 
    fds:by-admin <deelnemers/self#deelnemer> ; 
    fds:at-timestamp "2025-06-24T10:00:00"^^xsd:dateTime ; 
    fds:in-version <deelnamewijzigingen/v3> ]

  [ a fds:participant-removal
    fds:of-participant <deelnemers/organisatie-y/#deelnemer> ; 
    fds:by-admin <deelnemers/self#deelnemer> ; 
    fds:at-timestamp "2025-10-08T10:00:00"^^xsd:dateTime ; 
    fds:in-version <deelnamewijzigingen/v4> ]

....

)

Een voorbeeld van de resulterende deelnemerslijst (in Turtle):

@prefix fds: <http://fds.example.org/ontology#>
@base <http://admin-a.example.org/fds/>

<deelnemerslijst>
   fds:versionInfo 'v12' ;
   fds:priorVersion <deelnemerslijst/v11> ;
   fds:created-from <deelnamewijzigingen/v4> ,
                    <http://admin-b.example.org/fds/deelnamewijzigingen/v8> , 
                    <http://admin-c.example.org/fds/deelnamewijzigingen/v5> .

(
  <deelnemers/self#deelnemer> 
  <http://admin-b.example.org/fds/deelnemers/self#deelnemer> 
  <deelnemers/organisatie-x#deelnemer>
  <deelnemers/organisatie-z#deelnemer>

.... aangevuld met deelnemers vanuit andere administrateurs .....

)

De te gebruiken linked data ontologie (semantiek) en de daarbij te hanteren OWL en/of SHACL definities is nog onderwerp van onderzoek.

Standaarden

21 - Linked Data Design Rules

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.

Standaarden

22 - Processen voor deelname aan het FDS als organisatie

De operationele processen om de deelnemers van het FDS te administreren

Deelname aan het FDS als organisatie

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 deelnamecriteria zijn:

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.

Afnemers kunnen voor hun taken (sterk) afhankelijk zijn van door een aanbieder in het stelsel ingebrachte data. Processen die potentieel leiden tot intrekken en beëindigen van deelname zullen worden afgestemd op deze afhankelijkheid.

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.

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

24 - 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 😏

Zie ook:

Principe: Data direct uit de bron

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?

Beslissingsfactoren

Overwogen opties

Besluit

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

Programma Data bij de Bron

// TODO

Regie op Gegevens

Regie op gegevens is ook een programma van de Digitale Overheid. In dit programma is een voorstudie gedaan naar een kader voor regie op gegevens:

  • Hoofdprincipes
    • Mens centraal
    • Digitale autonomie
    • Inclusiviteit
  • Inrichtingsprincipes
    • Vertrouwen
    • Transparantie
    • Interoperabiliteit
    • Dataminimalisatie

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

NORA Principes

// TODO

samenvatting van NORA | Informeer bij de bron (NAP10)

Meenemen / overwegen:

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

25 - Lock-Unlock

Onderzoek van Kadaster DataScience Team over autorisatie in en als Linked Data
Lock-Unlock Infographic

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.

Voor wie meer wil weten en lezen, bekijk het volledige Lock-Unlock rapport dat gepubliceerd is op labs.kadaster.nl.

Scope van het Lock-Unlock onderzoeksproject

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.

Zie Lock-Unlock rapport: Afscherming

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.

Zie Lock-Unlock rapport: Autorisatie <em>als</em> Linked Data

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 concetpueel model
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.

Zie Lock-Unlock rapport: Conclusies

Onderwerpen voor nader onderzoek

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.

Zie Lock-Unlock rapport: Aanbevelingen

26 - FSC

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.

Meer info is te vinden op de website van CommonGround/FSC

FSC Consumer Provider

Architectuurlagen

Grondslagenlaag

Hier vind je wetten en drivers.

Componenttypen die we hier verwachten:

  • Doel/Driver
  • Principe
  • Requirement
  • Afspraak/Standaard (Wet/Overeenkomst)

Organisatorische laag

De organisatorische componenten vind je hier.

Componenttypen die we hier verwachten:

  • (Actor)
  • Rol
  • Functie
  • Service
  • Afspraak/Standaard
  • (Contract)

Informatielaag

Componenttypen die we hier verwachten:

  • Metadata-object
  • Metadata-object-relatie
  • Afspraak/Standaard

Applicatielaag

Componenttypen die we hier verwachten:

  • Functie (Technische stelselfuncties)
  • Applicatieservice
  • Afspraak/Standaard

Technologielaag

Componenttypen die we hier verwachten:

  • Node
  • Netwerk
  • Afspraak/Standaard

27 - PBAC

Position paper Policy Based Access Control voor een Federatief Datastelsel
It’s PBAC-time
PBAC voorblad

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:

  1. Identificatie zorgt er voor dat we weten wie je bent. Dit is je identiteit of een van je digitale identiteiten (accounts);
  2. Authenticatie zorgt er voor dat we met een bepaalde zekerheid weten dat je ook echt degene bent die je zegt te zijn;
  3. 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.

Access Control List
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).

Role Based Access Control
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

Een autorisatieaanvraag in PBAC (XACML)
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.

PBAC over meerdere organisaties
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:

  1. 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)).

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

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

  4. 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:

  1. Deze dienst mag alleen via een door ons vertrouwd netwerk gebruikt worden.
  2. De persoon moet geauthentiseerd zijn door een door ons vertrouwde IDP op het juiste niveau
  3. De persoon moet handelen namens een door ons vertrouwd bedrijf.
  4. 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:

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

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

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

  4. Complexiteit vanuit een landschapsperspectief: het overheidsorgaan is eigenaar van veel plekken waar de data staat:

    1. Er zijn meerdere plekken waar de data staat, want de data staat bij de bron;
    2. Er zijn meerdere afnemers van de data;
    3. 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:

  1. Casusbeschrijving en uitwerking van een use case met concrete policies en attributen;
  2. Onderzoek naar of XACML (of ODRL) nog steeds de standaard is;
  3. Verhouding PBAC met mechanismen van iSHARE, en met andere technieken;
  4. Uitwerking relatie PBAC en de poortwachterfunctie;
  5. Onderzoek naar het maken van specifieke endpoints voor specifieke klanten;
  6. Gebruik van FSC (VNG), verbinding moet verder worden uitgewerkt;

  1. Noraonline.nl – Nederlandse Overheid Referentie Architectuur ↩︎

  2. NIST 800-95 Guide to Secure Web Services ↩︎

  3. Om de twee organisaties te koppelen is er een transactielog nodig. Het Digilab is voornemens dit met FSC in november 2024 op te zetten. ↩︎

  4. FCS beschrijft in de certificaten een identiteit. Verder onderzoek is nodig om te kijken of dit de gewenste identiteit is. ↩︎

  5. NCSC: What about zero trust? ↩︎

  6. Zie Poortwachter ↩︎

28 - Expertisecentrum

Stelselfunctie voor het onderhouden van de stelselarchitectuur en het faciliteren van de communities waarin kennis en ervaring over het stelsel wordt gedeeld. Het kennisnetwerk.

Expertisecentrum

De organisatorische stelselfunctie Expertisecentrum:

  • Onderhoudt stelsel-architectuur.
  • Faciliteert community’s waarin kennis en ervaring over het stelsel wordt gedeeld.
  • Kennisnetwerk.

Status

  • Ontwikkelingen tijdens het programma Realisatie IBDS geven inzicht in de manier waarop het Expertisecentrum structureel moet worden ingericht.
  • Zodra de tijd rijp is, wordt een inrichtingsvoorstel opgesteld en ter goedkeuring voorgelegd via de Stelsel-governance.

Achtergrond

// TODO

FDS context & positionering

// TODO

Inhoudelijke verdieping

// TODO

Standaardisatie

// TODO

29 - Helpdesk

Stelselfunctie voor eerstelijnsondersteuning van gebruikers en geregistreerden. Tevens meldpunt voor het melden van fouten in overheidsregistraties.

Helpdesk

De organisatorische stelselfunctie Helpdesk:

  • 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

30 - Marktmeester

Stelselfunctie voor het verbinden van vraag en aanbod. Ondersteunt bij het inzichtelijk maken van het potentieel en het realiseren van nieuwe gebruikerswensen.

Marktmeester

De organisatorische stelselfunctie Marktmeester:

  • 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

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

Poortwachter

De organisatorische stelselfunctie Poortwachter:

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

Zie ook Position paper Policy Based Access Control.

Inhoudelijke verdieping

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

32 - Regisseur

Stelselfunctie voor de coördinatie van beheer en (door)ontwikkeling van het stelsel.

Regisseur

De organisatorische stelselfunctie Regisseur:

  • coördineert beheer en (door)ontwikkeling van het stelsel.

Status

Ontwikkelingen tijdens het programma Realisatie IBDS geven inzicht in de manier waarop de Regisseur-functie structureel moet worden ingericht.

Zodra de tijd rijp is, wordt een inrichtingsvoorstel opgesteld en ter goedkeuring voorgelegd via de Stelsel-governance.

Achtergrond

// TODO

FDS context & positionering

// TODO

Inhoudelijke verdieping

// TODO

Standaardisatie

// TODO

33 - Toezichthouder

Stelselfunctie die toeziet op het nakomen van stelselafspraken en die klachten en bezwaren daarover afhandelt.

Toezichthouder

De organisatorische stelselfunctie Toezichthouder:

  • Ziet toe op de nakoming van stelselafspraken.
  • Handelt klachten en bezwaren af.

Status

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