Globaal Ontwerp Gemeenschappelijke Bronontsluiting¶

ICTU | Augustus 2026

LET OP: Het project Gemeenschappelijke Bronontsluiting (GBO) is in ontwikkeling. Daarom is dit globaal ontwerp nog niet definitief. Bekijk de status van de documentatie.

1 Inleiding¶

Documenthiërarchie¶

Voor GBO geldt de volgende documenthiërarchie:

De inleiding en context beschrijven de doelen, de omgeving en de juridische kaders van GBO.
Het globaal ontwerp beschrijft op hoofdlijnen de oplossingsrichting, interactiepatronen, generieke functies en componenten.
De projectstartarchitectuur (PSA) beschrijft de kaders, eisen en ontwerpkeuzes voor de generieke functies en stelselfuncties.
Het technisch ontwerp beschrijft de technische inrichting van de voorzieningen en koppelvlakken.
De technische requirements specificeren de componenten die partijen moeten maken of aanpassen.
De uitwerking Semantiek beschrijft de informatiemodellen, begrippen, schema's en mappings voor de gegevensuitwisseling.

Bij verschillen over de oplossingsrichting of interactiepatronen is het globaal ontwerp leidend. De PSA is leidend voor de normerende architectuureisen.

De demo-omgeving toont aan hoe de voorgestelde oplossing in de praktijk kan werken. Let er wel op dat dit een demonstratie-omgeving is die nog in ontwikkeling is, testdata gebruikt en nog fouten kan bevatten.

Uitgangspunten¶

Europese interoperabiliteit: GBO volgt Europese afspraken en standaarden, waaronder EIF, eIDAS, OOTS en EUDI. GBO volgt ook de Nederlandse invulling daarvan, zoals de NL-Wallet en de Basisinrichting OOTS.
Generieke Digitale Infrastructuur (GDI): de GDI bevat afsprakenstelsels, standaarden en voorzieningen voor de digitale dienstverlening van publieke dienstverleners. De GDI heeft vier domeinen: toegang, interactie, gegevensuitwisseling en infrastructuur.
Federatief Datastelsel (FDS): het FDS ondersteunt organisaties met een publieke taak. Deelnemers gebruiken dezelfde standaarden en gaan daardoor op een uniforme manier met gegevens om.

Het FDS gebruikt de GDI-standaarden voor gegevensuitwisseling. Het FDS vult deze standaarden aan als afspraken of standaarden ontbreken. Federatieve Toegangsverlening is hiervan een voorbeeld. Deze standaard is gebaseerd op AuthZEN en is aangeboden aan Forum Standaardisatie.

Beleidsgedreven autorisatie (PBAC): GBO gebruikt een PBAC-architectuur voor autorisatie en toegang.
Waardengedreven inrichting: de organisatorische en technische inrichting volgt publieke waarden. De verdeling van rollen en verantwoordelijkheden ondersteunt een gelijk speelveld.
Keuzevrijheid: een bronhouder mag referentiecomponenten, onderdelen uit de GBO-vertaallaag of functioneel gelijkwaardige alternatieven gebruiken. Iedere oplossing moet voldoen aan de vastgestelde afspraken, standaarden en koppelvlakken.

Leeswijzer¶

Hoofdstuk 2 beschrijft de voorgestelde oplossingsrichting.
Hoofdstuk 3 beschrijft de interactiepatronen die GBO ondersteunt.
Hoofdstuk 4 beschrijft de benodigde generieke functies en stelselfuncties.
Hoofdstuk 5 beschrijft de componenten en afspraken die partijen nog moeten ontwikkelen.
Hoofdstuk 6 beschrijft de verwachte impact op de betrokken partijen.
Bijlage begrippenlijst bevat een lijst van begrippen die in dit globaal ontwerp gebruikt worden.

2 Voorgestelde oplossingsrichting¶

Knelpuntenanalyse¶

De pagina Gemeenschappelijke Bronontsluiting beschrijft de voordelen van GBO. De huidige situatie kent vier knelpunten die deze voordelen beperken:

Gegevensstromen vragen verschillende gegevenssets.
Gegevensstromen gebruiken verschillende autorisatiemodellen.
Gegevensstromen gebruiken verschillende protocollen.
Gegevensstromen vallen onder verschillende wet- en regelgeving.

GBO voorkomt dat bronhouders voor iedere gegevensstroom een aparte oplossing moeten maken. De gemeenschappelijke bronontsluiting:

Is één keer te implementeren en daarna meervoudig te gebruiken.
Stelt met configuratie gegevens beschikbaar voor de EUDI-Wallet, OOTS en private dienstverleners.
Verstrekt alleen gegevens die een gegevensvrager mag en kan opvragen.
Regelt de toegang met configureerbare autorisatie en een volledige audit trail.
Sluit met gemeenschappelijke oplossingen aan op OOTS, attribuutverstrekking en attribuutverificatie.
Geeft private dienstverleners toegang via een gemeenschappelijke toestemmingsvoorziening.

Oplossingsrichting¶

Bronhouders ontsluiten hun gegevens voor GBO via één API. Deze API kan verschillende gegevensverzoeken verwerken. Een bronhouder richt een nieuwe gegevensstroom in met configuratie. De bronhouder hoeft daarvoor geen nieuw endpoint te maken en te beheren.

Een generieke ontsluiting vraagt om aanvullende autorisatieregels. Beleidsregels (policies) kunnen deze regels instellen. Het koppelvlak gebruikt een betrouwbare en veilige standaard. Deze standaard borgt versleuteling, identificatie, authenticatie en logging.

GBO biedt hulpmiddelen aan bronhouders die deze inrichting nog niet zelf kunnen maken. Daarmee kunnen zij toch GBO-componenten gebruiken.

Centrale voorzieningen verbinden de gegevensstromen met bestaande protocollen en vertrouwensstelsels:

Voor de EUDI-Wallet gaat het om een Authentic Source Interface voor QTSP's en een voorziening voor PubEAA-uitgifte door overheidsbronnen. Bronhouders hoeven deze voorzieningen niet te gebruiken en mogen alternatieve oplossingen gebruiken.
Voor OOTS zorgt de OOTS-adapter voor de aansluiting op de Basisinrichting OOTS conform GBO. Als de gegevens semantisch vertaald worden, biedt de adapter een optionele vertaalfunctie aan volgens configuratie van de bronhouder. Bronhouders hoeven deze voorziening niet te gebruiken en mogen alternatieve oplossingen gebruiken om direct op OOTS of de Basisinrichting OOTS aan te sluiten.
Voor private dienstverleners gaat het om een toestemmingsvoorziening en een pseudonimiseervoorziening. Deze voorzieningen voorkomen dat het BSN terechtkomt bij organisaties zonder wettelijke grondslag. Als private dienstverleners gebruikmaken van deze gegevensstroom, zijn zij verplicht de toestemmingsvoorziening en de pseudonimiseringsvoorziening te gebruiken.

Het volgende diagram toont deze componenten in relatie tot elkaar.

