Fase 1

Fase 1 #

Doelstellingen #

De beoogde resultaten van fase 1 zijn, zoals vastgelegd in de subsidie:

  1. In kaart brengen van de stakeholders
  2. Inventarisatie van de huidig (meest voorkomende) geïmplementeerde oplossingen
  3. Onderzoek mogelijke moderne oplossingen passend bij API’s
  4. Plan van Aanpak fase 2
  5. Agendering van een besluit voor in gang zetten Fase 2 op programmeringstafel Gegevensuitwisseling / Toegang

Het einddoel van fase 1 was dat er een goed beschreven en geteste methodiek aan de programmeringstafel toegang besproken is, en daar positief advies voor, en richting aan, fase 2 gegeven wordt.

Activiteiten #

Het project beoogt een standaard voor te stellen. Zowel het verkrijgen van een status als standaard als de adoptie ervan vergen veel communicatie. Een belangrijk deel van de aanpak richt zich daarom op het verkennen van het terrein, het contact maken met de spelers en het bijeen brengen van een diverse community. Beleidsmakers, aanbieders en afnemers van gegevens, implementatiepartners en technische visionairs zijn allemaal essentieel voor het slagen. Het project zal deze community faciliteren, de discussie begeleiden en de resultaten vastleggen en agenderen. Dit is iets anders dan de beste oplossing menen te hebben en die aan zoveel mogelijk partijen op te leggen.

Ook is het van belang dat de juiste balans gevonden wordt tussen beschrijven, uitleggen en uitdragen enerzijds en concrete technische resultaten laten zien anderzijds. Beide zullen nodig zijn om positieve zichtbaarheid en adoptie te verkrijgen.

De projectactiviteiten zijn ingedeeld volgens de bovengenoemde doelstellingen:

  1. Initiatie: inlezen in de materie, verkennen van het speelveld, leggen van eerste contacten
  2. Zichtbaarheid: inrichten van een onlineomgeving waarin het project met alle resultaten en overwegingen publiek gemaakt wordt
  3. Maken van de stakeholder kaart en verifiëren van de correctheid daarvan bij de betrokkenen. Naast kennis voor het project wordt hiermee vooral zichtbaarheid en contact bereikt.
  4. Inventariseren van de huidige werkwijzen, inclusief analyse van voor- en nadelen, en attitude ten opzichte van dit initiatief. Ook hiermee wordt breder contact en begrip nagestreefd, naast inhoudelijke kennis en inspiratie.
  5. Inventariseren van de moderne methodieken. Met desktop research, gesprekken met andere initiatieven, en het uitvoeren van concrete technische verkenning worden de mogelijkheden overwogen. Resultaat hiervan is ook expliciet het laten zien dat de voorgestelde oplossing(en) correct en haalbaar zijn.
  6. Het uitvoeren van een proef samen met een implementatiepartner is een optie; het valt nog te bezien of hier ruimte voor is qua tijd en of er goede use cases en partners gevonden kunnen worden.
  7. Houden van bijeenkomsten waarin de meest relevante en inspirerende resultaten tot nu toe gedeeld worden, en eenieder vragen te reflecteren en mee te praten.
  8. Regelmatige afstemming van tussenresultaten en uitdaging bij de voornaamste klankborden: FDS, overlegtafels en Digilab

Risico’s #

