GBO¶

Project Start Architectuur¶

Versie 0.1
Maart 2026

Auteur: Govert Claus
Organisatie: ICTU

Project Start Architectuur (PSA) - GBO¶

Welkom bij de Project Start Architectuur voor GBO. Dit document beschrijft de architectuurkaders, principes en interactiepatronen die van toepassing zijn op dit project.

Over dit document¶

Deze PSA is opgebouwd uit verschillende modules om het beheer overzichtelijk te houden. Aan de linkerkant (of via het menu bovenin) kun je door de verschillende hoofdstukken navigeren.

Kerngegevens¶

Onderwerp	Details
Status	Concept / In review
Versie	0.0.1
Eigenaar	ICTU
GithubRep	https://github.com/ICTU/GBO
PDF	Pagina die als PDF afgedrukt kan worden
Laatst bijgewerkt	{{ git_revision_date }}

Leeswijzer¶

De PSA is als volgt opgebouwd:

Inleiding: Doel en scope van dit document.
Context: De omgeving waarin het project landt.
Architectuurprincipes: De kaders waaraan de oplossing moet voldoen.
Ontwerpprincipes: De kaders waaraan het technische ontwerp van de oplossing moet voldoen.
Ecosysteem en oplossingsrichting: Het systeem (rollen en relaties) waar we naar kijken en welke oplossingsrchting we voor ogen hebben.
Interactiepatronen: De interactiepatronen die uit de use cases volgen en die de oplossing moet ondersteunen.
Logische architectuur: De generieke functies waar de oplossing uit bestaat.
Capabilities: De capabiltities/ bedrijfsfuncties die de generieke functies invullen en waar het GBO stelsel inrichting aan moet geven.
Realisatiestrategie: De strategie om de oplossing te realiseren en te implementeren.
Vraagstukken en ontwerpkeuzes: Vraagstukken waarvoor nog geen oplossing is gevonden of keuze is gemaakt. Als er een oplossing is gevonden of een keuze is gemaakt, wordt deze in dit hoofdstuk vastgelegd als ontwerpkeuze en in het technisch ontwerp uitgewerkt.

Vragen over deze PSA kunnen gesteld worden aan de architect van het projectteam.

PSA ↵

Inleiding¶

Doel van dit document¶

Dit document beschrijft de Project Start Architectuur (PSA) voor het programma GBO (Gemeenschappelijke BronOntsluiting).

De PSA beschrijft wat de oplossing moet kunnen, maar legt nog geen technische implementatie vast.

Scope¶

De PSA beschrijft de architectuur voor een generieke infrastructuur waarmee:

burgers gegevens van overheidsorganisaties kunnen verkrijgen
burgers deze gegevens kunnen delen met private partijen
gegevens gebruikt kunnen worden voor Europese toepassingen zoals EDI Wallet en SDG/OOTS

De PSA omvat:

architectuur- en ontwerpprincipes
generieke functies
capabilities
realisatiestrategie

De PSA beschrijft niet:

concrete technische oplossingen
implementaties van componenten
leverancierskeuzes

Relatie met andere architecturen¶

De PSA sluit aan bij:

NORA
GDI
EDI Wallet / EUDI Wallet
Single Digital Gateway (SDG)
Once Only Technical System (OOTS)
Federatief Datastelsel
...

Context en aanleiding¶

Beleidscontext¶

Moderne dienstverlening aan burgers, zowel door overheden als private partijen, begint met vertrouwen in actuele en betrouwbare persoonsgegevens. Het beleidsdossier Regie op Gegevens richt zich, naast de regievormen inzage en eenmalige verstrekking, ook op het delen van gegevens: het mogelijk maken dat burgers hun eigen gegevens uit overheidsbronnen digitaal beschikbaar kunnen stellen aan dienstverleners of zichzelf.

Momenteel lopen er, naast vele andere trajecten, drie omvangrijke ontwikkelingen om het delen van gegevens mogelijk te maken:

EDI-wallet: Vanuit de eIDAS2-verordening wordt gewerkt aan de Europese Digitale Identiteit (EDIwallet). Met deze digitale portemonnee kunnen burgers zich digitaal identificeren, persoonlijke gegevens veilig delen en documenten digitaal ondertekenen – zowel bij publieke als bij private dienstverleners in Nederland en de rest van de EU.
SDG-OOTS: Vanuit de SDGverordening wordt gewerkt aan het Once Only Technical System (OOTS). OOTS maakt het mogelijk dat burgers (en bedrijven) een verklaring van instemming geven aan Europese publieke dienstverleners, waarna benodigde bewijsdocumenten éénmalig automatisch en veilig tussen overheidsorganisaties kunnen worden uitgewisseld.
DvTP: Vanuit het beleidsdossier Regie op Gegevens wordt, als reactie op het ongewenste scrapen van persoonlijke omgevingen van burgers binnen overheidswebsites (en daarmee overheidsbronnen), een oplossing ontwikkeld voor het delen van gegevens via toestemming met private dienstverleners (DvTP).

Deze drie ontwikkelingen hebben elk een eigen oorsprong, doel en reikwijdte. Wat ze gemeen hebben, is dat de gegevensdeling wordt geïnitieerd door de burger en dat daarvoor overheidsbronnen moeten worden ontsloten. Op de korte en middellange termijn staan overheidsorganisaties, de zogenoemde bronhouders, dan ook voor de opgave hun overheidsbronnen toegankelijk te maken voor deze ontwikkelingen.

Dit speelt zich af in een bredere context waarin bronhouders ook betrokken zijn bij de totstandkoming van het Federatief Datastelsel (FDS). In dit stelsel worden afspraken en standaarden voor gegevensuitwisseling binnen de overheid vastgelegd. Tegelijkertijd krijgt gegevensdeling met private partijen meer aandacht, waarvoor binnen de publiek-private samenwerking Trusted Information Partners (TIP) een afsprakenstelsel is ontwikkeld. Daarnaast maken de introductie van de Nederlandse Digitaliseringsstrategie (NDS) en de inwerkingtreding van de Europese verordening Interoperabel Europa (VIE) duidelijk dat het realiseren van nationale en Europese interoperabiliteit niet langer vrijblijvend is.

In 2025 is onderzocht of het ontsluiten van overheidsbronnen meer samenhangend en gezamenlijk kan worden opgepakt onder de noemer Gemeenschappelijke Bronontsluiting. Gemeenschappelijk benadrukt hier de collectieve aard van de opgave. Daarbij is gekeken naar één uniforme methode voor ontsluiting ten behoeve van de EDI-wallet, SDG-OOTS en DvTP, in samenhang met de ontwikkeling van FDS, TIP, NDS en (Europese) interoperabiliteit.

Huidige situatie¶

Onnodige administratieve lasten voor burgers en organisaties doordat dezelfde gegevens herhaaldelijk worden opgevraagd en aangeleverd.
Risicovolle werkpraktijken (documentuitwisseling, datadeler-apps, scraping) die niet passen bij een gecontroleerde, transparante en uniforme keten.
Beperkte innovatie en dienstverlening doordat hergebruik van geverifieerde brongegevens richting private diensten niet goed mogelijk is, terwijl de maatschappelijke behoefte hieraan groeit.

(zie probleemomschrijving in Beleidskompas)

Probleemstelling¶

Het delen van persoonsgegevens ondervindt op dit moment de volgende problemen:

Geheimhoudingsplichten en strikte doelbinding in sectorale wetten
Ontbreken van een expliciete bevoegdheid om aan private dienstverleners te verstrekken op verzoek van de burger
Toestemming van de burger is in de overheid-context vaak geen stevige grondslag
Versnippering van regels en verantwoordelijkheden over sectoren en organisaties
Omwegen in de praktijk door frictie tussen behoefte en wat juridisch/operationeel kan
Scraping en vergelijkbare vormen van geautomatiseerd verzamelen vergroten risico’s en zijn juridisch kwetsbaar

Doelstelling¶

Om de problemen uit de vorige paragraaf op te lossen wordt een stelsel (een verzameling afspraken, standaarden, stelselfuncties en voorzieningen) voorgesteld, waarin het mogelijk is dat:

burgers toestemming geven en beheren via een vertrouwde overheidsomgeving, op basis van begrijpelijke informatie over doel, gegevens en ontvanger;
private dienstverleners alleen gegevens opvragen binnen de afgesproken reikwijdte en de burger terugkoppelen welke gegevens zijn ontvangen en gebruikt;
bronhouders alleen verstrekken na verificatie van een geldig verzoek en binnen een afgebakend doel, met waarborgen voor integriteit en herleidbaarheid.

De doelstellingen van het GBO stelsel zijn:

Een lagere implementatielast voor bronhouders
Het voorkomen van maatwerk en ad-hoc-implementaties
Effectiever hergebruik van generieke voorzieningen
Samenhangende afsprakenstelsels die samenwerking tussen stelsels vereenvoudigen
Meer uniformiteit en interoperabiliteit tussen overheden, en overheid en private partijen

Architectuurprincipes GBO — Gegevensuitwisseling¶

Overzicht van de meest relevante architectuurprincipes voor het GBO-stelsel, gegroepeerd per juridisch/beleidskader. Bedoeld als input voor de PSA.

Kader 1 — AVG (Algemene Verordening Gegevensbescherming)¶

P-01 · Grondslag vóór uitwisseling¶

Stelling: Elke gegevensuitwisseling vereist een expliciete wettelijke grondslag en doelbinding, die vooraf door de afnemer worden vastgesteld en aantoonbaar gemaakt.

Bronnen:
- AVG art. 5 & 6
- NORA Domeinarchitectuur Gegevensuitwisseling §4.2
- NORA NAP05 — Nauwkeurig

P-02 · Minimale gegevensverwerking (dataminimalisatie)¶

Stelling: Er worden niet meer persoonsgegevens uitgewisseld dan strikt noodzakelijk voor het doel. Het stelsel levert attributen, niet ruwe (basis)registratie-dumps.

Bronnen:
- AVG art. 5 lid 1 sub c
- NORA NAP07 — Minimale gegevensverwerking

P-03 · Privacy by design & by default¶

Stelling: Privacybeschermende maatregelen — waaronder pseudonimisering — zijn ingebakken in het ontwerp van het stelsel, niet achteraf toegevoegd. Welke maatregelen nodig zijn kan per situatie verschillen, maar het moet altijd vanaf het ontwerp meegnomen worden.

Bronnen:
- AVG art. 25
- NORA Domeinarchitectuur Gegevensuitwisseling §4.2

P-12 · Logging & onweerlegbaarheid van gegevensuitwisselingen¶

Stelling: Elke (poging tot) gegevensuitwisseling wordt gelogd (metadata van verzending en ontvangst) zodat achteraf aantoonbaar is dat uitwisselingen hebben plaatsgevonden en door wie.

Bronnen:
- AVG art. 5 lid 2 (verantwoordingsplicht)
- NORA Domeinarchitectuur Gegevensuitwisseling §4.2
- BIO (Baseline Informatiebeveiliging Overheid)

P-13 · Transparantie & inzage voor de burger¶

Stelling: De burger heeft recht op inzage in welke gegevens over hem / haar zijn uitgewisseld, met wie en op welke grondslag.

Bronnen:
- AVG art. 13–15 (informatieplicht, inzagerecht)
- Programma Regie op Gegevens (BZK)
- NORA BP03 — Ontvanger is op de hoogte

Kader 2 — NORA (Nederlandse Overheids Referentie Architectuur)¶

P-08 · Eenmalige vastlegging, meervoudig gebruik (EV-MG)¶

Stelling: Gegevens worden eenmalig bij de bron vastgelegd en vanuit die bron hergebruikt. Het stelsel bevordert gegevensdeling in plaats van gegevens kopiëren.

Bronnen:
- NORA BP08 — Gebruik open standaarden
- NORA NAP10 — Neem gegevens als fundament
- FDS-architectuurprincipes

P-09 · Open standaarden & leveranciersonafhankelijkheid¶

Stelling: Het stelsel maakt gebruik van open standaarden (zoals OAuth 2.0, REST/GraphQL, Digikoppeling, OID4VC) van de Forum Standaardisatie 'pas toe of leg uit'-lijst, zodat vendor lock-in wordt voorkomen.

Bronnen:
- NORA Domeinarchitectuur Gegevensuitwisseling §4.2
- Forum Standaardisatie (lijsten verplichte/aanbevolen standaarden)
- EU Data Act hfst. VIII (interoperabiliteit)

P-11 · FAIR-principes voor gegevens¶

Stelling: Gegevens in het stelsel zijn voorzien van metadata die ze vindbaar en herbruikbaar maakt conform de FAIR-principes, inclusief semantische standaarden (GGM, RDF, SHACL).

Bronnen:
- FAIR-principes (Wilkinson et al., 2016)
- NORA NAP10 — Neem gegevens als fundament
- FDS-architectuurprincipes

P-14 · Scheiding van generieke en niet-generieke functies¶

Stelling: Het GBO beperkt zich tot generieke functies die overheidsbreed noodzakelijk zijn. Domeinspecifieke functionaliteit is de verantwoordelijkheid van de betreffende sector of partij.

Bronnen:
- NORA subsidiariteitsbeginsel
- GDI-Architectuur Basisprincipes (Bureau MIDO)
- Architectuur Digitale Overheid 2030

P-15 · Ontkoppeling voor wendbaarheid en robuustheid¶

Stelling: Afnemers, de generieke kern en bronhouders zijn technisch ontkoppeld via gestandaardiseerde koppelvlakken, zodat componenten onafhankelijk kunnen worden doorontwikkeld en vervangen.

Bronnen:
- GDI-Architectuur Basisprincipes — "Gebruik van flexibele en ontkoppelde functies"
- NORA BP09 — Pas open standaarden toe

Kader 3 — Wet digitale overheid (Wdo) & PKI¶

P-05 · Erkende authenticatiemiddelen op passend betrouwbaarheidsniveau¶

Stelling: Toegang tot het stelsel vereist een erkend inlogmiddel (DigiD, eHerkenning, EUDIW) op het betrouwbaarheidsniveau dat past bij het risiconiveau van de dienst.

Bronnen:
- Wet digitale overheid (Wdo) 2023
- eIDAS Verordening (EU) 2024/1183
- NORA Authenticatie(middelen)beheer

P-07 · Vertrouwensstelsel op basis van PKI en erkende toetredingseisen¶

Stelling: Alle deelnemende partijen (bronhouders, afnemers, private partijen) voldoen aan toetredingseisen en zijn aantoonbaar betrouwbaar via PKIoverheid-certificaten en/of het TIP-stelsel.

Bronnen:
- PKIoverheid-stelsel
- Wet digitale overheid (Wdo)
- Afsprakenstelsel ETD (eHerkenning)

Kader 4 — eIDAS2 & Europese digitale identiteit¶

P-06 · Ondersteuning van de Europese digitale identiteitswallet (EUDIW)¶

Stelling: Het stelsel is ontworpen om in de toekomst attributen uit te wisselen via de EU Digital Identity Wallet (OID4VC/OID4VP), zodat grensoverschrijdende dienstverlening mogelijk is.

Bronnen:
- eIDAS2 Verordening (EU) 2024/1183
- EU Architecture Reference Framework (ARF)
- Single Digital Gateway (SDG) Verordening

Kader 5 — EU Data Governance Act (DGA) & Data Act¶

P-10 · Datasoevereiniteit: de bronhouder behoudt regie¶

Stelling: Bronhouders behouden volledige zeggenschap over hun gegevens en de condities waaronder die worden ontsloten. GBO heeft geen eigenaarschap over de data welke ontsloten wordt, maar faciliteert deze enkel.

Bronnen:
- EU Data Governance Act (DGA) Verordening 2022/868
- FDS Design Principles for Data Spaces — principe 1
- NORA Domeinarchitectuur Gegevensuitwisseling §4.2

P-16 · Eerlijke en niet-discriminerende toegang voor private partijen¶

Stelling: Private partijen kunnen deelnemen aan het stelsel onder transparante, proportionele en niet-discriminerende toetredingsvoorwaarden, mits zij voldoen aan de gestelde beveiligings- en privacynormen en géén BSN verwerken, behalve als daar een wettelijke grondslag voor bestaat.

Bronnen:
- EU Data Governance Act art. 5 (condities hergebruik)
- Wabb art. 10 (BSN-verbod private partijen)
- DvTP-kader (Data delen via Toestemming met Private partijen)

Kader 6 — Wet algemene bepalingen BSN (Wabb) & Regie op Gegevens¶

P-04 · BSN-loos voor private afnemers (pseudonimisering)¶

Stelling: Private partijen mogen het BSN niet verwerken (Wabb art. 10). Het GBO levert aan private afnemers uitsluitend sectorale of context-specifieke pseudoniemen; de BSN-koppeling blijft binnen de vertrouwde kern. NB: als private partijen een wettelijke grondslag hebben om het BSN wel te verwerken, kan dit wel gedeeld worden.

Bronnen:
- Wet algemene bepalingen BSN (Wabb) art. 10
- AVG art. 25 (pseudonimisering)
- BSNk / Polymorfe pseudonimisering

Overzichtstabel¶

ID	Principe	Cluster	Primair kader
P-01	Grondslag vóór uitwisseling	Privacy & gegevensbescherming	AVG
P-02	Minimale gegevensverwerking	Privacy & gegevensbescherming	AVG
P-03	Privacy by design & by default	Privacy & gegevensbescherming	AVG
P-04	BSN-loos voor private afnemers	Privacy & gegevensbescherming	Wabb / AVG
P-05	Erkende authenticatiemiddelen op passend niveau	Identiteit & vertrouwen	Wdo / eIDAS2
P-06	Ondersteuning EUDIW	Identiteit & vertrouwen	eIDAS2 / ARF
P-07	Vertrouwensstelsel PKI & toetredingseisen	Identiteit & vertrouwen	Wdo / PKI
P-08	Eenmalige vastlegging, meervoudig gebruik	Gegevensuitwisseling	NORA / FDS
P-09	Open standaarden & leveranciersonafhankelijkheid	Gegevensuitwisseling	NORA / Data Act
P-10	Datasoevereiniteit: bronhouder behoudt regie	Gegevensuitwisseling	DGA / Data Act
P-11	FAIR-principes voor gegevens	Gegevensuitwisseling	NORA / FAIR
P-12	Logging & onweerlegbaarheid	Logging, audit & transparantie	AVG / NORA
P-13	Transparantie & inzage voor de burger	Logging, audit & transparantie	AVG / Regie op Gegev.
P-14	Scheiding generieke en niet-generieke functies	Architectuur & governance	NORA / GDI
P-15	Ontkoppeling voor wendbaarheid en robuustheid	Architectuur & governance	NORA / GDI
P-16	Eerlijke toegang voor private partijen	Architectuur & governance	DGA / Wabb / DvTP

Ontwerpprincipes GBO — Gegevensuitwisseling¶

Selectie van de meest relevante ontwerpprincipes voor de inrichting van het GBO-stelsel. Waar de architectuurprincipes de wat en waarom beschrijven, geven deze ontwerpprincipes richting aan de hoe — de concrete keuzes bij het bouwen van het stelsel.

Kader 1 — GDI / Gemeenschappelijke Overheidsarchitectuur (GA)¶

D-01 · Decentraal wat kan, centraal wat moet¶

Betekenis:
Taken, bevoegdheden en voorzieningen worden belegd op het laagst mogelijke niveau dat nog doelmatig en doeltreffend is. Centrale voorzieningen worden ingericht als decentrale alternatieven aantoonbaar onvoldoende zijn — bijvoorbeeld vanwege schaalniveau, interoperabiliteitseisen of beveiligingsrisico's. Voor de GBO betekent dit: generieke functies (authenticatie, toegang, bronontsluiting) worden centraal ingericht; domeinspecifieke functies mogen bij de betrokken partij blijven.

Toelichting voor GBO:
Bronhouders beheren zelf hun gegevens. Het GBO-stelsel biedt een centrale integratielaag, maar geen centrale gegevensopslag. Keuzes voor centrale voorzieningen worden expliciet gemotiveerd, maar kunnen ook op verzoek van bronhouders gemaakt worden.

Bronnen:
- Gemeentewet art. 117 lid 2 / Provinciewet art. 115 lid 2 (subsidiariteitsbeginsel)
- Code Interbestuurlijke Verhoudingen — "Decentraal wat kan, centraal wat moet"
- GDI-Meerjarenvisie 2024–2028 (Bureau MIDO / BZK)
- Architectuur Digitale Overheid 2030

D-02 · Afspraken gaan boven standaarden, standaarden gaan boven voorzieningen¶

Betekenis:
De voorkeursvolgorde bij het realiseren van een generieke functie is:
1. Afspraken — onderlinge afspraken tussen partijen zijn de lichtste en meest flexibele vorm; 2. Standaarden — als afspraken onvoldoende zijn, wordt een formele standaard vastgesteld; 3. Voorzieningen — pas als standaarden niet volstaan, wordt een gedeelde technische voorziening ingericht.

Dit principe voorkomt dat er onnodig zware centrale voorzieningen worden gebouwd die innovatie remmen en afhankelijkheden creëren.

Toelichting voor GBO:
Kies bij elke nieuwe GBO-functie eerst de lichtste adequate oplossing. Sla stappen niet over. Documenteer waarom een hogere trede nodig is.

Bronnen:
- GA Basisprincipes — principe D (NORA Online / Bureau MIDO)
- MIDO-kader 2024 — principe "afspraken boven standaarden boven voorzieningen"
- GDI Meerjarenvisie 2024–2028, §4 (principe U)
- Computable / Manifestgroep: 'Afspraken boven standaarden boven voorzieningen' (2017)
- Digitaleoverheid.nl — GDI-beschrijving bouwstenentypen

D-03 · Gebruik landelijke generieke voorzieningen (GDI-bouwstenen) tenzij…¶

Betekenis:
Overheidsorganisaties maken bij voorkeur gebruik van beschikbare GDI-bouwstenen (DigiD, eHerkenning, Digikoppeling, MijnOverheid, etc.) in plaats van eigen parallelle voorzieningen te bouwen. Afwijken is alleen toegestaan als de GDI-bouwsteen aantoonbaar niet voldoet aan de functionele of wettelijke eisen, en wordt gemotiveerd conform 'pas toe of leg uit'.

Toelichting voor GBO:
Voor authenticatie: DigiD / eHerkenning / EUDIW. Voor transport: Digikoppeling REST-profiel. Voor gegevensuitwisseling: Digilevering/Digipoort waar van toepassing. Eigen voorzieningen zijn aanvullend, niet vervangend.

Bronnen:
- GDI-Meerjarenvisie 2024–2028 (Bureau MIDO)
- GDI Programmeringsplan 2024 (Rijksoverheid / MIDO)
- Digitaleoverheid.nl — GDI bouwstenoverzicht
- NORA — gebruik generieke bouwstenen (BP07)

D-04 · Robuust, modulair en flexibel ontwerp¶

Betekenis:
Het stelsel is opgebouwd uit losgekoppelde, vervangbare modules met heldere interfaces. Elk component kan onafhankelijk worden doorontwikkeld of vervangen zonder andere componenten te raken. Het stelsel heeft geen single point of failure en is ontworpen op continuïteit.

Toelichting voor GBO:
Pas een gelaagde componentarchitectuur toe conform het NORA Vijflaagsmodel (interactie, procesinrichting, integratie, diensten, gegevensbronnen). Definieer expliciete API-contracten tussen lagen. Sla geen gegevens op die ook real-time bij de bron bevraagd kunnen worden.

Bronnen:
- GA Basisprincipes — principe V (Bureau MIDO)
- GDI-Meerjarenvisie 2024–2028
- NORA Vijflaagsmodel (noraonline.nl)
- GEMMA Informatiearchitectuurprincipes — componentgebaseerd werken (VNG Realisatie)

Kader 2 — NORA (Nederlandse Overheid Referentie Architectuur)¶

De NORA is het overkoepelende architectuurkader voor de gehele Nederlandse overheid en daarmee het primaire inhoudelijke kader voor GBO na GDI. De principes die eerder onder Common Ground (VNG/GEMMA) waren ondergebracht, zijn hier opgenomen: de Common Ground informatiearchitectuurprincipes zijn in 2024/2025 formeel opgegaan in de vernieuwde GEMMA-architectuurprincipes, die onderdeel uitmaken van de NORA-familie. Waar relevant wordt de GEMMA-herkomst van een principe in de bronnen vermeld.