%%{ init: { 'theme': 'base', 'themeVariables': { 'darkMode': false, 'background': '#FFFFFF', 'edgeLabelBackground': '#FFFFFF' }, 'themeCSS': 'svg, .mermaid, #mermaid-svg, .mermaid > svg { background-color: #FFFFFF !important; background: #FFFFFF !important; } @media (prefers-color-scheme: dark) { svg, .mermaid, #mermaid-svg, .mermaid > svg { background-color: #FFFFFF !important; background: #FFFFFF !important; } }' } }%% flowchart LR subgraph gbo["GBO Basis"] direction TB fsc_pap("Beleidsregels") fsc("Standaard koppelvlak Generieke bronontsluiting Configurabele autorisatie") fsc_tools("GBO tools (ondersteuning bronhouders)") end subgraph eudi["EUDI-Wallet kanaal"] direction LR eudi_asi("Bronontsluiting voor QTSP (Authentic Source Interface)") eudi_pubeaa("Uitgifte van publieke EAA (PubEAA)") eudi_qeaa["QTSP (QEAA)"] eudi_wallet["EUDI-Wallet"] end subgraph oots["OOTS kanaal"] direction LR oots_adapter("OOTS-adapter (semantische mapping)") oots_basis["Basisinrichting OOTS"] oots_afnemer["Europese overheid SDG-portaal"] end subgraph dvtp["DvTP kanaal"] direction LR dvtp_toestemming("Toestemmingsvoorziening") dvtp_pseudoniem["Pseudonimiseervoorziening"] dvtp_afnemer["Private dienstverlener"] end fsc_pap --- fsc fsc --- fsc_tools bron[("Overheidsbronnen BRP · BD · UWV · KvK · …")] --- gbo eudi_asi --- eudi_qeaa eudi_qeaa --- eudi_wallet gbo --- eudi_asi & eudi_pubeaa & oots_adapter & dvtp_afnemer eudi_pubeaa --- eudi_wallet oots_adapter --- oots_basis oots_basis --- oots_afnemer gbo --- dvtp_toestemming dvtp_toestemming --- dvtp_afnemer dvtp_toestemming --- dvtp_pseudoniem dvtp_pseudoniem ~~~ dvtp_afnemer eudi_wallet --- burger["Burger"] oots_afnemer --- burger dvtp_afnemer --- burger fsc_pap:::gbo fsc:::gbo fsc_tools:::gbo eudi_asi:::gbo eudi_pubeaa:::gbo eudi_qeaa:::eudi eudi_wallet:::eudi oots_adapter:::gbo oots_basis:::oots oots_afnemer:::oots dvtp_toestemming:::gbo dvtp_pseudoniem:::dvtp dvtp_afnemer:::dvtp bron:::bron burger:::burger %% Subgraph Stijlen (vervangt het geel) style gbo fill:#F4F5F7,stroke:#D1D5DB,stroke-width:1px style eudi fill:#F4F5F7,stroke:#D1D5DB,stroke-width:1px style oots fill:#F4F5F7,stroke:#D1D5DB,stroke-width:1px style dvtp fill:#F4F5F7,stroke:#D1D5DB,stroke-width:1px %% Onderscheidende Elementstijlen (zachte pasteltinten) classDef bron fill:#DDEBF7,stroke:#6F94B8,color:#1E293B classDef burger fill:#DDEBF7,stroke:#6F94B8,color:#1E293B classDef eudi fill:#f1efe8,stroke:#5f5e5a,color:#444441 classDef oots fill:#f1efe8,stroke:#5f5e5a,color:#444441 classDef dvtp fill:#f1efe8,stroke:#5f5e5a,color:#444441 classDef gbo fill:#DCFCE7,stroke:#16A34A,color:#0F172A

Figuur 1: Oplossingsrichting GBO.
Toelichting: GBO biedt de groene componenten aan voor de gemeenschappelijke bronontsluiting. De grijze componenten zijn bestaande voorzieningen waar GBO op aansluit.

De oplossingsrichting ondersteunt de drie gegevensstromen binnen de scope van GBO. Andere gegevensstromen vallen buiten deze scope. Zij kunnen dezelfde inrichting later hergebruiken. De configureerbare bronontsluiting-API en autorisatieregels ondersteunen bijvoorbeeld gegevensuitwisseling tussen overheidspartijen.

3 Interactiepatronen¶

GBO ondersteunt drie interactiepatronen. Ieder patroon heeft eigen actoren, grondslagen en protocollen.

Patroon A - burger gebruikt EUDI-Wallet¶

Een burger vraagt bij een overheidsbron een attestatie op voor zijn EUDI-Wallet. Deze attestatie is een verifieerbare credential (VC).

De wallet start via OpenID4VCI een ophaalverzoek bij GBO. GBO bevraagt de bron en retourneert het resultaat als SD-JWT VC of mdoc (ISO 18013-5).

De uitgever verzegelt de attestatie cryptografisch. Daarna kan de burger de attestatie via OpenID4VP aan een dienstverlener tonen. GBO is niet betrokken bij deze presentatie.

Een bronhouder mag attestaties rechtstreeks uitgeven als PubEAA's. Een Qualified Trust Service Provider (QTSP) mag attestaties uitgeven als QEAA's. PubEAA's en QEAA's hebben juridisch dezelfde betekenis.

GBO ondersteunt de technische rol van een gecentraliseerde voorziening voor PubEAA-uitgifte. GBO is zelf geen PubEAA-verstrekker. Welke organisatie deze rol mogelijk gaat vervullen, moet nog worden bepaald. De bronhouder gebruikt de voorziening om zelfstandig attestaties uit te geven. Het gebruik van de voorziening is optioneel. Een bronhouder mag ook zelf PubEAA's buiten GBO uitgeven. Die eigen uitgifte valt buiten de scope van GBO.

Voor uitgifte via een QTSP ondersteunt GBO de rol van Authentic Source Interface Provider (ASI-provider). De ASI-provider biedt twee diensten:

een verify-dienst die aangeleverde attributen controleert. Deze dienst geeft invulling de verplichting van lidstaten om ervoor te zorgen dat QTSP's de in artikel 45e bedoelde attributen elektronisch kunnen verifiëren bij authentieke bronnen, rechtstreeks of via een aangewezen intermediair.
een retrieve-dienst waarmee de QTSP namens de bronhouder attributen ophaalt en kwalificeert. Deze dienst is optioneel.

De ASI-provider van GBO gebruikt voor autorisatie en authenticatie de autorisatiedienst van GBO. Een bronhouder mag een eigen ASI-provider met een eigen autorisatiedienst gebruiken. Die eigen dienst valt buiten de scope van GBO.

Afstemming loopt: De betrokken partijen bepalen nog de voorkeur voor PubEAA-uitgifte door overheidsbronnen of QEAA-uitgifte via een QTSP. GBO ondersteunt beide varianten. De governance voor deze keuze valt buiten GBO.

De Europese Commissie onderzoekt of de OOTS Common Services twee catalogi kunnen ondersteunen:

de Semantic Repository met regelingen voor de attestering van attributen.
de Data Service Directory met leveranciers van attesteringen van attributen.

QTSP's en uitgevers van PubEAA's moeten de voorgeschreven catalogi gebruiken. Bronhouders zijn verantwoordelijk voor de juiste configuratie van deze catalogi.
GBO biedt een gedeelde voorziening voor semantische mappings. Deze voorziening vertaalt het formaat van de bronhouder naar het formaat dat de afnemer verwacht.
GBO onderzoekt nog of en hoe het bronhouders ondersteunt bij het vullen van de Data Service Directory.

%%{ init: { 'theme': 'base', 'themeVariables': { 'darkMode': false, 'background': '#FFFFFF', 'edgeLabelBackground': '#FFFFFF' }, 'themeCSS': 'svg, .mermaid, #mermaid-svg, .mermaid > svg { background-color: #FFFFFF !important; background: #FFFFFF !important; } @media (prefers-color-scheme: dark) { svg, .mermaid, #mermaid-svg, .mermaid > svg { background-color: #FFFFFF !important; background: #FFFFFF !important; } }' } }%% sequenceDiagram autonumber actor Burger participant Wallet as EUDI-Wallet participant QTSP as QTSP participant PubEAA as PubEAA voorziening participant VerifDienst as Verify-/retrievedienst (Authentic Source Interface) participant Auth as Autorisatie voorziening participant Bron as Overheids- bron Note over Burger,Bron: Stroom A — PubEAA: overheidsinstantie geeft attribuut rechtstreeks uit rect rgb(225, 245, 238) Burger->>Wallet: Vraag attribuut op Wallet->>PubEAA: Credential Request PubEAA->>Auth: Autorisatieverzoek Auth->>Wallet: Authenticatie- & autorisatieverzoek Wallet->>Burger: Toont verzoek & vraagt consent Burger->>Wallet: Geeft consent & presenteert PID / eID Wallet->>Auth: Authenticatie / consent (incl. PID / eID) Auth->>PubEAA: Autorisatie (incl. identificatie burger) PubEAA->>Bron: Bevraag bron Bron->>PubEAA: Attribuutgegevens PubEAA->>PubEAA: Kwalificeer attribuutgegevens PubEAA->>Wallet: PubEAA Wallet->>Burger: PubEAA opgeslagen in wallet end Note over Burger,Bron: Stroom B — QEAA: QTSP levert attribuut via verificatie- of retrievedienst rect rgb(238, 237, 254) Burger->>QTSP: Attestatie Request (incl. evt. stukken) Note over QTSP: QTSP verifieert attribuut (verify) of haalt attribuut op (retrieve) QTSP->>VerifDienst: Verify- of Retrieveverzoek VerifDienst->>Auth: Autorisatieverzoek Note over Auth: Bij gebruik ISO15000 geen autorisatie/authenticatie nodig Auth->>Wallet: Authenticatie- & autorisatieverzoek Wallet->>Burger: Toont verzoek & vraagt consent Burger->>Wallet: Geeft consent & presenteert PID / eID Wallet->>Auth: Authenticatie / consent (met PID / eID) Auth->>VerifDienst: Autorisatie (incl. identificatie burger) VerifDienst->>Bron: Bevraag bron Bron->>VerifDienst: Attribuutgegevens VerifDienst->>VerifDienst: Bij verify: Verifieer attribuutgegevens VerifDienst->>QTSP: (geverifieerd) attribuut QTSP->>QTSP: Issue QEAA QTSP->>Wallet: QEAA Wallet->>Burger: QEAA opgeslagen in wallet end