Het voorstellen van een standaard en het verkrijgen van adoptie daarvan is niet eenvoudig. Hier de belangrijkste risico’s die we a priori zien.

  1. Complexiteit Gegevensuitwisseling is een complex gebied. Veel lagen van techniek, standaarden en producten, veel belangen en behoeftes. Toegangsverlening is daar een onderdeel van dat raakt aan zowel techniek als inhoud, waardoor uitvoering en bestuur betrokken moeten zijn. Dit is een belangrijke reden waarom praktische uitvoering tot nu toe federatief niet ver gekomen is, ondanks technische mogelijkheden en organisatorische bereidheid.

    Een standaard kan de complexiteit in beeld brengen, en kan ook een deel van de complexiteit wegnemen. Zeker als er bouwstenen en/of voorzieningen geboden worden. Daarnaast zullen de eerste wegbereiders laten zien wat er mogelijk is en een positief voorbeeld van adoptie laten zien.

  2. Weerstand tegen verandering bij aanbieders en afnemers. Nu zijn aanbiedende partijen vrij om toegangsverlening te implementeren zoals zij dat het beste achten, en hebben dat ook gedaan. Het introduceren van een standaardmethode gaat hoe dan ook werk opleveren, zonder dat daar direct zichtbare verbeterde functionaliteit tegenover staat (‘het werkt nu toch ook’). Dit was ook het geval bij HaalCentraal: als koppelvlakstandaard is deze technisch duidelijk beter dan StUF of alleen REST, en toch bleef de adoptie steken en is de ontwikkeling stilgelegd.

    Het project zal moeten laten zien wat de belangrijkste drijfveren zijn (zoals kostenbesparing en voldoen aan de wet- en regelgeving), en een kritische massa aan ondersteuning, voorstanders, en geslaagde implementaties laten zien.

  3. Weerstand van leveranciers. Een bekend geluid is dat gemeentes en uitvoeringsinstanties veel geld kwijt zijn aan maatwerkoplossingen. Ze ervaren vast te zitten aan leveranciers (vendor lock-in). Het innoveren van bestaande oplossingen of overstappen wordt niet makkelijk gemaakt, uit (reële) angst voor omzetverlies door leveranciers.

    Het doorbreken van een dergelijke lock-in of monopolie kan, naast een goede standaard en uitleg, via de samenwerkingsplatforms die er al zijn, zoals Open Webconcept.

  4. Weerstand tegen verlegging van verantwoordelijkheden Het juist beleggen van verantwoordelijkheden betekent voor veel uitwisselingen dat de afnemer meer moet doen, en de aanbieder minder hoeft te doen. Dat kan aan beide kanten bezwaren opleveren:

    • Aanbieders (of eigenlijk bronhouders) geven een taak uit handen, en daarmee een stuk controle. Dat kan op weerstand stuiten.
    • Afnemers moeten meer verantwoording gaan afleggen. Ze zullen verplicht worden om verifieerbare verklaringen aan te vragen en het gebruik daarvan te implementeren, en daarmee een risico lopen dat dat niet goed gebeurt. Er is een kans dat niet meegewerkt wordt om dat risico te vermijden.

Planning en status #

planning

Fase 1 was origineel gepland voor heel 2024. Door een late start 1 juli was het budget nog niet geheel benut op de einddatum. Daarom is fase 1 met 2 maanden verlengd. Aan de resultaten zijn als gevolg al een eerste versie van de standaard en de referentie-implementatie toegevoegd.

Resultaten #

Dit zijn resultaten van fase 1, die allemaal op deze site te vinden zijn:

Onderzoek #

Qua stakeholders:

  • Deze zijn in kaart gebracht
  • Er is contact gemaakt met de belangrijkste stakeholders, en uitleg gegeven over het project en de toekomstige standaard
  • Er is een eerste werkgroep gehouden

De inventarisatie bij de Nederlandse overheid is afgerond met als onderzoeksgebieden:

  • Hoe toegang nu geregeld is
  • Waar al adoptie van PBAC is
  • Welke eerdere onderzoeken gedaan zijn

Bij de inventarisatie van de markt is gekeken naar:

  • Beschikbare producten, open source en commercieel. Gesprekken met de commerciële aanbieders zullen nog doorlopen.
  • Staat van zaken in Europees verband
  • Andere initiatieven tot standaardisatie

Standaard #

Er is een keus gemaakt om bij OpenID AuthZEN aan te sluiten. Een eerste versie van het NL Gov profiel daarop is vrijwel afgerond.

Referentie-implementatie #

TODO