Merge pull request #610 from Geonovum/strategie-werktekst

Strategie werktekst

overleggen/Werkgroep API beveiliging/Verslagen/verslag 12 juli 2023

@@ -0,0 +1,31 @@
+# Werkgroep Beveiliging
+
+**Datum:** 12-7-2023
+
+**Aanwezig:** 
+Frank Terpstra (Geonovum)
+Ronald Coenen (Tilburg)
+Alexander Green (Logius)
+Edward van Gelderen (VNG)
+Niels Dequeker (VNG)
+Erwin Reinhoud (Kennisnet)
+Peter Haasnoot (Logius)
+Martin van der Plas (Logius)
+Heiko Hudig
+
+
+**verslag vorige keer**
+geen opmerkingen op het verslag
+
+**FSC terugkoppeling**
+
+Edward en Heiko hebben gesproken over FSC. Heiko heeft suggesties voor het gebruik van Dynamic clientregistration en OIDConnect.
+We gaan dieper op in op de ideeën. Uitkomst is voor nu dat het logisch is dat je binnen FSC zelf iets defnieerd voor het registreren van deelnemende partijen en dat je voor regulier verkeer bestaande standaarden als OAuth gebruikt. Dit is ook het idee van de FSC standaard maar voor Heiko lijkt het nu nog niet zo wanneer je de specificaties leest. Frank Heiko en Edward plannen een vervolg afspraak in om hier verder over te praten. Erwin en Martin sluiten ook graag aan.
+
+**Testbaarheid modules transport security en access control**
+Frank laat resultaten zien van werkbijeenkomst Frank Martin en Hugo. Waarin testen worden beschreven. Belangrijkste punt is dat een aantal testen alleen uitgevoerd kunnen worden als de aanbieder van de te testen API aangeeft dat ze van toepassing zijn en in sommige gevallen zijn tests afhankelijk van het aanwezig zijn van een geldige OAS specificatie. Dit is voor de werkgroep geen probleem. Frank gaat de tests toevoegen in de werkversie van de modules.
+
+**rondvraag**
+Heiko: Remco druk aan het werk Digid en eherkenning op OIDConnect te kijken. Dat kan handig zijn voor andere SSO en brokers. Is daar informatie over te delen? Frank neemt contact op met Remco of dit op de fysieke bijeenkomst van 6 oktober gepresenteerd kan worden.
+Martin: Centraal aansluitpunt heeft bouwstenen voor eHerkenning en OAuth. Het is geen compliace voorzienign maar ze zouden mogelijk wel een omgeving beschikbaar kunnen stellen voor tests.
+Frank: 6 oktober is er weer een fysieke bijeenkomst van het Kennisplatform. Ideeën voor sprekers zijn welkom, een save the date wordt verstuurd. 4 oktober komen we weer online bijeen.

overleggen/Werkgroep API strategie en beleid/Werkversie/strategie-overheid.md

