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

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

Klik op de betreffende capability om te lezen waar deze over gaat, welke componenten, afhankelijkheden en relaties deze heeft.

 

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 moet worden afgedwongen tijdens de dataspace operatie. Ze omvatten bijvoorbeeld voorwaarden die betrekking hebben op het steeds groter wordende belang van naleving van verplichte voorschriften zoals GDPR of de 2e Payment Services Richtlijn (PSD2) in de financiële sector.

Bouwblokken

  • […]

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.

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 identificerend kenmerk dat kan worden vastgesteld bij het leggen van de verbinding voor de gegevensuitwisseling.

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.

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 deelnemer-kenmerken zoals het KvK-nummer, RSIN en/of OIN. Het Deelnemer-ID is een Linked Data URI. Deze structuur maakt het mogelijk om de Deelnemer-ID te gebruiken als decentralized identifier (DID) bij een Verifiable Credential (VC) volgens eIDAS 2.0.

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 garandeert de handhaving van het beleid inzake datatoegang en -gebruik gedefinieerd als onderdeel van de algemene voorwaarden die zijn vastgesteld wanneer databronnen of -services worden gepubliceerd (zie capability Datawaarde | Publicatie) of onderhandeld tussen providers en consumenten. Een data-aanbieder implementeert doorgaans mechanismen voor datatoegang om misbruik van middelen te voorkomen, terwijl het besturingsmechanismen voor datagebruik meestal aan de kant van de data-afnemer worden geïmplementeerd om misbruik van data te voorkomen. In complexe datawaardeketens worden beide mechanismen gecombineerd door ‘prosumeurs’. Toegangscontrole en gebruikscontrole vertrouwen op identificatie en authenticatie (zie capability Vertrouwen | Identiteit).

Bouwblokken

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

Bouwblokken

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

Metadata in brede zin met beschrijvingen, verwijzingen en meer. Ook de discovery, ontdekkingsmechanismen, van metadata valt onder deze capability, hoewel daar ook een sterke afhankelijkheid met Datawaarde | Publicatie in zit. Voor deze beschrijvingen en verwijzingen wordt gebruik gemaakt van gemeenschappelijke (zelf)beschrijvingen van bronnen, diensten en deelnemers. Dergelijke beschrijvingen kunnen zowel domein-agnostisch als domein-specifiek zijn. Ze moeten mogelijk worden gemaakt door semantische webtechnologieën en moeten principes van linked data omvatten.

Bouwblokken

  • […]

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 marktplaatsen worden opgericht. Deze capability ondersteunt de publicatie van dit aanbod, het beheer van processen die verband houden met het creëren en monitoren van slimme contracten (die duidelijk de rechten en plichten voor data- en servicegebruik beschrijven), en toegang tot data en diensten.

Bouwblokken

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 wordt daarbij gezien als een essentieel middel op nationaal niveau, ingebed in Europese kaders.

In het vervolg van dit basisconcept wordt ‘het Federatief Datastelsel’ voluit geschreven, of wordt het verkort aangeduid met alleen het acroniem ‘FDS’, dus zonder toevoeging van het lidwoord ‘het’.

3.1 - Doel en aanpak

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

3.2 - Context en scope

De context waarin het FDS functioneert als onderdeel van de Nederlandse digitale overheid enerzijds. Anderzijds hoe we de ontwikkeling van FDS afbakenen t.o.v. andere ontwikkelingen binnen de Nederlandse en Europese 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.

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

3.3 - Uitgangspunten

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’ het rechtstreeks bevragen van de aangewezen brondata in plaats van het werken met ‘niet gewaarmerkte kopieën’.

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.

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

Vertrouwensraamwerk

FDS is gericht op het optimaal en vertrouwd kunnen delen van data. Hiervoor is een raamwerk nodig dat vertrouwen creëert en waarborgt. Een vertrouwensraamwerk bestaande uit functies en mechanismen gericht op ondersteunen van o.a.:

  • 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 en andere functies moeten het vertrouwen van de deelnemers in het stelsel vergroten. De uitwerking van de capability ‘Vertrouwen’ zal resulteren in het vertrouwensraamwerk.

3.4 - Het basisconcept

De kern van het basisconcept van het Federatief Datastelsel. Aangevuld met een korte toelichting.