Figuur 2: Een burger haalt een gegeven op in de EUDI-Wallet.
Een gegeven kan als PubEAA rechtstreeks van een overheidsbron komen. Een QEAA komt via een QTSP.

Patroon B - grensoverschrijdend verzoek via OOTS¶

Nederlandse bronhouders moeten op OOTS aansluiten als zij digitale gegevens leveren voor een SDG-procedure in een andere lidstaat. Zij hebben drie mogelijkheden:

aansluiten op de Basisinrichting OOTS.
een sectorale aansluiting gebruiken, zoals de EMREX-brug.
zelf een aansluiting op OOTS ontwikkelen.

Stichting RINIS levert de Basisinrichting OOTS in opdracht van de ministeries van BZK en EZK. Sectorale en eigen aansluitingen vallen buiten de scope van dit globaal ontwerp.

Voor bronhouders is OOTS-V het relevante onderdeel van de Basisinrichting OOTS. OOTS-V ondersteunt Nederlandse dienstverleners. OOTS-V ontvangt bewijsverzoeken van publieke instanties uit andere lidstaten. Deze verzoeken zijn gericht aan bronhouders die op OOTS-V zijn aangesloten.

OOTS-V:

analyseert het verzoek.
laat de gebruiker zich opnieuw authenticeren.
controleert op identiteitsverwisseling.
haalt de gegevens bij de bron op.
laat de gebruiker de gegevens voor verzending bekijken.

OOTS-V verstuurt de gegevens pas nadat de gebruiker daarmee heeft ingestemd.

De lidstaten gebruiken e-Delivery, AS4, eBMS en RegRep volgens de Europese voorschriften. Het OOTS Exchange Data Model (OOTS-EDM) specificeert de verzoek- en antwoordberichten. Het SDG Evidence Data Model (SDG-EDM) beschrijft het semantische model of schema waarmee bewijsgegevens worden beschreven.

OOTS-V gebruikt nationale standaarden voor de interactie met bronhouders. Op dit moment is dat de Digikoppeling REST API. Bronhouders hoeven daardoor de OOTS-afspraken en standaarden niet zelf toe te passen.

Voor GBO moet OOTS-V ook met GraphQL-API's kunnen werken.

Bronhouders mogen hun brongegevens omvormen volgens afspraken tussen lidstaten. De SDG-verordening verplicht deze semantische omvorming niet, maar stimuleert haar wel. Lidstaten kunnen afspreken om gegevens volgens één OOTS-datamodel te leveren. Zij werken bijvoorbeeld samen aan een uniform bewijs van geboorte.

GBO biedt een voorziening die de semantische transformatie volgens de specificatie van de bronhouder uitvoert. Het gebruik van deze voorziening is optioneel. Als een bronhouder de voorziening gebruikt, bevraagt OOTS-V niet rechtstreeks de API van de bronhouder. OOTS-V bevraagt de GBO-voorziening, die gegevens in het SDG-EDM-formaat levert.

%%{ init: { 'theme': 'base', 'themeVariables': { 'darkMode': false, 'background': '#FFFFFF', 'edgeLabelBackground': '#FFFFFF' }, 'themeCSS': 'svg, .mermaid, #mermaid-svg, .mermaid > svg { background-color: #FFFFFF !important; background: #FFFFFF !important; } @media (prefers-color-scheme: dark) { svg, .mermaid, #mermaid-svg, .mermaid > svg { background-color: #FFFFFF !important; background: #FFFFFF !important; } }' } }%% sequenceDiagram autonumber participant BRG as Burger (rechthebbende) participant EU as EU dienst (OOTS) participant RINIS as Basisinrichting OOTS (BZK/RINIS) participant GBO as OOTS adapter (GBO voorziening) participant BRH as Bron (BRP / BD / …) rect rgb(250, 241, 251) Note over BRG,EU: Burger neemt dienst af BRG->>EU: Verzoek dienst Note over EU: Gegeven van bronhouder nodig end rect rgb(230, 241, 251) Note over EU,RINIS: OOTS-verzoek (eDelivery/AS4) EU->>RINIS: Evidence Request (eDelivery/AS4) end rect rgb(250, 238, 218) Note over RINIS,GBO: Doorzetten naar bron via GBO RINIS->>GBO: OOTS-payload (GraphQL) Note over RINIS: eDelivery → GraphQL ontkoppeling end rect rgb(225, 245, 238) Note over GBO: Semantische mapping (optioneel) SDG Evidence type ↔ Bron-formaat end rect rgb(225, 245, 238) Note over GBO,BRH: Bronontsluiting (GBO generieke API) GBO->>BRH: API-aanroep (GraphQL) BRH->>GBO: Gegevens (Bron-formaat) end rect rgb(225, 245, 238) Note over GBO: Semantische mapping Bron-formaat ↔ SDG Evidence type end rect rgb(250, 238, 218) Note over GBO,RINIS: Terugkoppeling naar OOTS-basisinrichting GBO->>RINIS: Evidence Response (SDG Evidence type formaat) Note over RINIS: GraphQL → eDelivery/AS4 vertaling end rect rgb(230, 241, 251) Note over RINIS,BRG: Toestemming burger (User Review) RINIS->>BRG: Tonen te delen gegevens BRG->>RINIS: Keuze te delen gegevens end rect rgb(230, 241, 251) Note over EU,RINIS: OOTS-antwoord (eDelivery/AS4) RINIS->>EU: Evidence Response end rect rgb(250, 241, 251) Note over BRG,EU: Burger neemt dienst af EU->>BRG: Levert dienst end

Figuur 3: Gegevensverzoek van een Europese overheidsorganisatie via OOTS.

Patroon C - gegevensverzoek van private dienstverlener (DvTP)¶

Een private dienstverlener vraagt overheidsgegevens op bij een bronhouder. Dit mag alleen met een geldige juridische grondslag. Voor DvTP is deze grondslag een wettelijk vastgestelde toestemming voor het delen van gegevens met private dienstverleners.

De burger authenticeert zich op een centraal toestemmingsportaal. De burger gebruikt daarvoor een eIDAS-middel met het vereiste betrouwbaarheidsniveau.
Daarna geeft de burger geïnformeerde toestemming. De toestemming geldt voor een specifiek doel, een specifieke afnemer en een specifieke gegevensset.
GBO registreert de toestemming in een toestemmingsregister. De private dienstverlener ontvangt een consent-id. De private dienstverlener ontvangt nooit het BSN, maar een partijspecifiek pseudoniem.

De bronhouder controleert:

of de private dienstverlener de gegevens mag opvragen.
of het consent-id geldig is.
of de gegevensvraag binnen de toestemming valt.

De bronhouder herleidt het BSN uit de versleutelde identiteit. Daarna levert de bronhouder het antwoord aan de private dienstverlener.

GBO stelt een centrale toestemmingsvoorziening voor. Deze voorziening bestaat uit een toestemmingsportaal en een toestemmingsregister. De voorziening is verplicht voor de DvTP-stroom: iedere private dienstverlener en iedere bronhouder in deze stroom gebruikt dezelfde voorziening. Dit vereist wettelijke verankering.