@@ -0,0 +1,57 @@
+# API first Strategie
+De API first strategie past binnen de huidige beleidsdoelen en de omgeving van de publieke sector. Voor uit te leggen wat API first inhoud lichten we eerst deze beleidsdoelen en de omgeving (vanuit APIs bezien) toe. Daarna volgt wat API first inhoud en drie concrete acties die er uit af te leiden zijn.
+
+## Beleidsdoelen
+
+Om de beleidsdoelen van de overheid te halen is doorontwikkeling van de digitale overheid van groot belang. API koppelvlakken 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](https://www.rijksoverheid.nl/onderwerpen/wet-open-overheid-woo) wil de overheid ondermeer _hergebruik van open data_ stimuleren. Zie ook de [Open Data Directive van de EU.](https://digital-strategy.ec.europa.eu/nl/policies/psi-open-data)
+* [Regie op gegevens.](https://www.digitaleoverheid.nl/overzicht-van-alle-onderwerpen/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](https://www.digitaleoverheid.nl/overzicht-van-alle-onderwerpen/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)](https://realisatieibds.pleio.nl/) 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.
+* [EU Data Act of _Datawet_](https://digital-strategy.ec.europa.eu/nl/policies/data-act) 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 APIs er een rol in kunnen spelen maar dat de API standaarden en best practices er nog niet altijd in beeld zijn.
+
+## 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. Zo herkent iedere burger hoe eenvoudige verschillende platforms uit de platform economie (Google Amazon Linkedin Meta) eenvoudig elkaars functionaliteit integreren. Denk aan de store in store concepten op bij grote online retailers, knoppen om informatie te delen op je favoriete sociale medium. 
+Het bedrijfsleven weet hoe via 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 salaris administratie middels API's met elkaar te integreren zijn. 
+De grootste kennis in de markt van (potentiële) software leveranciers in de publieke sector voor het verbinden van IT systemen ligt mede om bovengenoemde redenen bij RESTful API's.
+In de publieke sector zelf zijn API's in sommige sectoren 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. 
+API's pas je dus toe om goed aan te sluiten op de verwachtingen van je omgeving. 
+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 in de IT. 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 transitie mechanisme. APIs worden gebruikt om in stappen over te gaan naar nieuwe manier van werken waarbij API's het ontkoppelpunt vormen.
+
+## API first
+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 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 aanbied. 
+Je moet ze dus niet dwingen om één kanaal te gebruiken. Tegenwoordig zijn er veel kanalen om functionaliteit en data & functionaliteit langs te ontsluiten: 
+* Websites, 
+* Mobiele Apps, 
+* Computer applicaties,
+* IoT devices,
+* Fysieke loketten,
+* Brievenpost
+
+Achter al deze ontsluitingskanalen zit een IT systeem. Het is in de huidige digitale samenleving niet reëel om al je kanalen volledig zelf in de hand te hebben. Door direct toegang te geven tot data en functionaliteit middels een API biedt je de mogelijkheid om deze via verschillende kanalen aan te bieden. Je kan voor ieder kanaal afwegen of je dat als organisatie zelf aanbied of dit aan een andere partij laat. Je opereert dus "API first": Altijd is er een goed gedocumenteerde machine interface die aan de omgeving ter beschikking gesteld kan worden. voor de kanalen die je zelf direct bedient (bijvoorbeeld een website) maak je gebruik van diezelfde interface. Het geeft je omgeving de mogelijkheid om daar waar er voor hen geen geschikt kanaal bestaat, dit 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"](https://www.noraonline.nl/wiki/Bouw_diensten_modulair_op) en de bijbehorende implicatie ["wissel gegevens tussen (web)applicaties uit met API's"](https://www.noraonline.nl/wiki/Wissel_gegevens_tussen_(web)applicaties_uit_met_API%27s). Zoals Common ground en PSD2 laten zien is API first niet alleen een voorwaarde voor moderne IT systemen, het toepassen ervan is ook een middel voor modernisering. 
+
+
+## Actie 1: Houdt regie door open API standaarden toe te passen
+APIs 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 hou informatie middels open API standaarden wordt uitgewisseld. Samen werking met de de markt op basis van open standaarden is wenselijk. Samenwerking op basis van leveranciers eigen oplossingen 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 gebeurd. Met name als die bij de grote platforms terecht komen. De samenleving verwacht van organisaties in de publieke sector dat we zorgvuldig met hun gegevens omgaan. Het gebruik van niet open standaarden voor gegevensuitwisseling past daar niet bij.
+
+## Actie 2: Druk kosten door API standaarden toe te passen
+Als organisatie uit de publieke sector druk je kosten door zoveel mogelijk gebruik te maken van dat wat brede marktondersteuning heeft. Dan zijn er meer partijen die je kunnen helpen, is er meer personeel te vinden met de benodigde kennis en meer keuze betekent meer concurrentie en dus lagere kosten. Kennis over (RESTful) APIs in momenteel zeer breed in de markt beschikbaar. Breder dan nog regelmatig toegepaste alternatieven als SOAP XML(WUS/ ebMS koppelvlakken van Digikoppeling). Het is dus logisch om hier op in te zetten, tegelijkertijd is het goed om innovaties goed te volgen. Dit is eenvoudig te volgen via de lijsten met verplichte en veelgebruikte standaarden van het forum standaardisatie. Daarin is te vinden dat er de REST API Design rules zijn evanals een (daarop aansluitend) REST API profiel binnen Digikoppeling. Gebruik de standaarden bij inkoop voor nieuwbouw en verbouw van IT systemen. 
+Het volgen van standaarden als de REST API design rules is in het belang van de kosten van de overheid in zijn geheel omdat breed gebruik van de standaard interoperabiliteit, wendbaarheid en bijkomende kostenvoordeel voor de hele publieke sector bewerkstelligt.
+
+
+## Actie 3: Deel Kennis over 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 voor over ontwerpkeuzes binnen API's, voor de IT architectuur waarbinnen ze gebruikt worden als ook over de vindbaarheid van API's. We streven ernaar deze binnen bestaande gremia zoals de lijst verplichte standaarden van het forum standaardisatie voor standaarden en de NORA voor architectuur vast te stellen.
+
+
+## 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 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 grenzen openbaarheid) centraal en publiekelijk vindbaar zijn, dus niet alleen via de kanalen van de aanbiedende organisatie maar ook vanuit landelijke portalen/catalogi.