Het basisconcept voor het Federatief Datastelsel is weergegeven in figuur 4. Dit basisconcept vervangt de zogenoemde ‘Houtskoolschets’ die is gepubliceerd tijdens de stelseldag in november 2022.

Figuur 4: FDS Basisconcept
Figuur 4: FDS Basisconcept

Het basisconcept vormt het vertrekpunt voor verdere uitwerking tot FDS doelarchitectuur. De concrete aanpak daarvoor vertrekt uit de zogenoemde basis bekwaamheden. Deze worden gedetailleerd uitgewerkt. Daaruit leiden we de benodigde processen en functies af en kunnen we de benodigde afspraken, standaarden en eventuele voorzieningen definiëren.

Het basisconcept kent de volgende componenten:

  1. Strategische sturing:

    De strategische sturing gaat over het stelsel. Dit betreft vooral een Plan-Do-Check-Act-gebaseerde sturing op het maatschappelijk belang en de publieke waarden en daarbinnen op de effectiviteit en efficiency van het datadelen binnen het stelsel. In welke mate draagt FDS daadwerkelijk bij aan het beter benutten van data door de Nederlandse overheid, bij maatschappelijke opgaven en individuele dienstverlening conform de menselijke maat.

    De tactische en operationele sturing zijn bekwaamheden van het stelsel die in vervolg op dit basisconcept worden uitgewerkt.

  2. 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. Het data-aanbod wordt verder toegelicht op de pagina ‘stelselrollen’.

  3. Data-vraag:

    De vraag naar stelseldata wordt ingevuld doordat een Data-afnemer een of meer datadiensten afneemt van een of meer data-aanbieders. De data-vraag wordt verder toegelicht op de pagina ‘stelselrollen.

  4. 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. Op hoofdlijnen betreft dat ‘bekwaamheden (of capabilities)’ die het stelsel moet hebben, welke worden ingevuld door daartoe ingerichte ‘stelselfuncties’.

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

FDS stelt 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 data zijn:

Wettelijke grondslag

De datastrategie is gericht op (het beter) dienen van het publiek belang, door data verantwoord voor maatschappelijke opgaven te benutten. Dit vereist data waarvan verzekerd is dat deze juridisch en ethisch verantwoord kan worden gebruikt in publiek belang. Hiermee borgt FDS de publieke waarden en biedt tegelijk ook de data-afnemers het vertrouwen en de zekerheid dat zij hun publieke dienstverlening op data uit het stelsel kunnen en mogen baseren. Data die via FDS wordt gedeeld moet daarom voor zowel het aanbieden als het afnemen en toepassen ervan, een grondslag hebben. Die grondslag moet te herleiden zijn naar Nederlandse en/of Europese wet- en regelgeving.

Zo vinden het data-aanbod en het datagebruik uit de Basisregistratie Personen hun grondslag in de Wet basisregistratie personen. De Nederlandse Overheid Referentie Architectuur (NORA) beschrijft een groot aantal (sector)registraties en benoemt daarbij hun wettelijke grondslag. Bijvoorbeeld het Diplomaregister.

De wettelijke grondslag moet rechtvaardigen dat (bepaalde) data meervoudig kan worden gebruikt met andere doelstellingen en in een andere context, dan waarvoor de data oorspronkelijk is ingewonnen. Als er geen grondslag is, kan de data pas in het stelsel worden aangeboden als deze is gecreëerd. Ook afnemers kunnen alleen tot het stelsel toetreden als zij een wettelijke grondslag hebben voor het benutten van het stelselaanbod, i.c. als zij een wettelijke taak vervullen. De FDS stelselfuncties ondersteunen bij het creëren van het vereiste wettelijke kader en het borgen dat het aanbieden en afnamen in overeenstemming met de van toepassing zijnde wettelijke grondslagen plaatsvindt.

Meervoudig bruikbaar

Data wordt ingewonnen en/of bewerkt met een reden (doel) in een bepaalde context. Maar data kan ook bruikbaar zijn voor andere doelen in andere contexten. Zo is Identificatie en registratie van dieren nodig om snel te kunnen handelen bij uitbraak van dierziektes die een gevaar voor de volksgezondheid vormen. Dergelijke data kan echter ook nuttig zijn voor inzicht in concentraties van diersoorten die van invloed (kunnen) zijn op milieuomstandigheden. Bij hergebruik van data zal de gebruikscontext altijd anders zijn dan de gebruikscontext waarvoor de data oorspronkelijk is ingewonnen. Vooraf is een dergelijke nieuwe context niet bekend. 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.