D-05 · Gegevens bij de bron — geen onnodige kopieën¶

Betekenis:
Gegevens worden zoveel mogelijk real-time bevraagd bij de bronhouder via API's, in plaats van gekopieerd naar lokale registers of tussenopslagplaatsen. Kopieën zijn tijdelijke uitzonderingen die expliciet worden gemotiveerd (bijv. technische onmogelijkheid van real-time bevraging) en worden beheerst.

Toelichting voor GBO:
Het GBO fungeert als integratielaag, niet als gegevensmagazijn. Bronhouders (BRP, Belastingdienst, UWV, DUO, BAG/BRK) worden bevraagd via de gemeenschappelijke bronontsluiting-API. Tussenopslag is alleen toegestaan als performance of beschikbaarheid dit vereist, met expliciete AVG-grondslag.

Bronnen:
- NORA NAP12 — Informeer bij de bron (noraonline.nl)
- GEMMA Informatiearchitectuurprincipes — eenmalige vastlegging (VNG Realisatie, opgegaan in GEMMA 2024/2025)
- Haal Centraal-programma (VNG Realisatie) — "bevragen bij de bron"
- developer.overheid.nl — Vorderingenoverzicht Rijk (casestudy)

D-06 · Componentgebaseerd werken — herbruikbare bouwstenen¶

Betekenis:
Functionaliteit wordt opgesplitst in kleine, herbruikbare componenten die elk één verantwoordelijkheid hebben (single responsibility). Componenten zijn interoperabel via gestandaardiseerde API's en kunnen door verschillende afnemers worden hergebruikt zonder afhankelijkheid van één leverancier.

Toelichting voor GBO:
Denk aan afzonderlijke componenten voor: authenticatie, toestemmingsbeheer, bronontsluiting per registratie, pseudoniemvertaling, logging. Elk component heeft een eigen beheerder en een stabiel API-contract.

Bronnen:
- NORA NAP07 — Bouw diensten modulair op (noraonline.nl)
- NORA Vijflaagsmodel — serviceoriëntatie als leidende architectuurstijl
- GEMMA Informatiearchitectuurprincipes — componentgebaseerd werken (VNG Realisatie, opgegaan in GEMMA 2024/2025)

D-07 · Open source tenzij er zwaarwegende redenen zijn om dat niet te doen¶

Betekenis:
Componenten en standaarden worden bij voorkeur als open source ontwikkeld en gepubliceerd, zodat samenwerking, hergebruik en transparantie worden bevorderd. Hierdoor neemt de kans op vendor lock-in af en kunnen marktpartijen en andere overheden bijdragen.

Bronnen:
- NORA — gebruik open standaarden en open source (noraonline.nl)
- Werkagenda Waardengedreven Digitaliseren (BZK)
- GEMMA Realisatieprincipes — "Open Source Software wordt gestimuleerd" (VNG Realisatie)

D-13 · Standaardiseer waar mogelijk, maak uitzonderingen expliciet¶

Betekenis:
Hergebruik van bestaande standaarden, patronen en voorzieningen heeft sterk de voorkeur boven het ontwikkelen van nieuwe oplossingen. Als een uitzondering nodig is, wordt deze gedocumenteerd als architectuurbeslissing (ADR — Architecture Decision Record) met een onderbouwde motivatie.

Toelichting voor GBO:
Stel een ADR-register bij als onderdeel van de GBO-documentatie. Elke afwijking van een verplichte standaard of een vastgesteld architectuurprincipe krijgt een eigen ADR met: context, beslissing, overwogen alternatieven, en consequenties.

Bronnen:
- NORA BP09 — Pas open standaarden toe
- NORA Architectuurprincipes (noraonline.nl)
- GA Basisprincipes — principe D & H (Bureau MIDO)

D-14 · Interoperabiliteit — semantische en technische afstemming¶

Betekenis:
Gegevens die via het GBO worden uitgewisseld, zijn semantisch eenduidig vastgelegd en zijn zoveel mogelijk gebaseerd op bestaande informatiemodellen (waaronder GGM, NEN3610 en IMGeo) en bijbehorende standaarden voor datamodellering en ontologieën (zoals MIM, UML en RDF/SHACL). Technische koppelvlakken zijn gebaseerd op deze informatiemodellen en gespecificeerd volgens de OpenAPI Specification, waardoor afnemers gegevens machineleesbaar kunnen verwerken zonder aanvullende interpretatie.

Bronnen:
- NORA Domeinarchitectuur Gegevensuitwisseling — semantiek & validatie
- Gemeentelijk Gegevensmodel (GGM) — VNG
- Forum Standaardisatie — standaarden voor semantische interoperabiliteit
- EU Interoperabiliteitsraamwerk (EIF) / Interoperable Europe Act

Kader 3 — Forum Standaardisatie / Kennisplatform API's¶

D-08 · Pas toe of leg uit — verplichte open standaarden¶

Betekenis:
Overheidsorganisaties zijn verplicht de open standaarden op de 'pas toe of leg uit'-lijst van Forum Standaardisatie toe te passen. Afwijken is alleen toegestaan als er een zwaarwegende en gedocumenteerde reden is. Voor het GBO gelden in elk geval als verplicht: REST API Design Rules, NL GOV OAuth 2.0-profiel, NL GOV OIDC-profiel, Digikoppeling, MIM, DCAT2, SHACL en — zodra beschikbaar — OID4VC/OID4VP.

Toelichting voor GBO:
Neem in het stelselontwerp een expliciete mapping op van GBO-koppelvlakken naar verplichte standaarden. Documenteer elk koppelvlak dat afwijkt van de 'pas toe'-standaard.

Bronnen:
- Forum Standaardisatie — 'Pas toe of leg uit'-lijst
- Logius API-standaarden: REST API Design Rules, NL GOV OAuth 2.0, NL GOV OIDC
- GDI-Meerjarenvisie 2024–2028 — collectieve voorzieningen "pas toe of leg uit"
- NORA BP09 — Pas open standaarden toe

D-09 · API-first — ontsluiting via gestandaardiseerde API's¶

Betekenis:
Elke GBO-functie en elke bronontsluiting wordt primair aangeboden als een goed gedocumenteerde, versie-beheerde API. De API is het primaire koppelvlak; gebruikersinterfaces en batchprocessen zijn secundair. API's worden ontworpen conform de NLGov REST API Design Rules.

