API Strategie Algemeen (Inleiding)

Geonovum Handreiking
Versie ter vaststelling

Deze versie:
https://docs.geostandaarden.nl/api/vv-hr-API-Strategie-20231221/
Laatst gepubliceerde versie:
https://docs.geostandaarden.nl/api/API-Strategie/
Vorige versie:
https://docs.geostandaarden.nl/api/cv-hr-API-Strategie-20231006/
Laatste werkversie:
https://geonovum.github.io/KP-APIs/API-strategie-algemeen/
Redacteurs:
Frank Terpstra, Geonovum
Paul Dam, lex digitalis
Auteurs:
Edwin Wisse, Logius
Marcel Tulen, Sociale Verzekeringsbank
Marcel Krassenburg, CCoverheid
Redouan Ahaloui, Bureau Forum Standaardisatie
Theo Peters, Vereniging Nederlandse Gemeenten(VNG)
Gino Laan, RINIS
Vedran Bilanovic, Ministerie van Binnenlandse Zaken en Koninkrijksrelaties (BZK)
Dolf Daal, Informatiehuis Water (IHW)
Rob van der Horst, Politie
Frank Smit, Belastingdienst
Raymond Kers, Ministerie van Justitie en Veiligheid
Doe mee:
GitHub geonovum/KP-APIs
Dien een melding in
Revisiehistorie
Pull requests
Rechtenbeleid:

Samenvatting

Dit document beschrijft een API strategie voor de Nederlandse overheid.

Status van dit document

Deze paragraaf beschrijft de status van dit document ten tijde van publicatie. Het is mogelijk dat er actuelere versies van dit document bestaan. Een lijst van Geonovum publicaties en de laatste gepubliceerde versie van dit document zijn te vinden op https://www.geonovum.nl/geo-standaarden/alle-standaarden.

Dit is een definitief concept van de nieuwe versie van de handreiking. Wijzigingen naar aanleiding van consultaties zijn doorgevoerd.

Ten opzichte van de vorige versie van de API strategie (09-03-2022) is het hoofdstuk "API Strategie voor de overheid" aangepast. De sectie visie is aangepast en de sectie API first strategie zijn toegevoegd.

1. Inleiding van de NL API strategie

Dit onderdeel is niet normatief.

Dit Hoofdstuk geeft een inleiding op de Nederlandse API strategie. De stategie is opgebouwd uit meerdere documenten, standaarden en modulen. De NL API Strategie wordt doorontwikkeld en beheerd door het Kennisplatform API's.

1.1 Status

Op GitHub kan bekeken worden wat de actuele ontwikkelingen zijn met betrekking tot de Nederlandse API strategie.

1.2 Auteurs

Er worden slechts een beperkt aantal auteurs genoemd, echter aan deze strategie is door veel meer mensen gewerkt. Per onderdeel van de API strategie staan de degene verantwoordelijk voor de laatste versie vermeld. De genoemde auteurs zijn deelnemers aan de relevante werkgroep van het Kennisplatform API's zoals: API Strategie, Architectuur, Security, Design Rules, Authenticatie en Autorisatie, Strategie en Beleid, en Gebruikerswensen.

1.3 Leeswijzer

De API strategie bestaat uit een een inleidend document, verschillende normatieve documenten (NL GOV standaarden) en meerdere modulen die voor verschillende functionele of technische situaties kunnen worden ingezet. Een actueel overzicht van alle documenten is weergegeven in de onderstaande infographic:

Figuur 1 NL API Strategie Infographic

De verschillende onderdelen van de NL API Strategie bevat de volgende documenten:

Onderdeel Documentnaam &
Verwijzing naar de gepubliceerde versie
Status Versie
Algemeen Inleiding NL API Strategie Vastgesteld
(door Kennisplatform)
09-03-2022
Algemeen Architectuur NL API Strategie Vastgesteld
(door Kennisplatform)
09-03-2022
Algemeen Gebruikerswensen NL API Strategie Vastgesteld
(door Kennisplatform)
09-03-2022
Normatieve standaard API Design Rules (ADR) Verplicht
(pas toe leg uit)
09-07-2020
v1.0.0
Verplichte standaard Open API Specification (OAS) Verplicht
(pas toe leg uit)
25-05-2018
v3.0.0
Normatieve standaard NL GOV OAuth profiel Verplicht
(pas toe leg uit)
09-07-2020
v1.0.0
Voorgestelde standaard NL GOV OpenID Connect profile Verplicht
(pas toe leg uit)
18-02-2021
v1.0.0
Verplichte standaard Digikoppeling REST API koppelvlak specificatie Verplicht
(pas toe leg uit)
14-11-2022
v1.1.1
Aanvullende module API Geospatial Design Rules module Vastgesteld *
(door Kennisplatform)
23-05-2023
Aanvullende module API Transport Security module Stabiel *
(Werkgroep Kennisplatform)
11-07-2023
Aanvullende module API Access control module Stabiel
(Werkgroep Kennisplatform)
11-07-2023
Aanvullende module API Naming conventions module Stabiel
(Werkgroep Kennisplatform)
12-07-2023
Aanvullende module API Hypermedia module Stabiel
(Werkgroep Kennisplatform)
12-07-2023

2. API strategie voor de overheid

Dit onderdeel is niet normatief.

2.1 Samenvatting