Data zijn adequaat beschreven

De beschrijvingen van data en datadiensten moeten inzicht geven in de mogelijke herbruikbaarheid van de betreffende data. Hiervoor moet bijvoorbeeld duidelijk zijn wat de betekenis is van de data en waarvoor deze oorspronkelijk is ingezameld en gebruikt. Lees voor meer uitleg verder op pagina 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.

3.6 - 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 die daarvoor een wettelijke taak heeft. 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. Voor het FDS geldt het uitgangspunt dat de data-aanbieder verantwoordelijk is voor een bepaalde data-afname, ongeacht de achterliggende inrichting van de toepassing.

De data-afnemer staat richting de overige stelseldeelnemers garant voor het respecteren van het opgegeven gebruikersdoel. De data-afnemer past de data toe in het kader van het uitvoeren van een wettelijke taak. Hiermee is het verantwoord datadelen vanuit het publiek belang juridisch afdwingbaar.

3.7 - Metadata

Op hoofdlijnen de rol van metadata binnen FDS.

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.

Wat is metadata?

De NORA definieert metadata 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 vertelt o.a.:

  • welke data binnen het stelsel beschikbaar zijn,
  • wat de betekenis (semantiek) van die data is,
  • wat de grondslag is voor het verzamelen ervan,
  • voor welke context de data oorspronkelijk zijn bedoeld,
  • welke partijen daar bij betrokken zijn,
  • wat de rollen en verantwoordelijkheden zijn van de betrokken partijen,
  • hoe de data is vormgegeven (syntax),
  • hoe de data beschikbaar komt (API’s bijv.),
  • wat de kwaliteit van de data en datadiensten is (denk aan juistheid, actualiteit, etc.)
  • voor wie de data beschikbaar is en onder welke condities.

Waarom metadata?

De metadata geeft potentiële afnemers inzicht in wat binnen het stelsel beschikbaar is, voor wie en onder welke condities.

Federatieve stelselcatalogus

De metadata komt beschikbaar via de ‘federatieve stelselcatalogus’. Dit is een functionaliteit die voorziet in de mogelijkheid om data-assets van het FDS (i.c. data, datadiensten, data-aanbieders, data-afnemers met hun onderlinge relaties) in de vorm van metadata op gestandaardiseerde wijze te beschrijven. Stelselpartijen beschrijven de metadata zelf, conform de stelselstandaarden. De stelselfuncties voorzien in validatie van de metadata, waarna de betreffende stelselpartij deze beschikbaar stelt voor ontsluiting door deze te publiceren.

Door het geheel van de beschrijvingen in samenhang ontsluitbaar en presentabel te maken, wordt het inzichtelijk voor belangstellenden wat FDS kan bieden. De metadata van de federatieve catalogus is daarmee op zichzelf FDS-data die als open data volgens de FDS-standaarden voor belangstellenden wordt ontsloten.

3.8 - Bekwaamheden

Op hoofdlijnen de bekwaamheden waarover het stelsel moet kunnen beschikken.

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.

Figuur 3: FDS capabilities diagram

De bekwaamheden werken we uit tot een of meer bouwblokken. De beschreven bouwblokken moeten dus gerelateerd zijn aan minimaal één bekwaamheid.

3.9 - Stelselfuncties

Een korte inleiding op stelselfuncties met doorlink naar uitgebreidere beschrijving.

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.

Een uitgebreidere beschrijving is opgenomen op pagina Stelselfuncties.

4 - Stelselfuncties

Organisatorische en technische stelselfuncties

Het Federatief Datastelsel is een vertrouwensraamwerk voor datadeling tussen organisaties met publieke taken, die deelnemer van het stelsel zijn. Het FDS bestaat uit:

  • Functies Dit zijn de Stelselfuncties die zorgen voor de werking en doorontwikkeling van het FDS. We onderscheiden organisatorische functies en technische functies.

  • Afspraken Voorbeelden hiervan zijn de aansluitvoorwaarden voor aanbieders, de voorwaarden voor gebruikers en het kwaliteitsraamwerk.

  • Standaarden Bekende voorbeelden zijn DCAT2.0, voor het gestandaardiseerd beschrijven van data en dataservices, en SKOS, een standaard voor het vastleggen van begrippen.

  • Voorzieningen die het verantwoord datadelen ondersteunen. Hierbij geldt het principe: ‘decentraal wat kan, centraal wat moet’. Een voorbeeld van een centrale voorziening is de zogenaamde Informatiekundige kern, die het mogelijk maakt om te navigeren en data te combineren in het FDS.