GBO heeft ook decentrale registratie per bronhouder onderzocht. Het centrale model heeft de volgende voordelen:

Lagere kosten: één centrale inrichting is goedkoper dan een afzonderlijke inrichting bij iedere bronhouder.
Herkenbaarheid: de burger gebruikt steeds dezelfde voorziening. Dit ondersteunt herkenning en vertrouwen.
Inzage: de burger kan alle toestemmingen centraal bekijken en intrekken.
Eén toestemming: de burger kan in één handeling toestemming geven voor gegevens uit meerdere bronnen. Bij decentrale registratie is per bron een afzonderlijke toestemming nodig.

%%{ init: { 'theme': 'base', 'themeVariables': { 'darkMode': false, 'background': '#FFFFFF', 'edgeLabelBackground': '#FFFFFF' }, 'themeCSS': 'svg, .mermaid, #mermaid-svg, .mermaid > svg { background-color: #FFFFFF !important; background: #FFFFFF !important; } @media (prefers-color-scheme: dark) { svg, .mermaid, #mermaid-svg, .mermaid > svg { background-color: #FFFFFF !important; background: #FFFFFF !important; } }' } }%% sequenceDiagram autonumber actor Burger participant DV as Dienst- verlener participant Auth as Authenticatie- dienst participant TV as Toestemmings- voorziening participant PP as Pseudonimiserings- voorziening participant TR as Toestemmings- register participant BRH as Bron- 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 (met scope + doelbinding) Burger->>TV: Volgt redirect TV->>Auth: Authenticatieverzoek Note over Auth: DigiD of ander identificatiemiddel Auth->>Burger: Authenticeer burger Burger->>Auth: Authenticatie Auth->>TV: BSN (geverifieerde identiteit) TV->>TV: PI/PP aanwezig? TV->>PP: Activeer BSN PP->>TV: PI/PP TV->>TV: Registreer PI/PP TV->>PP: Transformeer PI/PP PP->>TV: Versleutelde PI/PP (VI/VP) TV->>Burger: Toon gegevensset waarvoor toestemming gevraagd wordt (scope + doelbinding) Burger->>TV: Verleent toestemming TV->>TR: Schrijf toestemming in register (VI · scope · doelbinding · TTL) TR->>TV: consent-id TV->>DV: Redirect terug naar dienstverlener (met consent-id en VI/VP) end Note over DV,BRH: Fase 2 — Gegevensopvraging bij bronhouder (per bron een verzoek) rect rgb(238, 237, 254) DV->>BRH: Gegevensverzoek (consent-id · VI · mTLS / certificaat) BRH->>BRH: Authenticeer dienstverlener (via certificaat) BRH->>BRH: Controleer bevoegdheid (via FSC contract/Trusted List) BRH->>TR: Valideer consent-id TR->>BRH: Consent geldig BRH->>BRH: Controleer data scope BRH->>BRH: Ontsleutel VI naar BSN BRH->>DV: Gevraagde gegevens DV->>Burger: Levert dienst end

Figuur 4: Gegevensverzoek van een private dienstverlener binnen DvTP.

4 Generieke functies en stelselfuncties¶

Het gebruik van generieke functies sluit aan bij een bredere ontwikkeling binnen de Nederlandse overheid. De GDI-Architectuur introduceerde dit begrip in de NORA.

Meerdere stelsels gebruiken generieke functies. Hiermee combineren zij technische keuzevrijheid met herkenbare functies voor gebruikers. Het Gezondheidsinformatiestelsel gebruikt bijvoorbeeld een vergelijkbaar abstractieniveau.

De indeling van GBO bouwt voort op de GDI-indeling. GBO past deze indeling toe op de eigen interactiepatronen. Dit leidt tot acht generieke functies:

GDI-domein	Generieke functies van GBO
Toegang	F1 - Identiteit & Vertrouwen. F2 - Toegang & Interactie. F6 - Grondslag & Beleid
Interactie	F2 - Toegang & Interactie
Gegevensuitwisseling	F3 - Gegevensvoorziening. F4 - Semantiek & Eenheid van Taal. F5 - Gegevenskwaliteit & Validatie. F7 - Orkestratie & Integratie
Infrastructuur	F8 - Beheer & Continuïteit

Eén of meer stelselfuncties vullen iedere generieke functie in. Stelselfuncties zijn concrete afspraken, standaarden of voorzieningen.

De volgende paragrafen beschrijven de generieke functies, voorgestelde stelselfuncties en huidige inrichtingsstatus.

F1 — Identiteit & Vertrouwen¶

GBO identificeert burgers met het BSN en organisaties met het organisatie-identificatienummer (OIN) of het handelsregisternummer (HRN). GBO pseudonimiseert het BSN voor afnemers zonder wettelijke grondslag om het BSN te verwerken.

Burgers authenticeren zich met DigiD of een ander eIDAS-middel. Het betrouwbaarheidsniveau past bij de dienst en de opgevraagde gegevens.

Als het eIDAS-middel geen BSN bevat, koppelt identity matching het middel aan het BSN. Systemen authenticeren zich met PKIoverheid-certificaten.

Organisaties kunnen alleen deelnemen als zij aan de aansluitvoorwaarden voldoen.

Hiervoor zijn de volgende stelselfuncties nodig:

Stelselfunctie	Relevante bouwstenen	Status	Ontbrekend onderdeel of actie
S03 — Burgeridentificatie & Pseudonimisering	BSNk PP. DigiD	BSNk PP is beschikbaar. Integratie is nodig. Identity Matching (wordt nog door GBO onderzocht).	DvTP-partijen als deelnemer aansluiten. Consent-id koppelen.
S04 — Organisatie-authenticatie & Vertrouwensstelsel	eHerkenning. PKIoverheid. Organisatie-identificatienummer (OIN). Centrale OIN Raadpleegvoorziening	FDS Poortwachter en Marktmeester zijn als concept uitgewerkt. De beschikbaarheid en toepassing binnen GBO zijn nog niet bepaald.	GBO-aansluitvoorwaarden opstellen. KvK, OIN en eIDAS koppelen.

F2 — Toegang & Interactie¶

Als toestemming volgens de AVG nodig is, gebruikt GBO een toestemmingsvoorziening. Deze voorziening bestaat uit een toestemmingsportaal en een toestemmingsregister.

GBO autoriseert gegevensvragen met beleidsregels volgens PBAC. GBO biedt hiervoor een referentie-implementatie op basis van FTV. Een bronhouder mag een eigen implementatie gebruiken als deze aan de eisen voldoet.

Hiervoor zijn de volgende stelselfuncties nodig:

Stelselfunctie	Relevante bouwstenen	Status	Ontbrekend onderdeel of actie
S01 — Toestemmingsregister (primair voor DvTP)	Mogelijk functioneel verwant aan DigiD Machtigen	Nog te realiseren ⚠️	Toestemmingsregister realiseren. Register als PIP gebruiken. Benodigde wet- en regelgeving vaststellen.
S02 — Toestemmingsportaal (primair voor DvTP)	MijnOverheid	Nog te realiseren ⚠️	Inzage en intrekking mogelijk maken. Koppelen aan het toestemmingsregister en MijnOverheid.
S05 — Autorisatie (PEP/PDP/PIP)	-	AuthZEN NLGov-profiel (NLgov Profile for OpenID AuthZEN Authorization API 1.0.0) is beschikbaar. FTV is in ontwikkeling. De GBO-inrichting ontbreekt nog.	Referentie-implementatie per bronhouder maken. Policy Store en PAP inrichten.
S06 — Beleidsbeheer & -distributie (PAP)	-	Nog te ontwerpen ⚠️	Policybundels beheren en verspreiden naar de PDP-instanties van bronhouders. Ook moet de governance bepalen wie policies mag opstellen, wijzigen en goedkeuren.

F3 — Gegevensvoorziening¶

Bronhouders ontsluiten hun gegevens via een generieke bronontsluiting-API. GBO stelt hiervoor GraphQL voor. GraphQL ondersteunt hergebruik en dataminimalisatie.

