Change Log¶
Wijzigingen na v0.9.3 (concept, nog niet uitgebracht)¶
Naar aanleiding van reviewfeedback op v0.9.3:
- §5, "GBO levert drie soorten resultaten.". Benoemt expliciet de drie soorten resultaten van GBO en geeft per centrale voorziening in een tabel: gegevensstroom, soort, verplicht of optioneel, beheerder. Beschrijft ook wat verplicht is voor publieke en private partijen.
- Minder "kan". Waar een keuze of verplichting bedoeld is, staat nu "mag", "biedt", "is optioneel", "is verplicht" of "nog te besluiten (zie PSA)". Onder andere: keuzevrijheid (§1), scope andere gegevensstromen (§2), PubEAA-instantie en ASI-provider (§3 patroon A), semantische mapping (§3 patroon A en B), toestemmingsvoorziening verplicht voor DvTP (§3 patroon C), register als PIP (§5), QTSP-aansluitvoorwaarden (§5), alternatieven voor bronhouders (§6).
Change Log v0.9.3¶
Van: versie 0.9.2 (juni 2026) → Naar: 0.9.3 (augustus 2026)
Dit is geen uitputtende opsomming van elke los gewijzigde zin, maar een overzicht van wat er conceptueel/structureel is veranderd, per hoofdstuk/paragraaf.
Samenvatting in één oogopslag¶
| Onderdeel | Aard van de wijziging | Details |
|---|---|---|
| Structuur document | +1 hoofdstuk (Impact op partijen), doorlopende nummering, uitgebreidere inleidingen per generieke functie | detailbeschrijving |
| Uitgangspunten | GDI en "Keuzevrijheid" als nieuwe expliciete uitgangspunten | detailbeschrijving |
| Patroon A (EUDI) | ASI-P met verify/retrieve-rol vervangt de twee-varianten-beschrijving; OOTS-catalogi genoemd | detailbeschrijving |
| Patroon B (OOTS) | Sterk uitgebreid: OOTS-V/OOTS-Adapter, sectorale aansluitingen, semantische omvorming; TIP-verwijzing verwijderd | detailbeschrijving |
| Patroon C (DvTP) | Terminologie "toestemmingsregister"/"-voorziening" aangescherpt; extra afrondstap in diagram | detailbeschrijving |
| Generieke functies | Nieuwe GDI-koppeltabel; minder harde koppeling aan OPA/Rego; diverse status-updates | detailbeschrijving |
| Componenten (H5) | Nieuwe kleurcodering/legenda in overzichtsplaat; LDV toegevoegd; Query Template Registry → dienstencatalogus; nieuwe slotparagraaf over stelselbeheer | detailbeschrijving |
| Impact op partijen | Volledig nieuw hoofdstuk 6 | detailbeschrijving |
Algemeen / opzet¶
- Nieuw hoofdstuk 6 — "Impact op betrokken partijen" toegevoegd. Dit is de belangrijkste structurele toevoeging: een tabel die per partij (Bronhouder, QTSP, Basisinrichting OOTS, Private dienstverleners, Burger) de verwachte impact en toelichting beschrijft.
- Nieuwe bijlagen: Begrippenlijst en deze Change Log.
- Hoofdstukken zijn nu doorlopend genummerd (1 Inleiding, 2 Voorgestelde oplossingsrichting, … 6 Impact op betrokken partijen) — in 0.9.2 hadden hoofdstukken geen nummer in de titel.
- Uitgangspunten (§1) zijn uitgebreid en herschreven:
- GDI is nu als apart uitgangspunt benoemd (met toelichting op de 4 domeinen: toegang, interactie, gegevensuitwisseling, infrastructuur).
- FDS-uitgangspunt is uitgebreider toegelicht, inclusief expliciete koppeling naar GDI-standaarden en het voorbeeld "Federatieve Toegangsverlening" (AuthZen, aangeboden bij Forum Standaardisatie).
- Nieuw uitgangspunt "Keuzevrijheid" toegevoegd: bronhouders zijn vrij om GBO-componenten te gebruiken, te combineren met eigen oplossingen, of niet te gebruiken.
- "Federatief Datastelsel"-omschrijving is losgekoppeld van specifieke stelselfuncties (FSC/FTV worden niet meer als uitgangspunt-bullet genoemd, maar verderop uitgewerkt).
- §1 Inleiding verwijst nu expliciet door naar de tabbladen "Gemeenschappelijke Bronontsluiting" (doelen) en "Context" (juridisch/organisatorisch kader).
- Verwijzing naar demo waar de voorgestelde oplossing in een demo-omgeving getoond wordt.
Hoofdstuk 2 — Voorgestelde oplossingsrichting¶
- Nieuwe subparagraaf "Knelpuntenanalyse" toegevoegd vóór de oplossingsrichting zelf: benoemt expliciet de vier knelpunten (verschillende gegevenssets, autorisatiemodellen, protocollen, wet- en regelgeving per gegevensstroom) en de bijbehorende oplossingsrichting in bullets.
- Oplossingsrichting-tekst is aangescherpt:
- "generieke API" is vervangen door "één API".
- Nieuwe zin toegevoegd: als een bronhouder de koppeling (nog) niet zelf kan inrichten, biedt GBO instrumenten om toch gebruik te maken van de componenten.
- De rol van de centrale voorzieningen per gegevensstroom (ASI/PubEAA-provider voor EUDI, semantische mapping voor OOTS, toestemmings-/pseudonimiseervoorziening voor DvTP) wordt nu expliciet in lopende tekst toegelicht, in plaats van alleen in het diagram.
- Figuur 1 (oplossingsrichting-diagram):
- Subgraph-label "SDG / OOTS" → "OOTS".
- Kleurstelling van bron/burger-knopen gewijzigd (van groen naar lichtblauw).
- Bijschrift uitgebreid met legenda-achtige toelichting: "de grijze componenten zijn actoren of bestaande voorzieningen die hergebruikt worden."
Hoofdstuk 3 — Interactiepatronen¶
Patroon A (EUDI-Wallet)¶
- Nieuwe zin: PubEAA's en QEAA's hebben juridisch dezelfde betekenis.
- De rolbeschrijving van GBO is verduidelijkt: GBO ondersteunt de PubEAA-uitgevende instantie én de rol van Authentic Source Interface Provider (ASI-P), die zowel een verify- als een retrieve-dienst kan bieden. De oude tekst met twee losse "varianten" (burger contracteert QTSP / bronhouder contracteert QTSP) is vervangen door deze bredere ASI-P-beschrijving.
- Nieuwe alinea over de OOTS common services: mogelijke inzet voor de attributencatalogus (Semantic Repository) en leverancierscatalogus (Data Service Directory), en de rol van GBO daarin (nog in onderzoek).
- Sequentiediagram (Figuur 2): participant "Verificatiedienst" hernoemd naar "Verify-/retrievedienst (Authentic Source Interface)"; extra notitie toegevoegd over ISO15000 (geen autorisatie/authenticatie nodig).
- Kader "Afstemming lopend" is verbreed: spreekt nu over "alle mogelijke varianten" i.p.v. alleen PubEAA vs. QTSP.
Patroon B (OOTS)¶
- Grotendeels herschreven en flink uitgebreid. Oude tekst (RINIS/BZK als nationaal OOTS-toegangspunt) is vervangen door een uitgebreidere beschrijving:
- Sectorale aansluitingen (bv. EMREX-brug) en eigen aansluitingen worden nu genoemd als alternatief voor de Basisinrichting OOTS (buiten scope van dit ontwerp).
- Stichting RINIS wordt genoemd als leverancier, in opdracht van BZK/EZK.
- Nieuwe alinea over de Europese transportlaag (eDelivery, AS4, eBMS, Regrep) en het OOTS Exchange Data Model (OOTS EDM).
- Nieuwe alinea over semantische omvorming: niet verplicht vanuit de SDG-verordening, maar wel gestimuleerd; voorbeeld uniform bewijs van geboorte; GBO kan deze transformatie namens de bronhouder uitvoeren.
- De oude passage over de TIP-basisfunctie "Delivering messages" (uitleg dat dit buiten scope van GBO valt) is verwijderd.
- Sequentiediagram (Figuur 3): participant "GBO (GBO voorziening)" hernoemd naar "OOTS adapter (GBO voorziening)"; een aparte stap voor semantische mapping is toegevoegd (nu stap ④, tussen ontvangst en bronbevraging), met als gevolg herschikte stapnummers t.o.v. 0.9.2.
Patroon C (DvTP)¶
- Terminologie "toestemmingenregister" is doorgaans vervangen door "toestemmingsregister", en "GBO kiest voor een centraal toestemmingenregister" is herschreven naar "GBO stelt een centrale toestemmingsvoorziening voor".
- De zin over real-time validatie van het consent-id op moment van uitvraag is vereenvoudigd/ingekort.
- Toestemmingsportaal wordt nu specifiek gekoppeld aan een centraal portaal in de openingsalinea (was voorheen pas later genoemd).
- Fase 2-titel in het sequentiediagram aangevuld met "(per bron een verzoek)".
- Sequentiediagram (Figuur 4): kleine technische aanpassingen (consent-id-validatie response, VI/VP-doorgifte in redirect) en een extra laatste stap "DV → Burger: Levert dienst" toegevoegd.
Hoofdstuk 4 — Generieke functies en stelselfuncties¶
- Nieuwe tabel die de generieke functies koppelt aan de vier GDI-domeinen (Toegang, Interactie, Gegevensuitwisseling, Infrastructuur), met een toelichtende alinea over hoe dit aansluit bij de NORA/GDI-architectuur en vergelijkbare indelingen (bv. Gezondheidsinformatiestelsel). Dit ontbrak volledig in 0.9.2.
- Elke generieke functie (F1 t/m F8) heeft nu een uitgebreide, inhoudelijke inleidende alinea i.p.v. de korte cursieve one-liner uit 0.9.2. Bijvoorbeeld:
- F1: nu met uitleg over BSN/OIN-identificatie, pseudonimisering, betrouwbaarheidsniveaus en identity matching.
- F2: uitleg over PBAC en dat bronhouders een eigen implementatie mogen gebruiken als deze de centrale beleidsregels toepast.
- F3: uitgebreide uitleg over GraphQL, GBO-vertaallaag, OOTS-adapter en attestatie-uitgifte.
- F7: nu expliciet vermeld dat procesorkestratie voor de huidige use cases (nog) niet relevant is.
- F8: expliciet vermeld dat beheer & continuïteit nog niet diepgaand is uitgewerkt.
- Wijzigingen in specifieke stelselfuncties:
- S03: status uitgebreid met "Identity Matching nog in onderzoek".
- S05: status "OPA/Rego" vervangen door "AuthZEN NLGov profiel beschikbaar; FTV in ontwikkeling" — minder hard gekoppeld aan één specifieke policy-engine.
- S06: tekst "OCI-bundles"/PAP-omschrijving vrijwel gelijk gebleven, maar "OPA/Rego-policy-bundles" is verkort naar "policy-bundles" (technologieneutraler).
- S07: gap/actie "Query Template Registry" vervangen door "Dienstencatalogus".
- S08: naam ingekort van "OOTS-adapter (Grensoverschrijdend)" naar "OOTS-adapter"; gap/actie uitgebreid met GraphQL-ondersteuning in OOTS-V en mapping naar het Evidence Exchange Data Model.
- S09: status nu "FSC Logging en Logboek Dataverwerking (LDV) beschikbaar" i.p.v. het generieke "Standaarden beschikbaar".
- S11: naam gewijzigd van "Attesteringsuitgifte (PubEAA / QEAA)" naar "Attesteringsuitgifte (voor EUDI-wallet)"; nu gekoppeld aan F3 én F7 (was alleen F3).
- Het totaaloverzicht (samenvattende tabel) is dienovereenkomstig bijgewerkt.
Hoofdstuk 5 — Te ontwikkelen componenten¶
- Figuur 5 (Overzichtsplaat) is inhoudelijk het meest veranderde onderdeel:
- Volledig nieuwe kleurcodering met legenda: groen = generieke decentrale bronontsluiting, paars = centrale voorzieningen (optioneel, bronhouder mag alternatief kiezen), rood = centrale voorzieningen (verplicht bij deze gegevensstroom), grijs = bestaande voorzieningen. In 0.9.2 was er alleen een generiek onderscheid tussen "gbo"- en "generieke" kleur zonder deze semantiek.
- ASI-provider is nu expliciet "verify/retrieve dienst" i.p.v. alleen "verify dienst".
- Koppeling OOTS-adapter ↔ Basisinrichting OOTS is nu GraphQL i.p.v. REST-JSON.
- Koppeling GBO ↔ toestemmingsvoorziening is nu gestippeld en gelabeld als PIP-relatie i.p.v. een gewone REST-JSON-lijn.
- Bouwstenen die hergebruikt worden:
- LDV (Logboek Dataverwerking) is toegevoegd als nieuwe herbruikbare bouwsteen.
- OPA/Rego is niet langer als aparte, met naam genoemde bouwsteen opgevoerd; verwijzingen zijn generieker gemaakt ("een policy-taal zoals OPA/Rego").
- GraphQL-bouwsteen: "Query Template Registry" vervangen door "dienstencatalogus".
- OAuth 2.0/OIDC-bouwsteen: aangevuld met een zin over Identity Matching wanneer het authenticatiemiddel geen BSN bevat.
- Paragraaf "GraphQL als selectief bevragingsmechanisme": de losse subparagraaf over de Query Template Registry is vervallen; hiervoor in de plaats staat nu een bullet over de dienstencatalogus.
- Paragraaf "OOTS-aansluiting": "OOTS-adapter" is hernoemd naar "protocolvertaler", met toevoeging "en vice-versa" (dus ook de retourroute).
- Nieuwe slotparagraaf "Stelselafspraken en voorzieningenbeheer" toegevoegd: benoemt dat alle te ontwikkelen voorzieningen en afspraken in een stelsel moeten landen, met beheer, naleving en monitoring — verder uit te werken in de PSA.
Hoofdstuk 6 — Impact op betrokken partijen (volledig nieuw)¶
Compleet nieuw hoofdstuk met een tabel die per partij de impact en toelichting beschrijft:
| Partij | Kern van de impact |
|---|---|
| Bronhouder | Implementatie GraphQL API, FSC, FTV; beheer van catalogi (dienstencatalogus, semantische mapping, data request registry) |
| QTSP | Aansluiting op de Authentic Source Interface |
| Basisinrichting OOTS | Ondersteuning van GraphQL nodig in OOTS-V |
| Private dienstverleners | Toetreden tot het (nog uit te werken) stelsel, aansluiten op BSNk, FSC outway, koppeling toestemmingsvoorziening |
| Burger | Kan gegevens delen op basis van centraal beheerde toestemming, maar houdt losse ingangen/stelsels per partij — burgerperspectief is nog niet in scope |