Toelichting voor GBO — REST vs. GraphQL: De NLGov REST API Design Rules zijn verplicht ('pas toe of leg uit') voor REST-API's. GraphQL valt buiten deze verplichting maar is niet verboden. Een keuze voor GraphQL vereist:
- Expliciete motivatie (bijv. flexibele selectie van attributen reduceert dataminimalisatierisico's);
- Aantoonbare naleving van vergelijkbare beveiligings-, autorisatie- en auditprincipes;
- Documentatie conform OpenAPI Specification of vergelijkbaar schema.

Overweeg een hybride aanpak: REST-endpoints voor standaard bevragingen (conform verplichte standaard), GraphQL voor flexibele attribuutselectie door afnemers.

Bronnen:
- NLGov REST API Design Rules (Forum Standaardisatie, verplicht 'pas toe of leg uit' — Logius)
- Kennisplatform API's (developer.overheid.nl)
- GEMMA Informatiearchitectuurprincipes — "maximaal openstellen voor hergebruik via API's"
- EU Open Data Richtlijn — API-verplichting voor overheidsdata (art. 5)

Kader 4 — Informatiebeveiliging & Privacy (BIO / AVG / NIS2)¶

D-10 · Informatiebeveiliging en privacy by design¶

Betekenis:
Beveiligings- en privacymaatregelen worden vanaf het eerste ontwerp ingebakken in het stelsel — niet achteraf toegevoegd als laag. Dit omvat: minimale gegevensverwerking, pseudonimisering, toegangsbeperking op need-to-know-basis, encryptie in transit en at rest, en expliciete beveiligingsarchitectuur per component.

Toelichting voor GBO:
Voer voor elk nieuw component een Data Protection Impact Assessment (DPIA) uit. Stel een expliciete beveiligingsclassificatie vast per gegevenstype. Ontwerp de toegangslaag op basis van zero-trust-principes (geen impliciete vertrouwensrelaties tussen componenten).

Bronnen:
- AVG art. 25 — privacy by design & by default
- BIO2 (Baseline Informatiebeveiliging Overheid 2) — gebaseerd op ISO/IEC 27001:2022 & 27002:2022
- GA Basisprincipes — principe H (privacy by design, security by design)
- NIS2-richtlijn (EU) 2022/2555 — verplichting beveiligingsmaatregelen vitale infrastructuur
- Cyberbeveiligingswet (Cbw, implementatie NIS2)

D-11 · Least privilege — toegang op basis van minimale rechten¶

Betekenis:
Elke afnemer, component en beheerder krijgt uitsluitend de toegang die strikt noodzakelijk is voor de uit te voeren taak. Autorisaties zijn granulaar, tijdgebonden en worden actief ingetrokken als ze niet meer nodig zijn. Er zijn geen statische 'admin'-accounts met brede rechten.

Toelichting voor GBO:
Implementeer OAuth 2.0-scopes per API-endpoint en per gegevenstype. Koppel autorisaties aan grondslag en doelbinding (zie architectuurprincipe P-01). Log elke autorisatiebeslissing.

Bronnen:
- BIO2 — toegangsbeheer (ISO 27002 domein 8)
- NL GOV Assurance profile for OAuth 2.0 (Logius)
- AVG art. 5 lid 1 sub b (doelbinding) & sub c (dataminimalisatie)

D-12 · Aantoonbare veiligheid — audit en pen-testing¶

Betekenis:
De beveiliging van het stelsel wordt periodiek getoetst door onafhankelijke audits en penetratietests. Bevindingen worden transparant gerapporteerd en aantoonbaar opgevolgd. Het stelsel voldoet aan de BIO2-normen en — voor vitale functies — aan de eisen van de Cyberbeveiligingswet.
Ook deelnemers moeten aantoonbaar voldoen aan beveiligings- en privacy-eisen bij aansluiting op het stelsel.

Bronnen:
- BIO2 (Baseline Informatiebeveiliging Overheid 2) — risicomanagement & audit
- NIS2-richtlijn / Cyberbeveiligingswet — zorgplicht en meldplicht
- ISO/IEC 27001:2022 — ISMS-certificering

Overzichtstabel¶

ID	Principe	Cluster	Primair kader
D-01	Decentraal wat kan, centraal wat moet	Governance & organisatie	GDI / GA / Gemeentewet
D-02	Afspraken > standaarden > voorzieningen	Governance & organisatie	GDI / GA (MIDO)
D-03	Gebruik landelijke GDI-bouwstenen tenzij…	Governance & organisatie	GDI / NORA
D-04	Robuust, modulair en flexibel ontwerp	Technische architectuur	GDI / NORA
D-05	Gegevens bij de bron — geen onnodige kopieën	Gegevensarchitectuur	NORA (NAP12) / GEMMA
D-06	Componentgebaseerd werken — herbruikbare bouwstenen	Technische architectuur	NORA (NAP07) / GEMMA
D-07	Open source tenzij zwaarwegende redenen	Technische architectuur	NORA / BZK
D-08	Pas toe of leg uit — verplichte open standaarden	Standaarden & koppelvlakken	Forum Standaardisatie
D-09	API-first — NLGov REST API Design Rules (en GraphQL-afweging)	Standaarden & koppelvlakken	Forum Standaardisatie / EU
D-10	Informatiebeveiliging en privacy by design	Beveiliging & privacy	BIO2 / AVG / NIS2
D-11	Least privilege — toegang op basis van minimale rechten	Beveiliging & privacy	BIO2 / OAuth / AVG
D-12	Aantoonbare veiligheid — audit en pen-testing	Beveiliging & privacy	BIO2 / NIS2 / Cbw
D-13	Standaardiseer waar mogelijk, uitzonderingen expliciet (ADR)	Kwaliteit & beheersbaarheid	NORA / GA
D-14	Interoperabiliteit — semantische en technische afstemming	Kwaliteit & beheersbaarheid	NORA / EIF

Noot: REST vs. GraphQL voor het GBO¶

De NLGov REST API Design Rules staan verplicht op de 'pas toe of leg uit'-lijst en zijn van toepassing als REST wordt ingezet. De standaard verplicht het gebruik van REST zelf niet — het gebruik van GraphQL is daarmee formeel niet in strijd.

Voor het GBO is een hybride aanpak verdedigbaar:

Criterium	REST (NLGov ADR)	GraphQL
Verplichte standaard	Ja (bij gebruik van REST)	Nee (geen verplichte NL Gov-standaard)
Dataminimalisatie	Vaste response-structuur	Client selecteert exact benodigde velden
Beveiligingsvolwassenheid	Hoog (OAuth 2.0-profiel beschikbaar)	Gemiddeld (vereist extra scope-mapping)
Tooling & ecosystem	Breed beschikbaar	Breed, maar minder overheid-specifiek
Aanbeveling GBO	Standaard externe ontsluiting	Optioneel voor interne/flexibele queries

Ecosysteem en oplossingsrichting¶

Actoren¶

De volgende actoren spelen een rol bij het delen van gegevens in de context die eerder is beschreven:

Burger

De burger is de persoon om wiens gegevens het gaat en die de gegevens wil gebruiken om een dienst af te kunnen nemen. De burger is echter niet de eigenaar van de gegevens: dat is de bronhouder. Om de gegevens van de bronhouder te gebruiken moet de burger daartoe toestemming geven, of moet er sprake zijn van een andere grondslag.

Bronhouder

De bronhouder is de eigenaar en beheerder van de gegevens. Deze gegevens zijn verzameld voor een bepaald doel en mogen alleen voor een ander doel gebruikt worden als de burger daartoe toestemming heeft gegeven. In sommige gevallen is zelfs dat niet mogelijk en moet er mogelijk wet- en regelgeving aangepast worden.

Wallet

De Wallet is een voorziening (vaak een mobiele app) waarmee de burger eigen persoonsgegevens in digitale en gewaarmerkte vorm kan beheren en kan hergebruiken. De feitelijke actor is dus de burger, maar nu in de rol van gegevensverwerker.

Private partij

De private partij is een organisatie die een dienst aan de burger levert en daarvoor persoonsgegevens nodig heeft. Deze gegevens komen uit een overheidsbron, waar de private partij geen rechtstreekse toegang toe heeft.

SDG/OOTS

SDG/OOTS (Single Digital Gateway / Once Only Technical System) is een Europese voorziening waarmee Europese overheden gegevens uit overheidsbronnen van andere Europese lidstaten kan opvragen. De feitelijke actor is dan de overheidsfunctionaris die een persoonsgegeven nodig heeft voor het leveren van een dienst aan een burger die in het buitenland is.

GBO stelsel

Om de gegevens uit te wisselen zijn afspraken nodig en mogelijk een of enkele voorzieningen. Deze afspraken en eventuele voorzieningen worden beheerd in een stelsel. In dit document wordt dit stelsel het "GBO stelsel" genoemd, maar in de praktijk is het de bedoeling dat de afspraken en eventuele voorzieningen worden ondergebracht bij bestaande stelsel en/ of organisaties.

Contextdiagram¶

In de contextdiagram worden de actoren ten opzichte van elkaar en van het GBO stelsel geschetst.


flowchart LR

Bronhouder
DvTP["GBO stelsel
(afspraken, standaarden, voorzieningen)"]
Wallet
Privaat["Private partij"]
SDG["SDG/OOTS"]

Bronhouder --> DvTP
DvTP --> Wallet
DvTP --> Privaat
DvTP --> SDG

Contextdiagram

Oplossingsrichting¶

Zoals in de contextdiagram wordt geschetst worden de gegevens van de bronhouder via het GBO stelsel voor drie doelen gebruikt. Dit ontlast de bronhouder en maakt hergebruik van gegevens eenvoudiger. Ook als er meer doelen bijkomen vormt deze opzet een oplossing die hergebruikt kan worden.

Om deze oplossing mogelijk te maken zal het stelsel een aantal interactiepatronen moeten ondersteunen. Het achterhalen van deze interactiepatronen gebeurt via use cases, die in de bijlage zijn uitgewerkt. De interactiepatronen worden in het volgende hoofdstuk besproken.

In het volgende hoofdstuk worden eerst de kaders van de oplossing besproken: de architectuur- en ontwerpprincipes waar de oplossing rekening mee moet houden.

Interactiepatronen GBO¶

Dit document beschrijft de belangrijkste interactiepatronen voor GBO zoals afgeleid uit de use cases. In de patronen is op verschillende plekken sprake van een "dienst"; dit kunnen standaarden of centrale of decentrale voorzieningen zijn. Daar wordt in het hoofdstuk Capabilities dieper op ingegaan.

Gegevensverzoek van private partij met toestemming aan bronhouder (DvTP)¶

Doel¶

Een private dienstverlener haalt gegevens op bij een bronhouder op basis van een geldige toestemming van de burger.

Interactie¶


sequenceDiagram
    autonumber
    actor Burger
    participant DV as Dienst-<br/>verlener
    participant Auth as Authenticatie-<br/>dienst
    participant TV as Toestemmings-<br/>voorziening (GBO)
    participant PP as BSNk PP<br/>(pseudonimisering)
    participant TR as Toestemmings-<br/>register
    participant BRH as Bron-<br/>houder

    Note over Burger,BRH: Fase 1 — Toestemming verlenen

    rect rgb(225, 245, 238)
        Burger->>DV: Neemt dienst af
        DV->>Burger: Redirect naar toestemmingsvoorziening GBO<br/>(met scope + doelbinding)
        Burger->>TV: Volgt redirect
        TV->>Auth: Authenticatieverzoek
        Note over Auth: DigiD óf EDI-Wallet (eIDAS 2.0)
        Auth->>Burger: Authenticeer burger
        Burger-->>Auth: Authenticatie
        Auth-->>TV: BSN (geverifieerde identiteit)
        TV->>PP: Pseudonimiseer BSN<br/>(BSNk PP)
        PP-->>TV: Pseudoniem (PP-id)
        TV->>Burger: Toon gegevens waarvoor toestemming<br/>gevraagd wordt (scope + doelbinding)
        Burger-->>TV: Verleent toestemming
        TV->>TR: Schrijf toestemming in register<br/>(PP-id · scope · doelbinding · TTL)
        TR-->>TV: consent_id
        TV->>Burger: Redirect terug naar dienstverlener<br/>(met consent_id)
        Burger->>DV: Volgt redirect (consent_id)
    end

    Note over DV,BRH: Fase 2 — Gegevensopvraging bij bronhouder

    rect rgb(238, 237, 254)
        DV->>BRH: Gegevensverzoek<br/>(consent_id · mTLS / certificaat)
        BRH->>BRH: Authenticeer dienstverlener<br />(via certificaat)
        BRH->>BRH: Controleer bevoegdheid<br />(via FSC contract/Trusted List)
        BRH->>TR: Valideer consent_id<br/>(geldig? scope? TTL?)
        TR-->>BRH: Consent geldig + PP-id
        BRH->>PP: De-pseudonimiseer PP-id<br/>(BSNk PP)
        PP-->>BRH: BSN
        BRH->>BRH: Controleer data scope<br />(template match)
        BRH-->>DV: Gevraagde gegevens<br/>(gezegeld door bronhouder)
    end

Interactiepatroon Private Partij haalt gegevens op met toestemming van de burger

Toelichting¶

De dienstverlener kan rechtstreeks gegevens opvragen bij de bronhouder, maar heeft daarvoor toestemming van de burger nodig. Deze toestemming wordt door GBO afgehandeld via een toestemmingsvoorziening (een interface waar de burger vrij, specifiek, geïnformeerd en ondubbelzinnig de toestemming verleent) en een toestemmingsregister waar de toestemming wordt vastgelegd en waar deze gecontroleerd kan worden. De toestemmingsvoorziening moet de burger ook toegang geven tot de gegeven toestemmingen om te zien of die is gebruikt en om deze - indien relevant - in te trekken.

De dienstverlener gebruikt nooit het BSN van de burger. Daarom moet deze gepseudonimiseerd worden. De pseudonimisering moet zo gebeuren dat de dienstverlener deze telkens kan depseudonimiseren naar een eigen identificatie, die echter geen betekenis heeft voor andere partijen. De bronhouder moet het pseudoniem kunnen depseudonimiseren naar het originele BSN.

Bij controle van de gegevensvraag door de dienstverlener bij de bronhouder, authenticeert de bronhouder de dienstverlener op basis van het certificaat dat ook voor de versleuteling van het transport (mTLS) gebruikt wordt. Daarnaast moet de bronhouder controleren of de dienstverlener bevoegd is om gegevens op te vragen. Dat kan via FSC-contracten - de dienstverlener moet een contract hebben afgesloten om de API van de bronhouder te mogen bevragen. Dit kan ook op basis van een lijst met bevoegde afnemers (Trusted List). Zo'n lijst kan sectoraal beheerd worden, wat voorkomt dat een bronhouder met heel veel afnemers (bv. alle hypotheekverstrekkers) contracten moet afsluiten en beheren.

Gegevensverzoek van burger om gegevens via wallet te delen¶

Doel¶

Een burger vraagt een gegeven op als gekwalificeerd elektronisch attest van een attribuut om in zijn/haar wallet op te nemen en te delen met een dienstverlener.

Interactie¶


sequenceDiagram
    autonumber
    actor Burger
    participant Wallet as EDI-Wallet
    participant QTSP as QTSP
    participant VerifDienst as Verificatie-<br/>dienst
    participant PubEAA as PuB-EAA<br/>voorziening
    participant Bron as Overheids-<br/>bron
    participant DV as Dienst-<br/>verlener

    Note over Burger,Bron: Stroom A — PuB-EAA: overheidsinstantie geeft attribuut rechtstreeks uit

    rect rgb(225, 245, 238)
        Burger->>Wallet: Vraag attribuut op (OID4VCI initiate)
        Wallet->>PubEAA: Credential Request (OID4VCI)
        Note over PubEAA: PuB-EAA voorziening: aangeboden<br/>door bron zelf óf centraal via GBO
        PubEAA->>Wallet: Authenticatieverzoek
        Wallet->>Burger: Authenticatieverzoek
        Wallet->>PubEAA: Athenticatie (met BSN)
        PubEAA->>Bron: Bevraag bron
        Bron-->>PubEAA: Attribuutgegevens
        PubEAA->>PubEAA: Kwalificeer attribuutgegevens
        PubEAA-->>Wallet: PuB-EAA credential<br/>(SD-JWT VC · ISO 18013-5,<br/>gezegeld door overheidsinstantie)
        Wallet-->>Burger: PuB-EAA opgeslagen in wallet
    end

    Note over Burger,Bron: Stroom B — QEAA: QTSP kwalificeert attribuut via verificatiedienst

    rect rgb(238, 237, 254)
        Burger->>Wallet: Vraag attribuut op (OID4VCI initiate)
        Wallet->>QTSP: Credential Request (OID4VCI)
        QTSP->>Wallet: Authenticatieverzoek
        Wallet->>Burger: Authenticatieverzoek
        Wallet->>QTSP: Athenticatie (met BSN)
        Note over QTSP: QTSP verifieert attribuut<br/>via verificatiedienst
        QTSP->>VerifDienst: Verificatieverzoek
        Note over VerifDienst: Verificatiedienst: aangeboden<br/>door bron of centraal via GBO
        VerifDienst->>Bron: Bevraag bron
        Bron-->>VerifDienst: Attribuutgegevens
        VerifDienst-->>QTSP: Geverifieerd attribuut
        QTSP-->>Wallet: QEAA credential<br/>(SD-JWT VC · ISO 18013-5,<br/>QES/QESeal door QTSP)
        Wallet-->>Burger: QEAA opgeslagen in wallet
    end

    Note over Burger,DV: Gebruik — burger deelt credential met dienstverlener

    rect rgb(250, 238, 218)
        Burger->>DV: Deel credential (OID4VP)
        DV->>DV: Controleer credential
        Note over DV: PuB-EAA of QEAA,<br/>gelijke juridische status (eIDAS 2.0)
    end

Gegevensverzoek van burger om credential via wallet te delen

Toelichting¶

Iedere bronhouder kan in theorie gegevens uitleveren aan wallets, maar deze gegevens krijgen pas juridische waarde als ze gekwalificeerd zijn. Dat kwalificeren kan op twee manieren: de overheid ondertekent het gegeven, waardoor het een PuB-EAA wordt, of een gekwalificeerde verlener van vertrouwensdiensten (QTSP).
Als de overheid het gegeven kwalificeert kan de bronhouder dit zelf doen, maar het kan schaalvoordeel bieden om dit te centraliseren in een GBO PuB-EAA-dienst. Als een QTSP het gegeven kwalificeert, moet deze QTSP het gegeven kunnen verifiëren via een verificatiedienst. Ook hier kan een bronhouder de dienst zelf aanbieden, of kan ervoor gekozen worden om dit te centraliseren in een GBO verificatiedienst.

Gegevensverzoek van Europese overheidsdienst aan Nederlandse overheidsbron¶

Doel¶

Een Europese overheidsdienst vraagt een gegeven (Evidence Request) aan een Nederlandse overheidsbron om een dienst aan een Nederlandse burger te kunnen leveren.

Interactie¶


sequenceDiagram
    autonumber
    participant EU as EU dienst<br/>(SDG/OOTS)
    participant RINIS as RINIS<br/>(nationaal OOTS-punt)
    participant GBO as GBO<br/>(GBO voorziening)
    participant BRG as Burger<br/>(rechthebbende)
    participant BRH as Bronhouder<br/>(BRP / DUO / …)

    rect rgb(230, 241, 251)
        Note over EU,RINIS: ① Ontvangst OOTS-verzoek (eDelivery/AS4)
        EU->>RINIS: Evidence Request (eDelivery/AS4)
        Note over RINIS: eDelivery → REST ontkoppeling
    end

    rect rgb(250, 238, 218)
        Note over RINIS,GBO: ② Doorzetten naar GBO (nationaal)
        RINIS->>GBO: OOTS-payload (REST/JSON)
    end

    rect rgb(238, 237, 254)
        Note over GBO,BRG: ③ Toestemming burger (GBO)
        GBO->>BRG: Toestemmingsvoorziening (GBO)
        BRG->>GBO: Toestemming + Consent-ID (incl. BSN)
    end

    rect rgb(250, 238, 218)
        Note over GBO: ④ Identiteit & grondslag (intern GBO)
        Note over GBO: BSN · pseudonimisering · AVG/grondslag
    end

    rect rgb(225, 245, 238)
        Note over GBO,BRH: ⑤ Bronontsluiting (GBO generieke API)
        GBO->>BRH: API-aanroep (GBO-formaat)
        BRH->>GBO: Gegevens (JSON/REST)
    end

    rect rgb(250, 238, 218)
        Note over GBO: ⑥ Semantische mapping & logging (intern GBO)
        Note over GBO: GBO-formaat → SDG Evidence type · audit log · doelbinding
    end

    rect rgb(230, 241, 251)
        Note over GBO,EU: ⑦ Terugkoppeling via RINIS naar EU
        GBO->>RINIS: Evidence Response (REST/JSON)
        Note over RINIS: REST → eDelivery inpakken
        RINIS->>EU: Evidence Response (AS4/eDelivery)
    end

Interactiepatroon gegevensverzoek Europese overheidsdienst via SDG/OOTS

Toelichting¶

RINIS is het nationale toegangspunt voor eDelivery en verzorgt de basisinrichting OOTS — het Nederlandse toegangspunt en de generieke koppelingen met gerelateerde systemen. Dit is een transportrol: RINIS spreekt het AS4/eDelivery-protocol richting de EC Common Services, en vertaalt dit naar een nationaal berichtformaat.
GBO is een verwerkingsrol: identiteit, grondslag, toestemming, bronontsluiting, semantiek. Dit zijn inhoudelijke functies, geen transport.

De praktische knip zit op het grenswerk tussen fase 1 en fase 2 in het diagram: RINIS ontvangt het AS4-bericht van buiten, pakt de OOTS-payload uit en geeft die als REST-aanroep door aan GBO. Bij de terugkoppeling (fase 7) geldt het omgekeerde: GBO geeft de Evidence Response terug aan RINIS, die het opnieuw inpakt in AS4 voor verzending. Bronhouders zien uitsluitend de GBO-API — OOTS-kennis is voor hen niet nodig.

NB: Openstaand architectuurvraagstuk is nog waar de OOTS-specifieke toestemmingsflow (het "preview"-scherm dat de burger het bewijsstuk laat zien vóór afgifte, verplicht per SDG-verordening) belegd wordt. Momenteel zit dit in de RINIS-basisinrichting. Als GBO de toestemming afhandelt, moeten we afspreken of het OOTS-preview-scherm bij RINIS blijft of naar GBO verschuift — dat raakt de verantwoordelijkheidsverdeling tussen de twee voorzieningen.

Logische architectuur (generieke functies)¶

De oplossingsrichting met gemeenschappelijke bronontsluiting wordt gerealiseerd door generieke functies.

Logisch architectuurdiagram¶

Het logische architectuurdiagram schetst de generieke functies ten opzichte van elkaar.

graph LR
    %% ── Bronhouders (links) ──────────────────────────────────
    subgraph BRH["Bronhouders — generieke zijde"]
        direction TB
        BRP["BRP"]
        BD["Belastingdienst"]
        UWV["UWV"]
        DUO["DUO"]
        BAG["BAG / BRK"]
        OV["Overige bronnen…"]
    end

    %% ── GBO Kern (midden) ────────────────────────────────────
    subgraph GBO["GBO — Generieke Zijde"]
        direction TB

        subgraph TRUST["Juridisch &amp; Identiteit"]
            direction TB
            TG["⚖️ Toestemming &amp; Grondslag\nWdo / AMvB / AVG"]
            BI["🪪 Burgeridentificatie\nBSN · pseudonimisering"]
            VS["🔐 Vertrouwensstelsel\nPKI(O) · eHerkenning · eIDAS · TIP"]
        end

        subgraph FUNC["Generieke functies — GBO"]
            direction LR
            F1["Identiteit &amp; Vertrouwen\nID · Authc · Authz · PKI · Audit logging"]
            F2["Toegang &amp; Interactie\nSSO · Federatief inloggen · Consent UI · Machtigen"]
            F3["Gegevensvoorziening\nConnectiviteit · Lokalisatie · API-beheer · Raadplegen"]
            F4["Semantiek &amp; Eenheid van Taal\nGGM · RDF · OWL · SKOS · JSON-LD · Vocabularia"]
            F5["Gegevenskwaliteit &amp; Validatie\nSHACL · Herkomst · W3C PROV-O · Feedbackloops"]
            F6["Grondslag &amp; Beleid\nConsent · Doelbinding · AVG · Beleidsregels"]
            F7["Orkestratie &amp; Integratie\nProcesorkestratie · mapping · Event-afhandeling"]
            F8["Beheer &amp; Continuïteit\nLogging · Monitoring · Versiebeheer · Incidentbeheer"]
        end

        BRON_API["🔗 Gemeenschappelijke bronontsluiting API\nOAuth 2.0 · REST/GraphQL · Digikoppeling"]
    end

    %% ── Afnemers (rechts) ────────────────────────────────────
    subgraph AFN["Afnemers — specifieke zijde"]
        direction TB
        PP["🏢 Private partijen\nDvTP — toestemming burger"]
        EU["🇪🇺 Europese overheden\nSDG / OOTS"]
        EDI["📱 EDI-Wallet burger\neIDAS2 / ARF"]
    end

    %% ── Burger (onderaan) ────────────────────────────────────
    BRG["👤 Burger — rechthebbende\nRegie op Gegevens · toestemming"]

    %% ── Verbindingen ─────────────────────────────────────────
    BRP -.->|generieke ontsluiting| BRON_API
    BD  -.->|generieke ontsluiting| BRON_API
    UWV -.->|generieke ontsluiting| BRON_API
    DUO -.->|generieke ontsluiting| BRON_API
    BAG -.->|generieke ontsluiting| BRON_API
    OV  -.->|generieke ontsluiting| BRON_API

    BRON_API --> FUNC

    FUNC --> TG
    FUNC --> BI
    FUNC --> VS

    TG -->|DvTP flow| PP
    TG -->|SDG/OOTS| EU
    BI -->|OID4VC| EDI

    TG -->|toestemming| BRG

    %% ── Stijlen ──────────────────────────────────────────────
    classDef afnemer_private fill:#FAECE7,stroke:#993C1D,color:#712B13
    classDef afnemer_eu      fill:#E6F1FB,stroke:#185FA5,color:#0C447C
    classDef afnemer_edi     fill:#E1F5EE,stroke:#0F6E56,color:#085041
    classDef juridisch       fill:#FAEEDA,stroke:#854F0B,color:#633806
    classDef identiteit      fill:#EEEDFE,stroke:#534AB7,color:#3C3489
    classDef generiek        fill:#F1EFE8,stroke:#5F5E5A,color:#444441
    classDef bronontsluiting fill:#EAF3DE,stroke:#3B6D11,color:#27500A
    classDef bronhouder      fill:#EAF3DE,stroke:#3B6D11,color:#27500A
    classDef burger          fill:#EEEDFE,stroke:#534AB7,color:#3C3489

    class PP afnemer_private
    class EU afnemer_eu
    class EDI afnemer_edi
    class TG juridisch
    class BI,VS identiteit
    class F1,F2,F3,F4,F5,F6,F7,F8 generiek
    class BRON_API bronontsluiting
    class BRP,BD,UWV,DUO,BAG,OV bronhouder
    class BRG burger

Architectuuroverzicht GBO

Het diagram onderscheidt drie lagen binnen de GBO:

Juridisch & Identiteit — de grondslag- en vertrouwenslaag die bepaalt wie gegevens mag opvragen en op basis waarvan.
Generieke functies — de acht functionele clusters die de gegevensuitwisseling mogelijk maken.
Bronontsluiting — de generieke API waarmee bronhouders eenmalig hun gegevens beschikbaar stellen.

De generieke functies die het GBO-stelsel moet bieden zijn:

Identiteit & Vertrouwen
Toegang & Interactie
Gegevensvoorziening
Semantiek & Eenheid van Taal
Gegevenskwaliteit & Validatie
Grondslag & Beleid
Orkestratie & Integratie
Beheer & Continuïteit

Vanuit de architectuur- en ontwerpprincipes worden aan deze generieke functies eisen gesteld, die hieronder zijn uitgewerkt. De eisen zijn bewust technologieneutraal geformuleerd; ze beschrijven wat een generieke functie moet kunnen, niet hoe dat gerealiseerd wordt.

Juridisch & Identiteit¶

De vier functies in deze laag vormen de voorwaarden waaronder de generieke functies mogen opereren. Ze zijn geen onderdeel van de gegevensstroom zelf, maar worden door alle generieke functies geraadpleegd.

Toestemming¶

Doel: Vaststellen en beheren van de testemming voor gegevensdeling.

Eisen:

Toestemming van de burger is altijd herleidbaar tot een specifiek doel, een specifieke afnemer, en een specifieke gegevensvraag (doelbinding).
De toestemming is machineleesbaar raadpleegbaar op het moment van gegevensuitvraag — niet alleen vastgelegd in een document of token dat van tevoren is uitgegeven.
Intrekking van toestemming werkt met onmiddellijke ingang: een ingetrokken grondslag leidt bij de eerstvolgende uitvraag automatisch tot weigering, zonder dat daarvoor aparte notificaties of tokeninvalidatie nodig zijn.
De burger heeft inzage in welke toestemmingen namens hem actief zijn en kan deze zelf beheren via een toegankelijke interface.
De vastlegging van toestemmingen voldoet aan de eisen van de AVG, de Wdo en de van toepassing zijnde AMvB's.

Burgeridentificatie¶

Doel: Het vaststellen van de identiteit van de burger ten behoeve van gegevensontsluiting.

Eisen:

De identiteitsvaststelling sluit aan op de voor het traject vereiste betrouwbaarheidsniveaus (eIDAS Laag/Substantieel/Hoog) en maakt gebruik van erkende authenticatiemiddelen.
Voor het EDI-wallet traject ondersteunt de functie het ontvangen van een burgeridentiteit via een wallet-presentatie (conform eIDAS2/ARF), met verificatie via de relevante Trusted List.

Pseudonimisering¶

Doel: Het garanderen dat het BSN uitsluitend circuleert binnen de overheidsinfrastructuur en nooit zichtbaar is voor private afnemers.

Eisen:

Het BSN wordt nooit doorgegeven aan of verwerkt door private dienstverleners. Voor private afnemers wordt altijd een partij-specifiek, onomkeerbaar pseudoniem gebruikt.
Pseudoniemen voor verschillende private partijen zijn niet onderling koppelbaar, ook niet wanneer die partijen samenwerken.
Herhaald gebruik van hetzelfde pseudoniem voor dezelfde burger levert cryptografisch onkoppelbare uitvoer op (geen correlatierisico over tijd).
De omzetting van BSN naar pseudoniem — en terug, aan de bronhouderszijde — vindt plaats in een door de overheid beheerde en gecertificeerde voorziening.

Vertrouwensstelsel & Authenticatie van organisaties¶

Doel: Vaststellen dat een afnemende organisatie (dienstverlener, EU-lidstaat) daadwerkelijk is wie zij zegt te zijn, en bevoegd is om deel te nemen aan het desbetreffende traject.

Eisen:

Iedere deelnemende organisatie is aantoonbaar geregistreerd en geautoriseerd vóór zij gegevens kan opvragen. Onboarding is een expliciete beheerhandeling.
Organisatie-authenticatie is gebaseerd op certificaten uitgegeven door een erkende, toezichthoudende vertrouwensdienstverlener (conform eIDAS of PKI Overheid).
Het vertrouwensstelsel ondersteunt zowel binnenlandse als grensoverschrijdende partijen, waarbij grensoverschrijdend vertrouwen via de Europese Trusted List-infrastructuur wordt verankerd — niet via bilaterale afspraken per traject.
Vertrouwensankers (certificaten, attestaties van gekwalificeerde aanbieders) zijn verificeerbaar zonder afhankelijkheid van de uitgevende partij op het moment van verificatie.
Het vertrouwensstelsel is onafhankelijk van het transportprotocol: dezelfde vertrouwensbeoordeling geldt ongeacht of de verbinding via het binnenlandse koppelnetwerk of via een Europese infrastructuur binnenkomt.

Generieke functie 1 — Identiteit & Vertrouwen¶

Doel: Vaststellen en handhaven van de identiteit van alle deelnemende systemen en organisaties, en borgen van de integriteit en vertrouwelijkheid van de gegevensuitwisseling via PKI en audit logging.

Eisen:

Iedere gegevensuitvraag — ongeacht het traject of de afnemer — doorloopt dezelfde autorisatieketen. Er zijn geen trajectspecifieke omwegen of parallelle handhavingspunten.
Het beleid is uitgedrukt in een formele, machineleesbare taal. Menselijk leesbare beschrijvingen zijn afgeleid van dezelfde bron, niet de bron zelf.
De autorisatiebeslissing is gebaseerd op: de identiteit van de afnemer, de gevraagde gegevens, de aanwezige grondslag (via toestemmingenregister, grondslagenregister of impliciet in request), en de context van het verzoek. Deze vier elementen zijn altijd expliciet aanwezig in de beslissing.
De autorisatiecomponent raadpleegt de toestemming real-time op het moment van uitvraag — er is geen vertrouwen op eerder uitgegeven tokens die de toestemmingsstatus "bevroren" vastleggen.
Beleidsdefinities zijn per traject instelbaar zonder wijziging van de autorisatie-infrastructuur zelf.
De beslissing (allow/deny) en de relevante context worden vastgelegd ten behoeve van auditbaarheid.
BSN-resolving vindt pas plaats na de autorisatiebeslissing (PDP), binnen de handhavingscomponent (PEP) — niet als invoer voor de beleidsevaluatie.

Generieke functie 2 — Toegang & Interactie¶

Doel: De burger geeft geïnformeerde, specifieke toestemming voor gegevensdeling via een toegankelijke interface, en kan die toestemming inzien en intrekken. Organisaties krijgen toegang via federatieve mechanismen (SSO, machtigen).

Eisen:

De toestemmingsinteractie is begrijpelijk voor de burger: doel, afnemer en gegevens zijn in gewone taal gepresenteerd, niet in technische of juridische termen.
De burger authenticeert zich op een betrouwbaarheidsniveau dat passend is bij de gevoeligheid van de betrokken gegevens.
Na het geven van toestemming ontvangt de burger een bevestiging, en kan hij via dezelfde of een gelijkwaardige interface zijn actieve toestemmingen inzien en intrekken.
De UI-component schrijft de vastgelegde toestemming weg naar het toestemmingenregister, zodat de autorisatiecomponent deze real-time kan raadplegen.
De pseudonimiseringsactie (BSN → pseudoniem voor de afnemer) vindt plaats als onderdeel van het toestemmingsproces, transparant voor de burger en zonder dat het BSN wordt gedeeld.
De functie ondersteunt federatief inloggen en machtigingenbeheer voor organisaties die namens een burger of een andere organisatie handelen.

Generieke functie 3 — Gegevensvoorziening¶

Doel: Bronhouders stellen hun gegevens beschikbaar via een gestandaardiseerde interface die door alle trajecten herbruikbaar is, inclusief grensoverschrijdende uitwisseling conform SDG/OOTS.

Eisen:

Een bronhouder realiseert één generieke ontsluiting. Er zijn geen trajectspecifieke endpoints of koppelingen per afnemer.
De interface ondersteunt selectieve gegevensuitvraag: de afnemer kan exact de velden opvragen die voor het specifieke gebruik nodig zijn. Dataminimalisatie is structureel ingebouwd, niet afhankelijk van afsprakenstelsel of goede wil.
De set van toegestane gegevensvragen per gebruik is vooraf geregistreerd (via een catalogus of template-mechanisme) en door beleid afdwingbaar. Binnen de toegestane gegevensvraag bepaalt de afnemer welke gegevens voor zijn situatie nodig zijn. Afwijkingen die buiten de toegestane gegevensvraag vallen zijn niet mogelijk.
De interface is onafhankelijk van het BSN als externe sleutel: het subject-identifier in een uitvraag van een private afnemer is altijd een pseudoniem of een consent-referentie; BSN-resolving is een interne aangelegenheid van de ontsluiting.
Bronhouders implementeren de ontsluiting eenmalig; aanpassingen voor nieuwe afnemers of trajecten vereisen geen bronhouder-specifieke ontwikkeling, alleen aanpassing van het beleid en de query-registratie.
Verzoeken vanuit andere EU-lidstaten (SDG/OOTS) worden aan de GBO-zijde vertaald naar het binnenlandse formaat en protocol. Bronhouders zien geen EU-specifiek transportprotocol.
Serviceregistratie voor grensoverschrijdende discovery (SMP) wordt centraal beheerd, niet door individuele bronhouders.

Generieke functie 4 — Semantiek & Eenheid van Taal¶

Doel: Gegevens die via GBO worden uitgewisseld hebben een eenduidige, gedocumenteerde betekenis, ongeacht het traject of de afnemer.

Eisen:

Per bronhouder bestaat een geregistreerde, door GBO beheerde beschrijving van de beschikbaar gestelde gegevenselementen (naam, type, definitie, herkomst).
Dezelfde gegevensset kan worden geserialiseerd naar de voor elk traject vereiste uitwisselingsformaten (JSON voor binnenlands, OOTS-EDM XML voor grensoverschrijdend, SD-JWT VC of mdoc voor de wallet). De canonieke definitie is eenmalig vastgelegd.
Mapping tussen de GBO-canonieke definitie en trajectspecifieke schema's (zoals OOTS Semantic Repository types of PuB-EAA attestatieschema's) is expliciet en beheerbaar.
Vocabularia zijn gebaseerd op open, breed gedragen standaarden (RDF, OWL, SKOS, JSON-LD) en sluiten aan op de Nederlandse overheidsstandaarden (GGM, NORA).
Semantische afspraken zijn versiebeheerd; wijzigingen in definities zijn traceerbaar en worden beheerst doorgevoerd.

Generieke functie 5 — Gegevenskwaliteit & Validatie¶

Doel: Gegevens die via GBO worden uitgewisseld zijn aantoonbaar correct, volledig en afkomstig van de opgegeven bron.

Eisen:

Gegevensherkomst (bronhouder, tijdstip, versie) is altijd meegeleverd bij uitgewisselde gegevens.
Uitgewisselde gegevens zijn cryptografisch gezegeld door de bronhouder, zodat de authenticiteit en integriteit door de afnemer verifieerbaar zijn.
Validatie van gegevens tegen het geregistreerde schema (conform Generieke functie 4) vindt plaats vóór uitlevering, niet bij de afnemer.
Afnemers kunnen geconstateerde onjuistheden terugmelden via een gestandaardiseerde feedbackloop; terugmeldingen zijn herleidbaar tot de specifieke gegevenslevering.
De kwaliteitseisen per gegevenselement (actualiteit, volledigheid, nauwkeurigheid) zijn gedocumenteerd als onderdeel van de catalogusbeschrijving.

Generieke functie 6 — Grondslag & Beleid¶

Doel: Elke gegevensuitvraag wordt getoetst aan het geldende beleid. De toetsing is geünificeerd, machineleesbaar en herleidbaar. Beleid en grondslagen zijn beheerbaar zonder wijziging van de verwerkende infrastructuur.

Eisen:

Beleidsdefinities omvatten: welke afnemers welke gegevens mogen opvragen, onder welke grondslagtypen, voor welke doelen, en met welke beperkingen (doelbinding, dataminimalisatie).
Beleidsregels zijn uitgedrukt in een formele, machineleesbare taal. Menselijk leesbare beschrijvingen zijn afgeleid van dezelfde bron, niet de bron zelf.
Wijzigingen in beleid (nieuwe afnemer, nieuwe gegevensvraag, gewijzigde AMvB) zijn door te voeren zonder aanpassing van de verwerkende systemen van bronhouders of de centrale GBO-infrastructuur.
De grondslag wordt real-time geraadpleegd op het moment van uitvraag. Er is geen vertrouwen op eerder uitgegeven tokens die de grondslagstatus "bevroren" vastleggen.
De autorisatiebeslissing en de bijbehorende beleidscontext worden vastgelegd ten behoeve van auditbaarheid (zie Generieke functie 8).

Generieke functie 7 — Orkestratie & Integratie¶

Doel: Gegevensuitvragen die meerdere bronhouders, trajecten of verwerkingsstappen omvatten, worden gecoördineerd afgehandeld. Integratie met bestaande systemen van bronhouders en afnemers verloopt via beheerde adapters.

Eisen:

Een gegevensuitvraag die gegevens van meerdere bronhouders vereist, wordt als één samengesteld verzoek afgehandeld. De afnemer ziet één gecoördineerde respons, niet een reeks losse antwoorden.
Procesorkestratie is configureerbaar per traject zonder dat de onderliggende bronhouderssystemen worden aangepast.
Mapping tussen het interne GBO-model en de externe formaten van afnemers (REST/JSON, AS4/XML, SD-JWT VC) is een expliciete, beheerde transformatiestap — geen impliciete conversie in de transportlaag.
De orkestratie-component handelt foutscenario's af (bronhouder niet bereikbaar, gedeeltelijke respons) op een voorspelbare, per traject instelbare manier.
Event-gedreven interacties (notificaties bij wijziging van brongegevens) worden ondersteund als aanvulling op synchrone bevraging.

Generieke functie 8 — Beheer & Continuïteit¶

Doel: Het GBO-stelsel is beheersbaar, monitorbaar en aantoonbaar betrouwbaar. Iedere gegevensuitvraag is herleidbaar: welke afnemer heeft wanneer welke gegevens over welke burger opgevraagd, op basis van welke grondslag, met welk besluit.

Eisen:

Iedere gegevensuitvraag genereert een vastlegging conform de Logboek Dataverwerkingen (LDV) standaard.
Logregels over de keten heen zijn correleerbaar via een gestandaardiseerde verzoekidentificator, zodat een uitvraag van afnemer tot bronhouder volledig reconstrueerbaar is.
Audit-logs zijn niet aanpasbaar door de componenten die ze genereren (onweerlegbaarheid).
De burger heeft recht op inzage in de verwerkingen die zijn gegevens betreffen; de logging is zo ingericht dat dit recht technisch uitvoerbaar is.
Wallet-lokale logs (EDI-traject) vallen buiten de server-side correlatie; de architectuur maakt geen aannames over inzage in wallet-transacties van de burger zelf.
Versies van beleid, schema's en configuraties zijn beheerd en traceerbaar, zodat een uitvraag altijd reconstrueerbaar is naar de op dat moment geldende instellingen.
Incidentbeheer en monitoring zijn ingericht conform de continuïteitseisen die gelden voor overheidsinfrastructuur.

Samenhang¶

De generieke functies zijn niet op zichzelf staand. De onderstaande afhankelijkheden zijn architectureel kritiek:

Generieke functie 1 (Identiteit & Vertrouwen) is afhankelijk van de Vertrouwensstelsel-laag voor de identiteitsvaststelling van organisaties, en van Generieke functie 6 (Grondslag & Beleid) als informatiebron voor autorisatiebeslissingen.
Generieke functie 2 (Toegang & Interactie) is de schrijfinterface naar Toestemming & Grondslag, en triggert de pseudonimiseringsactie van Burgeridentificatie & Pseudonimisering.
Generieke functie 3 (Gegevensvoorziening) is afhankelijk van Generieke functie 1 voor toegangshandhaving, en van Generieke functie 4 (Semantiek) voor de definitie van wat er ontsloten wordt.
Generieke functie 5 (Gegevenskwaliteit & Validatie) is een uitvoerende kwaliteitslaag bovenop Generieke functie 3, en levert herkomstinformatie aan Generieke functie 4.
Generieke functie 7 (Orkestratie & Integratie) coördineert verzoeken die meerdere instanties van Generieke functie 3 aanroepen, en verzorgt de formatmapping naar afnemers.
Generieke functie 8 (Beheer & Continuïteit) is een cross-cutting concern: iedere andere generieke functie genereert input voor de audit-keten.

Capabilities¶

Dit hoofdstuk beschrijft wat het stelsel moet kunnen en is een uitwerking van de generieke functies naar afspraken, standaarden en voorzieningen, die als "capabilities" door het stelsel geleverd moeten worden.

Leeswijzer¶

Per capability is aangegeven:
- Type invulling: afspraak, standaard of voorziening
- Beheer: centraal (GBO-stelsel of bestaand stelsel beheert) of decentraal (bronhouder / afnemer implementeert zelf)
- Instantiëring: gedeelde instantie of eigen instantie per partij
- Bestaande invulling: wat er al is en hergebruikt kan worden
- Gap: wat er nog ontbreekt of nog ingevuld moet worden (apart gemarkeerd met ⚠️)

De context is het GBO-stelsel, ingebed in NORA/GDI en het Federatief Datastelsel (FDS), met aansluiting op het eIDAS2/ARF Europees kader. Stelselafspraken landen in bestaande afsprakenstelsels: FDS en TIP (Trusted Information Partners).

De structuur "afspraken boven standaarden boven voorzieningen" is het expliciete uitgangspunt van FDS en wordt hier overgenomen. Waar mogelijk worden bestaande FDS-stelselfuncties hergebruikt (zie met name capabilities 3 en 5). Het iWlz-afsprakenstelsel geldt als blauwdruk voor de inrichting van het GBO-afsprakenstelsel zelf: gelaagd opgebouwd (organisatiebeleid → proces → informatie → applicatie → IT-infrastructuur → uitwisselprofielen), met een formeel RFC-proces voor wijzigingen.

Naast technische gaps kent dit document ook juridische randvoorwaarden (gemarkeerd met ⚖️): capabilities die pas zinvol te realiseren zijn nadat de benodigde wettelijke grondslag in de Wet digitale overheid (Wdo) en bijbehorende AMvB is verankerd.

Capability 1 — Grondslagregistratie¶

Het machineleesbaar vastleggen en raadplegen van de juridische grondslag per gegevensuitvraag (toestemming, wettelijke basis, doelbinding), zodat de autorisatiecomponent deze real-time kan toetsen.

⚖️ Juridische randvoorwaarde: Deze capability is voor het DvTP-traject pas zinvol te realiseren nadat de Wdo een expliciete bevoegdheid voor bronhouders bevat om op verzoek van de burger gegevens te verstrekken aan private dienstverleners. Zolang sectorale geheimhoudingsplichten (AWR art. 67, Wet SUWI art. 74 e.a.) niet via de Wdo zijn doorbroken, heeft een technisch grondslagregister geen werkende juridische basis. De technische uitwerking van deze capability loopt parallel aan het wetgevingstraject, maar kan pas operationeel worden na inwerkingtreding van de Wdo-grondslag en bijbehorende AMvB.

Afspraken¶

Afspraak	Type	Beheer	Invulling
Welke grondslagtypen geldig zijn per traject (toestemming / wettelijke basis / doelbinding)	Stelselafspraak	Centraal — GBO/FDS	⚠️ Nog te maken; raakt aan AVG-uitwerking in AMvB Wdo
Formaat en inhoud van een grondslag-record (minimale attributen, geldigheid, scope)	Stelselafspraak	Centraal — GBO	⚠️ Nog te maken
Intrekkingsrecht burger: termijnen en effect op lopende verwerkingen	Stelselafspraak	Centraal — GBO/FDS, raakvlak AVG	⚠️ Nog te maken; deels bepaald door AVG art. 7
Aansluiting bronhouders en afnemers op de grondslagregistratie	Toetredingsafspraak (FDS)	Centraal — FDS afsprakenstelsel	⚠️ Nog te maken als FDS-toetredingseis

Standaarden¶

Standaard	Beheer	Bestaande invulling
W3C ODRL (Open Digital Rights Language) — uitdrukken van beleid en toestemming als machineleesbare policy	Internationaal / W3C	Beschikbaar; binnen FDS en DCAT-AP NL al in gebruik voor beleidsbeschrijving
OData/REST of GraphQL als raadpleeginterface voor de grondslagregistratie (PIP-interface)	GBO-stelsel	⚠️ Nog te standaardiseren als GBO PIP-profiel

Voorzieningen¶

Voorziening	Type	Beheer	Instantiëring	Bestaande invulling
Toestemmingsregister / grondslagregister	Centrale voorziening	Centraal — GBO-stelsel (of Logius als beheerder)	Gedeelde instantie	⚠️ In de zorg gebruikt men Mitz waarvan geleerd kan worden; nog geen generieke GBO-voorziening
Inzage- en beheerinterface voor burger (Mijn Toestemmingen)	Centrale voorziening	Centraal — GBO/Logius	Gedeelde instantie	⚠️ Raakvlak MijnOverheid; nog geen generieke invulling
Policy Store (centrale beleidsdefinities overige grondslagen)	Centrale voorziening	Centraal — GBO	Gedeeld	⚠️ Nog te realiseren - zie ook Capability 4

Capability 2 — Burgeridentificatie & Pseudonimisering¶

Het vaststellen van de identiteit van de burger op het vereiste betrouwbaarheidsniveau, en het omzetten van het BSN naar partij-specifieke, onomkeerbare pseudoniemen zodat het BSN nooit bij private afnemers terechtkomt.

Afspraken¶

Afspraak	Type	Beheer	Invulling
BSN mag private dienstverleners nooit bereiken; pseudoniem is verplicht voor DvTP-traject	Stelselafspraak	Centraal — GBO, verankerd in AMvB Wdo / Wabvpz	Deels al wettelijk bepaald (Wabvpz); uitwerking in GBO-stelsel nog nodig
Koppeling tussen toestemmingsrecord en pseudoniem (consent_id als brug)	Stelselafspraak	Centraal — GBO	⚠️ Nog te maken
Betrouwbaarheidsniveaus per traject (welk eIDAS-niveau vereist voor welk type gegevens)	Stelselafspraak	Centraal — GBO/FDS, raakvlak eIDAS2	⚠️ Nog te maken als GBO-beleidsprofiel
Onboarding private dienstverleners als BSNk PP-deelnemer (EP-sleuteldistributie)	Toetredingsafspraak	Centraal — Logius/BSNk	Bestaand BSNk-onboardingproces; uitbreiding voor DvTP-partijen nodig

Standaarden¶

Standaard	Beheer	Bestaande invulling
eIDAS2 / ARF — wallet-gebaseerde identiteitspresentatie (PID)	Europese Commissie	ARF v2.x beschikbaar; NL implementatie via pilotprogramma eWallet NL
OpenID4VP — presentatieprotocol voor wallet naar verifier	OpenID Foundation	Beschikbaar als onderdeel van ARF; aansluiting op GBO nog te realiseren
ISO 18013-5 (mDL) — proximity presentatie voor offline scenario's	ISO	Beschikbaar; relevant voor EDI-wallet traject

Voorzieningen¶

Voorziening	Type	Beheer	Instantiëring	Bestaande invulling
DigiD	Centrale voorziening	Logius	Gedeeld	Beschikbaar; ondersteunt eIDAS Substantieel; koppeling met GBO via bestaande DigiD-aansluiting
eHerkenning	Stelselvoorziening	Logius / markt	Gedeeld (meerdere leveranciers)	Beschikbaar voor organisatie-authenticatie; relevant voor onboarding dienstverleners
eIDAS-erkende buitenlandse authenticatiemiddelen	Stelselvoorziening	eIDAS-knooppunt (Logius)	Gedeeld	Beschikbaar via NL eIDAS-knooppunt; relevant voor EDI-wallet en OOTS
BSNk PP (polymorf pseudonimiseringsstelsel)	Centrale voorziening	Logius	Gedeeld	Beschikbaar en in productie (eToegang-stelsel, ~2019); integratiewerk voor GBO/DvTP-traject nog nodig
BSNk Activate / Transform / Close	Onderdelen van BSNk PP	Logius	Gedeeld	Beschikbaar; onboarding Toestemmingsportaal als AD/MR-deelnemer en PEP als BSN-geautoriseerde component nog te realiseren

Capability 3 — Organisatie-authenticatie & Vertrouwensstelsel¶

Vaststellen dat een deelnemende organisatie (dienstverlener, bronhouder, EU-lidstaat) is wie zij zegt te zijn, bevoegd is tot deelname, en verifieerbaar verbonden is aan het stelsel.

ℹ️ FDS hergebruik: De organisatorische stelselfuncties Poortwachter (toelating en onboarding van nieuwe deelnemers) en Marktmeester (beheer van de deelnemerslijst en naleving van aansluitvoorwaarden) zijn binnen FDS al gedefinieerd en gedeeltelijk ingericht. GBO hergebruikt deze functies voor de toelating van bronhouders en private dienstverleners, aangevuld met GBO-specifieke aansluitvoorwaarden (zie ook Capability 5).

Afspraken¶

Afspraak	Type	Beheer	Invulling
Welke certificaattypen / trust anchors geaccepteerd worden per traject	Stelselafspraak	Centraal — GBO/FDS	PKI Overheid als basis voor binnenlands; eIDAS Trusted List voor grensoverschrijdend; ⚠️ profiel nog te maken
Onboardingproces dienstverleners (registratie, contractering, certificaatuitgifte)	Toetredingsafspraak	Centraal — GBO-stelsel, aansluiting FDS	⚠️ Nog te maken als GBO-toetredingsprocedure
Erkenning QTSP-uitgegeven attestaties en gekwalificeerde zegels als vertrouwensanker	Stelselafspraak	Centraal — GBO, verankerd in eIDAS	Basis aanwezig via eIDAS; ⚠️ GBO-specifiek beleidsprofiel voor PDP-verificatie nog te maken
Wederzijdse erkenning organisatie-identifiers (OIN, KvK, EIDAS NTRNL)	Stelselafspraak	Centraal — FDS / Logius OIN-register	OIN-register beschikbaar; ⚠️ koppeling KvK ↔ OIN ↔ eIDAS-identifier nog niet gestandaardiseerd

Standaarden¶

Standaard	Beheer	Bestaande invulling
PKI Overheid (certificatenbeleid)	Logius	Beschikbaar en verplicht binnen overheid; basis voor FSC-authenticatie
eIDAS Trusted Lists (LoTL / nationale TL)	Europese Commissie / RDI	Beschikbaar; NL Trusted List beheerd door RDI
ETSI EN 319 412 (certificaatprofielen voor gekwalificeerde zegels en handtekeningen)	ETSI	Beschikbaar; relevant voor QTSP-erkenning en PuB-EAA signing

Voorzieningen¶

Voorziening	Type	Beheer	Instantiëring	Bestaande invulling
OIN-register (Organisatie Identificatienummer)	Centrale voorziening	Logius	Gedeeld	Beschikbaar; uitbreiding met KvK-koppeling en eIDAS-identifier gewenst
PKI Overheid TSP's (vertrouwensdienstverleners)	Stelselvoorziening	Markt onder toezicht RDI	Gedeeld (meerdere TSP's)	Beschikbaar
eIDAS-knooppunt NL	Centrale voorziening	Logius	Gedeeld	Beschikbaar; relevant voor grensoverschrijdende organisatie-authenticatie
FSC Directory (contractregister)	Onderdeel FSC-stelsel	RINIS	Gedeeld	Beschikbaar als onderdeel FSC; registratie van actieve contracten tussen partijen
FDS Poortwachter (toelating en onboarding deelnemers)	Organisatorische stelselfunctie FDS	Centraal — FDS-beheer / GBO	Gedeeld	Beschikbaar als FDS-functie; GBO vult deze functie in voor bronhouders en private dienstverleners met GBO-specifieke aansluitvoorwaarden — ⚠️ GBO-aansluitvoorwaarden zelf nog te maken
FDS Marktmeester (deelnemerslijst en nalevingsbeheer)	Organisatorische stelselfunctie FDS	Centraal — FDS-beheer / GBO	Gedeeld	Beschikbaar als FDS-functie; GBO breidt deze functie uit met GBO-specifieke nalevingseisen voor private dienstverleners