GBO biedt een vertaallaag aan bronhouders zonder GraphQL-API. Deze laag vertaalt een bestaand protocol naar GraphQL. GBO gebruikt daarnaast de FSC-standaard.

Deze architectuur introduceert een adapter waarmee bronhouders de gegevens vanuit hun bron kunnen omvormen naar de gegevensformaten die zij via OOTS willen leveren. Bronhouders mogen deze adapter gebruiken zodra zij gegevens voor het OOTS gaan omvormen. Voor de uitwisseling van gegevens via OOTS is geen toestemming op grond van de AVG nodig. De Basisinrichting OOTS zorgt voor het verpakken van de gegevens van de bronhouder, zodat de uitwisseling voldoet aan de Europese voorschriften voor bewijsuitwisseling, zoals RegRep en OOTS-EDM. De Basisinrichting OOTS onderhoudt ook de verbindingen naar de lidstaten.

Voor de EUDI-Wallet geven bronhouders PubEAA's uit. QTSP's mogen namens bronhouders QEAA's uitgeven.

Hiervoor zijn de volgende stelselfuncties nodig:

Stelselfunctie	Relevante bouwstenen	Status	Ontbrekend onderdeel of actie
S07 — Gegevensontsluiting (bronontsluiting-API)	API-standaarden. Digikoppeling	De NL API Strategie, API Design Rules en Digikoppeling met FSC zijn beschikbaar. GraphQL is nog niet gestandaardiseerd als API-profiel.	Dienstencatalogus maken. GraphQL binnen FDS positioneren. GBO-vertaallaag maken.
S08 — OOTS-adapter	-	De Basisinrichting OOTS is beschikbaar.	GraphQL aan OOTS-V toevoegen. Bronformaat semantisch mappen naar SDG-EDM indien geconfigureerd, anders ongestructureerd doorleveren.
S11 — Attesteringsuitgifte (voor EUDI-Wallet)	-	Nog te realiseren ⚠️	OpenID4VCI-endpoint, attestatieschema's en ondertekeningsinfrastructuur maken. QTSP-diensten voor verify en retrieve maken.

F4 — Semantiek & Eenheid van Taal¶

Om de verschillende gegevensstromen vanuit één bronontsluiting te bedienen, biedt GBO een gedeeld begrippenkader volgens NL-SBB als hulpmiddel aan. GBO beoordeelt informatiemodellen op de toepassing van MIM.

GBO verankert semantiek in RDF, SKOS of allebei. GBO beschrijft catalogi volgens DCAT-AP-NL.

Om inzicht te geven in beschikbare gegevenssets, biedt GBO de mogelijkheid om canonieke gegevensmodellen van bronhouders te koppelen aan een gedeeld begrippenkader. Daarmee kunnen afnemers hun gegevensvraag beter afstemmen op het aanbod van de bronhouders.

GBO beschrijft ook de voorwaarden waaronder gegevens opvraagbaar zijn, zoals de grondslag en de dienst. Waar nodig biedt GBO mappings naar SDG-EDM en attestatieschema's.

Bronhouders blijven zelf verantwoordelijk voor hun gegevens en hoe ze deze aanbieden aan de centrale GBO voorzieningen. Om dit te configureren biedt GBO een decentraal configuratiecomponent aan bronhouders. Deze decentrale configuratie wordt bevraagd per gemeenschappelijke voorziening om gegevensvragen voor een specifiek kanaal af te handelen.

Hiervoor zijn de volgende stelselfuncties nodig:

Stelselfunctie	Relevante bouwstenen	Status	Ontbrekend onderdeel of actie
S10 — Semantiek & Gegevenscatalogus	Samenwerkende Catalogi. Begrippenvoorziening. Stelselcatalogus	Nog te realiseren ⚠️	Canonieke gegevensmodellen maken. Begrippenkader volgens NL-SBB maken. MIM toepassen. Catalogi volgens DCAT-AP-NL vastleggen. Mappings maken.

F5 — Gegevenskwaliteit & Validatie¶

GBO ontsluit overheidsgegevens voor hergebruik. Daarom moet de gegevenskwaliteit voldoende zijn geborgd. De precieze inrichting is nog niet uitgewerkt.

SHACL kan RDF-representaties, validatieprofielen en kwaliteitsmetadata controleren. Andere uitwisselformaten vragen om andere mechanismen, zoals JSON Schema, GraphQL-schema's, XML Schema of domeinspecifieke regels.

PROV-O kan de herkomst van gegevens vastleggen. Het NORA Kwaliteitsraamwerk en W3C DQV kunnen de gegevenskwaliteit meten.

Afnemers moeten onjuiste, onvolledige of verouderde gegevens kunnen terugmelden aan bronhouders. GBO moet hiervoor een proces inrichten.

Hiervoor zijn de volgende stelselfuncties nodig:

Stelselfunctie	Relevante bouwstenen	Status	Ontbrekend onderdeel of actie
S10 — Semantiek & Gegevenscatalogus	Samenwerkende Catalogi. Begrippenvoorziening. Stelselcatalogus	Nog te realiseren ⚠️	Validatieprofielen per gegevensset maken. Herkomst registreren. Gegevenskwaliteit meten. Terugmeldproces inrichten.

F6 — Grondslag & Beleid¶

Als toestemming de grondslag is, moet de bronhouder deze toestemming kunnen controleren. GBO biedt daarvoor een centraal toestemmingsregister.

Als een andere grondslag geldt, controleren beleidsregels deze grondslag. De PEP/PDP/PIP-keten controleert ook andere voorwaarden voor gegevensverzoeken.

Hiervoor zijn de volgende stelselfuncties nodig:

Stelselfunctie	Relevante bouwstenen	Status	Ontbrekend onderdeel of actie
S01 — Toestemmingsregister	Zie F2	Zie F2	Zie F2
S05 — Autorisatie (PEP/PDP/PIP)	Zie F2	Zie F2	Zie F2
S06 — Beleidsbeheer & -distributie (PAP)	Zie F2	Zie F2	Zie F2

F7 — Orkestratie & Integratie¶

GBO voorziet voor de huidige interactiepatronen geen afzonderlijke centrale procesorkestratie.

Om met GBO aan te sluiten op het OOTS Intermediair Platform, is een OOTS-adapter nodig. De aansluiting op de EUDI-Wallet van de gemeenschappelijke bronontsluiting vraagt om integratie met EUDI-standaarden.

Hiervoor zijn de volgende stelselfuncties nodig:

Stelselfunctie	Relevante bouwstenen	Status	Ontbrekend onderdeel of actie
S08 — OOTS-adapter	Zie F3	Zie F3	Zie F3
S11 — Attesteringsuitgifte (voor EUDI-Wallet)	Zie F3	Zie F3	Zie F3

F8 — Beheer & Continuïteit¶

Dit globaal ontwerp werkt beheer en continuïteit nog niet volledig uit. De volgende stappen moeten deze onderwerpen verder uitwerken.

GBO heeft hiervoor in ieder geval stelselfuncties nodig. De tabel noemt de stelselfunctie die nu het meest voor de hand ligt.

Stelselfunctie	Relevante bouwstenen	Status	Ontbrekend onderdeel of actie
S09 — Logging, Audit & Traceerbaarheid	Logboek Dataverwerking. Diginetwerk	FSC Logging, het Logboek Dataverwerking en de standaard Authorization Decision Log 1.0.0 zijn beschikbaar. De GBO-invulling ontbreekt nog.	Afspraken voor ketenbrede herleidbaarheid en verantwoording. Koppeling met de autorisatieketen maken.

Overzicht: stelselfuncties en generieke functies¶

De volgende tabel toont alle stelselfuncties en hun relatie met de generieke functies.