Hieronder gaan we in op de ontwikkeling van de Stelselfuncties. Doel: inzicht geven in de prioriteiten en de ontwikkelaanpak.

 

Organisatorische stelselfuncties

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

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

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

Helpdesk

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

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

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

Technische stelselfuncties

Verantwoordingsfunctie

  • 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

Catalogusfunctie

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

Monitoringsfunctie

  • 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

Notificatiefunctie

  • 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

Terugmeldfunctie

  • 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

Toegang

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

5 - Wat is het FDS?

Beschrijving van wat FDS, het Federatief Datastelsel, inhoudt en betekent

Context

Het Federatief Datastelsel komt voort uit het volgende 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 datasoevereiniteit. 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.

*Hier moet een verwijzing komen naar een paragrafen over informatiekundige kern (juiste sleutels) en het aansluiten van de context van inwinning en gebruik.

Het FDS is dus een datastelsel dat datadeel relaties 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 ook afspraken over de minimaal te realiseren inhoudelijke kwaliteit van (meta)data en datadiensten. Dit geheel zorgt ervoor dat afnemers goed kunnen bepalen of ze voor hun dienstverlening op een FDS-compliant databron kunnen bouwen.

Naast het sectoraal/domeinoverstijgende aspect 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 opgegebouwd 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 overzichtfunctie 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 de sleutels uit de informatiekundige kern3 van het stelsel benaderbaar is. De informatiekundige kern is bedoeld om de meest voorkomende relaties te kunnen leggen. Het betreft afspraken over het standaardiseren van de identificatie van natuurlijke personen, niet-natuurlijke personen en locaties. Dit borgt dat op een informatiekundige betrouwbare manier gegevens kunnen worden gecombineerd (“gekoppeld”) omdat door het toepassen van gestandaardiseerde id’s zoals het BSN, het KVK-nr en het BAG-id, eenvoudig kan worden vastgesteld dat het dezelfde burgers, bedrijven of locaties betreft waarvan kenmerken worden gedeeld. 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 de informatiekundige 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 Poortwachter4 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.


  1. Hier moet een verwijzing naar de two pager private datasets komen. ↩︎

  2. Hier moet een verwijzing naar de two pager catalogus komen ↩︎

  3. Hier moet een link naar de uitleg van de informatiekundige kern komen ↩︎

  4. Stelselfunctie Poortwachter ↩︎

6 - Handreiking opstellen standaard dienstenniveaubeschrijving voor 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.

7 - Deelnemen aan het FDS

Hier lees je alles over hoe je kunt deelnemen aan het federatief datastelsel

Wees welkom en doe mee

We zijn blij dat je meer informatie wilt lezen over hoe je kunt deelnemen, want het succes van het stelsel is een optelsom van de bijdragen van de deelnemers. Deelname aan het stelsel brengt ook rechten en plichten met zich mee, zoals: aan de collectieve afspraken en standaarden voldoen, denk hierbij aan beschrijven en monitoren van de data(kwaliteit). Niet alle afspraken en standaarden zijn al allemaal uitgewerkt, maar hier bieden we inzicht hoe dit proces er tot nu toe uit ziet.

Meepraten en meedenken over de gezamenlijke koers, afspraken en standaarden is belangrijk, omdat zo collectief kennis, templates en voorbeelden ontstaan om de stelseldeelnemers te faciliteren en te ondersteunen. Transparantie over deelname, beschikbaarheid van data en behaalde resultaten staan hierbij centraal.

Processtappen deelnemen data-aanbieders

Organisaties kunnen in 6 stappen participeren in het fds.

Processtappen aansluiten fds

Voorverkenning

Als een organisatie een interessante dataset in beheer heeft en deze beschikbaar wil stellen via het afsprakenstelsel is er in de meeste gevallen al contact geweest met vertegenwoordiging vanuit het fds. Bijvoorbeeld met de marktmeester. Ook kunnen de deelnamevoorwaarden als test al eens (samen) nagelopen zijn om te beoordelen of er voldoende aansluitingsmogelijkheden zijn.