De platformeconomie biedt nieuwe kansen voor de digitale overheid. Om deze kansen te benutten en tegelijkertijd de dienstverlening van de digitale overheid te verbeteren vindt er transitie plaats in het gegevenslandschap. Initiatieven zoals Common Ground, Toekomst BRP en het Digitaal Stelsel Omgevingswet (DSO) willen de digitale overheid efficiënter, slimmer, veiliger en beter beheersbaar maken door applicaties beter te scheiden van de gegevens en de gegevens alleen bij de bron te beheren. Hierdoor hoeven gegevens niet meer op grote schaal gedupliceerd en gesynchroniseerd te worden. In deze ambitie spelen API’s als ondersteunende technologie een belangrijke rol.

De overheid gebruikt data voor het oplossen van maatschappelijke vraagstukken en opgaven zoals in wonen, stikstof, de energietransitie, armoede, de bestrijding van criminaliteit en ondermijning, schulden en zorg. Met API's zijn we in staat een platform van data te laten ontstaan waarop we de maatschappelijke vraagstukken en dienstverlening organiseren. Het bedrijfsleven en grote internetplatforms maken al volop gebruik van API's om data flexibel te ontsluiten.

Nagenoeg alle organisaties binnen de overheid zijn de omslag van traditionele IT naar een API-ecosysteem aan het maken. Dit hoofdstuk biedt een kader aan waarbinnen de overheid zich kan committeren bij ontwikkeling en te realiseren beleid rondom API’s. Het hoofdstuk sluit af met een Intentieverklaring van organisaties uit de publieke sector die dit commitment willen geven. De uitnodiging is open aan alle organisaties uit de publieke sector om ook te ondertekenen.

2.2 Visie

Het gebruik van API's maakt een een onstuimige groei door. Steeds meer organisaties bieden API's aan en veel organisaties bieden steeds meer API's aan. API's bieden de overheid de kans om data snel, eenvoudig en in real-time aan te bieden. De samenleving verwacht een open overheid. Dat kan met API's. De data die de overheid voor het uitvoeren van haar taken verzamelt, wordt nu al voor hergebruik beschikbaar gemaakt. Nu wordt data nog vaak als bestand beschikbaar gemaakt waarbij het aan de gebruiker is de data te vinden, binnen te halen en te verwerken. Met API's wordt data steeds bij de bron opgehaald, pas wanneer de data nodig is. Met API's kan data heel toegespitst op een vraag verstrekt worden, waardoor bovenmatige verstrekking van data wordt voorkomen (dataminimalisatie). Met API's is het eenvoudiger het datagebruik te verantwoorden. Door al deze voordelen maken API's nieuwe toepassingen met data mogelijk voor burgers.

2.2.1 Een wendbare informatievoorziening

Een eenvoudiger, flexibeler en slimmer ingerichte informatievoorziening faciliteert de overheid hierbij. We kunnen beleidsdoelen met toepassing van API's beter mogelijk maken. In de Staat van de Uitvoering is een oproep opgenomen Breng gegevensuitwisseling tussen publieke dienstverleners nu echt op gang. Deze gegevensuitwisseling kan juist met API's worden gefaciliteerd. Verschillende initiatieven zijn al genomen, zoals de Interbestuurlijke Datastrategie, het Federatief Data Stelsel, Data bij de bron en het Digitaal Stelsel Omgevingswet.

Dit is hard nodig nu in hoog tempo meer data verzameld en opgeslagen wordt. De vraag om data en het datagebruik nemen toe. Dit past ook bij de Europese datastrategie.1

2.2.2 Afspraken en standaardisatie API’s sleutel tot succes

De API Strategie van de Nederlandse overheid bevat afspraken en standaarden om API’s te ontwerpen, te beveiligen, toegankelijk te maken en te gebruiken. Zo zijn API’s door afspraken over de publicatie van de specificaties voor afnemers op een uniforme en voorspelbare manier vindbaar. En zijn al afspraken en standaarden voor API’s op het gebied van authenticatie, autorisatie, logging en andere onderwerpen die data beter en op een uniforme manier toegankelijk en bruikbaar maken. Het gebruik van de afspraken en standaarden door aanbieders vergemakkelijkt het gebruik van API’s voor afnemers. Dit geeft aanbieders het vertrouwen dat hun API’s door afnemers op een bekende voorspelbare manier te gebruiken zijn. Daarnaast maken afspraken en standaarden het mogelijk om aan te geven of API’s aan minimumvereisten voldoen. Daarmee neemt het vertrouwen van afnemers in de kwaliteit van API’s toe. Zo voorkomen we dat de manier van datadeling op verschillende manieren wordt ingericht.

Nu het gebruik van API’s in opmars is, is het van belang de gemaakte afspraken toe te passen. Voor zover verdere afspraken nodig zijn, werken we samen in de Werkgroepen van het Kennisplatform API's.

2.2.3 Visie op het Kennisplatform API’s

Het Kennisplatform API’s wil de adoptie van API’s stimuleren en brengt daartoe partijen samen. Het Kennisplatform API’s is dé plek voor overheden om afspraken over de toepassing van API’s te maken en om standaardisatie te bevorderen. Aanbieders van API’s krijgen handvatten waarmee zij hun API’s vorm kunnen geven. Afnemers van API’s profiteren door een meer uniform aanbod van API’s. Het Kennisplatform API’s streeft naar gedragen uitgangspunten voor technische interoperabiliteit, vindbaarheid, toegang, aansluitvoorwaarden en andere afspraken voor het aanbieden en gebruiken van API’s. Deze afspraken worden door het Kennisplatform API's voorbereid op vier thema's:

  1. governance, strategie en beleid
  2. architectuurprincipes
  3. beveiliging
  4. API design rules