Stelselfunctie	Generieke functie(s)	Status
S01 — Toestemmingsregister (primair voor DvTP)	F2, F6	Nog te realiseren ⚠️
S02 — Toestemmingsportaal (primair voor DvTP)	F2	Nog te realiseren ⚠️
S03 — Burgeridentificatie & Pseudonimisering	F1	BSNk PP is beschikbaar. Integratie is nodig ⚠️. Identity Matching is nog in onderzoek ⚠️.
S04 — Organisatie-authenticatie & Vertrouwensstelsel	F1	FDS Poortwachter en Marktmeester zijn als concept uitgewerkt. GBO moet de beschikbaarheid en toepassing nog bepalen ⚠️.
S05 — Autorisatie (PEP/PDP/PIP)	F2, F6	AuthZEN NLGov-profiel is beschikbaar. FTV is in ontwikkeling. De GBO-inrichting ontbreekt nog ⚠️.
S06 — Beleidsbeheer & -distributie (PAP)	F2, F6	Nog te ontwerpen ⚠️
S07 — Gegevensontsluiting (bronontsluiting-API)	F3, F7	De NL API Strategie, API Design Rules en Digikoppeling met FSC zijn beschikbaar. GraphQL is nog niet gestandaardiseerd als API-profiel ⚠️.
S08 — OOTS-adapter	F3, F7	De Basisinrichting OOTS is beschikbaar. Waar afspraken over gegevensformaten zijn gemaakt, moeten partijen de semantische mapping nog ontwikkelen ⚠️.
S09 — Logging, Audit & Traceerbaarheid	F8	FSC Logging, Logboek Dataverwerking en Authorization Decision Log 1.0.0 zijn beschikbaar. De GBO-invulling ontbreekt nog ⚠️.
S10 — Semantiek & Gegevenscatalogus	F4, F5	Nog te realiseren ⚠️
S11 — Attesteringsuitgifte (voor EUDI-Wallet)	F3, F7	Nog te realiseren ⚠️

Legenda: ⚠️ betekent dat partijen een onderdeel nog moeten realiseren.

5 Te ontwikkelen componenten¶

Overzicht voorgestelde oplossing¶

Hoofdstuk 2 beschrijft de oplossingsrichting. De volgende figuur koppelt deze oplossingsrichting aan de componenten die de vereiste functies invullen.

%%{ init: { 'theme': 'base', 'themeVariables': { 'darkMode': false, 'background': '#FFFFFF', 'edgeLabelBackground': '#FFFFFF' }, 'themeCSS': 'svg, .mermaid, #mermaid-svg, .mermaid > svg { background-color: #FFFFFF !important; background: #FFFFFF !important; } @media (prefers-color-scheme: dark) { svg, .mermaid, #mermaid-svg, .mermaid > svg { background-color: #FFFFFF !important; background: #FFFFFF !important; } }' } }%% flowchart LR subgraph gbo["GBO Basis"] direction TB fsc_config("configuratie (services/mappings/etc.)") fsc("FSC / GraphQL / PBAC (generieke bronontsluiting)") fsc_tools("GBO tools (vertaallaag)") end subgraph eudi["EUDI-Wallet kanaal"] direction LR eudi_asi("ASI-provider (verify/retrieve dienst)") eudi_pubeaa("PubEAA-provider (PubEAA)") eudi_qeaa["QTSP (QEAA)"] eudi_wallet["EUDI-Wallet"] end subgraph oots["OOTS kanaal"] direction LR oots_adapter("OOTS-adapter (semantische mapping)") oots_basis["Basisinrichting OOTS (incl. OOTS-V backend)"] oots_afnemer["Europese overheid SDG-portaal"] end subgraph dvtp["DvTP kanaal"] direction LR dvtp_toestemming("Toestemmingsvoorziening") dvtp_pseudoniem["Pseudonimiseervoorziening (BSNk PP)"] dvtp_afnemer["Private dienstverlener"] end fsc_config --- fsc fsc --- fsc_tools bron[("Overheidsbronnen BRP · BD · UWV · KvK · …")] -- Bron API (GraphQL / REST-JSON / ...) --- gbo eudi_asi -- verify --- eudi_qeaa eudi_asi -- retrieve --- eudi_qeaa eudi_qeaa -- OpenID4VCI --- eudi_wallet gbo -- GraphQL --- eudi_asi & eudi_pubeaa & oots_adapter & dvtp_afnemer eudi_asi ~~~ eudi_pubeaa eudi_pubeaa -- OpenID4VCI --- eudi_wallet oots_adapter -- GraphQL --- oots_basis oots_basis -- e-Delivery/AS4 --- oots_afnemer gbo -. PIP .- dvtp_toestemming dvtp_toestemming -. consent-id .- dvtp_afnemer dvtp_toestemming -- REST-JSON --- dvtp_pseudoniem dvtp_pseudoniem ~~~ dvtp_afnemer eudi_wallet --- burger["Burger"] oots_afnemer --- burger dvtp_afnemer --- burger fsc:::gbo_d fsc_tools:::gbo_d fsc_config:::gbo_d eudi_asi:::gbo_k eudi_pubeaa:::gbo_k eudi_qeaa:::eudi eudi_wallet:::eudi oots_adapter:::gbo_k oots_basis:::oots oots_afnemer:::oots dvtp_toestemming:::gbo_c dvtp_pseudoniem:::dvtp dvtp_afnemer:::dvtp bron:::bron burger:::burger %% Subgraph Stijlen style gbo fill:#F4F5F7,stroke:#D1D5DB,stroke-width:1px style eudi fill:#F4F5F7,stroke:#D1D5DB,stroke-width:1px style oots fill:#F4F5F7,stroke:#D1D5DB,stroke-width:1px style dvtp fill:#F4F5F7,stroke:#D1D5DB,stroke-width:1px %% Elementstijlen classDef bron fill:#DDEBF7,stroke:#6F94B8,color:#1E293B classDef burger fill:#DDEBF7,stroke:#6F94B8,color:#1E293B classDef eudi fill:#f1efe8,stroke:#5f5e5a,color:#444441 classDef oots fill:#f1efe8,stroke:#5f5e5a,color:#444441 classDef dvtp fill:#f1efe8,stroke:#5f5e5a,color:#444441 classDef gbo_c fill:#FEDCD8,stroke:#E28F80,color:#1E293B classDef gbo_d fill:#DCFCE7,stroke:#16A34A,color:#0F172A classDef gbo_k fill:#FFEDD5,stroke:#EA580C,color:#0F172A

Figuur 5: Oplossingsrichting met de voorgestelde componenten.
Groen toont de generieke decentrale bronontsluiting. Oranje toont optionele centrale aansluitvoorzieningen. Rood toont verplichte centrale voorzieningen voor de betreffende gegevensstroom. Grijs toont bestaande voorzieningen waarop GBO aansluit.
De bronhouder beheert de bronspecifieke configuratie van de centrale componenten met behulp van het decentrale configuratiecomponent.

GBO levert drie soorten resultaten. De verplichting verschilt per soort:

Afspraken en standaarden. Deze zijn verplicht voor iedere deelnemer. Zij gelden voor de bronontsluiting-API, de autorisatieketen, de logging en de aansluitvoorwaarden. GBO legt deze afspraken vast in bestaande afsprakenstelsels (zie Stelselafspraken en voorzieningenbeheer).
Referentiecomponenten. Deze zijn optioneel. Een bronhouder mag een referentiecomponent, de GBO-vertaallaag of een functioneel gelijkwaardig alternatief gebruiken. Het alternatief moet aan de afspraken en standaarden voldoen.
Centrale voorzieningen. Of een centrale voorziening verplicht is, hangt af van de gegevensstroom.
De volgende tabel geeft per voorziening de status.

Voorziening	Gegevensstroom	Soort	Verplicht of optioneel	Beheerder
Bronontsluiting-API, PEP/PDP/PAP, FSC Inway	Alle	Decentraal, bij de bronhouder	Afspraken verplicht. Referentiecomponent optioneel.	Bronhouder
PAP	Alle	Centraal en/of decentraal	Afspraken verplicht. Referentiecomponent optioneel.	Nog te bepalen (zie PSA)
GBO-vertaallaag	Alle	Referentiecomponent	Optioneel	Nog te bepalen (zie PSA)
GBO-configuratie	Alle	Decentraal	Verplicht (voor de centrale componenten waar de bronhouder gebruik van wil maken)	Bronhouder
Voorziening voor PubEAA-uitgifte	EUDI-Wallet	Centrale aansluitvoorziening	Optioneel. Een bronhouder mag ook zelf PubEAA's buiten GBO uitgeven.	Nog te bepalen (zie PSA)
ASI-provider (verify en retrieve)	EUDI-Wallet	Centrale aansluitvoorziening	Optioneel. De verify-functie is voor bronhouders wel wettelijk verplicht (eIDAS2, artikel 45e), maar niet via GBO.	Nog te bepalen (zie PSA)
OOTS-adapter (semantische mapping)	OOTS	Centrale aansluitvoorziening	Optioneel. Een bronhouder mag zelf rechtstreeks op OOTS of OOTS-V aansluiten.	Nog te bepalen (zie PSA)
Toestemmingsvoorziening (portaal en register)	DvTP	Centrale voorziening	Verplicht voor de DvTP-stroom	Nog te bepalen (zie PSA). Vereist wettelijke verankering.
Pseudonimiseervoorziening (BSNk PP)	DvTP	Bestaande GDI-voorziening	Verplicht voor de DvTP-stroom	Logius