Stap 1: Aanmelden

De organisatie meldt zich aan met één of meerdere datasets bij het fds en geeft daarbij aan wie het aanspreekpunt vanuit de organisatie is voor het fds (veelal de CDO) en wie op het niveau van de individuele dataset (contactgegevens). Fds registreert de aanmelding en zorgt voor verwerking in de fds-deelnemersregistratie.

Stap 2: Deelname als organisatie

Wij nemen contact op met de contactpersoon ter tekening van de intentieverklaring fds. Dit betekent dat er op bestuurlijk niveau commitment van de data-aanbieder is op de (deels nog te vormen) afspraken, standaarden en voorzieningen van het fsd en dat de data-aanbieder een actieve bijdrage wil leveren aan gestandaardiseerde overheidsbrede datadeling. Fds registreert het tekenen van de intentieverklaring in de fds-deelnemersregistratie. Vanaf dit moment is de organisatiedeelname inclusief de vervolgacties en -resultaten zichtbaar voor de buitenwereld.

Stap 3: Deelname dataset

Wij nemen contact op met de contactpersoon van de dataset en maken afspraken over het invullen van de deelnamevoorwaarden. De deelnamevoorwaarden zullen we hier zo snel mogelijk publiceren. Samen concluderen we of de dataset als deelnemer of kandidaat-deelnemer aan het fds kan deelnemen, hier zijn drie conclusies mogelijk:

  • deze dataset is geschikt voor deelname fds
  • deze dataset is kandidaat-deelnemer fds
  • óf deze dataset voldoet niet aan de fds-deelname voorwaarden

Wij zorgen voor registratie van de conclusie in de fds-deelnemersregistratie.

Stap 4: Maatwerkplan

Als de conclusie een kandidaat-deelnemer betreft, worden de acties voor het maatwerkplan gezamenlijk opgesteld, inclusief de termijn. Er zijn twee opties mogelijk:

  • Uitvoering is conform plan verlopen: organisatie verklaart dat de werkzaamheden zijn afgerond en verstrekt openbare informatie waarmee dat kan worden vastgesteld.
  • Uitvoering verloopt niet conform plan: organisatie geeft aan of ze kandidatuur intrekt of dat ze in overleg met fds een nieuwe activiteit of termijn wil vaststellen.

Wij verifiëren of de eigen verklaring aan de maatwerkafspraak voldoet en leggen vast dat de kandidaat-deelnemer volwaardig deelnemer is geworden. Vervolgens registreren we de dataset in de fds-deelnemersregistratie.

Stap 5: Beschikbaar stellen van data

De organisatie publiceert de metadata van de dataset en de bijbehorende datadiensten conform de daarvoor afgesproken metadata standaarden en ‘profielen’ in de fds-catalogus zodat het nieuwe aanbod voor de fds-data-afnemers zichtbaar wordt.

Stap 6: In werking

De organisatie controleert en monitort periodiek en informeert fds over haar bevindingen. Deze bevindingen worden gepubliceerd en geregistreerd.

Transparantie Deelnameproces

Alle stappen in het deelnameproces worden geregistreerd in de deelnemersregistratie voor zowel de organisatie als de dataset. Na het tekenen van de intentieverklaring door de organisatie wordt de status zichtbaar via een communicatiekanaal van het fds (nog te bepalen), inclusief eventuele documentatie.

Deelname als organisatie en deelname per dataset

Het bovenstaande stappenplan beschrijft het proces per dataset voor data-aanbiedende organisaties. Dit betekent dat een organisatie met verschillende datasets in verschillende stadia kan participeren. Voor organisaties die al deelnemer zijn, verloopt een deel van het proces veel sneller omdat zij zich al eerder gecommitteerd hebben aan de fds-afspraken.

Bronhouder of data-aanbieder

Per dataset kan de rol van de organisatie verschillen (bronhouder of data-aanbieder). Als de data-aanbieder een andere organisatie is dan de bronhouder, dient deze de bronhouder(s) over de voorgenomen deelname te hebben geïnformeerd voordat de data-aanbieder voor deze dataset het proces kan doorlopen.

7.1 - Intentieverklaring

Hier lees je hoe de intentieverklaring eruit ziet als je wilt deelnemen aan het stelsel