1. De Data Governance Regulation en de Data act maken deel uit van deze strategie. Het eindrapport van het API guidelines for government project An Application Programming Interface (API) framework for digital government geeft een aantal voorstellen voor API toepassing voor overheden zoals Align API's with policy goals en Measure policy impacts of API's.

2.3 API first Strategie

De API first strategie past binnen de huidige beleidsdoelen en de omgeving van de publieke sector. Eerst leggen we uit wat "API first" inhoud daarna hoe je daarmee je omgeving bediend en voor welke beleidsdoelen "API first" relevant is. Als laatste zetten we de strategie om in 4 acties die in het beleid van een "API first" organisatie opgenomen zouden moeten worden.

2.3.1 API first

Iedere organisatie zou voor ontsluiting van data en functionaliteit altijd "API first" moeten werken:

  • Altijd is er een goed gedocumenteerde machine interface die aan de omgeving ter beschikking gesteld kan worden.
  • Voor de ontsluiting die je zelf direct realiseert (bijvoorbeeld een website) maak je gebruik van diezelfde interface. Het geeft je omgeving de mogelijkheid om daar waar er voor hen geen geschikte ontsluiting bestaat, deze zelf te maken, als ook om nieuwe mogelijkheden te ontdekken die je zelf nog niet had bedacht.
  • Wanneer je de API met iedereen deelt geeft het ook je gehele omgeving in de basis een gelijke informatiepositie.
  • De API first strategie is in lijn met het NORA principe "bouw diensten modulair op" en de bijbehorende implicatie "wissel gegevens tussen (web)applicaties uit met API's".
  • Maak gebruik van API technieken die breed in de markt ondersteund worden. Dat zorgt ervoor dat benodigde kennis en middelen voor het toepassen eenvoudig verkrijgbaar zijn. Zorg dus voor actuele kennis binnen je organisatie over wat er in de markt speelt, en deel deze kennis met andere organisaties. Op moment van schrijven zijn REST API's op basis van HTTP en JSON bijvoorbeeld breed ondersteund, maar dat kan in de toekomst veranderen.
  • API first is niet alleen een voorwaarde voor moderne IT systemen, het toepassen ervan is ook een middel voor modernisering, zoals Common ground en PSD2 laten zien (zie sectie bedien de omgeving).

2.3.2 API first voor de omgeving

Tot de omgeving van een publieke organisatie hoort iedereen die interactie heeft of wil hebben met een publieke organisatie. Burger, bedrijf, ketenpartner of andere organisaties uit de publieke sector. De omgeving van een organisatie uit de publieke sector is al jaren bekend met API's en de toepassing ervan.

2.3.2.1 Burgers

Zo herkent iedere burger hoe eenvoudig verschillende platforms uit de platform economie (zoals Google, Amazon, Linkedin en Meta) eenvoudig elkaars functionaliteit integreren. Denk aan de store in store concepten bij grote online retailers en knoppen om informatie te delen op je favoriete sociale medium.

2.3.2.2 Bedrijven

Het bedrijfsleven weet hoe via de "payment service directive 2" (PSD2) de functionaliteit en data van de bankwereld via API's is opengebroken en interoperabel gemaakt is. Men weet ook hoe functionaliteit als betalingen, klantrelatiesystemen, boekhoudpakketten en salarisadministratie door API's met elkaar te integreren zijn. De grootste kennis in de markt van (potentiële) softwareleveranciers in de publieke sector voor het verbinden van IT systemen ligt mede om bovengenoemde redenen bij API's.

2.3.2.3 Publieke sector

In de publieke sector zelf zijn API's in sommige onderdelen ook al dominant, CBS ontsluit al haar statistische informatie al meer dan 10 jaar via API's, het digitaal stelsel omgevingswet heeft ze van begin af aan omarmt, het KNMI en het Kadaster en vele anderen bieden hun open data via API's aan zodat anderen deze kunnen hergebruiken.

2.3.2.4 Bedien de omgeving

De omgeving van organisaties in de publieke sector bedien je het best door hen de mogelijkheid te geven zoveel mogelijk op hun eigen voorwaarden gebruik te maken van data en functionaliteit die je als publieke organisatie aanbiedt. Je moet ze dus niet dwingen om één manier te gebruiken. Tegenwoordig zijn er vele manieren om data & functionaliteit te ontsluiten:

  • websites,
  • mobiele Apps,
  • computer applicaties,
  • IoT devices,
  • fysieke loketten, en
  • brievenpost.

Achter al deze ontsluitingsmanieren zit een IT systeem. Het is in de huidige digitale samenleving niet reëel om al deze manieren volledig zelf in de hand te hebben. Door direct toegang te geven tot data en functionaliteit door een API bied je de mogelijkheid om deze via verschillende kanalen aan te bieden. Je kan voor ieder kanaal afwegen of je dat als organisatie zelf aanbiedt of dit aan een andere partij overlaat.