Capability 4 — Autorisatie (PEP/PDP/PIP-keten)¶

Iedere gegevensuitvraag wordt getoetst aan machineleesbaar beleid, op basis van de identiteit van de afnemer, de gevraagde gegevens, en de real-time raadpleging van de grondslag. De beslissing is herleidbaar en trajectonafhankelijk.

Afspraken¶

Afspraak	Type	Beheer	Invulling
Geünificeerde autorisatieketen voor alle trajecten (één PEP/PDP, trajectspecifieke policies)	Architectuurafspraak	Centraal — GBO	⚠️ Nog te maken als GBO-architectuurprincipe
Standaard Subject/Action/Resource/Context vocabulaire voor GBO-autorisatievragen	Stelselafspraak	Centraal — GBO, aansluiting FTV/AuthZEN	⚠️ Nog te maken als GBO-AuthZEN-profiel
Beleidstemplates per traject (wie mag wat opvragen onder welke grondslag)	Stelselafspraak	Centraal beheer, decentrale configuratie per sector of bronhouder	⚠️ Nog te maken; iWlz-Rego-patronen als vertrekpunt
BSN-resolving vindt uitsluitend plaats binnen de PEP, na de beleidsbeslissing	Architectuurafspraak	Centraal — GBO	⚠️ Nog te maken als GBO-architectuurprincipe

Standaarden¶

Standaard	Beheer	Bestaande invulling
AuthZEN NL Gov (draft) — gestandaardiseerde interface tussen PEP en PDP	Logius	Draft-standaard; FTV (Federatieve Toegangsverlenig, Logius) loopt pilot
OPA/Rego — machineleesbare beleidstaal voor PDP-evaluatie	Open Policy Agent / CNCF	In productie bij iWlz (ZIN/Ketenbureau iWlz) voor gevoelige zorgdata; directe precedentwaarde
XACML 3.0 — alternatieve PDP-standaard (minder actueel, maar breed ingezet)	OASIS	Beschikbaar; minder geschikt voor fine-grained data-access dan OPA/Rego
PBAC (Policy-Based Access Control) als autorisatieparadigma	Conceptueel kader	Beschreven in FTV-architectuur; aansluiting GBO gewenst

Voorzieningen¶

Voorziening	Type	Beheer	Instantiëring	Bestaande invulling
PEP (Policy Enforcement Point)	Decentrale voorziening	Decentraal — per bronhouder geïnstantieerd	Eigen instantie per bronhouder	⚠️ Nog te realiseren; GBO levert referentie-implementatie / deployable package
PDP (Policy Decision Point)	Decentrale voorziening (centraal beheerde policies)	Policies centraal beheerd door GBO; PDP-instantie decentraal bij bronhouder	Eigen instantie per bronhouder	⚠️ Nog te realiseren; iWlz OPA/Rego als precedent
PIP-interface naar grondslagregistratie	Koppelvlak	Centraal — GBO (grondslagregistratie als PIP)	Gedeeld koppelvlak	⚠️ Nog te standaardiseren als GBO PIP-profiel (zie Capability 1)
Policy Store (centrale opslag van beleidsdefinities per traject)	Centrale voorziening	Centraal — GBO	Gedeeld	⚠️ Nog te realiseren

Capability 5 — Gegevensontsluiting (Bronontsluiting API)¶

Bronhouders stellen gegevens beschikbaar via één generieke, herbruikbare interface. Selectieve uitvraag is structureel mogelijk en afdwingbaar. Geen trajectspecifieke endpoints.

ℹ️ FDS hergebruik: De FDS-stelselfunctie Poortwachter regelt het onboardingproces voor bronhouders als data-aanbieders binnen FDS. GBO hergebruikt dit proces en breidt het uit met GBO-specifieke stappen (BSNk PP-onboarding, query-template registratie, trajectactivatie). De FDS-stelselfunctie Datadiensten definieert het kwaliteitskader voor data-aanbod; GBO-bronontsluiting valt hieronder als een specialisatie.

Afspraken¶

Afspraak	Type	Beheer	Invulling
Elke bronhouder realiseert één generieke ontsluiting; geen trajectspecifieke koppelingen	Architectuurafspraak	Centraal — GBO/FDS	⚠️ Nog te maken als FDS-architectuureis voor GBO-bronhouders
Query-registratie: toegestane gegevensvragen per use case zijn vooraf geregistreerd en afdwingbaar	Stelselafspraak	Centraal — GBO (query-catalogus)	⚠️ Nog te maken
Onboarding bronhouders: PKIoverheid-certificaat → FSC-registratie → DCAT-beschrijving → trajectactivatie	Toetredingsafspraak	Centraal — GBO/FDS	⚠️ Nog te maken als GBO-onboardingprocedure
DCAT-AP NL als verplicht formaat voor zelfbeschrijving van bronhouder-datasets	Stelselafspraak	Centraal — FDS (al bestaande FDS-eis)	Beschikbaar — FDS mandateert DCAT-AP NL

Standaarden¶

Standaard	Beheer	Bestaande invulling
FSC (Federated Service Connectivity) — binnenlands koppelnetwerk voor REST/HTTP	Logius / FSC-community	Beschikbaar en in gebruik binnen overheid; standaard voor domestiek verkeer in FDS
GraphQL — selectieve gegevensuitvraag op basis van geregistreerde schema's	GraphQL Foundation	Beschikbaar; in productie bij iWlz; nog niet opgenomen in FDS standaardenlandkaart als datadienst-type — ⚠️ positionering als FDS-datadienst-type nog nodig
DCAT-AP NL — datacatalogus beschrijving	Geonovum / FDS	Beschikbaar en verplicht binnen FDS
NL API Strategie / REST API Design Rules	Geonovum / Kennisplatform API's	Beschikbaar en verplicht binnen overheid; GraphQL loopt over HTTP en is hiermee verenigbaar

Voorzieningen¶

Voorziening	Type	Beheer	Instantiëring	Bestaande invulling
FSC Inway (per bronhouder)	Decentrale voorziening	Decentraal — bronhouder beheert eigen Inway	Eigen instantie per bronhouder	Beschikbaar — FSC Inway referentie-implementatie beschikbaar
FSC Outway (per afnemer)	Decentrale voorziening	Decentraal — afnemer beheert eigen Outway	Eigen instantie per afnemer	Beschikbaar — FSC Outway referentie-implementatie beschikbaar
Query Template Registry (catalogus van geregistreerde gegevensvragen)	Centrale voorziening	Centraal — GBO	Gedeeld	⚠️ Nog te realiseren als GBO-voorziening
GBO Vertaallaag (shared service voor kleine bronhouders zonder eigen GraphQL)	Centrale voorziening	Centraal — GBO	Gedeeld	⚠️ Nog te realiseren; optioneel voor gemeenten en kleine bronhouders

Capability 6 — Grensoverschrijdende gegevensuitwisseling (OOTS-brug)¶

Verzoeken vanuit andere EU-lidstaten via het OOTS-stelsel worden vertaald naar het binnenlandse GBO-protocol. Bronhouders zien geen EU-specifiek transport. De brug is een EU-rechtelijke verplichting.

Afspraken¶

Afspraak	Type	Beheer	Invulling
De OOTS-brug is de enige AS4-toegangspoort; binnenlands verkeer gebruikt FSC direct	Architectuurafspraak	Centraal — GBO	⚠️ Nog te maken als GBO-architectuurprincipe
SMP-registratie van GBO-bronhouders voor OOTS-discovery wordt centraal beheerd door de brug	Stelselafspraak	Centraal — GBO	⚠️ Nog te maken
Autorisatie van OOTS-verzoeken doorloopt dezelfde PEP/PDP-keten als binnenlandse verzoeken	Architectuurafspraak	Centraal — GBO	⚠️ Nog te maken als GBO-architectuurprincipe

Standaarden¶

Standaard	Beheer	Bestaande invulling
eDelivery AS4 (CEF) — transport voor OOTS	Europese Commissie / CEF	Verplicht op basis van EU 2018/1724; referentie-implementatie via Domibus
OOTS-EDM (Evidence Data Model) — XML-payloadformaat	Europese Commissie / OOTS	Beschikbaar als onderdeel OOTS technical design; Schematron-validatieregels beschikbaar
SMP 2.1 (Service Metadata Publisher) — discovery van toegangspunten	OASIS / CEF	Verplicht als onderdeel OOTS; NAPTR DNS-koppeling
SDG Regulation (EU 2018/1724)	EU wetgeving	Juridische verplichting; technische specificaties via EC OOTS Working Group

Voorzieningen¶

Voorziening	Type	Beheer	Instantiëring	Bestaande invulling
Domibus Access Point	Centrale voorziening	Centraal — GBO (één NL-instelling voor GBO-bronhouders)	Gedeelde instantie	Beschikbaar als open source (EC); ⚠️ operationele inrichting voor GBO nog te doen
OOTS-EDM Adapter (XML ↔ FSC/GraphQL vertaling)	Centrale voorziening	Centraal — GBO	Gedeelde instantie	⚠️ Nog te realiseren
SMP 2.1 Publisher	Centrale voorziening	Centraal — GBO	Gedeelde instantie	⚠️ Nog te realiseren; configuratie gebaseerd op query-catalogus (zie Capability 5)

Capability 7 — Toestemmingsportaal (Burger Interactie)¶

De burger geeft via een toegankelijke interface geïnformeerde toestemming voor gegevensdeling, authenticeert zich daarvoor op het vereiste niveau, en kan toestemmingen inzien en intrekken. De pseudonimiseringsactie vindt hier plaats.

⚖️ Juridische randvoorwaarde: De werking van dit portaal is onlosmakelijk verbonden aan de Wdo-grondslag (zie Capability 1). Bovendien moeten de vrijwilligheidsborging en het gelijkwaardig alternatief wettelijk worden verankerd als aansluiteis voor private dienstverleners, voordat het portaal operationeel zinvol is. Zonder die verankering is niet afdwingbaar dat dienstverleners de digitale route niet als dwingend voorwaarde mogen stellen.