Intentieverklaring federatief datastelsel1

Let op: als je de intentieverklaring ook daadwerkelijk wilt indienen, download deze dan hier op de IBDS website. Dan kun je de gegevens invullen en mailen naar teamIBDS@ictu.nl.

Hieronder lees je alleen waartoe je je verplicht bij het indienen van de intentieverklaring.

Ja:

Wij willen als stelseldeelnemers data onze en voor het oplossen van maatschappelijke vragen. Zo kan iedereen de vruchten plukken van de digitalisering van de samenleving. Wij geloven dat dit alleen lukt als we bij het datadelen de publieke waarden centraal ze en. Daarom gaan we werken volgens de uitgangspunten van het Federatief Datastelsel:

  1. De burger2 staat centraal

    Datadelen doen we niet voor onszelf, maar voor de maatschappij. Wij baseren onze dienstverlening op juiste, volledige en actuele gegevens die zijn afgestemd op de situatie. Daarbij realiseren we ons dat de data waarop we ons handelen baseren een afspiegeling zijn van de realiteit. We weten dat er al jd situaties kunnen voorkomen waarin de leefwereld van de individuele burger niet past in het door ons gehanteerde databeeld. Daar houden we rekening mee. Als een burger desondanks toch klem komt te zi en in de door ons geconstrueerde datawereld, dan zullen we als stelseldeelnemers alles in het werk stellen om deze burger alsnog recht te doen. Daarbij vallen we de burger niet lastig met de complexiteit van gegevensdeling binnen een stelsel. Dat is ons probleem en niet dat van de burger.

  2. Transparant data-aanbod

    We beschrijven op eenduidige wijze de kenmerken van de in het stelsel aangeboden data. We zijn open over de beoogde en gerealiseerde kwaliteit van onze data en onze datadiensten.

  3. Transparant datagebruik

    We maken zichtbaar met wie we waarvoor data delen en zijn in staat en bereid daarover verantwoording af te leggen3. We zullen gestandaardiseerd de verwerking van stelseldata gaan registreren zodat we altijd kunnen aantonen dat dit rechtmatig is gebeurd en we eenvoudig aan burgers kunnen laten zien op welke data onze besluiten zijn gebaseerd en welke organisatie wanneer en waarvoor zijn persoonlijke gegevens heeft geraadpleegd.

  4. Transparante belangenafweging

    Hoewel de letter en de geest van de wet een belangrijk kader voor het datadelen bieden, blijven er altijd situaties bestaan waarin verschillende legitieme belangen kunnen botsen. Dan moet er gekozen worden. We hanteren daarvoor een zorgvuldig openbaar proces met waarborgen dat aan alle belangen recht wordt gedaan. We maken de uitkomst van dit proces openbaar zodat iedereen kan nagaan waarop de uiteindelijke keuze is gebaseerd. We zijn ons ervan bewust dat dit aanleiding kan geven voor maatschappelijk debat, maar we beschouwen dat juist als gewenst.

  5. Waar het kan, werken we op dezelfde manier

    We maken gebruik van de stelselfuncties (afspraken, standaarden en voorzieningen) om onze data zo beschikbaar, bruikbaar en bestendig mogelijk te maken en in het datagebruik de publieke waarden te borgen.

  6. Iedereen draagt bij

    Het Federatief Datastelsel maken we samen. We realiseren ons dat het succes van het stelsel een optelsom is van de bijdragen van de deelnemers. We geven samen vorm aan de ontwikkeling van het stelsel en stemmen onze eigen ontwikkelagenda daarop af. We zijn duidelijk over wat we van elkaar verlangen en delen onze kennis en ervaring.

  7. Open, verbonden en verantwoord

    Wij zijn ambassadeur van het Federatief Datastelsel en dragen de kernwaarden open, verbonden en verantwoord uit.


  1. Geïnspireerd door het Manifest Netwerk Digitaal Erfgoed ↩︎

  2. Burger wordt hier in ruime zin gebruikt. Hier vallen zowel natuurlijke als niet natuurlijke personen (organisaties) onder. ↩︎

  3. Natuurlijk gelden hierbij de gebruikelijke uitzonderingen voor inlichtingen- en opsporingsdiensten. ↩︎

8 - 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

9 - 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 als 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

10 - 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

11 - 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 ↩︎