Niet alle organisaties zijn zo ver. Sommige cruciale bedrijfsprocessen draaien nog op oude (maar meestal ook zeer stabiele) systemen die bedacht zijn voordat API's gemeengoed werden. Je zal hen moeten blijven bedienen tot zij de omslag hebben kunnen maken. Die omslag maken is vaak niet eenvoudig, in de bankwereld was er de PSD2-wetgeving nodig om dit te laten gebeuren. In de gemeentelijk wereld wordt deze omslag gemaakt in het Common Ground initiatief. Net als bij PSD2 worden API's ook bij Common Ground ingezet als transitiemechanisme. API's worden gebruikt om in stappen over te gaan naar een nieuwe manier van werken waarbij API's het ontkoppelpunt vormen.

2.3.3 API first voor beleidsdoelen

Om de beleidsdoelen van de overheid te halen is doorontwikkeling van de digitale overheid van groot belang. API's kunnen hierin een rol spelen om informatie eenvoudig en veilig uit te wisselen tussen overheden onderling en tussen overheden en burgers of bedrijven. Een aantal beleidsdoelen waarin API's een rol kunnen spelen (met het voor API's relevante sleutelwoord in cursief) zijn:

  • Transparante overheid. In het kader van de Wet Open Overheid wil de overheid ondermeer hergebruik van open data stimuleren. Zie ook de Open Data Directive van de EU.
  • Regie op gegevens. Hierbij is het doel om burgers en bedrijven te ondersteunen bij regie op hun gegevens, die door de overheid verzameld en gebruikt worden. Dit resulteert in een sector-overstijgend kader dat veilige, betrouwbare en gebruiksvriendelijke digitale uitwisseling van gegevens tussen overheden, private en maatschappelijke organisaties mogelijk maakt. Veiligheid en betrouwbare gegevensuitwisseling kan worden gewaarborgd door toepassing van de API Design Rules.
  • Digitale inclusie Door gegevens via een API first strategie openbaar te maken kunnen gedifferentieerde gebruikersinterfaces die voor minder digitaal vaardige burgers bruikbaar zijn.
  • De Interbestuurlijke Data Strategie (IBDS) is het resultaat van nauwe samenwerking tussen departementen, uitvoeringsorganisaties en koepels van medeoverheden. Het programma zorgt ervoor dat het makkelijker wordt om binnen de overheid verantwoord met data te werken. Een van de speerpunten van het IBDS is het ontwikkelen van overheidsbrede systeemfuncties waaronder een federatief datastelsel waarmee data beter vindbaar en technisch uitwisselbaar wordt.
  • In nieuwe wetgeving wordt de digitale overheid steeds belangrijker. De Wet hergebruik overheidsinformatie (Who) beoogt het hergebruik van overheidsinformatie mogelijk te maken, voor doelstelling anders dan het oorspronkelijke doel waarmee de informatie aangemaakt is. Anders dan bij de WOB moet informatie machine-leesbaar aangeboden worden, bij voorkeur in open formaten met open standaarden. De Wet modernisering elektronisch bestuurlijk verkeer is in behandeling. Het gaat om een wijziging van Algemene wet bestuursrecht (Awb) waarbij bestuurorganen verplicht digitale kanalen moeten bieden voor digitale berichten. Het gebruik van API's kan dus helpen invulling te geven aan deze wettelijke plichten.
  • EU Data Act of Datawet De datawet is gericht op eerlijke toegang tot en het gebruik van gegevens. Hierbij worden met name Internet of Things (IoT) apparaten genoemd en middelen voor openbare lichamen om toegang te krijgen tot gegevens die in het bezit zijn van de particuliere sector. De datawet maakt deel uit van de Europese datastrategie.

Voor al deze beleidsdoelen geldt dat API's er een rol in kunnen spelen maar dat de API standaarden en best practices er nog niet altijd in beeld zijn. Onderstaande acties verdienen verankering in het beleid van de organisatie wanneer je API first wilt werken.

2.3.4 Actie 1: Houdt regie door open API-standaarden toe te passen

API's vormen bij de grote platforms van de IT wereld, maar ook al bij nationale leveranciers, een essentieel onderdeel van hun strategie. In de relatie met de markt houdt je als overheid de regie door zelf te bepalen hoe informatie door open API-standaarden wordt uitgewisseld. Samenwerking met de markt op basis van open standaarden is wenselijk. Samenwerking op basis van eigen oplossingen van leveranciers onder voorwaarden van die leverancier is (hoewel op korte termijn soms aantrekkelijk) op de lange termijn zeer risicovol. Vanwege de kans op "vendor lock-in" maar misschien nog wel meer vanwege de mogelijkheid dat we als publieke sector de controle verliezen over wat er met gevoelige informatie die wij bijhouden gebeurt. Met name als die bij de grote platforms terecht komt. De samenleving verwacht van organisaties in de publieke sector dat die zorgvuldig met hun gegevens omgaan. Het gebruik van niet-open standaarden voor gegevensuitwisseling past daar niet bij.

2.3.5 Actie 2: Gebruik API's bij (ver)bouw van IT-systemen

Gebruik de standaarden bij inkoop voor nieuwbouw en verbouw van IT-systemen. Dit begint bij het volgen van de lijsten met verplichte en veelgebruikte standaarden van het Forum Standaardisatie. Daar zijn de verplichte en veel gebruikte API-standaarden te vinden. Het toepassen van standaarden is echter het begin, pas ze toe binnen een modulair opgebouwde architectuur volgens de NORA. Maar denk vooral ook na over het ontwerp van je API's. Dit moet afgestemd zijn op de behoefte van de afnemers van de API. Zorg ervoor dat je de omgeving van je organisatie en de onderdelen van je eigen organisatie zo goed mogelijk bedient. Het gebruik van API's maakt het mogelijk verschillende onderdelen van een IT-systeem zo veel mogelijk te ontkoppelen (onafhankelijk van elkaar te maken). Dit zorg ervoor dat het systeem in de toekomst met minimale inspanning op nieuwe eisen en uitdagingen is aan te passen. Volg niet alleen bij standaarden maar ook bij het ontwerp de kennis van de markt. Brede marktondersteuning zorgt ervoor dat er veel te kiezen valt als je ondersteuning nodig hebt (of het nu gaat om vinden van geschikt personeel of aanschaf van software). Meer keuze in de markt leidt tot lagere kosten.

2.3.6 Actie 3: Deel Kennis over het toepassen van API's

Je staat als organisatie in de publieke sector in de uitvoering nooit alleen. Je maakt de functionaliteit niet alleen, je werkt altijd in een keten met andere overheden en niet-overheden. De kern van de samenwerking zit voor een significant deel in de koppeling. Daarom is het op een uniforme manier aanpakken van de API's die daar invulling aan geven van belang. Als organisatie in de publieke sector deel je kennis over hoe je dat doet met de hele publieke sector en maakt waar mogelijk hergebruik van wat anderen al hebben gemaakt. Voor API's doen we dat binnen het kennisplatform API's. Daar maken we standaarden en best practices die we met elkaar delen. Het gaat hier om standaarden voor uniformiteit, en interoperabiliteit van API's, maar ook om ontwerpkeuzes binnen API's, voor de IT-architectuur waarbinnen API's gebruikt worden en over de vindbaarheid van API's. We streven ernaar deze binnen bestaande structuren en afspraken zoals over het toepassen van de lijst met verplichte standaarden van het Forum Standaardisatie en de NORA vast te stellen.

2.3.7 Actie 4: Zorg dat API's vindbaar zijn

Het is niet alleen belangrijk om API's aan te bieden, ze moeten ook door de omgeving gevonden kunnen worden. Het is belangrijk om een balans te vinden tussen vindbaarheid en vereiste inspanning om alle publieke informatie op verschillende plekken actueel te houden. Vindbaarheid verhoog je door het voor makers van API's zo laagdrempelig mogelijk te maken om API's te publiceren. Praktisch zijn er, afhankelijk van de ambitie en middelen van een organisatie, meerdere manieren voor. Je kan een eigen developer portaal bouwen waar je API's ontsluit, de toegang regelt (indien nodig) en zorgt voor goede documentatie. Je kan ook hergebruik maken van de catalogi en portalen die de overheid biedt. We werken als publieke sector aan afspraken (zoals in het Federatief Data Stelsel) om de vindbaarheid van API's in catalogi en portalen te vergroten waarbij het streven is dat informatie over API's eenmalig door de aanbieder wordt aangeleverd en in meerdere catalogi en portalen kan worden hergebruikt. API's moeten waar mogelijk (binnen de grenzen van openbaarheid) centraal en publiekelijk vindbaar zijn, dus niet alleen via de kanalen van de aanbiedende organisatie maar ook vanuit landelijke portalen/catalogi.

2.4 Praktijkvoorbeelden

2.4.1 De BRP API van RvIG (voorheen Haal Centraal)

Persoonsgegevens uit de Basisregistratie Personen (BRP) worden nu vaak gesynchroniseerd met een lokale kopiedatabase bij een gemeente. In de processen van de gemeente wordt die kopiedatabase bevraagd in processen waarvoor persoonsgegevens nodig zijn. Binnen het programma Toekomst BRP experimenteert de Rijksdienst voor Identiteitsgegevens (RvIG) met een API waarmee gemeenten in hun werkprocessen direct de Basisregistratie Personen (BRP) kunnen bevragen. De API is gerealiseerd in samenwerking met gemeenten en gebaseerd op de informatiebehoefte van gemeenten, provincies en waterschappen. De API biedt niet alleen persoonsgegevens uit de BRP, maar ook informatieproducten zoals leeftijd, aanschrijfwijze, aanhef, verwijzing naar een persoon in de tekst van een brief, adressering (passend voor brief en vensterenvelop), en historische bewoning van een adres. Hiervoor is een wetwijziging nodig: het Experimentbesluit Dataminimalisatie. Gemeenten en andere afnemers van de BRP met een autorisatiebesluit van RvIG mogen zonder extra kosten deelnemen aan het experiment en de BRP API gebruiken.

Over de voordelen van de BRP API heeft Haal Centraal een heldere video gemaakt. Op de developer portal van de BRP API vind je hoe je kunt aansluiten en aan welke voorwaarden moet worden voldaan. Als het experiment slaagt, wordt gewerkt aan structurele wetgeving die dataminimalisatie door vraaggestuurde productontwikkeling met API's mogelijk maakt.

2.4.2 De API's voor verstrekken van gegevens aan burgers (Vorderingenoverzicht Rijk)

Het verzamelen van gegevens over actuele betalingsverplichtingen is voor burgers die in schuldhulpverlening terecht komen een grote drempel. Ook in andere situaties willen burgers graag toegang tot gegevens die over hen zijn vastgelegd, bijvoorbeeld om snel te checken of je geen rekening gemist hebt. Het opvragen van die gegevens werkt overal anders en kost veel tijd en middelen. Het Vorderingenoverzicht Rijk verlaagt die drempels, door middel van standaardiseren en automatiseren, zodat problemen met betalingen en schulden sneller kunnen worden opgelost of worden voorkomen. Het Vorderingenoverzicht Rijk maakt dit mogelijk met API-first ontwerp dat invulling geeft aan het API-contactoppervlak G2C uit de Nederlandse API Strategie: API's voor burgers maken het mogelijk dat burgers daadwerkelijk zelf digitaal zaken doen met de overheid. Met de API's van het Vorderingenoverzicht Rijk kan een burger alle informatie over zijn financiële verplichtingen aan overheidsorganisaties opvragen bij de bronnen, tonen in één overzicht, en op basis daarvan de gewenste acties ondernemen.

2.4.3 De API voor Zaakgericht Werken van Common Ground

Veel gemeenten werken zaakgericht. Dit betekent dat informatie over dienstverlening aan inwoners in zaken is geordend in een zaaksysteem. Deze manier van werken richt zich op het transparant afhandelen van een samenhangende hoeveelheid werk (een 'zaak'), welke een duidelijk omschreven aanleiding kent (bijvoorbeeld een aanvraag) en leidt tot een duidelijk omschreven resultaat.

ICT systemen ondersteunen zaakgericht werken met als voordelen het automatische termijnbewaking en routeren van taken naar betrokken medewerkers of systemen. Met daarbij ook het parallel kunnen uitvoeren van samenhangende taken, geautomatiseerd toekennen van metadata en het duurzaam toegankelijk bewaren van het zaakdossier. De API-standaarden voor zaakgericht werken helpen bij het (ont)koppelen van zaaksystemen en de registers waar documenten en overige informatie in zijn opgeslagen. Als alle gemeenten de API-standaarden voor zaakgericht werken gebruiken, wordt de uitwisseling van gegevens voor deze systemen efficiënter. Het is bovendien een belangrijke stap in het realiseren van Common Ground, iets waar alle gemeenten naar streven.

2.4.4 De API voor Basisregistratie Kadaster (BRK) - Publiekrechtelijke Beperkingen

De Wet kenbaarheid publiekrechtelijke beperkingen onroerende zaken (Wkpb) geeft inzicht in door de overheid opgelegde beperkingen op een stuk grond of een daarop staand gebouw. Sinds 2021 is de vernieuwde Wet kenbaarheid publiekrechtelijke beperkingen (Wkpb) van kracht. Deze vernieuwde wet schrijft wijzigingen voor in het systeem voor het kenbaar maken van publiekrechtelijke beperkingen. Inwoners, ondernemers en overige partijen kunnen alle informatie over beperkingen en bijbehorende brondocumenten bij één partij kunnen vinden: het Kadaster.

In het oude systeem registreerden de gemeenten hun eigen gegevens terwijl andere overheden de basisregistratie van het Kadaster gebruikten. Deze twee langs elkaar werkende systemen brachten allerlei problemen met zich mee. Het was niet mogelijk om gemeentelijke brondocumenten bij het Kadaster op te vragen. En soms bleek de gemeentelijke situatie van een pand of object niet overeen te komen met de kenmerken zoals die in de basisregisters van het Kadaster zijn vastgelegd. Voorts konden overheden in het oude systeem alleen beperkingen opleggen op een kadastraal perceel, wat in veel gevallen niet aansloot op de praktijk. De vernieuwde Wkpb registreert en beheert alle publiekrechtelijke beperkingen in de Basisregistratie Kadaster publiekrechtelijke beperkingen (BRK-PB). Overheden en organisaties uit de private sector hebben zo een unieke bron waar ze alle gegevens kunnen raadplegen. En omdat beperkingen nu, behalve op een perceel, ook gelegd kunnen worden op objecten uit de de basisregistraties Adressen en Gebouwen (BAG) en Grootschalige Topografie (BGT), of via een zelf vervaardigde contour, sluit de registratie veel beter aan op de uitvoeringspraktijk.

De BRK-PB kan al benaderd worden met de BRK-API. Het bij de bron registreren en beheren van gegevens heeft hier dus zichtbare meerwaarde, zowel voor de overheid als voor de private sector , zie ook dit artikel in Binnenlands Bestuur.

2.4.5 De API voor regie op gegevens

De Wet bescherming persoonsgegevens (Wrp) en z'n opvolger, de Algemene verordening gegevensbescherming (AVG) geven ons al bijna twintig jaar recht op inzage en correctie van de gegevens die de overheid over ons verzamelt en beheert. Dit betekent dat je als burger het recht hebt om te weten welke persoonsgegevens de overheid over je heeft vastgelegd en welke gegevens de overheid heeft gebruikt en uitgewisseld voor welk doel. Uit dit onderzoek uit 2017 van Berenschot (uitgevoerd in opdracht van BZK) blijkt dat volledig digitale inzage in alle relevante persoonsgegevens die onder de AVG vallen, in het huidige gegevenslandschap niet haalbaar is.

In de beleidsbrief regie op gegevens regie op gegevens van 2019 onderstreept het kabinet nog eens het beleidsvoornemen om serieus werk te maken van regie op gegevens. Maar dan er zal er dus iets moeten gebeuren in het gegevenslandschap om dit mogelijk te maken.

Om het inzicht in de verstrekking van persoonsgegevens veel eenvoudiger te maken, is er door VNG-Realisatie een model API opgesteld, die overheden in staat kan stellen de verwerking van persoonsgegevens op een toegankelijke manier te tonen. Deze API haakt aan bij wat conform de AVG al tot stand komt: de organisatie-brede registers van verwerkingen van persoonsgegevens. Als de overheid gegevens bij de bron gaat beheren en ontsluiten met API's, wordt het gemakkelijker om bij de bron volledige inzage te geven. De overheid kan dan digitale inzage geven in een uniform gebruiksvriendelijk format, en ook de correctie van gegevens wordt eenvoudiger.

2.5 Intentieverklaring API strategie

In onze visie zal de digitale overheid de komende jaren steeds meer veilig en efficiënt data uitwisselen door applicaties zoveel mogelijk te scheiden van de data, en deze data bij de bron te bewaren. Voorzieningen gaan data ophalen bij de bron zodra deze nodig is. Om deze data-uitwisseling mogelijk te maken, zijn platformen, API's en verplichte standaarden onmisbaar. Hiermee biedt de overheid toegang tot evenwichtige en consistente data sets, onafhankelijk van de complexiteit van achterliggende systemen, voor burgers, bedrijven en ketenpartners van de overheid.

Met deze intentieverklaring, verklaart onze organisatie dat wij de volgende afspraken tussen de deelnemers van het Kennisplatform API's zullen naleven:

  1. In lijn met de "API first" strategie bij te dragen aan modernisering van de IT voorzieningen in de overheid

  2. Deelnemers aan het Kennisplatform API's leveren een actieve bijdrage aan standaardisatie van het gebruik van API's in en buiten het Kennisplatform API's.

  3. We houden ons aan de API standaarden die we samen hebben ontwikkeld welke op de lijst verplichte standaarden van het forum standaardisatie staan, zoals de REST API Design Rules voor het aanbieden van RESTful API's en het NL GOV Assurance Profile for OAuth 2.0 voor autorisatie op API's waar door gebruikers rechtendelegatie kan worden toegepast.

  4. De overheid registreert haar extern toegankelijke REST API's bij een centraal vindbare openbare catalogus, tenzij dit om beveiligingsredenen niet gewenst is. Zo kunnen ontwikkelaars de API's van de overheid altijd vinden.

2.6 Ondertekening

De hieronder vermelde organisaties hebben bijgedragen aan deze API strategie voor de overheid en onderschrijven de basisafspraken: ... | Forum Standaardisatie | Geonovum | ICTU | Logius | Ministerie van Binnenlandse Zaken en Koninkrijksrelaties | VNG Realisatie | ...

Dit is nog geen officiële lijst van ondertekenaars

3. Standaarden

Dit onderdeel is niet normatief.

Binnen de Nederlandse publieke sector zijn meerdere standaarden die betrekking hebben op APIs. In dit hoofdstuk geven we verwijzingen naar de standaarden die zijn voortgekomen uit het Kennisplatform APIs. Hieronder zijn de meest relevante standaarden opgenomen. Kijk voor een actueel en volledig overzicht van alle standaarden altijd op forum standaardisatie.

3.1 API Designrules (Nederlandse API Strategie)

Deze sectie beschrijft de status en uitgangspunten voor de standaard "API Designrules". De standaard is een op zichzelfstaand document en is hier te vinden:

https://logius-standaarden.github.io/API-Design-Rules/ (werkversie)

https://publicatie.centrumvoorstandaarden.nl/api/adr/ (stabiele versie)

3.1.1 Oorsprong standaard

De API designrules vinden hun oorsprong in de "API strategie" van het digitaal stelsel omgevingswet (DSO). Bij het opstellen van de API Designrules is de DSO API strategie het startpunt geweest en heeft de werkgroep API strategie gekeken hoe deze toepasbaar gemaakt kunnen worden voor de hele Nederlandse publieke sector.

3.1.2 Status bij forum standaardisatie

De API designrules standaard is op 9 juli 2020 goedgekeurd door het OBDO voor opname op de "pas toe of leg uit lijst" van het forum standaardisatie.

3.1.2.1 Werkingsgebied standaard

Bij aanmelding was het beoogd organisatorisch werkingsgebied: Overheden, semi-overheden en instellingen uit de publieke sector

3.1.2.2 Toepassingsgebied standaard

Bij aanmelding was het beoogd functioneel toepassingsgebied: Het aanbieden van RESTful APIs ten behoeve van het ontsluiten van overheids informatie/functionaliteit en enkelvoudige datasets aan eenieder waarvoor deze bedoeld is(burger, bedrijf, andere overheid, etc…). Het ontsluiten van meervoudige en/of statistische datasets via één API valt buiten het functioneel werkingsgebied hiervoor staat de standaard ODATA reeds op de lijst met aanbevolen standaarden.

3.2 API Designrules modulen

Deze sectie beschrijft de status en uitgangspunten voor de standaard "API Designrules modulen". De (concept) modulen zijn op zichzelfstaand document en te vinden op github & docs.geostandaarden.nl:

https://geonovum.github.io/KP-APIs/API-strategie-extensies/ (werkversie)

https://docs.geostandaarden.nl/api/vv-hr-API-Strategie-ext-20190715/ (stabiele versie)

3.2.1 Oorsprong standaard

De API designrules modulen bevatten onderwerpen die bij het opstellen van de eerste versie van de API designrules nog niet als stabiel werden beschouwd. Er wordt nog actief gewerkt om deze modulen tot een stabiele versie te maken. Uiteindelijk zal een deel van de modulen mogelijk direct onderdeel worden van de normatieve API design rules. Een ander deel zal een set van optionele modulen blijven die gebruikt kunnen worden wanneer specifieke extra techniek of functionaliteit nodig is.

3.2.2 Status

De API designrules modulen zijn nog in ontwikkeling en hebben geen formele status.

3.2.2.1 Werkingsgebied standaard

Een werkingsgebied is (nog) niet van toepassing.

3.2.2.2 Toepassingsgebied standaard

Een toepassingsgebied (nog) niet van toepassing.

3.3 Nederlands profiel OAuth

Deze sectie beschrijft de status en uitgangspunten voor het Nederlands profiel OAuth. het profiel zelf is een op zichzelfstaand document. Het Nederlands profiel OAuth is hier te vinden:

https://publicatie.centrumvoorstandaarden.nl/api/oauth/

In aanvulling hierop is er een document dat de verschillen met iGOV kort samenvat en voorziet van rationales:

Additional specification and constraints of iGov-NL to the iGov profile

3.3.1 Oorsprong standaard

Het opstellen van deze standaard is voortgekomen uit het Expert advies OAuth [Expert]. Daarin wordt aangeraden eerst een nederlands profiel op stellen alvorens OAuth op de pas toe of leg uit lijst van het forum standaardisatie te plaatsen. Het maken van dit Nederlandse profiel is opgepakt door de werkgroep Authenticatie/Autorisatie van het Kennisplatform API's.

3.3.2 Status bij forum standaardisatie

Het Nederlands OAuth profiel is op 9 juli 2020 goedgekeurd door het OBDO voor opname op de "pas toe of leg uit lijst" van het forum standaardisatie. De internationale standaard OAuth is opgenomen op de lijst met aanbevolen standaarden.

3.3.2.1 Werkingsgebied standaard

Als organisatorisch werkingsgebied wordt in het expert advies geadviseerd: Nederlandse overheden (Rijk, provincies, gemeenten en waterschappen) en instellingen uit de (semi-) publieke sector

3.3.2.2 Toepassingsgebied standaard

Als functioneel toepassingsgebied wordt in het expert advies voorgesteld: Het gebruik van OAuth 2.0 is verplicht voor applicaties waarbij gebruikers (resource owner) toestemming geven (impliciet of expliciet) aan een dienst (van een derde) om namens hem toegang te krijgen tot specifieke gegevens via een RESTful API. Het gaat dan om een RESTful API waar de resource owner recht tot toegang heeft.

3.3.2.3 Bijzonderheden
3.3.2.3.1 OpenID connect buiten scope

de expertgroep van het forum standaardisatie is op 7 juli en op 22 september 2016 bijeengekomen om de standaarden, de aandachtspunten en openstaande vragen uit het voorbereidingsdossier te bespreken. Daarbij is vastgesteld dat OpenID Connect niet voor opneming op de lijst open standaarden in aanmerking komt. Inmiddels is OpenID connect apart voorgedragen voor opname op de "pas toe of leg uit" lijst van het forum standaardisatie. Voor deze standaard komt ook een Nederlands profiel. Dit zal ook gebaseerd zijn op iGOV zoals in de volgende sectie uitgelegd wordt.

3.3.2.3.2 Aansluiting op internationale standaard iGov

Het Nederlands profiel OAuth baseerd zich op het internationale iGOV OAuth 2.0 profiel [iGOV.OAuth2]. Niet alle keuzes van dit internationale profiel worden overgenomen aangezien dit een aantal keuzes bevat die sterk leunen op de amerikaanse situatie. Het kan het best beschouwd worden als een fork waarbij in het profiel aangeven wordt waar afwijkingen zijn. iGov heeft naast het OAuth profiel ook een OpenID connect profiel [iGOV.OpenID]. Wanneer mogelijk ook OpenID connect op de pas toe of leg uit lijst van het Forum standaardisatie komt kan het Nederlandse profiel OAuth uitgebreid worden met een Nederlandse variant van het iGov OpenID Connect profiel. De usecase die wordt beschreven aan het begin van het Nederlands profiel OAuth sorteert daar al op voor.

A. Referenties

A.1 Informatieve referenties

[Expert]
Expertadvies OAuth 2.0. P. Dam. Forum Standaardisatie. 24 februari 2017. URL: https://www.forumstandaardisatie.nl/sites/bfs/files/Expertadvies%20OAuth%202.0.pdf
[iGOV.OAuth2]
International Government Assurance Profile (iGov) for OAuth 2.0. J. Richer, M. Varley, P. Grassi. OpenID foundation. October 5 2018. URL: https://openid.net/specs/openid-igov-oauth2-1_0.html
[iGOV.OpenID]
International Government Assurance Profile (iGov) for OpenID Connect 1.0 - draft 3. M. Varley, P. Grassi. OpenID foundation. October 5 2018. URL: https://openid.net/specs/openid-igov-openid-connect-1_0.html