Voor publieke partijen geldt: een bronhouder die een gegevensstroom via GBO ontsluit, volgt de afspraken en standaarden van die stroom.
Voor private dienstverleners geldt: deelname aan de DvTP-stroom is vrijwillig. Een private dienstverlener die deelneemt, moet de toestemmingsvoorziening en BSNk PP gebruiken en aan de aansluitvoorwaarden voldoen. Het vertrouwensstelsel voor private dienstverleners is nog niet uitgewerkt.

Bouwstenen die hergebruikt worden¶

GBO gebruikt het Federatief Datastelsel (FDS) als basisafsprakenstelsel en de GDI-voorzieningen als basisvoorzieningen. GBO bouwt zoveel mogelijk voort op bestaande bouwstenen die daaruit voortkomen:

FSC voor koppelingen.
FTV voor autorisatie.
LDV voor logging en verantwoording.
DCAT-AP-NL voor gegevenscatalogi.
Poortwachter en Marktmeester voor aansluiting en naleving.

Poortwachter en Marktmeester zijn nog in ontwikkeling.

De oplossingsrichting hergebruikt de volgende bouwstenen.

FSC (Federated Service Connectivity). FSC is een binnenlands koppelnetwerk. Het verzorgt verbindingen op basis van mTLS tussen GBO, bronhouders en private dienstverleners. Iedere deelnemer beheert een eigen FSC Inway, Outway of allebei. FSC heeft een open referentie-implementatie en is de FDS-standaard voor binnenlands gegevensverkeer.

LDV (Logboek Dataverwerking). GBO gebruikt de LDV-standaard voor logging en verantwoording. Deze standaard koppelt dataverwerkingen van verschillende bronnen en afnemers aan elkaar.

GraphQL. GBO stelt GraphQL voor als protocol voor selectieve gegevensvragen aan de bronontsluiting-API. GraphQL is een aanvulling op REST. Bronhouders zonder GraphQL-implementatie mogen de GBO-vertaallaag gebruiken. Formele standaardisatie als FDS-datadiensttype verloopt via Digikoppeling en Forum Standaardisatie.

OAuth 2.0 / OpenID Connect. Dit protocol geeft toestemmingstokens uit na succesvolle identificatie van de burger. Voor de Nederlandse overheid wordt NL GOV Assurance profile for OpenID Connect 1.0.1 gebruikt. De burger gebruikt DigiD of een ander eIDAS-middel. Als het middel geen BSN bevat, koppelt Identity Matching het middel aan het BSN.

AuthZEN. AuthZEN is de gestandaardiseerde koppelinterface tussen de PEP en de PDP. Deze interface maakt de autorisatieketen onafhankelijk van een specifiek protocol of product. Voor de Nederlandse overheid wordt NLgov Profile for OpenID AuthZEN Authorization API 1.0.0 gebruikt.

Authorization Decision Log 1.0.0. Authorization Decision Log 1.0.0 beschrijft hoe organisaties autorisatiebeslissingen vastleggen. Daarmee kan men achteraf nagaan wie toegang kreeg, wanneer en op welke grondslag. Een uniek kenmerk koppelt registraties van meerdere organisaties in een proces aan elkaar.

ODRL (Open Digital Rights Language). ODRL is een W3C-standaard voor machineleesbare beleidsregels. GBO gebruikt ODRL als beschrijvingstaal voor beleidsregels in de PAP. Dit sluit aan op het gebruik van ODRL in FDS en DCAT-AP-NL.

BSNk PP (Polymorfe Pseudonimisering). BSNk PP is bij Logius in productie. GBO gebruikt deze voorziening voor alle DvTP-verzoeken. De voorziening zet het BSN om naar een partijspecifiek en onomkeerbaar pseudoniem. Dit gebeurt voordat een private dienstverlener gegevens ontvangt.

OpenID4VCI / OpenID4VP. OpenID4VCI ondersteunt de uitgifte van verifieerbare credentials aan een wallet. OpenID4VP ondersteunt de presentatie van credentials door een wallet aan een dienstverlener. Deze protocollen vormen de technische basis voor de EUDI-Wallet en andere toepassingen van VC's.

SD-JWT VC / mdoc (ISO 18013-5). Dit zijn attestatieformaten voor de EUDI-Wallet volgens het ARF. SD-JWT VC is het standaardformaat voor online presentatie. mdoc ondersteunt ook offline presentaties op korte afstand.

AS4 / e-Delivery via de Basisinrichting OOTS. AS4 en e-Delivery verzorgen het Europese OOTS-berichtenverkeer. GBO communiceert via GraphQL met de Basisinrichting OOTS. De Basisinrichting OOTS beheert de volledige AS4-laag.

Voor de beoogde toepassingen zijn aanvullende afspraken en componenten nodig. De volgende paragrafen beschrijven deze aanvullingen.

GraphQL als selectief bevragingsmechanisme¶

FDS gebruikt REST als standaardtype voor datadiensten volgens de NL API Strategie en REST API Design Rules. GBO stelt voor de bronontsluiting ook GraphQL voor. GraphQL maakt hergebruik eenvoudiger: met één API kunnen verschillende gegevensstromen bediend worden. Dit kan met configuratie in plaats van het moeten inrichten (en beheren) van een extra endpoint. Ook biedt GraphQL meer mogelijkheden voor dataminimalisatie: de vragende partij hoeft niet alle beschikbare gegevens op te vragen. GraphQL maakt selectieve veldopvraging standaard onderdeel van het querymodel. Bij REST moet een API selectieve veldopvraging expliciet ondersteunen.

Partijen moeten de volgende onderdelen nog afspreken of realiseren:

GraphQL als type datadienst positioneren. GBO stelt voor GraphQL naast REST te gebruiken. GraphQL ondersteunt structurele dataminimalisatie en hergebruik via parameters. GraphQL werkt met FSC Inway en Outway. Formele standaardisatie vraagt om een wijzigingsvoorstel via het kennisplatform API's, Digikoppeling en Forum Standaardisatie. De GBO-pilots doen al ervaring op met GraphQL.
Een GBO-vertaallaag maken. Deze laag ondersteunt bronhouders zonder eigen GraphQL-implementatie. De laag vertaalt een bestaande API naar een GraphQL-bron. Bronhouders hoeven GraphQL daardoor niet zelf te implementeren.
DCAT-AP-NL gebruiken. GBO volgt de bestaande FDS-verplichting voor gegevenscatalogi. Als aanvullende metadata nodig zijn, bespreekt GBO deze met de beheerder en gemeenschap van DCAT-AP-NL. GBO maakt geen eigen profiel boven op het bestaande DCAT-AP-NL profiel.
Een dienstencatalogus maken. Deze catalogus bevat toegestane gegevensvragen per toepassing. Afnemers kunnen geen gegevens opvragen die buiten de toegestane gegevensvragen vallen. GBO stelt voor om de inhoud van de dienstencatalogus federatief te beheren met een gemeenschappelijk profiel en centrale vindbaarheid.

Toestemming en grondslag als afdwingbaar autorisatiemechanisme¶

FDS verplicht een geldige grondslag voor gegevensuitwisseling. FDS schrijft geen technische oplossing voor toestemmingsbeheer of directe raadpleging van de grondslag voor.

FTV biedt een autorisatieraamwerk. Dit raamwerk kan voor ieder verzoek een extern toestemmingsregister als PIP raadplegen. Het raamwerk kan ook de doelbinding voor DvTP controleren.