Afspraken¶

Afspraak	Type	Beheer	Invulling
Minimale informatie-eisen voor toestemmingspresentatie aan burger (doel, afnemer, gegevens, geldigheidsduur)	Stelselafspraak	Centraal — GBO, AVG art. 7 als basis	⚠️ Uitwerking als GBO-UX-richtlijn nog te maken
Betrouwbaarheidsniveau authenticatie burger bij toestemming geven	Stelselafspraak	Centraal — GBO/FDS	⚠️ Nog te bepalen per type gegevens; minimaal eIDAS Substantieel verwacht
Pseudonimisering vindt plaats in het portaal op het moment van toestemmingsvastlegging	Architectuurafspraak	Centraal — GBO	⚠️ Nog te maken als GBO-architectuurprincipe
Gelijkwaardig alternatief verplicht: private dienstverleners mogen de digitale toestemmingsroute niet als enige toegangsweg stellen	Aansluiteis (wettelijk te verankeren)	Centraal — Wdo / RDI-toezicht	⚖️ Moet wettelijk worden verankerd als aansluiteis in Wdo of AMvB; handhaving bij RDI
Geen nadeel bij weigering: weigering van toestemming mag niet leiden tot weigering van dienst, vertraging, hogere kosten of slechtere voorwaarden	Aansluiteis (wettelijk te verankeren)	Centraal — Wdo / RDI-toezicht	⚖️ Moet wettelijk worden verankerd; bewijslast ligt bij de private dienstverlener
Transparantie over vrijwilligheid: burger wordt vooraf in begrijpelijke taal geïnformeerd dat de route vrijwillig is en welk alternatief beschikbaar is	Stelselafspraak / UX-eis	Centraal — GBO	⚠️ Uitwerking als GBO-UX-richtlijn en aansluiteis nog te maken

Standaarden¶

Standaard	Beheer	Bestaande invulling
DigiD-aansluiting (SAML 2.0 / OpenID Connect)	Logius	Beschikbaar; standaard aansluitprocedure Logius
WCAG 2.1 AA — toegankelijkheidseisen overheidswebsites	W3C / Digitoegankelijk	Verplicht voor overheidsdiensten
OpenID Connect (OIDC) — authenticatieprotocol naar burger	OpenID Foundation	Beschikbaar; onderdeel DigiD-aansluiting

Voorzieningen¶

Voorziening	Type	Beheer	Instantiëring	Bestaande invulling
Toestemmingsportaal	Centrale voorziening	Centraal — GBO (of Logius als beheerder)	Gedeelde instantie	⚠️ Nog te realiseren als GBO-voorziening; raakvlakken MijnOverheid en DvTP-pilot
DigiD	Centrale voorziening	Logius	Gedeeld	Beschikbaar
BSNk Activate (BSN → PI+PP bij eerste toestemmingsregistratie)	Onderdeel BSNk PP	Logius	Gedeeld	Beschikbaar; ⚠️ onboarding portaal als BSNk-deelnemer nog te realiseren

Capability 8 — Logging, Audit & Traceerbaarheid¶

Iedere gegevensuitvraag is over de hele keten herleidbaar. Logregels zijn correleerbaar, onweerlegbaar, en zodanig ingericht dat inzagerechten van de burger technisch uitvoerbaar zijn.

ℹ️ iWlz precedent: Het iWlz-afsprakenstelsel heeft TraceID/SpanID-correlatie (RFC0022a) en LDV-conforme logging als formeel vastgestelde RFC's opgenomen. Dit patroon is daarmee bewezen in productie voor gevoelige zorgdata en direct herbruikbaar als GBO-standaard voor gedistribueerde tracing.

Afspraken¶

Afspraak	Type	Beheer	Invulling
LDV-conforme logging is verplicht voor alle GBO-componenten	Stelselafspraak	Centraal — GBO/FDS	⚠️ Nog te maken als GBO-aansluiteis; LDV-standaard zelf in consultatie
Cross-component correlatie via gestandaardiseerde trace-identifier	Stelselafspraak	Centraal — GBO	⚠️ Nog te maken als GBO-technisch profiel
Burger heeft inzagerecht in verwerkingen; logstructuur maakt dit mogelijk	Stelselafspraak	Centraal — GBO, AVG art. 15 als basis	⚠️ Inzagevoorziening voor burger nog te ontwerpen
Wallet-lokale logs vallen buiten server-side correlatie	Architectuurafspraak	Centraal — GBO	⚠️ Vast te leggen als GBO-architectuurkeuze

Standaarden¶

Standaard	Beheer	Bestaande invulling
Logboek Dataverwerkingen (LDV)	Logius	In publieke consultatie voor vaststelling bij MIDO (consultatie gesloten januari 2026); referentie-implementatie beschikbaar via Digilab; opname op Forum Standaardisatie lijst aanbevolen standaarden wordt beoogd
OpenTelemetry — gedistribueerde tracing en correlatie	CNCF	Beschikbaar; breed ingezet in overheids-IT; trace-ID als correlatiesleutel over componenten
W3C Trace Context — HTTP-header standaard voor trace propagation	W3C	Beschikbaar; onderdeel OpenTelemetry-ecosysteem

Voorzieningen¶

Voorziening	Type	Beheer	Instantiëring	Bestaande invulling
LDV-logging per component	Decentrale voorziening	Decentraal — elke component logt conform LDV	Eigen instantie per component	⚠️ Nog te realiseren per GBO-component
Centrale audit-aggregatie (optioneel)	Centrale voorziening	Centraal — GBO	Gedeeld	⚠️ Nog te bepalen of centraal aggregatiepunt nodig is; privacy-implicaties afwegen
Inzageportaal burger (verwerkingsregister)	Centrale voorziening	Centraal — GBO / MijnOverheid	Gedeeld	⚠️ Raakvlak MijnOverheid/Logius; nog niet gerealiseerd voor GBO

Capability 9 — Semantiek & Gegevenscatalogus¶

Gegevens die via GBO uitgewisseld worden hebben een eenduidige, beheerde betekenis. Dezelfde canonieke definitie wordt geserialiseerd naar de voor elk traject vereiste uitwisselingsformaten.

Afspraken¶

Afspraak	Type	Beheer	Invulling
Per bronhouder bestaat een beheerde, GBO-geregistreerde schemabeschrijving	Stelselafspraak	Centraal — GBO (schema-registry)	⚠️ Nog te maken als GBO-cataloguseis
Canonieke schemadefinitie is de enige bron van waarheid; serialisaties zijn afgeleid	Architectuurafspraak	Centraal — GBO	⚠️ Nog te maken als GBO-architectuurprincipe
Mapping naar OOTS Semantic Repository evidence types is verplicht voor OOTS-trajecten	Stelselafspraak	Centraal — GBO, aansluiting EC OOTS	⚠️ Nog te maken
Mapping naar PuB-EAA attestatieschema's is verplicht voor EDI-wallet traject	Stelselafspraak	Centraal — GBO, aansluiting ARF/EC	⚠️ Nog te maken

Standaarden¶

Standaard	Beheer	Bestaande invulling
DCAT-AP NL — datacatalogus voor zelfbeschrijving datasets	Geonovum / FDS	Beschikbaar en verplicht binnen FDS
Bestaande sectorale gegevensmodellen (zoals GGM, SGR, ...)	VNG / SBKWI / ...	worden als vertrekpunt gebruikt bij de opstelling van het canonieke schema per bronhouder
SHACL (Shapes Constraint Language) — validatie van RDF-data	W3C	Beschikbaar; relevant voor validatie van uitgewisselde gegevens
SD-JWT VC — credential-formaat voor wallet-presentaties	IETF	Beschikbaar als onderdeel ARF; ⚠️ GBO-serialisatieprofiel nog te maken
OOTS-EDM (Evidence Data Model)	EC / OOTS	Beschikbaar; 9 evidence types gedefinieerd in OOTS Semantic Repository

Voorzieningen¶

Voorziening	Type	Beheer	Instantiëring	Bestaande invulling
GBO Schema Registry / Catalogus	Centrale voorziening	Canonieke definitie als leesbare tekst (markdown/HTML) en ook machineleesbaar (RDF/OWL/SHACL), centraal vastgesteld (GBO), decentraal geïnitieerd via RFC-proces.	Gedeeld	⚠️ Nog te realiseren; bouwt op FDS-datacatalogus infrastructuur
Serialisatie-service (canoniek schema → JSON / XML / SD-JWT VC / mdoc)	Centrale voorziening	Centraal — GBO	Gedeeld	⚠️ Nog te realiseren
FDS Datacatalogus (bestaande DCAT-infrastructuur)	Centrale voorziening	FDS / Logius	Gedeeld	Beschikbaar; GBO-uitbreiding voor schema-registry gewenst

Capability 10 — Attesteringsuitgifte (PuB-EAA / QEAA)¶

Het omzetten van brongegevens uit authentieke overheidsbronnen naar digitaal ondertekende attesteringen die burgers kunnen opslaan in een EUDI-wallet en presenteren aan vertrouwende partijen.

⚖️ Juridische randvoorwaarde: De vereisten voor PuB-EAA-uitgifte zijn vastgelegd in Uitvoeringsverordening (EU) 2025/1569 en de bijbehorende ETSI-normen. Overheidsorganen die PuB-EAAs uitgeven moeten beschikken over een goedgekeurd Conformity Assessment Report (CAR) van een geaccrediteerde Conformity Assessment Body (CAB). De Europese regelgeving op dit punt is nog in ontwikkeling; de uitwerking van GBO op dit vlak loopt parallel aan de nadere invulling van het Europese kader.

ℹ️ Scope-afbakening: GBO overweegt een centrale PuB-EAA-uitgifte-dienst in te richten die namens overheidsbronhouders attesteringen uitgeeft op basis van de generieke bronontsluiting (Capability 5), en een centrale verificatiedienst waar vertrouwende partijen de geldigheid van uitgegeven attesteringen kunnen controleren. De keuze of beide voorzieningen centraal worden ingericht, decentraal per bronhouder, of dat de uitgifte elders (buiten GBO) wordt belegd, is nog niet gemaakt en wordt hier als open vraag behandeld.

Afspraken¶

Afspraak	Type	Beheer	Invulling
Welke overheidsbronnen PuB-EAAs uitgeven en voor welke attribuuttypen	Stelselafspraak	Centraal — GBO, per bronhouder te activeren	⚠️ Nog te maken; lijst van attribuuttypen sluit aan op canonieke schema's (C9)
Attestation Rulebook per attribuuttype: vereiste gegevens, opmaak, bewijzen, beveiligingseisen, intrekkingsbeleid	Stelselafspraak	Centraal — GBO, aansluiting EC/ARF-rulebooks	⚠️ Nog te maken per attribuuttype; Europese standaardrulebooks in ontwikkeling
Wallet binding: koppeling van uitgifte aan specifieke wallet-instantie van de burger	Architectuurafspraak	Centraal — GBO	⚠️ Nog te maken als GBO-technisch profiel; conform ARF wallet binding vereisten
Intrekkingsbeleid: wanneer een attestering wordt ingetrokken en hoe de statuslijst wordt bijgehouden	Stelselafspraak	Centraal — GBO	⚠️ Nog te maken; sluit aan op statuslijstmechanisme (Token Status List of OCSP)
Opname van de centrale PuB-EAA-dienst op de Nederlandse Trusted List (beheerd door RDI)	Toetredingsafspraak	Centraal — RDI / GBO	⚠️ Vereist CAR-certificering; procedure nog te doorlopen
Verificatiedienst: welke partijen de centrale verificatieservice mogen bevragen en onder welke voorwaarden	Stelselafspraak	Centraal — GBO	⚠️ Nog te maken

Standaarden¶

Standaard	Beheer	Bestaande invulling
OpenID4VCI (OpenID for Verifiable Credential Issuance) — protocol voor uitgifte van credentials aan wallet	OpenID Foundation / ARF	Beschikbaar; verplicht binnen ARF; implementatierichtlijnen in uitvoeringsverordening 2025/1569
SD-JWT VC (Selective Disclosure JWT Verifiable Credential) — credential-formaat voor wallet-opslag	IETF / ARF	Beschikbaar; primair formaat voor PuB-EAA in ARF
ISO/IEC 18013-5 (mdoc) — alternatief credential-formaat voor proximity-presentatie	ISO / ARF	Beschikbaar; relevant voor offline en proximity use cases
ETSI EN 319 412 — eisen aan gekwalificeerde zegels voor ondertekening van PuB-EAA	ETSI	Beschikbaar; ondertekening met QESeal verplicht voor PuB-EAA
Token Status List (IETF draft) — mechanisme voor statusbeheer van uitgegeven credentials	IETF	Beschikbaar als draft; ⚠️ nog niet definitief vastgesteld als verplichte standaard in ARF
OpenID4VP (OpenID for Verifiable Presentations) — protocol voor presentatie van credentials door wallet aan verifier	OpenID Foundation / ARF	Beschikbaar; verplicht binnen ARF; relevant voor de verificatiedienst

Voorzieningen¶

Voorziening	Type	Beheer	Instantiëring	Bestaande invulling
Centrale PuB-EAA-uitgifte-dienst (Credential Issuer)	Centrale voorziening (optie)	Centraal — GBO of Logius als beheerder	Gedeelde instantie namens meerdere bronhouders	⚠️ Nog te realiseren; vereist CAR-certificering; bouwt op C5 (bronontsluiting) en C2 (burgeridentificatie)
CAR-certificering voor de uitgifte-dienst	Conformiteitseis	Geaccrediteerde CAB (markt, onder toezicht RDI)	Per uitgifte-dienst	⚠️ Nog te doorlopen; vereiste uit uitvoeringsverordening 2025/1569
Centrale verificatiedienst (Status List / Verifier endpoint)	Centrale voorziening (optie)	Centraal — GBO of Logius	Gedeelde instantie	⚠️ Nog te realiseren; biedt vertrouwende partijen een gestandaardiseerd endpoint voor intrekkingsstatus en uitgeversketen
Opname op Nederlandse Trusted List (LoTE)	Registratie bij RDI	RDI	Eenmalig per erkende uitgevende dienst	⚠️ Vereist goedgekeurde CAR; procedure loopt via RDI conform eIDAS Trusted List Infrastructure
NL Wallet (EUDI Wallet referentie-implementatie NL)	Nationale voorziening	Logius / stelselbeheerder EDI-stelsel	Gedeeld	Beschikbaar als pilotimplementatie; GBO-attesteringen moeten aansluiten op NL Wallet-specificaties

Overzicht: gaps per capability¶

De gaps zijn onderverdeeld in drie categorieën: - ⚖️ Juridische gap — vereist wetgeving of AMvB voordat de technische invulling zinvol is - ⚠️ Technische/organisatorische gap — nog te realiseren binnen bestaand juridisch kader - ✅ Beschikbaar — bestaande invulling die hergebruikt wordt

Capability	Juridische gaps ⚖️	Technische / organisatorische gaps ⚠️	Bestaande basis ✅
1 — Grondslagregistratie	Wdo-grondslag DvTP; AMvB doelbinding en gegevenscategorieën	Grondslagregister als GBO-voorziening; PIP-interface standaard; stelselafspraken intrekking	W3C ODRL; DCAT-AP NL
2 — Burgeridentificatie & Pseudonimisering	—	BSNk PP-integratie voor DvTP (onboarding portaal en PEP); betrouwbaarheidsniveau-beleid per traject	BSNk PP (productie); DigiD; eIDAS-knooppunt
3 — Vertrouwensstelsel	—	GBO-vertrouwensprofiel (welke trust anchors per traject); OIN ↔ KvK ↔ eIDAS-identifier koppeling; GBO-aansluitvoorwaarden	FDS Poortwachter; FDS Marktmeester; FSC Directory; PKI Overheid; OIN-register
4 — Autorisatie (PEP/PDP)	—	Volledige PEP/PDP/PIP-keten nog te realiseren; GBO AuthZEN-profiel; Policy Store; BSN-resolving post-decision	OPA/Rego (iWlz, productie); FTV/AuthZEN (pilot)
5 — Bronontsluiting API	—	Query Template Registry; GraphQL als FDS-datadienst-type positioneren; GBO onboardingprocedure bronhouders	FSC (productie); FDS Poortwachter; DCAT-AP NL; iWlz GraphQL-patroon
6 — OOTS-brug	—	OOTS-EDM Adapter; SMP Publisher; operationele inrichting Domibus voor GBO	Domibus (open source, EC); AS4/OOTS-EDM standaarden
7 — Toestemmingsportaal	Wdo-grondslag DvTP; wettelijke verankering vrijwilligheidseis en gelijkwaardig alternatief als aansluiteis	Portaal zelf; BSNk-onboarding portaal; UX-richtlijnen toestemmingspresentatie; transparantie-eis uitwerking	DigiD; BSNk Activate
8 — Logging & Audit	—	LDV-profiel per GBO-component; inzagevoorziening burger	LDV (in consultatie, referentie-impl. beschikbaar); OpenTelemetry; iWlz TraceID/SpanID RFC (productie)
9 — Semantiek	—	Schema Registry; serialisatie-service; mappings naar OOTS-EDM en PuB-EAA	FDS Datacatalogus; DCAT-AP NL; OOTS-EDM
10 — Attesteringsuitgifte	CAR-certificering uitgifte-dienst; opname op NL Trusted List (RDI)	Centrale uitgifte-dienst; Attestation Rulebooks per attribuuttype; wallet binding profiel; verificatiedienst; intrekkingsbeleid	OpenID4VCI; SD-JWT VC; ARF; NL Wallet (pilot)

Bijlage: GBO-afsprakenstelsel¶

Er is een afsprakenstelsel nodig dat de bovenstaande capabilities verbindt in één samenhangend geheel van afspraken, standaarden en voorzieningen. Het iWlz-afsprakenstelsel is hiervoor de aangewezen blauwdruk: het is gelaagd opgebouwd, formeel vastgesteld, en heeft een werkend RFC-proces voor wijzigingen.

De aanbevolen lagenstructuur voor het GBO-afsprakenstelsel, analoog aan iWlz:

Laag	Inhoud voor GBO
Organisatiebeleid	Governance, rollen (bronhouder, afnemer, GBO-beheer), ontwerpkeuzes, serviceafspraken, wijzigingsbeheer
Proces	GBO-trajectprocessen: DvTP-toestemmingsstroom, OOTS-brugstroom, EDI-wallet uitgifte- en presentatiestroom
Informatie	Gegevensmodellen per bronhouder, canonieke schema's, mappings naar OOTS-EDM en PuB-EAA
Applicatie	Technische afspraken per capability: PEP/PDP-keten, FSC-profiel, BSNk PP-integratie, query-templates
IT-infrastructuur	Connectiviteit (FSC), certificaten (PKI Overheid), netwerkeisen, SLA's
Uitwisselprofielen	Per traject (DvTP, OOTS, EDI-wallet): specifieke afspraken aanvullend op de generieke lagen

Wijzigingen in het GBO-afsprakenstelsel verlopen via een formeel RFC-proces, analoog aan de iWlz RFC-aanpak, met gepubliceerde versies en expliciete inwerkingtreding per implementatiestap.

NB: waar nu sprake is van het GBO-afsprakenstelsel, kunnen de afspraken landen in bestaande afsprakenstelsels en wetgeving.
Een voorstel hiervoor:
- Afspraken die uitsluitend overheid-overheid betreffen → landen in het FDS-afsprakenstelsel
- Afspraken waarbij ook private partijen zijn betrokken (toelating dienstverleners, aansluitvoorwaarden, vrijwilligheidseis) → landen in het TIP-afsprakenstelsel (Spoor 1 governance, niet het TIP-transport)
- Wat wettelijk verankerd moet zijn → in Wdo en AMvB

Realisatiestrategie¶

Beschrijving van:

pilot
gefaseerde implementatie
validatie via use cases
stelselfuncties bij bestaande gremia

Vraagstukken en ontwerpkeuzes¶

Inleiding¶

In dit hoofdstuk worden de vraagstukken waarvoor een oplossing gevonden moet worden of waarvoor een keuze gemaakt moet worden besproken.
Als er een oplossing is gevonden of een keuze is gemaakt, wordt dit in dit hoofdstuk als ontwerpkeuze vastgelegd. De verdere uitwerking vindt plaats in het technisch ontwerp.

Identificatie & authenticatie private partijen¶

eHerkenning is de logische kandidaat, maar de onboarding, accreditatie en het onderscheid tussen directe afnemers en intermediairs/integrators moeten worden uitgewerkt. TIP biedt hiervoor aanknopingspunten.

Burgeridentificatie en het BSN¶

Het BSN mag bij private partijen niet direct worden doorgegeven. Dit vereist een pseudonimiseringslaag of sector-ID, terwijl voor OOTS de eIDAS-identifier geldt en de wallet werkt met SD-JWT VC-attributen. Dit zijn drie verschillende regimes op één generieke ontsluiting.

BSNk-PP dienst van BZK?

Vertrouwensstelsel¶

Welke partijen mogen deelnemen, hoe worden ze geaccrediteerd, welke niveaus van zekerheid gelden per gegevenstype, en hoe verhouden PKI(O), eHerkenning, eIDAS, FDS en TIP-afspraken zich tot elkaar?

Toestemming¶

De wettelijke grondslag (via Wdo/AMvB), de technische implementatie (toestemmingsregister, tokens, TTL), intrekking, en het onderscheid met OOTS waar toestemming een "verklaring van instemming" is, en de wallet waar de burger zelf de credential beheert.

Toestemmingsvoorziening¶

De OOTS-verplichte toestemmingspreview (SDG-verordening) is momenteel belegd bij RINIS-basisinrichting. Als GBO de toestemmingsflow overneemt, moet worden bepaald of het preview-scherm bij RINIS blijft of naar GBO verhuist. Dit raakt de verantwoordelijkheidsverdeling en dient te worden beslecht vóór technisch ontwerp.

Gekwalificeerde elektronische attesteringen van attributen¶

Hoe laten we attributen elektronisch kwalificeren? Hoe wordt de "attesteringsuitgifte" ingericht?
Dit is nodig voor de Wallet, maar mogelijk ook voor de andere use cases. Er is Europese Wetgeving, maar die laat nog ruimte voor de inrichting en wie welke rol invult.

Gebruik QEAA / QTSP?
Inrichten Pub-EAA?
Centrale verificatiedienst tbv QEAA?

Centrale Componenten¶

Ontwerpprincipe D01 stelt "Decentraal wat kan, centraal wat moet". Dit geldt als uitgangspunt, maar als een centrale voorziening voldoende voordelen biedt, past in de geldende wet- en regelgeving en niet tegn andere ontwerpprincipes ingaat, dan kan ervoor gekozen worden hiervoor te kiezen.
Bij de volgende voorzieningen die in theorie decentraal ingericht kunnen worden, wordt een centrale inrichting overwogen:

PuB-EAA dienst waar alle overheidsbronnen gebruik van kunnen maken.
Verificatiedienst waarmee QTSP's gegevens kunnen verifiëren en waar alle overheidsbronnen gebruik van kunnen maken.
Vertaalvoorziening om GraphQL verzoeken om te zetten naar REST/API verzoeken voor overheidsbronnen die (nog) geen eigen GraphQL implementatie willen/ kunnen realiseren.

Transformatie-architectuur¶

Hoe één bronhouder-API leidt tot drie verschillende afnemerprotocollen (DvTP/REST+OAuth, OOTS/AS4+eDelivery, Wallet/OID4VC)? Dit is het technische hart van de "bronhouder één keer, afnemer naar wens"-ambitie.

RINIS biedt een dienst om berichten uit te wisselen tussen OOTS/eDelivery/AS4 en REST-API?
Vanuit Synergy en UBO is gekeken naar het koppelen van OOTS en de Wallet.
Onze oplossingsrichting werkt vanuit de FDS-standaarden (REST-API/ GraphQL).

Ended: PSA

Technisch ontwerp ↵

GBO Reference Architecture¶

Executive Summary¶

GBO (Gemeenschappelijke Bronontsluiting) provides a common source access layer enabling government data sources -- Belastingdienst, RvIG, DUO, UWV, gemeenten -- to serve five consuming trajectories through a single technical backbone:

DvTP (Delen via Toestemming met Private partijen): Consent-based data sharing from government to private sector (fully in draft -- no documents finalized)
EDI-wallet (European Digital Identity): Citizen-held attestations from government sources, issued by a shared PubEAA Provider
SDG-OOTS (Single Digital Gateway): Cross-border evidence exchange within the EU
Gov-to-Gov: Direct government-to-government data exchange over FSC + GraphQL, authorized by legal basis
Authentic Source Interface (ETSI TS 119 478): Mandated by Article 45e eIDAS -- enables QTSPs to verify attributes against government registers so they can issue QEAAs

The architecture rests on seven pillars:

Pillar	Standard	Proven by
Data access	GraphQL with scope-driven field authorization (dienstencatalogus) + constraint-based where-clause binding, validated via `graphql.parse_query()` AST inspection	iWlz / nID (healthcare, production)
Authorization	Five-factor authorization model → federated PDP (OPA/Rego) via AuthZEN, no central authorization server. FSC Manager issues cert-bound JWTs. PAP (Policy Administration Point) distributes signed bundles via OCI registry.	iWlz + FTV + FSC
Connectivity	FSC (domestic REST) + AS4 bridge (cross-border, EU mandate)	FSC (government), Domibus (EU)
Consent / Legal basis	Toestemmingsregister as PIP for consent-based access; legal basis encoded in policy bundles for law-mandated access. Two paths, same PDP. Single consent spans multiple bronhouders; wettelijke dienstencatalogus caps maximum scope.	New -- replaces DvTP's custom authorization
Pseudonymization	BSNk PP polymorphic pseudonyms for BSN-free private sector queries	BSNk PP (Logius, production)
EUDI issuance	PubEAA Provider (shared, optional per bronhouder) + OpenID4VCI	New -- avoids 100% QTSP reliance
EUDI verification	Authentic Source Interface (ETSI TS 119 478, I2 Verify + I4 Authorize)	New -- Article 45e mandate

Architecture Overview¶


graph TB
    subgraph Consumers
        direction TB
        HV[Hypotheekverlener]
        WALLET[EUDI Wallet]
        EU_PROC[EU Online Procedure]
        GOV["Afnemer (overheid)"]
        QTSP[QTSP]
    end

    subgraph "GBO Shared Services"
        direction LR
        PORTAL[Toestemmingsportaal]
        CREG[(Toestemmingsregister / PIP)]
        BSNK[BSNk PP - Pseudonymization]
        SECTOR_PIP["Sector PIPs<br/>(KNB, KvK, BIG)"]
        ASIP[Authentic Source Interface]
        PUBEAA[PubEAA Provider]
        AS4_BRIDGE[SDG-OOTS Adapter]
        DOMIBUS[Domibus Access Point]
    end

    subgraph "Central — Policy Distribution"
        OCI["PAP — OCI Registry<br/>(signed OPA bundles)"]
    end

    subgraph "Bronhouder (e.g. Belastingdienst)"
        direction TB
        MGR["FSC Manager<br/>(Manager PDP ①②)"]
        FSC_IN[FSC Inway]
        PEP[PEP]
        PDP["Bronhouder PDP ③④⑤<br/>OPA/Rego"]
        GQL[GraphQL API]
    end

    %% Policy distribution — same PAP feeds both PDPs
    OCI -->|"OPA Bundle API"| MGR
    OCI -->|"OPA Bundle API"| PDP

    %% DvTP flow
    HV -->|"FSC Outway<br/>mTLS + PKI-O"| MGR
    MGR -->|"JWT with<br/>verified claims"| FSC_IN
    FSC_IN --> PEP
    PEP -->|"AuthZEN eval"| PDP
    PDP -.->|"consent check<br/>(DvTP only)"| CREG
    PEP -->|"if allowed"| GQL

    %% Manager PIP
    SECTOR_PIP -.->|"org attributes"| MGR

    %% Consent flow
    HV -.->|"redirect citizen"| PORTAL
    PORTAL -->|"write consent"| CREG
    PORTAL -->|"activate/transform"| BSNK
    BSNK -.->|"EP in consent token"| HV
    PEP -->|"resolve PI to BSN"| BSNK

    %% Gov-to-Gov flow
    GOV -->|"FSC"| MGR

    %% EUDI issuance flow (PubEAA Provider)
    WALLET -->|"OpenID4VCI"| PUBEAA
    PUBEAA -->|"FSC"| FSC_IN

    %% Authentic Source Interface flow
    QTSP -->|"I2 Verify"| ASIP
    ASIP -->|"FSC"| FSC_IN

    %% OOTS flow
    EU_PROC -->|"AS4"| DOMIBUS
    DOMIBUS --> AS4_BRIDGE
    AS4_BRIDGE -->|"REST/FSC"| MGR

    style CREG fill:#5b2d6b,stroke:#333,color:#fff
    style PDP fill:#5b2d6b,stroke:#333,color:#fff
    style PEP fill:#5b2d6b,stroke:#333,color:#fff
    style MGR fill:#5b2d6b,stroke:#333,color:#fff
    style SECTOR_PIP fill:#5b2d6b,stroke:#333,color:#fff
    style AS4_BRIDGE fill:#2d7a2d,stroke:#333,color:#fff
    style BSNK fill:#6b3a6b,stroke:#333,color:#fff
    style GQL fill:#2d7a2d,stroke:#333,color:#fff
    style PUBEAA fill:#1a5276,stroke:#333,color:#fff
    style ASIP fill:#1a5276,stroke:#333,color:#fff
    style HV fill:#1a3c4d,stroke:#333,color:#fff
    style WALLET fill:#1a3c4d,stroke:#333,color:#fff
    style EU_PROC fill:#1a3c4d,stroke:#333,color:#fff
    style GOV fill:#1a3c4d,stroke:#333,color:#fff
    style QTSP fill:#1a3c4d,stroke:#333,color:#fff

The architecture separates concerns cleanly:

Bronhouders expose a single GraphQL API behind an FSC Inway with PBAC enforcement. They do not implement trajectory-specific protocols. Each bronhouder runs a federated PDP (OPA/Rego) loaded with centrally-authored, signed policy bundles.
The GBO edge layer handles protocol translation: consent portal + BSNk PP for DvTP, Domibus/AS4 bridge for OOTS (EU mandate), PubEAA Provider for EUDI wallet issuance, Authentic Source Interface for QTSP attribute verification (Article 45e).
Authorization is federated: every data request passes through the same PEP/PDP chain at the bronhouder. The FSC Manager (provider-side) issues cert-bound JWTs — there is no central authorization server. The toestemmingsregister (PIP) is the only centralized runtime dependency, and only for consent-based flows. Legal basis flows evaluate entirely locally.
PAP (Policy Administration Point) is a central policy service with async distribution: policies authored by GBO Gremium, signed, distributed as OPA bundles via OCI registry (the PAP), pulled independently by each bronhouder's PDP at regular intervals.
Gov-to-Gov is the simplest path: direct FSC Outway → Manager → Inway with legal-basis authorization, no consent or pseudonymization needed.
The PubEAA Provider is shared infrastructure -- bronhouders can optionally run their own Credential Issuer, but the default path avoids 100% reliance on commercial QTSPs for government-sourced attestations.

Core Design Decisions¶

1. GraphQL over REST for Bronontsluiting APIs¶

Decision: Bronhouders expose GraphQL endpoints, not REST APIs.

Why: REST requires additional patterns to achieve field-level data minimization. Data minimization in DvTP means you need different field sets per consent scope. With REST, that means separate endpoints per scope or custom filter parameters -- and then policies to control which filters each consumer may use. Over time, this can lead to duplicated logic between the API layer and the policy layer.

With GraphQL, data minimization is the default. Each consumer sends a query selecting exactly the fields they need. The policy engine controls which parts of the schema each consumer can access. The query IS the data minimization.

Precedent: iWlz runs GraphQL + OPA/Rego in production for sensitive healthcare data (WLZ Indicatieregister). The pattern is proven at scale with Dutch government data.

FDS compatibility: FDS does not prohibit GraphQL. The IMX orchestration engine already supports GraphQL as a backend. Lock-Unlock explicitly identifies the problem with REST for fine-grained access. GraphQL runs over HTTP -- FSC Inway/Outway proxies it without modification.

Decision: Authorization concern ③ (access basis) has two paths. For consent-based access (DvTP): when a citizen gives consent via the portal, it is written to a register that serves as a PIP for the PBAC authorization chain. For legal basis access (wettelijke grondslag): the legal basis is encoded in the signed policy bundle and evaluated locally — no PIP call needed, no citizen involvement. Both paths use the same PDP; the Rego policy branches on whether a legal_basis or consent_id claim is present.

What this replaces (from DvTP draft v0.1 -- note: all DvTP documents are in draft status, nothing has been finalized):

DvTP draft v0.1 component	Replaced by	Why
Autorisatievoorziening (custom gateway)	PEP + PDP (FTV/AuthZEN standard)	Reusable across all trajectories
Vertrouwensleverancier + trust token	FSC Contract + mTLS	FSC already handles org-level trust
Double consent check at bronhouder	Single PDP evaluation at PEP	Policy decision is authoritative
Consentregister (standalone database)	Same register, exposed as PIP	Same data, standard interface

The citizen experience is identical. The change is plumbing: what happens after consent is recorded, and how the data request is authorized.

Decision: Toestemmingen (consents) are not 1:1 linked to a single bronhouder or data source. A single toestemmingsaanvraag can span multiple bronhouders and data elements simultaneously. A wettelijke dienstencatalogus defines the maximum reikwijdte (scope) of what may be requested. Integrators (softwarepartijen) that technically execute API calls must be separately onboarded.

Multi-source consent: A citizen giving consent for a mortgage application does not give five separate consents to five separate bronhouders. Instead, the toestemmingsportaal presents a single consent screen covering all required data elements across sources. One consent action, multiple bronhouders:

Bronhouder	Data element	Voorbeeld scope-ID
Belastingdienst	IB vorig jaar	`bd:ib:2025`
Belastingdienst	IB jaar daarvoor	`bd:ib:2024`
DUO	Studieschuld	`duo:studieschuld`
UWV	Inkomen	`uwv:inkomen`
BKR	Kredietregistratie	`bkr:registratie`

The toestemmingsregister stores this as a single consent record with multiple scope entries. Each scope entry references a bronhouder + data element + time period. When a dienstverlener later queries a specific bronhouder, the PDP checks whether the consent record includes a matching scope entry for that bronhouder -- not whether a separate consent exists.

Wettelijke dienstencatalogus as ceiling: The dienstencatalogus is a legally anchored register (grondslag in AMvB / ministeriële regeling) that defines the maximum reikwijdte of data that may be requested per use case. It acts as a policy ceiling:

The consent screen can only show data elements that appear in the dienstencatalogus for the relevant use case
The PDP enforces the catalog as a hard constraint -- even if a consent record somehow includes a scope outside the catalog, the policy denies it
The catalog is maintained by Bureau DvTP and updated through a formal governance process (sectorvertegenwoordiger → Bureau DvTP → departementale toetsing)

This separation means: the dienstencatalogus defines what is maximally possible, the citizen's consent defines what is actually permitted for a specific request.

Two-axis enforcement — scopes + constraints: GraphQL authorization in GBO combines two complementary mechanisms, following the pattern proven by nID/iWlz in production:

Scopes (field-level / column axis): The dienstencatalogus defines which GraphQL fields are allowed per scope. Each scope in a consent record (e.g., bd:ib:2025) maps to a set of allowed fields in the catalog. The PDP parses the incoming GraphQL query into an AST using OPA's built-in graphql.parse_query() and verifies that every requested field is within the allowed set for the granted scopes. This enforces data minimization — a hypotheekverlener cannot request inkomenUitBox3 if the scope only allows verzamelinkomen and inkomenUitBox1.
Constraints (record-level / row axis): Like nID/iWlz, the PDP enforces that mandatory where-clause arguments are present in the query and that their values match the caller's identity claims. For DvTP, the consent_id must appear as a where-clause argument (binding the query to a specific citizen's consent). For Gov-to-Gov, the requesting organization's OIN and legal basis must appear. The PDP inspects the AST to verify these structural constraints — not just field names, but argument presence and value binding.

Together, scopes answer "which fields may you see?" and constraints answer "which records may you access?". Neither alone is sufficient: scopes without constraints allow accessing any citizen's data; constraints without scopes allow seeing all fields including those outside the consent.

Integrator / softwarepartij onboarding: The dienstverlener (e.g., a hypotheekverlener) is not always the party that technically sends API requests. In practice, a softwarepartij (integrator) builds and operates the technical integration. This party must be separately onboarded:

The integrator receives its own PKI-O certificate and FSC registration
The FSC Manager verifies both the integrator's identity (① org identity) and the dienstverlener on whose behalf they act (② org permission via delegation grant)
The integrator acts as a transparent relay -- it cannot access or modify the data content (consistent with DvTP's "doorgeefluik" principle)
Onboarding includes: compliance check (AVG, security), technical certification, and registration in the dienstencatalogus as an approved softwarepartij for the relevant use case

4. BSNk PP for BSN Pseudonymization¶

Decision: Private dienstverleners never see or process the BSN. The Toestemmingsportaal uses BSNk PP (Logius' production polymorphic pseudonymization infrastructure) to generate per-party encrypted pseudonyms. Bronhouders receive the actual BSN through the identity path. The consent_id serves as the opaque bridge between the two worlds.

The problem: Private parties (hypotheekverleners, insurers) are not legally allowed to process BSN (Wabb/Wabvpz restrictions). Yet DvTP requires them to query government registers about a specific citizen. The naive solution -- passing BSN to the private party -- is illegal and creates a universal correlation key.

How BSNk PP solves it: BSNk PP uses modified El Gamal encryption on elliptic curves (Eric Verheul, Radboud University) to transform a BSN into recipient-specific, irreversible pseudonyms. The Pseudonymization Facility transforms encrypted curve points without ever seeing the plaintext BSN.

Citizen authenticates → DigiD → BSN (government-internal) ↓ BSNk Activate: BSN → PI + PP (encrypted curve points) ↓ Consent portal stores PI + PP in consent record ↓ ┌────────────────────────┴────────────────────────┐ ↓ ↓ BSNk Transform: PP → EP BSNk Transform: PI → EI (for private dienstverlener) (for bronhouder, via PEP) ↓ ↓ Dienstverlener decrypts EP PEP decrypts EI → BSN → party-specific pseudonym → queries bronhouder by BSN (cannot derive BSN) (government-internal)

Security properties (formally proven under DDH assumption):

Private party cannot derive BSN from their pseudonym
Two cooperating private parties cannot link their pseudonyms for the same citizen
Each transformation is randomized: repeated uses are cryptographically unlinkable
The Pseudonymization Facility never sees the BSN
The consent portal generates different encrypted forms per bronhouder and per dienstverlener

Why not simple PKI encryption? BSNk PP adds three properties that simple "encrypt BSN with public key" lacks: (1) non-BSN-authorized parties decrypt to a pseudonym, not the BSN; (2) randomization makes repeated uses unlinkable; (3) the closing key ensures even the KMA and PF cannot compute final pseudonyms. Plus, BSNk PP is already running in production at Logius -- no new infrastructure to build.

Precedent: BSNk PP has been operational since ~2019, serving the entire eToegang ecosystem. It is not a proposal; it is an integration of existing government infrastructure.

5. Five-factor authorization model — Federated PDP, No Central Authorization Server¶

Decision: Authorization is not one question but five independent checks. Each has a different change frequency, decision maker, and protocol. All are evaluated by a federated PDP (OPA/Rego) at each bronhouder. There is no central authorization server.

#	Concern	Policy Question	Protocol	Decision Format	Evaluation Moment
①	Org identity	"Is this a legitimate org?"	X.509 / mTLS (PKI-Overheid)	Certificate	At TLS handshake
②	Org permission	"May this org access this service?"	FSC Contract + JWT (RFC 8705 cert-bound)	Signed Grant → JWT	At token request (FSC Manager)
③	Access basis	"Is there a legal/consent basis?"	Toestemmingsregister PIP query OR legal basis in policy bundle	Consent record or policy rule	Per-request (consent) or from bundle (legal basis)
④	Data scope	"Which fields may be returned?"	OPA/Rego + `graphql.parse_query()` AST inspection	Scope (allowed fields) + Constraint (where-clause binding)	Per-request (local)
⑤	Request validity	"Is this specific request well-formed?"	OpenID AuthZEN 1.0	allow/deny	Per-request (local)

Every data request passes through all five checks as a pipeline:

graph LR
    REQ[Request] --> C1
    C1["① Org Identity<br/>mTLS + PKI-O X.509"] --> C2
    C2["② Org Permission<br/>FSC Contract + JWT"] --> C3
    C3["③ Access Basis<br/>Consent PIP or Legal Basis"] --> C4
    C4["④ Data Scope<br/>GraphQL template"] --> C5
    C5["⑤ Request Validity<br/>AuthZEN eval"] --> DATA
    DATA[Response]

    style C1 fill:#2d6a2d,stroke:#333,color:#fff
    style C2 fill:#2d5f8a,stroke:#333,color:#fff
    style C3 fill:#8b3a8b,stroke:#333,color:#fff
    style C4 fill:#8a6d2d,stroke:#333,color:#fff
    style C5 fill:#8a2d2d,stroke:#333,color:#fff

Policy-driven FSC Manager: The FSC Manager is upgraded from a simple grant lookup to a policy-driven token issuer — it runs its own OPA/Rego PDP, loaded from the same PAP as the bronhouder PDP, with access to PIPs for organizational attribute verification. This solves two problems at once:

Organizational attributes — PKI-O proves who (OIN), but not what kind of organization. The Manager's PDP queries sector PIPs (KvK SBI codes, professional registers like KNB for notarissen, BIG for healthcare) to verify "this OIN is a notaris" before issuing a JWT with a sector claim.
Sector-level grants — Instead of 800 individual contracts between 800 notariskantoren and the Belastingdienst, a single SectorConnectionGrant says "notarissen may access kadaster data." The Manager verifies sector membership via PIP at token issuance time.

The architecture becomes one pattern, applied twice: the Manager PDP evaluates concerns ①② (org identity + attributes + permission) at token issuance; the bronhouder PDP evaluates concerns ③④⑤ (access basis + data scope + request validity) per-request. Both load policies from the same PAP, both query PIPs — just different ones.

See Authorization Models Analysis §9.5 for the full design including sector grant types, Manager PDP Rego policies, and the PIP integration pattern.

No central authorization server: Unlike iWlz (VECOZO autorisatieserver) or the NL GOV OAuth2 pattern, GBO uses the FSC Manager at each provider as the token issuer. The Manager is federated — each provider runs their own. Consent (concern ③) is verified per-request by the bronhouder PDP via the toestemmingsregister — it was never in the token. There is nothing a central AS would add.

Two access basis paths — consent and legal basis are handled by the same PDP, different policy rules:

Path	When	PDP behavior	Network dependency
Consent-based (DvTP)	Citizen gave consent in MijnOverheid	PDP queries toestemmingsregister PIP per-request	Yes — PIP is only runtime network call
Legal basis (wettelijke grondslag)	Law mandates access (e.g., Participatiewet Art. 64)	PDP evaluates legal basis from signed policy bundle — no PIP call	None — pure local evaluation

Policy lifecycle: Policies are authored centrally (GBO Gremium), stored in Git, built into signed OPA bundles, published to an OCI registry that acts as the PAP (Policy Administration Point), and pulled by each bronhouder's PDP independently at regular intervals.

graph LR
    subgraph BUILD["Central — Policy Distribution"]
        GOV["GBO Gremium"] -->|"author"| GIT["Git repo"]
        GIT -->|"merge + CI"| OCI["PAP — OCI Registry<br/>signed bundles"]
    end

    subgraph RUNTIME["Federated — per provider"]
        OCI -->|"OPA Bundle API"| MGR_PDP["Manager PDP<br/>token issuance ①②"]
        OCI -->|"OPA Bundle API"| BH_PDP_A["Bronhouder PDP A<br/>request eval ③④⑤"]
        OCI -->|"OPA Bundle API"| BH_PDP_B["Bronhouder PDP B<br/>request eval ③④⑤"]
    end

    subgraph PIPS["PIPs — runtime"]
        TR["Toestemmingsregister<br/>(consent)"]
        SECTOR["Sector registers<br/>(KNB, KvK, BIG)"]
    end

    MGR_PDP -->|"JWT with<br/>verified claims"| BH_PDP_A
    SECTOR -.->|"org attributes"| MGR_PDP
    TR -.->|"consent check<br/>(DvTP only)"| BH_PDP_A
    TR -.->|"consent check"| BH_PDP_B

    style BUILD fill:#1a2a3a,stroke:#48a,color:#fff
    style RUNTIME fill:#1a3a1a,stroke:#4a4,color:#fff
    style PIPS fill:#3a1a3a,stroke:#a4a,color:#fff

All authorization evidence -- consent records (DvTP), legal basis (OOTS, domestic law-based), wallet presentations (EUDI) -- is translated into AuthZEN Subject/Action/Resource/Context evaluations at the PEP, then evaluated by OPA/Rego policies:

Trajectory	Authorization input	Access basis path	AuthZEN translation
DvTP	Citizen consent in register	Consent → PIP query	Subject=provider org, Resource=consent_id+scope, Context=consent record from PIP
SDG-OOTS	Legal basis (SDG Regulation)	Legal basis → policy bundle	Subject=requesting MS, Resource=evidence type, Context=OOTS request metadata
Domestic legal basis	Law mandates access (e.g., Participatiewet)	Legal basis → policy bundle	Subject=requesting org, Resource=register+BSN, Context=legal_basis claim
EDI-wallet (PubEAA issuance)	EUDI wallet PID via OpenID4VCI	Self-request (citizen = data subject)	Subject=citizen (via PID), Resource=attestation type, Context=PubEAA Provider trust status
Authentic Source (Art. 45e)	OAuth token (citizen-authorized) + QTSP status	Citizen-authorized → OAuth	Subject=QTSP (on Trusted List), Resource=attribute type, Context=citizen authorization via I4/I5

One PDP, one policy language, one enforcement point. Multiple trajectories, multiple policy sets — no central authorization server needed.

For the full protocol-level analysis including JWT anatomy, Rego examples, and sequence diagrams for each system, see Authorization Models Analysis.

6. FSC-Primary Connectivity¶

Decision: FSC handles all domestic connectivity. Cross-border (OOTS) traffic arrives via an AS4 bridge that translates to FSC at the edge. There is no need for additional domestic transport protocols -- FSC is the single domestic connectivity stack.

Bronhouders implement one connectivity stack (FSC Inway). The GBO edge layer handles OOTS cross-border translation.

7. AS4 Bridge for SDG-OOTS (EU Mandate)¶

Decision: A Domibus Access Point handles SDG-OOTS cross-border evidence exchange. This is an EU regulatory requirement (Single Digital Gateway Regulation), not a choice.

GBO builds this bridge because it must. The bridge translates OOTS AS4 requests into FSC/GraphQL requests toward bronhouders. This is the only scenario where AS4 is needed -- all domestic traffic uses FSC directly.

Component Architecture¶

GraphQL Schema Registry + Scope-Driven Field Authorization¶

Each bronhouder publishes a GraphQL schema describing their data. The dienstencatalogus defines which fields are allowed per scope — not as static query templates, but as field allowlists that the PDP evaluates against the parsed query AST at runtime. This follows the approach proven by nID/iWlz, extended with field-level scope enforcement for DvTP's data minimization requirements.

graph LR
    subgraph "Schema Registry (GBO Catalogus)"
        SCHEMA_BD["Belastingdienst (BRI): InkomensgegevensPerJaar, Aanslag"]
        SCHEMA_DUO["DUO: Diploma, Inschrijving, Studieschuld"]
        SCHEMA_UWV["UWV: Inkomen, Dienstverbanden"]
    end

    subgraph "Dienstencatalogus (scope → allowed fields)"
        S1["bd:ib:* → verzamelinkomen, inkomenUitBox1, grondslag, peilDatum"]
        S2["duo:studieschuld → hoofdsom, openstaandSaldo, maandbedrag"]
        S3["uwv:inkomen → brutoJaarinkomen, dienstverbanden"]
    end

    S1 -->|"subset of"| SCHEMA_BD
    S2 -->|"subset of"| SCHEMA_DUO
    S3 -->|"subset of"| SCHEMA_UWV

The PDP uses OPA's built-in graphql.parse_query() to parse the incoming query into an AST, then enforces two checks:

Scope check (field axis): every field in the query's selection set must appear in the allowed field set for the granted scopes in the dienstencatalogus
Constraint check (record axis): mandatory where-clause arguments must be present and their values must match the caller's identity claims (consent_id for DvTP, OIN + legal_basis for Gov-to-Gov)

Example: Belastingdienst BRI schema (subset of full schema)

```graphql type InkomensgegevensPerJaar { belastingjaar: Int! verzamelinkomen: Int inkomenUitBox1: Int inkomenUitBox2: Int inkomenUitBox3: Int grondslag: CodeOmschrijving # e.g. "Definitieve aanslag IB" status: CodeOmschrijving # e.g. "Definitief vastgesteld" peilDatum: Date }

type Aanslag { belastingjaar: Int! soort: SoortAanslag! # VOORLOPIG | DEFINITIEF dagtekening: Date! verzamelinkomen: Int verschuldigdeBelasting: Int teBetalen: Int # positief = betalen, negatief = terug status: AanslagStatus! }

input InkomensgegevensInput { burgerservicenummer: BSN! belastingjaren: [Int!] # Data minimization via GraphQL selection set — PDP validates fields against dienstencatalogus }

type Query { inkomensgegevens(input: InkomensgegevensInput!): [InkomensgegevensPerJaar!]! aanslagen(input: AanslagenInput!): [Aanslag!]! inkomensverklaring( input: InkomensverklaringInput! ): InkomensverklaringResponse! } ```

Note: this is the bronhouder-internal schema — it uses burgerservicenummer: BSN! directly. For DvTP queries, the dienstverlener never sees BSN. The PEP sits in front and translates: the consumer sends a query with consent_id, the PEP resolves consent_id → PI → BSNk Transform → EI → BSN, then forwards the query to the bronhouder's internal API with the BSN substituted. Debt data (hypotheekschuld, studieschuld) is not in the BRI — it comes from other bronhouders (DUO, BKR).

Example: DvTP query for "aankoop-woning" consent — Belastingdienst leg

The dienstverlener sends a query with consentId as subject. The PEP intercepts, resolves consent_id → BSN via BSNk PP, and forwards to the bronhouder's internal API. Here is the consumer-facing query:

```graphql

Dienstverlener sends this via FSC — consentId is the subject, no BSN¶

The selection set IS the data minimization — PDP checks fields against catalog¶

query AankoopWoningInkomen($consentId: UUID!, $jaren: [Int!]!) { inkomensgegevens(input: { consentId: $consentId, belastingjaren: $jaren }) { belastingjaar verzamelinkomen inkomenUitBox1 grondslag { code omschrijving } # inkomenUitBox2 — not in scope bd:ib:, PDP would reject # inkomenUitBox3 — not in scope bd:ib:, PDP would reject } } ```

The PEP translates this to the bronhouder-internal query (substituting BSN for consentId):

```graphql

Bronhouder-internal — PEP has resolved consentId → BSN via BSNk PP¶

query { inkomensgegevens( input: { burgerservicenummer: "123456789", belastingjaren: [2025, 2024] } ) { belastingjaar verzamelinkomen inkomenUitBox1 grondslag { code omschrijving } } } ```

The PDP validates the consumer-facing query by:

Parsing the query into an AST via graphql.parse_query()
Scope check: the consent record includes bd:ib:2025 → dienstencatalogus maps this to allowed fields {verzamelinkomen, inkomenUitBox1, grondslag, peilDatum} → all requested fields are in this set → pass
Constraint check: consentId argument is present and matches a valid consent_id with withdrawn == false and valid_until in the future → pass

The dienstverlener sends separate queries to each bronhouder in the consent (one to Belastingdienst for income, one to DUO for studieschuld, one to UWV for employment income, etc.). Each bronhouder's PDP independently validates its leg against the shared consent record and its own catalog entry.

The same bronhouder schema serves all trajectories. The dienstencatalogus defines different allowed field sets per scope:

Scope	Trajectory	Allowed fields (Belastingdienst BRI)
`bd:ib:*`	DvTP	verzamelinkomen, inkomenUitBox1, grondslag, peilDatum
`income-evidence-eu`	SDG-OOTS	Maps to OOTS-EDM income evidence type fields
`income-attestation`	EUDI	Fields for PuB-EAA income attestation credential

PEP/PDP/PIP Authorization Chain¶

graph TB
    REQ["Consumer request<br/>mTLS + PKI-O cert"] --> MGR

    subgraph "Token Issuance (concerns ① ②)"
        MGR["FSC Manager PDP<br/>(OPA/Rego)"]
        S_PIP[("Sector PIPs<br/>(KNB, KvK, BIG)")]
        M_BUNDLE[("Signed OPA Bundle<br/>(token issuance policies)")]

        MGR -.->|"①→② org attributes"| S_PIP
        MGR -->|"② grant + scope"| M_BUNDLE
    end

    MGR -->|"JWT with verified claims<br/>(sub, sector, scope, grant_hash, cnf)"| IW

    subgraph "FSC Inway"
        IW["FSC Inway<br/>✓ JWT signature<br/>✓ cert-bound (RFC 8705)<br/>✓ grant_hash active"]
    end

    IW --> PEP

    subgraph "Request Evaluation (concerns ③ ④ ⑤)"
        PEP["PEP — Policy Enforcement"]
        PDP["Bronhouder PDP<br/>OPA/Rego via AuthZEN"]
        PIP_C[("Toestemmingsregister<br/>(consent PIP — DvTP only)")]
        BUNDLE[("Signed OPA Bundle<br/>(request eval policies +<br/>templates + legal bases)")]
    end

    PEP -->|"POST /access/v1/evaluation<br/>(AuthZEN 1.0)"| PDP
    PDP -.->|"③ consent check<br/>(DvTP only)"| PIP_C
    PDP -->|"③ legal basis<br/>④ scope + constraint check<br/>⑤ request validity<br/>(all local)"| BUNDLE
    PDP -->|"ALLOW or DENY<br/>+ obligations (field mask)"| PEP

    PEP -->|"if ALLOW"| GQL["GraphQL API"]
    PEP -->|"if DENY"| ERR["Error response<br/>+ reason code"]

    style MGR fill:#2d5f8a,stroke:#333,color:#fff
    style S_PIP fill:#3a1a3a,stroke:#a4a,color:#fff
    style PIP_C fill:#3a1a3a,stroke:#a4a,color:#fff
    style BUNDLE fill:#1a3a1a,stroke:#4a4,color:#fff
    style M_BUNDLE fill:#1a3a1a,stroke:#4a4,color:#fff

The core GBO authorization policy (Rego pseudocode):

This follows the two-axis model: scopes (field-level) + constraints (record-level), using OPA's built-in graphql.parse_query() for AST inspection — the same approach proven in production by nID/iWlz.

```rego package gbo.authz

import future.keywords.in import future.keywords.if

default allow := false

Parse the incoming GraphQL query into an AST (OPA built-in, same as nID/iWlz)¶

query_ast := graphql.parse_query(input.request.query)

Main policy: all five concerns must pass¶

Concerns ① and ② are pre-verified by the FSC Inway (JWT + cert-binding)¶

The PDP evaluates concerns ③, ④, and ⑤¶

allow if { valid_org_permission # Concern ② (double-check grant_hash in active_grants) valid_access_basis # Concern ③ (consent OR legal basis) valid_data_scope # Concern ④ (scope: allowed fields from dienstencatalogus) valid_constraints # Concern ④b (constraint: mandatory where-clause binding) valid_request # Concern ⑤ (well-formed, within rate limits) }

② Org permission: FSC grant hash matches an active grant for this scope¶

valid_org_permission if { grant := data.active_grants[input.subject.fsc_grant] input.context.scope in grant.allowed_scopes }

valid_access_basis if { valid_citizen_consent } valid_access_basis if { valid_legal_basis }

valid_citizen_consent if { input.pip.consent.exists == true input.pip.consent.withdrawn == false time.now_ns() < time.parse_rfc3339_ns(input.pip.consent.valid_until) input.context.scope in input.pip.consent.granted_scopes # scope entry for this bronhouder input.context.scope in data.dienstencatalogus[input.action.use_case].allowed_scopes # catalog ceiling }

③b Legal basis path: no PIP call — evaluated from signed policy bundle¶

valid_legal_basis if { basis := data.legal_basis_registry[input.context.legal_basis] basis.consent_exempt == true input.context.scope in basis.allowed_scopes }

④ Scope axis: every field in the query AST must be in the allowed field set¶

The dienstencatalogus maps each scope to an allowed field set per bronhouder¶

valid_data_scope if { allowed := data.dienstencatalogus[input.context.scope].allowed_fields operation := query_ast.Operations[0] every selection in operation.SelectionSet { every field in selection.SelectionSet { field.Name in allowed } } }

④b Constraint axis: mandatory input arguments must be present and identity-bound¶

Like nID/iWlz: inspect AST arguments, not just field names¶

valid_constraints if { operation := query_ast.Operations[0] # consentId must appear as an input argument (DvTP) some selection in operation.SelectionSet some arg in selection.Arguments arg.Name == "input" some field in arg.Value.Children field.Name == "consentId" }

⑤ Request validity: rate limit, format, timestamp¶

valid_request if { time.now_ns() - time.parse_rfc3339_ns(input.context.timestamp) < 300000000000 data.rate_limits[input.subject.id].requests_last_hour < 1000 }

NOTE: BSN resolution (BSNk Transform) happens AFTER this decision, inside the PEP¶

```

How the two axes work together — the dienstencatalogus drives both:

Axis	What it checks	Data source	nID/iWlz precedent
Scope (fields)	Requested fields ⊆ allowed fields for this scope	`dienstencatalogus[scope].allowed_fields`	New for GBO — nID does not restrict fields because all iWlz actors are government/healthcare with broad access
Constraint (records)	Mandatory where-clause arguments present and identity-bound	AST argument inspection via `graphql.parse_query()`	Direct from nID — `where_required()` pattern, proven in production

The scope axis is necessary because DvTP serves private-sector consumers who should only see the specific fields covered by the citizen's consent. The constraint axis ensures queries are bound to the correct citizen and organization. Neither alone is sufficient.

OOTS AS4 Bridge¶

graph TB
    subgraph "Cross-border (EU)"
        EU_AP[Member State Access Points]
    end

    subgraph "GBO OOTS Bridge"
        DOMIBUS[Domibus Access Point]
        OOTS_ADAPTER[OOTS-EDM Adapter]
        TRANSLATOR[FSC Translator]
        SMP_PUB[SMP 2.1 Publisher]
    end

    subgraph "Source Side"
        FSC_IN[FSC Inway - Bronhouder]
    end

    EU_AP -->|"AS4 eDelivery (OOTS PMode)"| DOMIBUS
    DOMIBUS --> OOTS_ADAPTER
    OOTS_ADAPTER --> TRANSLATOR
    TRANSLATOR -->|"REST/FSC"| FSC_IN
    TRANSLATOR -.->|"publish"| SMP_PUB

    style DOMIBUS fill:#2d7a2d,stroke:#333,color:#fff
    style TRANSLATOR fill:#2d7a2d,stroke:#333,color:#fff

OOTS bridge specifications:

Aspect	Specification
Payload	OOTS-EDM XML (RegRep 4.0)
Trust	PKI certificates (national CAs)
Discovery	SMP 2.1 + NAPTR DNS
MEP	One-Way (request + separate response)
Validation	Schematron (25 rule sets)
Mandate	EU Regulation 2018/1724 (SDG)

The bridge translates OOTS requests into FSC REST requests toward the bronhouder. The bronhouder sees a standard FSC request regardless of whether it originated from a Dutch dienstverlener (DvTP) or a German Einwohnermeldeamt (OOTS).

PubEAA Provider¶

The PubEAA Provider is shared GBO edge infrastructure that issues PuB-EAAs (Public Body Electronic Attestations of Attributes) on behalf of bronhouders. Without it, the Netherlands would rely entirely on commercial QTSPs for issuing attestations based on government sources -- a supply-chain consideration worth addressing.

graph TB
    subgraph "Citizen"
        WALLET[EUDI Wallet]
    end

    subgraph "GBO Edge Layer"
        PUBEAA[PubEAA Provider]
    end

    subgraph "Bronhouder"
        FSC_IN[FSC Inway → PEP → PDP → GraphQL]
    end

    subgraph "Trust Infrastructure"
        LOTE[Trusted List / LoTE]
    end

    WALLET -->|"OpenID4VCI"| PUBEAA
    PUBEAA -->|"query via FSC"| FSC_IN
    PUBEAA -.->|"registered as PuB-EAA issuer"| LOTE

    style PUBEAA fill:#1a5276,stroke:#333,color:#fff

Key properties:

Aspect	Detail
Protocol	OpenID4VCI (same as current EUDI wallet flow)
Data access	Queries bronhouder GraphQL APIs via FSC -- same PEP/PDP chain as all other trajectories
Signing	Qualified electronic seal (PKIoverheid or EUDI Access CA)
Trust	Registered on EUDI Trusted Lists as a PuB-EAA Provider
Scope	Shared but optional -- bronhouders with capacity can run their own Credential Issuer
Authorization	"subject.bsn == resource.bsn" (citizen requests own data) -- same policy as current EUDI issuance

The PubEAA Provider does not change the bronhouder's responsibilities. It is a shared service that handles the OpenID4VCI protocol, credential formatting (SD-JWT VC / mdoc), and qualified seal signing. The bronhouder only needs to expose a GraphQL API behind an FSC Inway -- the same requirement as for all other trajectories.

Authentic Source Interface (ETSI TS 119 478)¶

Article 45e of the amended eIDAS Regulation obliges EU Member States to ensure that QTSPs can verify attributes against authentic sources within the public sector, at the request of the user. ETSI TS 119 478 specifies the interfaces for this. GBO implements the Authentic Source Interface as an edge layer component on top of existing infrastructure.

graph TB
    subgraph "Citizen"
        USER_WALLET[EUDI Wallet / eID]
    end

    subgraph "Trust Service Provider"
        QTSP_NODE[QTSP]
    end

    subgraph "EU Common Services"
        CATALOGUE[Catalogue of Attributes]
    end

    subgraph "GBO Edge Layer"
        ASIP_NODE[Authentic Source Interface]
        AZS_NODE[Authorization Server]
    end

    subgraph "Bronhouder"
        FSC_IN_NODE[FSC Inway → PEP → PDP → GraphQL]
    end

    %% Discovery
    QTSP_NODE -.->|"I1 Discover"| CATALOGUE

    %% User authorization
    USER_WALLET -->|"I5 authorize"| AZS_NODE
    AZS_NODE -->|"OAuth token"| QTSP_NODE

    %% Verification
    QTSP_NODE -->|"I2 Verify (attributes + PID)"| ASIP_NODE
    ASIP_NODE -->|"query via FSC"| FSC_IN_NODE
    ASIP_NODE -->|"verified / not-verified"| QTSP_NODE

    style ASIP_NODE fill:#1a5276,stroke:#333,color:#fff
    style AZS_NODE fill:#1a5276,stroke:#333,color:#fff

Interfaces implemented:

Interface	Status	Purpose
I1 (Discover)	Via EU common services	QTSP discovers available attributes and data service endpoints
I2 (Verify)	Implemented	QTSP sends attribute values + user PID → authentic source confirms verified/not-verified
I3 (Retrieve)	Not implemented	Optional per regulation; PubEAA Provider covers direct issuance
I4 (Authorize)	Implemented	OAuth 2.0 authorization -- citizen authorizes QTSP access
I5 (User)	Implemented	Citizen authenticates via EUDI Wallet or eID, authorizes the verification request

How it maps to GBO: The Authentic Source Interface is a protocol adapter. GBO's bronhouder GraphQL APIs behind FSC Inways are the authentic sources. The ASIP translates I2 (Verify) requests into GraphQL queries via FSC, compares the result with the QTSP-provided attribute values, and returns a verification result. The authorization flow (I4/I5) is analogous to DvTP's consent portal -- different mechanism (OAuth vs consent register), same pattern (citizen authorizes access to their data).

Technical variant: HTTP/OAuth (ETSI TS 119 478 clause 6.1) -- aligns with GBO's REST/FSC stack.

Demo Interaction 1: DvTP -- Hypotheekverlener Queries Income Data¶

Scenario: Jan wants a mortgage. His hypotheekverlener (mortgage provider) needs his income data from the Belastingdienst. Jan must give explicit consent.

Full Sequence¶

sequenceDiagram
    actor Jan as Jan (Burger)
    participant HV as Hypotheekverlener -(Private Dienstverlener)
    participant PORTAL as Toestemmingsportaal -(Government)
    participant DIGID as DigiD / EUDI Wallet
    participant BSNK as BSNk PP -(Logius)
    participant CREG as Toestemmingsregister -(PIP)
    participant FSC_O as FSC Outway -(HV)
    participant MGR as FSC Manager -(Belastingdienst, Manager PDP)
    participant FSC_I as FSC Inway -(Belastingdienst)
    participant PEP as PEP
    participant PDP as Bronhouder PDP -(OPA/Rego)
    participant GQL as GraphQL API -(Belastingdienst)

    Note over Jan,HV: Phase 1: Consent + Pseudonymization

    Jan->>HV: "Ik wil een hypotheek aanvragen"
    HV->>Jan: Redirect to Toestemmingsportaal -(context: scope=aankoop-woning, -provider=HV, return_url=...)

    Jan->>PORTAL: Arrives at consent portal
    PORTAL->>DIGID: Authenticate citizen
    DIGID->>Jan: DigiD login (or EUDI Wallet PID)
    Jan->>DIGID: Authenticates (BSN verified)
    DIGID->>PORTAL: Identity confirmed (BSN: 123456789)

    PORTAL->>BSNK: BSNk Activate(BSN=123456789)
    BSNK-->>PORTAL: Signed PI + Signed PP
    PORTAL->>BSNK: BSNk Transform(PP, target=HV OIN)
    BSNK-->>PORTAL: Encrypted Pseudonym (EP) for HV

    PORTAL->>Jan: Shows consent screen: -"Hypotheekverlener BV wil de volgende -gegevens opvragen: -- Belastingdienst: inkomensgegevens (2024, 2025) -- DUO: studieschuld -- UWV: inkomen -- BKR: kredietregistratie -Geldig voor 30 dagen."
    Jan->>PORTAL: Geeft toestemming (consent granted)

    PORTAL->>CREG: Write consent record: -consent_id=550e8400..., PI=..., -provider=HV, -scopes=[bd:ib:2025, bd:ib:2024, -duo:studieschuld, uwv:inkomen, -bkr:registratie], -expires=2026-04-11
    Note over CREG: No BSN stored -- only PI. -Single consent, multiple bronhouders.

    PORTAL->>Jan: Redirect back to HV with -consent_token(consent_id, EP, scope, expiry, sig)
    Note over HV: HV decrypts EP with own key -+ closing key = party-specific pseudonym. -HV NEVER sees BSN.

    Note over HV,GQL: Phase 2: Token Issuance (Manager PDP evaluates ① ②)

    HV->>FSC_O: GraphQL query (scope: bd:ib) -variables: consentId=550e8400..., jaren=[2025,2024]

    FSC_O->>MGR: POST /token (mTLS + PKI-O cert) -{ grant_hash: "abc123", -scope: "dvtp:aankoop-woning" }

    Note over MGR: Manager PDP evaluates: -✓ ① PKI-O cert valid (OIN = HV) -✓ ② Grant active, scope allowed -✓ ①→② Org type verified (sector PIP)

    MGR-->>FSC_O: JWT { sub: "OIN:...HV", -scope: "dvtp:aankoop-woning", -grant_hash: "abc123", -cnf: { x5t#S256: "..." } }

    Note over HV,GQL: Phase 3: Data Retrieval (Bronhouder PDP evaluates ③ ④ ⑤)

    FSC_O->>FSC_I: POST /graphql + Bearer JWT -(mTLS + PKI-O cert)
    FSC_I->>FSC_I: ✓ JWT signature valid -✓ cert-bound (RFC 8705) -✓ grant_hash active
    FSC_I->>PEP: Forward request

    PEP->>PDP: AuthZEN eval: -subject={org: HV, grant: "abc123"} -action={scope: aankoop-woning, query: <GraphQL body>} -resource={consent_id: 550e8400...} -context={trajectory: dvtp}

    PDP->>CREG: Consent exists for -consent_id 550e8400... + HV + aankoop-woning?
    CREG-->>PDP: Yes, valid until 2026-04-11

    PDP->>PDP: Scope check: requested fields ⊆ -catalog[bd:ib:2025].allowed_fields? Yes. -Constraint check: consent_id in -where-clause? Yes.

    PDP-->>PEP: ALLOW -(obligations: allowed_fields)

    Note over PEP,BSNK: BSN Resolution (government-internal)
    PEP->>BSNK: BSNk Transform(PI from consent, -target=Belastingdienst OIN)
    BSNK-->>PEP: Encrypted Identity (EI) for Belastingdienst
    PEP->>PEP: Decrypt EI with own key = BSN

    PEP->>GQL: Execute GraphQL query -(BSN substituted internally, -never exposed to dienstverlener)
    Note over GQL: Returns ONLY authorized fields: -verzamelinkomen, inkomenUitBox1, -grondslag, peilDatum

    GQL-->>PEP: Sealed response (qualified electronic seal)
    PEP-->>FSC_I: Response + log to Logboek Dataverwerkingen
    FSC_I-->>FSC_O: mTLS response
    FSC_O-->>HV: Income data (only consented fields, no BSN)

    HV->>Jan: "Uw gegevens zijn opgehaald, -we verwerken uw aanvraag."

What the GraphQL Request Looks Like¶

```graphql

Sent by Hypotheekverlener via FSC — Belastingdienst leg only¶

PDP validates: selection set fields ⊆ catalog[bd:ib:*] + consentId in input¶

Note: consentId is the subject -- NO BSN in the request¶

query AankoopWoningInkomen($consentId: UUID!, $jaren: [Int!]!) { inkomensgegevens(input: { consentId: $consentId, belastingjaren: $jaren }) { belastingjaar verzamelinkomen inkomenUitBox1 grondslag { code omschrijving } } } ```

Variables: { "consentId": "550e8400-e29b-41d4-a716-446655440000", "jaren": [2025, 2024] }

The PEP intercepts this query, resolves consent_id → PI → BSNk Transform → EI → BSN, and substitutes the BSN into the bronhouder's internal query. The dienstverlener's query and response contain no BSN at any point.

What the Policies Evaluate¶

Two PDPs evaluate in sequence — the Manager PDP at token issuance, the bronhouder PDP per-request:

``` ── Manager PDP (at token issuance, concerns ① ②) ──

INPUT: client_cert.oin = "OIN:00000004003214345001" (Hypotheekverlener BV) client_cert.chain = valid (PKI-O Root CA → TSP CA → end cert) grant_hash = "abc123" requested_scopes = ["dvtp:aankoop-woning"] pip.sector = { member: true, sector: "hypotheekverleners" } (from KvK SBI PIP)

POLICY CHECKS: ① Is PKI-O cert chain valid? -> YES ①→② Is OIN in sector "hypotheekverleners"? -> YES (KvK SBI PIP) ② Is grant "abc123" active for this scope? -> YES ② Is "dvtp:aankoop-woning" ⊆ grant.scopes? -> YES

DECISION: ISSUE JWT { sub: "OIN:...HV", scope: "dvtp:aankoop-woning", sector: "hypotheekverleners", grant_hash: "abc123", cnf: { x5t#S256: "" } }

── Bronhouder PDP (per-request, concerns ③ ④ ⑤) ──

INPUT (from JWT claims + request): subject.org_id = "OIN:00000004003214345001" (from JWT sub) subject.fsc_grant = "abc123" (from JWT grant_hash) action.scope = "aankoop-woning" action.query = resource.consent_id = "550e8400-e29b-41d4-a716-446655440000" context.trajectory = "dvtp"

POLICY CHECKS: ③ Does consent exist for consent_id+provider? -> YES (PIP query to register) ③ Does consent include scope for this bronhouder? -> YES (bd:ib:2025 ∈ granted_scopes) ③ Is consent still valid (not expired, not withdrawn)? -> YES (expires 2026-04-11) ③ Is scope within dienstencatalogus ceiling? -> YES (bd:ib:2025 ∈ catalog[aankoop-woning]) ④ Scope: are all requested fields in catalog[bd:ib:*]? -> YES (verzamelinkomen, inkomenUitBox1, grondslag ⊆ allowed) ④ Constraint: is consentId in input arguments? -> YES (identity-bound) ⑤ Rate limit OK? Format valid? -> YES

DECISION: ALLOW (obligations: allowed_fields=[verzamelinkomen, inkomenUitBox1, grondslag, peilDatum])

POST-DECISION (inside PEP, not visible to dienstverlener): 6. Retrieve PI from consent record 7. BSNk Transform(PI, bronhouder_oin) → EI 8. Decrypt EI → BSN (government-internal) 9. Substitute BSN into bronhouder query ```

Note: steps 6-9 happen after the policy decision, inside the PEP. The dienstverlener's request and the policy evaluation never touch BSN. BSN only appears in the government-internal leg between PEP and bronhouder.

If Jan revokes his consent via the consent management portal (FR-20), the register record status changes to "revoked." The next time the hypotheekverlener sends a query:

POLICY CHECK ③: consent.status == "open"? -> NO (status: "revoked") DECISION: DENY (reason: "consent_revoked")

No token invalidation needed. No notification to the hypotheekverlener needed. The PDP simply denies the next request. This is cleaner than the approach in DvTP's draft v0.1 of checking consent tokens at multiple points.

Demo Interaction 2: EUDI Wallet -- Citizen Stores Income Attestation via PubEAA Provider¶

Scenario: Jan wants his income data in his EUDI wallet so he can present it to anyone -- not just the hypotheekverlener. He retrieves a PuB-EAA (Public Body Electronic Attestation of Attributes) via the shared PubEAA Provider, which queries the Belastingdienst on his behalf. The PuB-EAA is stored in his wallet.

Issuance -- PubEAA Provider Issues Attestation to Wallet¶

sequenceDiagram
    actor Jan as Jan (Burger)
    participant WALLET as EUDI Wallet App
    participant PUBEAA as PubEAA Provider -(GBO Edge)
    participant FSC_I as FSC Inway -(Belastingdienst)
    participant PEP as PEP
    participant PDP as PDP (OPA/Rego)
    participant GQL as GraphQL API -(Belastingdienst)

    Jan->>WALLET: "Inkomensverklaring toevoegen"
    WALLET->>PUBEAA: OpenID4VCI Authorization Request -(credential_type: income-attestation)

    PUBEAA->>WALLET: Authentication challenge
    WALLET->>Jan: Authenticate with PID -(or DigiD during transition)
    Jan->>WALLET: Biometric / PIN confirmation
    WALLET->>PUBEAA: PID presentation (BSN verified)

    PUBEAA->>FSC_I: GraphQL query via FSC -(template: income-attestation, BSN: 123456789)
    FSC_I->>PEP: Intercept incoming request
    PEP->>PDP: AuthZEN eval: -subject={pubeaa_provider, citizen_bsn: 123456789} -action={scope: income-attestation, type: issuance} -resource={bsn: 123456789}

    Note over PDP: No consent PIP check needed -- -citizen is requesting their OWN data. -Policy: "allow if subject.citizen_bsn == resource.bsn -AND action.type == issuance -AND subject is registered PubEAA Provider"

    PDP-->>PEP: ALLOW

    PEP->>GQL: Execute query template "income-attestation"
    GQL-->>PEP: Income data (all attestation fields)
    PEP-->>FSC_I: Response
    FSC_I-->>PUBEAA: Income data via FSC

    PUBEAA->>PUBEAA: Create PuB-EAA: -Sign with qualified electronic seal -(PKIoverheid or EUDI Access CA)

    PUBEAA-->>WALLET: OpenID4VCI Credential Response -(SD-JWT VC or mdoc/CBOR)
    WALLET->>WALLET: Store attestation

    WALLET->>Jan: "Inkomensverklaring opgeslagen"

Note: Bronhouders can optionally run their own Credential Issuer instead of using the shared PubEAA Provider. The data flow remains the same -- only the issuer endpoint changes.

Demo Interaction 3: Gov-to-Gov -- Gemeente Queries RvIG¶

Scenario: A gemeente needs to verify a citizen's address data from RvIG (Basisregistratie Personen). This is a government-to-government exchange -- no consent needed, no pseudonymization, just legal-basis authorization over FSC.

Full Sequence¶

sequenceDiagram
    participant GEM as Gemeente -(FSC Outway)
    participant FSC_I as FSC Inway -(RvIG)
    participant PEP as PEP
    participant PDP as PDP (OPA/Rego)
    participant GQL as GraphQL API -(RvIG / BRP)

    GEM->>FSC_I: GraphQL query via FSC -(template: adresgegevens, BSN: 123456789)
    FSC_I->>PEP: Intercept incoming request

    PEP->>PDP: AuthZEN eval: -subject={org: gemeente-amsterdam, type: government} -action={scope: adresgegevens, query: <GraphQL body>} -resource={bsn: 123456789} -context={trajectory: gov-to-gov, legal_basis: "Wet BRP art. 3.5"}

    Note over PDP: No consent check needed. -No BSNk PP needed (both parties are BSN-authorized). -Policy: "allow if subject.type == government -AND legal_basis is valid -AND FSC contract is active -AND query conforms to template"

    PDP-->>PEP: ALLOW

    PEP->>GQL: Execute query template "adresgegevens" -(BSN: 123456789)
    GQL-->>PEP: Address data
    PEP-->>FSC_I: Response + log to Logboek Dataverwerkingen
    FSC_I-->>GEM: Address data via FSC

This is the simplest GBO flow -- it shows the pure backbone without any consent, pseudonymization, or protocol translation. All other trajectories build on this foundation by adding edge-layer components.

What the Policy Evaluates¶

``` INPUT: subject.org_id = "OIN:00000001003214345001" (Gemeente Amsterdam) subject.type = "government" subject.fsc_contract = { status: "active" } action.scope = "adresgegevens" action.query = resource.bsn = "123456789" context.trajectory = "gov-to-gov" context.legal_basis = "Wet BRP art. 3.5"

POLICY CHECKS: 1. Is subject a government organization? -> YES 2. Is FSC contract active? -> YES 3. Is legal basis valid for this data type? -> YES (Wet BRP art. 3.5) 4. Does query structure conform to template "adresgegevens"? -> YES

DECISION: ALLOW ```

No consent register lookup, no BSNk PP resolution. Government parties are BSN-authorized and access is governed by legal basis, enforced by the same PEP/PDP chain.

Demo Interaction 4: Citizen Presents Credential to Relying Party¶

Scenario: Jan already has his income PuB-EAA in his wallet (from Demo 2). He visits a hypotheekverlener and presents the attestation directly -- no real-time query to the Belastingdienst needed.

Full Sequence¶

sequenceDiagram
    actor Jan as Jan (Burger)
    participant WALLET as EUDI Wallet App
    participant HV as Hypotheekverlener -(Relying Party)
    participant LOTE as Trusted List / LoTE

    Jan->>HV: "Ik wil een hypotheek aanvragen"
    HV->>WALLET: OpenID4VP Presentation Request -(requested: income-attestation, -fields: verzamelinkomen, inkomenUitBox1)

    WALLET->>Jan: "Hypotheekverlener BV vraagt: -- Verzamelinkomen -- Inkomen uit box 1 - -Wilt u deze gegevens delen?"

    Note over Jan,WALLET: Selective disclosure: wallet presents -only the requested fields, not the full attestation

    Jan->>WALLET: Approve (biometric/PIN)

    WALLET->>HV: VP Token with selected fields -(SD-JWT VP or mdoc presentation)

    HV->>LOTE: Verify issuer signature -(PubEAA Provider on Trusted List?)
    LOTE-->>HV: Valid (qualified PuB-EAA issuer)

    HV->>HV: Verify attestation: -- Signature valid -- Issuer trusted -- Not expired -- Fields present

    HV->>Jan: "Gegevens ontvangen, -we verwerken uw aanvraag."

The Relying Party verifies the PuB-EAA independently -- no connection to GBO or the bronhouder is needed at presentation time. Trust is established via the EUDI Trusted List: the PubEAA Provider is registered as a qualified PuB-EAA issuer.

Demo Interaction 5: QTSP Verifies Attributes via Authentic Source Interface¶

Scenario: A QTSP wants to issue a QEAA (Qualified Electronic Attestation of Attributes) for Jan's income data. Before issuing, the QTSP must verify the attributes against the authentic source (Belastingdienst), as mandated by Article 45e. Jan authorizes this verification.

Full Sequence¶

sequenceDiagram
    actor Jan as Jan (Burger)
    participant WALLET as EUDI Wallet / eID
    participant QTSP as QTSP
    participant AZS as Authorization Server -(GBO)
    participant ASIP as Authentic Source Interface -(GBO Edge)
    participant FSC_I as FSC Inway -(Belastingdienst)
    participant PEP as PEP
    participant PDP as PDP (OPA/Rego)
    participant GQL as GraphQL API -(Belastingdienst)
    participant CATALOGUE as EU Catalogue of Attributes

    Note over QTSP,CATALOGUE: Phase 1: Discovery (design-time or runtime)
    QTSP->>CATALOGUE: I1 Discover: search -(country=NL, attribute=income)
    CATALOGUE-->>QTSP: Data service endpoint -(Belastingdienst income verification)

    Note over Jan,AZS: Phase 2: Citizen Authorization (I4/I5)
    QTSP->>Jan: "We need to verify your income data. -Please authorize access."
    Jan->>WALLET: Authenticate (PID / DigiD)
    WALLET->>AZS: I5 User authorization -(scope: verify-income, qtsp: QTSP-OIN)
    Jan->>WALLET: Approve authorization
    AZS-->>QTSP: OAuth access token -(scope: verify-income, bsn: 123456789)

    Note over QTSP,GQL: Phase 3: Attribute Verification (I2)
    QTSP->>ASIP: I2 Verify Request -(OAuth token, attributes: {verzamelinkomen: 45000, -inkomenUitBox1: 42000}, PID: 123456789)

    ASIP->>FSC_I: GraphQL query via FSC -(template: income-verification, BSN: 123456789)
    FSC_I->>PEP: Intercept request
    PEP->>PDP: AuthZEN eval: -subject={qtsp, on_trusted_list: true} -action={scope: income-verification, type: verify} -resource={bsn: 123456789} -context={trajectory: authentic-source, -citizen_authorized: true}
    PDP-->>PEP: ALLOW

    PEP->>GQL: Execute query
    GQL-->>PEP: Actual income data
    PEP-->>FSC_I: Response
    FSC_I-->>ASIP: Income data via FSC

    ASIP->>ASIP: Compare QTSP-provided values -with authentic source values
    ASIP-->>QTSP: Verification result: -verzamelinkomen: VERIFIED -inkomenUitBox1: VERIFIED

    Note over QTSP: QTSP now has verified authentic source -confirmation. Issues QEAA.
    QTSP->>QTSP: Issue QEAA -(qualified electronic seal)
    QTSP-->>Jan: QEAA stored in wallet

The Authentic Source Interface acts as a protocol adapter: it translates ETSI TS 119 478 I2 (Verify) requests into GraphQL queries via FSC, compares the QTSP-provided attribute values against the register, and returns a verification result. The bronhouder sees a standard FSC request -- it does not know whether the request came from a DvTP dienstverlener, an OOTS bridge, a PubEAA Provider, or the Authentic Source Interface.

Key Differences Across Trajectories¶

Aspect	DvTP (Demo 1)	PubEAA Issuance (Demo 2)	Gov-to-Gov (Demo 3)	RP Presentation (Demo 4)	Art. 45e Verification (Demo 5)
Who initiates	Private dienstverlener	Citizen via wallet	Government party	Citizen via wallet	QTSP (citizen-authorized)
Authorization	Consent register (PIP)	Self-request (bsn == bsn)	Legal basis (wettelijke grondslag)	N/A (citizen presents directly)	OAuth token (citizen-authorized)
BSN handling	BSNk PP pseudonymization	BSN via PID (government-internal)	BSN directly (both gov parties)	No BSN (credential-based)	BSN via PID (citizen-authorized)
Bronhouder involved	Every request	At issuance only	Every request	Not at all	Every verification request
Data freshness	Real-time	Issuance moment	Real-time	Issuance moment (may be stale)	Real-time verification
Edge component	Consent portal + BSNk PP	PubEAA Provider	None (direct FSC)	None (wallet-to-RP)	Authentic Source Interface + AuthZ Server
Consumer sees BSN?	Never	N/A (citizen's own data)	Yes (gov-authorized)	No	No (PID only)

Same backend: All server-side trajectories (Demo 1, 2, 3, 5) use the same bronhouder GraphQL API and the same PEP/PDP infrastructure. The difference is in the authorization policy and the protocol at the consumer edge. Demo 4 (RP presentation) is purely wallet-to-RP and does not touch GBO infrastructure at all.

SDG-OOTS Cross-Border Bridge¶

Why OOTS Requires an AS4 Bridge¶

The Single Digital Gateway Regulation (EU 2018/1724) mandates cross-border evidence exchange via the Once-Only Technical System (OOTS). This is a legal obligation, not an architectural choice. OOTS uses eDelivery AS4 transport with Domibus Access Points, four-corner routing, and SMP 2.1 discovery.

GBO must build an AS4 bridge to serve cross-border requests. This bridge translates OOTS AS4 requests into FSC/GraphQL requests toward bronhouders, and returns evidence in OOTS-EDM format.

OOTS Bridge Architecture¶

graph TB
    subgraph "Cross-Border (EU)"
        OOTS_IN["OOTS AS4 messages from EU Member States"]
    end

    subgraph "OOTS AS4 Bridge"
        DOMIBUS[Domibus Access Point]
        OOTS_ADAPT["OOTS-EDM Adapter"]
        FSC_TRANS["FSC Translator"]
        SMP_PUB["SMP 2.1 Publisher"]
    end

    subgraph "Domestic (GBO)"
        FSC_IN["FSC Inway → PEP → PDP → GraphQL"]
    end

    OOTS_IN -->|"AS4 eDelivery"| DOMIBUS
    DOMIBUS --> OOTS_ADAPT
    OOTS_ADAPT --> FSC_TRANS
    FSC_TRANS -->|"FSC request + AuthZEN context"| FSC_IN
    FSC_TRANS -.->|"publish"| SMP_PUB

    style DOMIBUS fill:#2d7a2d,stroke:#333,color:#fff
    style FSC_TRANS fill:#2d7a2d,stroke:#333,color:#fff

From the bronhouder's perspective, cross-border requests look identical to domestic DvTP requests -- an FSC request with an AuthZEN-evaluable authorization context. Whether it originated from a Dutch hypotheekverlener (DvTP/FSC) or a German Einwohnermeldeamt (OOTS/AS4) is invisible to the source. The bridge handles all translation.

Domestic dienstverleners use FSC directly. AS4 is reserved for cross-border traffic via the OOTS bridge.

Gap Analysis & Recommendations¶

Gap 1: Authorization Policy Lifecycle (Critical)¶

Gap: The five orthogonal authorization concerns are now well-defined (see Authorization Models Analysis), but the end-to-end policy lifecycle — from authoring to signing to distribution to runtime evaluation — requires tooling and governance processes that do not yet exist.

Recommendation:

Start with iWlz's OPA/Rego as the PDP baseline — it works in production
Implement the policy distribution pipeline: Git repo → CI/CD (cosign signing) → OCI registry → OPA Bundle API pull at each bronhouder
Define the AuthZEN S/A/R/C vocabulary for GBO: Subject=OIN from PKI-O cert, Action=GraphQL operation+fields, Resource=register+data_subject, Context=scope+legal_basis+timestamp
Implement the dual access basis path in Rego: consent check (PIP query) for DvTP, legal basis check (from bundle) for law-mandated access
Publish Rego policy templates for each trajectory so bronhouders don't write policies from scratch
Define FSC Grant schema extensions: scope annotations (Level 2) and policy bundle references (Level 3) — propose via Logius/VNG standards process
No central authorization server — the FSC Manager is the token issuer. Upgrade it to policy-driven: own OPA/Rego PDP loaded from the same PAP, with PIP access to sector registers (KvK SBI, KNB, BIG, AFM) for organizational attribute verification at token issuance time
Define SectorConnectionGrant type in FSC Grant schema — enables sector-level grants ("all notarissen may access kadaster data") instead of per-organization contracts. Document JWT claim set including: sub, scope, fsc_grant_hash, cnf, policy_version, sector, sector_verified_by

Gap 2: Identity Convergence + BSN Pseudonymization (High)¶

Gap: PKIoverheid and EUDI introduce different trust models (Access CA + Trusted Lists). BSN pseudonymization for private parties is needed -- BSNk PP provides this but is not yet integrated into the GBO architecture.

Recommendation:

Push for PKIoverheid as the Dutch EUDI Access Certificate Authority -- this is the highest-leverage convergence decision
Mandate PKIoverheid for all bronhouders and dienstverleners (they already have certificates for FSC)
Map organizational identifiers: OIN, KvK-nummer, ETSI NTRNL-xxx, and EUDI identifiers to a common anchor (KvK-nummer)
Integrate BSNk PP as the pseudonymization layer: onboard Toestemmingsportaal as BSNk participant (AD/MR role), onboard PEP as BSN-authorized component for PI→EI resolution, onboard private dienstverleners for EP decryption key distribution
Clarify relationship between BSNk PP pseudonyms (server-to-server, per-OIN) and EUDI wallet pseudonyms (user-controlled, per-rpId) -- these are complementary, not competing systems
Recognize QTSP trust chains via EUDI Trusted Lists -- accept QTSP-signed attestations and seals as trust evidence in PDP policies via the eIDAS trust infrastructure

Gap 3: Semantic Mapping (Medium)¶

Gap: No canonical data models for the "generieke gegevenssets" that span trajectories. National data formats don't map to OOTS-EDM evidence types or EUDI attestation schemas.

Recommendation:

Define GraphQL schemas per bronhouder as the canonical model (single source of truth)
Generate serializations from the schema: JSON for FSC, OOTS-EDM XML for cross-border, SD-JWT VC / mdoc for EUDI wallet
Prioritize the data sets from DvTP FR-05 through FR-25 as the first canonical models
For OOTS: map to the 9 evidence types in the OOTS Semantic Repository
For EUDI: align with PuB-EAA attestation schemas from the Commission Implementing Regulations

Gap 4: GraphQL Standardization within FDS (Medium)¶

Gap: FDS mandates REST API Design Rules. GraphQL is not yet a recognized datadienst type, though IMX already supports it and Lock-Unlock identifies the REST limitation for fine-grained access.

Recommendation:

Position GraphQL as running OVER FSC, not replacing it. FSC proxies HTTP; it doesn't care about payload format
Propose GraphQL as an additional datadienst type alongside REST via the FDS standaardenlandkaart process
Use iWlz as the precedent: a Dutch government system running GraphQL + OPA/PBAC in production for sensitive data
Align with FTV's AuthZEN: GraphQL query introspection maps cleanly to Subject/Action/Resource/Context

Gap 5: Traceability Correlation (Medium)¶

Gap: No cross-framework log correlation. FSC Transaction Logs, OOTS evidence records, wallet transaction logs, and DvTP audit logs exist in separate systems.

Recommendation:

Mandate Logboek Dataverwerkingen (LDV) for all GBO interactions
Use OpenTelemetry trace IDs as the correlation key across systems
Accept that EUDI wallet-local logs are private (cannot be correlated server-side)
Implement iWlz's TraceID/SpanID pattern for distributed tracing across GBO components

Gap 6: Bronhouder Onboarding Toolkit (Medium)¶

Gap: Even with the simplified architecture (one GraphQL endpoint + FSC Inway + PEP), onboarding bronhouders is complex. Smaller bronhouders (gemeenten) may lack capacity.

Recommendation:

Provide pre-configured GBO containers: FSC Inway + Manager with PDP + PEP + bronhouder OPA/Rego PDP as a deployable package. Both PDPs load from the same PAP (OCI registry)
Publish Rego policy templates per trajectory (token issuance policies for Manager PDP, request evaluation policies for bronhouder PDP)
Provide sector PIP integration configuration: pre-built connectors for KvK SBI, KNB, BIG, AFM registers so the Manager PDP can verify organizational attributes out of the box
Offer a GBO translation layer (shared service) for small bronhouders who cannot run their own GraphQL endpoint
Define a reference onboarding process: PKIoverheid cert → FSC registration → sector PIP registration → DCAT self-description → policy configuration → trajectory activation

Gap 7: PubEAA Provider (Critical)¶

Gap: No government-operated PuB-EAA Provider exists for issuing electronic attestations of attributes from government sources. Without one, the Netherlands relies entirely on commercial QTSPs for government-sourced attestations -- a supply-chain consideration worth addressing.

Recommendation:

Build the PubEAA Provider as shared GBO edge infrastructure, issuing PuB-EAAs on behalf of bronhouders via OpenID4VCI
Register on EUDI Trusted Lists as a qualified PuB-EAA issuer
Define issuance policies per bronhouder and attestation type (Rego policy templates)
Sign PuB-EAAs with qualified electronic seal (PKIoverheid or EUDI Access CA)
Offer as default path -- bronhouders with capacity can optionally run their own Credential Issuer

Gap 8: Authentic Source Interface -- Article 45e (Critical)¶

Gap: Article 45e of the amended eIDAS Regulation mandates that EU Member States ensure QTSPs can verify attributes against authentic sources within the public sector, at the request of the user -- by 24 December 2026. ETSI TS 119 478 specifies the interfaces. No such interface exists yet for Dutch government registers. Without it, QTSPs cannot verify government-sourced attributes, blocking the entire QEAA ecosystem.

Recommendation:

Build the Authentic Source Interface as a GBO edge service implementing ETSI TS 119 478 (HTTP/OAuth variant, clause 6.1)
Implement I2 (Verify) + I4 (Authorize) on top of existing FSC/GraphQL infrastructure -- the ASIP translates verification requests into GraphQL queries via FSC
I3 (Retrieve) is optional per regulation and not implemented -- the PubEAA Provider covers direct issuance
Register data services in the EU catalogue of attributes via I1 (Discover), reusing OOTS common services infrastructure
Build the Authorization Server (I4) using OAuth 2.0 -- citizen authorizes QTSP access via EUDI Wallet or eID (I5)
Define PDP policies for QTSP verification requests: requester must be on Trusted List, citizen must have authorized, requested attributes must be in scope

Sources¶

This document synthesizes analysis from:

authorization-models-analysis.md -- Authorization model decomposition: five concerns, protocol-level analysis of iWlz/FSC/FTV/OAuth2/PKI-O/toestemmingsregister, federated PDP design, policy lifecycle, JWT anatomy
proposals/bsnk-pp-gbo-integration.md -- BSNk PP integration for BSN pseudonymization
proposals/dvtp-pbac-alignment.md -- Consent-as-PIP architecture design
proposals/graphql-pbac.md -- GraphQL + PBAC design with iWlz precedent
conflict-analysis/trust-model-comparison.md -- Five trust models compared
synthesis/gbo-synthesis.md -- Full per-layer synthesis with recommendations
../02-normalized/dvtp/ -- DvTP protocol analysis (17 components, 5 flows)
../02-normalized/eudi/ -- EUDI Wallet ARF v2.7.4+ analysis
../02-normalized/iwlz/ -- iWlz reference patterns (GraphQL, OPA/Rego)
../02-normalized/sdg-oots/ -- SDG-OOTS reference implementation analysis
../02-normalized/bsnk-pp/ -- BSNk PP polymorphic pseudonymization analysis