Partijen moeten de volgende onderdelen nog afspreken of realiseren:

Een pseudonimiseringsprofiel voor GBO en DvTP. Dit profiel verplicht BSNk PP. Daardoor ontvangt een private dienstverlener nooit het BSN.
Een toestemmingsportaal voor burgers. Burgers kunnen hierin toestemming geven, bekijken en intrekken. Het portaal is gekoppeld aan het toestemmingsregister.
Een centraal toestemmingsregister. Het register koppelt iedere toestemming aan een doel, afnemer en gegevensset. Intrekking heeft direct effect. De autorisatieketen raadpleegt het register als PIP.
Een PEP/PDP/PIP-keten. Deze keten gebruikt AuthZEN en een policytaal zoals OPA/Rego. De keten vult het FTV-autorisatieraamwerk voor GBO in. Een PAP beheert de policies en verspreidt ze naar de PDP-instanties van bronhouders.
Een PAP (Policy Administration Point). Dit component beheert en verspreidt ondertekende policybundels. De PAP is ook het bestuurlijke gezagspunt voor toegangsregels. De governance moet bepalen wie policies mag opstellen, wijzigen en goedkeuren. GBO beschrijft de beleidsregels in ODRL. Dit sluit aan op FDS en DCAT-AP-NL.

Juridische voorwaarde: toestemming kan pas als afdwingbare grondslag werken nadat de benodigde wet- en regelgeving in werking is getreden. De technische uitwerking loopt parallel aan het wetgevingstraject.

OOTS-aansluiting¶

FDS is een binnenlands afsprakenstelsel en ondersteunt geen grensoverschrijdende gegevensuitwisseling. OOTS gebruikt AS4/e-Delivery als transportprotocol en SDG-EDM als semantisch kader. Beide vallen buiten de scope van FDS.

Partijen moeten de volgende onderdelen nog afspreken of realiseren:

Een protocolvertaler in de Basisinrichting OOTS. Deze vertaler zet AS4/e-Delivery-verkeer uit andere lidstaten om naar GraphQL voor GBO en andersom. Bronhouders hoeven daardoor geen OOTS-kennis te hebben. Zij gebruiken alleen de bronontsluiting-API.
Semantische mappings. Deze mappings vertalen de gegevens in het bronformaat naar SDG-EDM, indien geconfigureerd door de bronhouder. De vertaling gebeurt centraal met de instellingen uit het decentrale configuratiecomponent.

Uitgifte van attestaties voor de EUDI-Wallet (PubEAA-uitgifte)¶

Overheidsbronnen moeten attestaties kunnen uitgeven als verifieerbare credentials. De burger slaat deze credentials op in de EUDI-Wallet en kan ze daarna aan dienstverleners tonen (dit interactiepatroon valt buiten de scope van FDS).

Partijen moeten de volgende onderdelen nog afspreken of realiseren:

De rol van GBO als ondersteuner van PubEAA-uitgifte. GBO biedt infrastructuur voor uitgifte via OpenID4VCI en presentatie via OpenID4VP. GBO is juridisch geen PubEAA-verstrekker.
Attestatieschema's per gebruikssituatie. Deze schema's mappen attributen van bronhouders naar de vereiste EUDI-Walletschema's. De mapping gebeurt centraal met de instellingen uit het decentrale configuratiecomponent.
Een ondertekeningsinfrastructuur. Deze infrastructuur ondertekent attestaties digitaal volgens eIDAS2, het ARF en de relevante Europese Trusted Lists.
Standaardisatie van attestatieformaten. SD-JWT VC ondersteunt online presentatie. Mdoc volgens ISO 18013-5 ondersteunt offline presentaties op korte afstand.
Duidelijkheid over de rol van QTSP's. Een PubEAA heeft onder eIDAS2 dezelfde juridische waarde als een QEAA. Een QTSP is daarom niet verplicht voor grensoverschrijdend gebruik. Een bronhouder mag kiezen voor uitgifte via een QTSP. GBO ondersteunt beide varianten. De voorkeursroute is nog te besluiten (zie PSA).

Verificatie- en retrievedienst voor QTSP's (ASI-provider)¶

eIDAS2 verplicht lidstaten ervoor te zorgen dat QTSP's de in artikel 45e bedoelde attributen elektronisch kunnen verifiëren bij authentieke bronnen, rechtstreeks of via een aangewezen intermediair. De verify-dienst van de GBO ASI-provider kan hieraan invulling geven. Hiermee kunnen QTSP's attributen bij de bronhouder controleren voordat zij een attestatie uitgeven.
Deze verplichting valt buiten de scope van FDS en volgt uit Europese wetgeving.

Naast een verificatiedienst stelt GBO voor om ook een retrievedienst aan te bieden aan QTSP's. Daarmee kunnen zij attributen namens de bronhouder uitgeven. Deze dienst is niet verplicht, maar biedt de bronhouders meer opties om attributen uit te geven.

Partijen moeten de volgende onderdelen nog afspreken of realiseren:

Een ASI-provider. Dit component volgt ETSI TS 119 478 en bevat de interfaces I2 Verify, I3 Retrieve en I4 Authorize.
Technische aansluitvoorwaarden voor QTSP's op de ASI-provider. Deze voorwaarden vullen het FDS-Poortwachterproces aan. QTSP-erkenning, het vertrouwensanker en de certificaatprofielen (ETSI EN 319 412) volgen uit het eIDAS/EUDI-stelsel. GBO maakt hiervoor geen eigen afspraken.

Stelselafspraken en voorzieningenbeheer¶

Alle nieuwe afspraken en voorzieningen moeten onderdeel worden van een stelsel. Het stelsel moet het beheer, de naleving en de monitoring organiseren.

GBO wil de nieuwe afspraken en voorzieningen zo veel mogelijk opnemen in bestaande stelsels. De PSA geeft hiervoor een eerste voorstel. Verdere uitwerking blijft nodig.

6 Impact op betrokken partijen¶

Bronhouders moeten enkele componenten implementeren en beheren om GBO te gebruiken. GBO ondersteunt hen daarbij met referentiecomponenten en de GBO-vertaallaag.

GBO probeert ook de afnemers zo veel mogelijk te ondersteunen. Toch heeft de aansluiting ook voor hen gevolgen.

De volgende tabel geeft een eerste inschatting. De inschatting is gebaseerd op dit globaal ontwerp. Na de PSA, het technisch ontwerp en de technische requirements moet GBO de inschatting opnieuw beoordelen.

Partij	Impact	Toelichting
Bronhouder	Een GraphQL-bronontsluiting aanbieden, rechtstreeks of via een vertaallaag/functioneel gelijkwaardig alternatief. FSC en FTV implementeren. Relevante catalogi beheren, waaronder de dienstencatalogus en semantische mappings voor de verschillende gegevensstromen. Voor het beheer hiervan gebruikt de bronhouder één decentraal configuratiecomponent.	GBO biedt referentiecomponenten en een vertaallaag voor bronnen zonder GraphQL-API. Bronhouders mogen functioneel gelijkwaardige alternatieven gebruiken.
Integrators en softwareleveranciers	Decentrale componenten in software en dienstverlening implementeren. De afspraken en standaarden van het stelsel volgen.	Een integrator moet voldoen aan de technische aansluitvoorwaarden. De bronhouder blijft verantwoordelijk voor de inhoud van de gegevens.
QTSP	Aansluiten op de ASI-provider.	De aansluiting volgt Europese standaarden. Een QTSP heeft deze aansluiting nodig voor de uitgifte van QEAA's.
Basisinrichting OOTS	GraphQL ondersteunen in OOTS-V.	OOTS-V heeft al een FSC-koppeling.
Private dienstverlener	Toetreden tot het stelsel, aansluiten op BSNk, een FSC Outway implementeren en koppelen met de toestemmingsvoorziening.	Partijen moeten het stelsel nog uitwerken.
Burger	Gegevens met private dienstverleners kunnen delen op basis van centraal beheerde toestemming.	De burger houdt verschillende ingangen en stelsels voor het delen van persoonsgegevens. Het burgerperspectief valt nog buiten de scope.