Realisatiestrategie¶

Werkwijze¶

Er komt geen nieuw stelsel en er komen geen "GBO"-voorzieningen, maar bestaande afspraken, standaarden en voorzieningen worden hergebruikt. Waar afspraken of standaarden aangevuld of aangepast moeten worden of voorzieningen ontworpen of ingericht moeten worden, wordt dit ingebracht bij de bestaande gremia. Voor het uitvoeren van pilots kan het nodig zijn om bepaalde functies tijdens de projectfase onder projectverantwoordelijkheid uit te voeren, maar voor in productiename zullen ook deze functies ondergebracht worden bij een bestaand afsprakenstelsel of een bestaande beheerorganisatie. Zie ook de paragraaf Gebruik van bestaande stelsels voor een verdere uitwerking hiervan.
Er worden gedurende de projectfase al wel pilots gestart waarin wordt gewerkt met de gewenste afspraken, standaarden en voorzieningen. Als deze nog niet bestaan, worden voorbeeld implementaties gebruikt die tevens gebruikt worden om het ontwerp te verbeteren. Uiteindelijk worden deze ontwikkelingen als referentie implementaties aangeboden aan de gremia waar het beheer belegd wordt. Dit gaat tot het niveau van "pre-productie": d.w.z. dat de afspraak of voorziening volledig genoeg is uitgewerkt om in productie genomen te kunnen worden. Maar de daadwerkelijke productiegang wordt aan de beoogde beheerder overgelaten. In sommige gevallen kan hier wet- en regelgeving voor nodig zijn, die in werking moet zijn getreden voor in productie gegaan kan worden.
De inrichting van de ontbrekende afspraken, standaarden en voorzieningen moet voldoen aan de ontwerpprincipes. Gedurende het traject worden de ontwikkelingen hier periodiek op beoordeeld, waarover zo openbaar mogelijk (maar in elk geval naar de betrokken partijen) wordt gerapporteerd.

Werkpakketten¶

De stelselfuncties die nodig zijn om de GBO te kunnen gebruiken voor de drie gewenste toepassingen worden opgedeeld in werkpakketten. Met deze werkpakketten is het mogelijk om de drie toepassingen los van elkaar mogelijk te maken en afhankelijk van de prioriteiten rond de toepassingen te implementeren. Verder bieden de werkpakketten verschillende "deployment-opties" (manieren waarop de stelselfuncties geïmplementeerd en beheerd kunnen worden) waar afhankelijk van de prioriteit en de afnemersvragen voor gekozen kunnen worden.

Er worden drie werkpakketten onderscheiden, die gekoppeld zijn aan de drie toepassingen. Daarnaast is er een werkpakket dat voor alle toepassingen nodig is: de GBO-basis functies.

flowchart LR subgraph gbo["GBO Basis"] direction TB fsc_pap("PAP (beleidsregels)") fsc("FSC / GraphQL / FTV (generieke bronontsluiting)") fsc_tools("GBO tools (vertaallaag)") end subgraph eudi["EUDI-Wallet"] direction LR eudi_asi("ASI-provider (verify dienst)") eudi_pubeaa("PubEAA-provider (PubEAA)") eudi_qeaa["QTSP (QEAA)"] eudi_wallet["EUDI-Wallet"] end subgraph oots["OOTS"] 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"] direction LR dvtp_toestemming("Toestemmingsvoorziening") dvtp_pseudoniem["Pseudonimiseervoorziening (BSNk PP)"] dvtp_afnemer["Private dienstverlener"] end fsc_pap --- fsc fsc --- fsc_tools bron[("Overheidsbronnen BRP · BD · UWV · KvK · …")] -- Bron API (GraphQL / REST-JSON / ...) --- gbo eudi_asi -- REST-JSON (HTTP / OAuth) --- eudi_qeaa eudi_qeaa -- OpenID4VCI --- eudi_wallet gbo -- GraphQL --- eudi_asi & eudi_pubeaa & oots_adapter & dvtp_afnemer eudi_pubeaa -- OpenID4VCI ---- eudi_wallet oots_adapter -- REST-JSON --- oots_basis oots_basis -- eDelivery-AS4 --- oots_afnemer gbo -- REST-JSON (PIP) --- dvtp_toestemming dvtp_toestemming -- REST-JSON --- dvtp_afnemer dvtp_toestemming -- REST-JSON --- 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 classDef bron fill:#edf7df,stroke:#6aa13a,color:#27500a classDef generiek fill:#f1efe8,stroke:#5f5e5a,color:#444441 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:#fff0e8,stroke:#000000,color:#000000 classDef burger fill:#edf7df,stroke:#6aa13a,color:#27500a

De werkpakketten getekend in relatie tot elkaar.
NB: in deze figuur zijn enkel de voorzieningen geschetst - daarnaast kunnen de werkpakketten ook afspraken of standaarden nodig hebben.
De lichtrode voorzieningen moeten nog ontwikkeld worden. De overige voorzieningen bestaan al - daar moet op aangesloten worden.

Werkpakket GBO Basis¶

Legt de gemeenschappelijke fundatie voor alle drie de toepassingen: generieke bronontsluiting (GraphQL/FSC), autorisatieketen (PEP/PDP/PIP/PAP), logging en semantische catalogus.

#	Onderdeel	Stelselfunctie	Afspraken (nog te maken)	Standaarden (te kiezen)	Voorzieningen (hergebruiken of ontwikkelen)
1	Bronontsluiting API	S07	Stelselafspraak (FDS): - één generieke ontsluiting per bronhouder, geen trajectspecifieke koppelingen - query-registratie verplicht - onboardingprocedure bronhouders	- FSC ✅ - GraphQL ✅ (⚠️ positionering in FDS) - DCAT-AP NL ✅	FSC Inway ✅ - FSC Outway ✅ - Query Template Registry ⚠️
2	PEP/FTV in FSC + stelselrollen	S05	Architectuurafspraak: - geünificeerde PEP/PDP-keten voor alle trajecten - GBO-AuthZEN-profiel - BSN-resolving alleen post-decision in PEP	- AuthZEN NL Gov (draft) - OPA/Rego ✅ (iWlz)	- PEP ⚠️ (ref-impl.) - PDP ⚠️ (ref-impl.) - PAP/Policy Store ⚠️
3	Logging & traceerbaarheid	S09	- LDV-logging verplicht voor alle GBO-componenten - cross-component correlatie via trace-identifier	- LDV ✅ (ref-impl.) - OpenTelemetry ✅ - W3C Trace Context ✅	- LDV-logging per component ⚠️ (decentraal)
4	Semantiek & catalogus	S10	- Canoniek schema verplicht per bronhouder - serialisaties zijn afgeleid	- DCAT-AP NL ✅ - SHACL ✅	- GBO Schema Registry ⚠️ - Serialisatie-service ⚠️

Werkpakket EUDI-wallet (EDI)¶

Maakt het mogelijk dat burgers overheidsgegevens als digitale attestatie (PuBEAA) in een EUDI-wallet opslaan. Bouwt op GBO Basis.

#	Onderdeel	Stelselfunctie	Afspraken (nog te maken)	Standaarden (te kiezen)	Voorzieningen (hergebruiken of ontwikkelen)
1	PuBEAA provider (centrale uitgiftedienst)	S11	- Attestation Rulebook per attribuuttype - wallet binding-profiel - intrekkingsbeleid - ⚖️ opname op NL Trusted List (RDI) - ⚖️ conformiteitsbeoordeling vereist (Verordening 910/2014)	- OpenID4VCI ✅ - SD-JWT VC ✅ - mdoc (ISO 18013-5) ✅ - QESeal (ETSI EN 319 412) ✅ - Token Status List ⚠️	- Centrale PuBEAA uitgiftedienst ⚠️ - Opname LoTE ⚠️ - NL Wallet ✅ (pilot)
2	Authentic Source Interface (verificatiedienst)	S11	- Welke partijen de verificatieservice mogen bevragen en onder welke voorwaarden?	- OpenID4VP ✅	- Centrale verificatiedienst ⚠️
3	Mapping GraphQL → EDI-attestaties	S10	- Mapping naar PuBEAA attestatieschema's verplicht per bronhouder	- SD-JWT VC / mdoc	- Serialisatie-service ⚠️ (onderdeel S10)

Werkpakket OOTS¶

Maakt het mogelijk dat Europese overheden via OOTS (Once Only Technical System) bewijsstukken opvragen bij Nederlandse bronhouders (SDG-verordening EU 2018/1724). Bouwt op GBO Basis.

#	Onderdeel	Stelselfunctie	Afspraken (nog te maken)	Standaarden (te kiezen)	Voorzieningen (hergebruiken of ontwikkelen)
1	OOTS-adapter (XML ↔ GraphQL)	S08, S10	Architectuurafspraak: - Basisinrichting OOTS is enige AS4-toegangspoort - SMP-registratie centraal beheerd - OOTS-verzoeken door zelfde PEP/PDP-keten	- eDelivery AS4 ✅ - OOTS-EDM ✅ - SMP 2.1 ✅	- Domibus Access Point ✅ (⚠️ inrichting) - OOTS Adapter ⚠️ - SMP Publisher ⚠️
2	Mapping GraphQL → OOTS-schema's	S10	- Mapping naar OOTS Semantic Repository evidence types verplicht - per bronhouder bepalen welke data ontsloten wordt	OOTS-EDM ✅	Via GBO Schema Registry (S10)

Werkpakket DvTP¶

Maakt het mogelijk dat private dienstverleners met toestemming van de burger gegevens opvragen bij overheidsbronhouders. Bouwt op GBO Basis en voegt toestemmingsinfrastructuur toe.

⚖️ Juridische randvoorwaarde: Pas operationeel na inwerkingtreding van de Wdo-grondslag (expliciete bevoegdheid voor bronhouders om op verzoek van de burger gegevens te verstrekken aan private dienstverleners) en bijbehorende AMvB. Technische uitwerking loopt parallel aan het wetgevingstraject.

#	Onderdeel	Stelselfunctie	Afspraken (nog te maken)	Standaarden (te kiezen)	Voorzieningen (hergebruiken of ontwikkelen)
1	Toestemmingsportaal	S02	- GBO-UX-richtlijnen (doel, afnemer, gegevens, geldigheidsduur) - ⚖️ gelijkwaardig alternatief verplicht (wettelijk te verankeren in Wdo) - ⚖️ geen nadeel bij weigering - architectuurafspraak: pseudonimisering in portaal	- DigiD (SAML/OIDC) ✅ - WCAG 2.1 AA ✅	- Toestemmingsportaal ⚠️ - BSNk Activate ✅ (⚠️ onboarding portaal)
2	Toestemmingsregister	S01	- Grondslagtypen per traject (toestemming/wettelijke basis/doelbinding) - formaat grondslag-record - intrekkingsrecht burger - ⚖️ Wdo-grondslag vereist	- W3C ODRL ✅ - GBO PIP-profiel ⚠️	- Toestemmingsregister ⚠️ - Policy Store ⚠️
3	Aansluiting BSNk PP	S03	- BSN mag private dienstverleners nooit bereiken (verankerd in AMvB Wdo/Wabvpz) - onboarding private dienstverleners als BSNk PP-deelnemer		- BSNk PP ✅ (productie) - BSNk Transform/Close ✅ (⚠️ PEP-integratie)
4	Aansluiting Stelsel Toegang	S04	- Onboardingprocedure private dienstverleners - welke trust anchors geaccepteerd per traject	- PKI Overheid ✅ - eIDAS Trusted Lists ✅	- FDS Poortwachter ⚠️ - FDS Marktmeester ⚠️ - eHerkenning ✅
5	Policies voor afnemers o.b.v. dienstenregister	S05, S06	- Beleidstemplates per traject (wie mag wat opvragen, onder welke grondslag) - governance beleidswijzigingen - RFC-procedure analoog aan iWlz	- OPA/Rego ✅ - OPA Bundle API ✅ - W3C ODRL ✅	- PAP/Policy Store ⚠️ - OPA Bundle Server ⚠️

Legenda: ✅ beschikbaar / in gebruik · ⚠️ nog te realiseren · ⚖️ juridische randvoorwaarde

Implementatie bij bronhouders¶

Bronhouders die gebruik willen maken van GBO moeten de componenten van het GBO-Basis werkpakket in de eigen omgeving installeren en onderhouden. Alleen de policy store met beleidsregels (PAP) wordt centraal aangeboden, maar daar moet wel op aangesloten worden.
GBO biedt bronhouders hiervoor referentiecomponenten aan, die de inrichting sterk vereenvoudigen. En als het (nog) niet haalbaar is om gegevens uit de bron met een GraphQL-API beschikbaar te stellen, biedt GBO ondersteuning en tools om eventueel met andere API's aan te sluiten.

Als bronhouders de GBO-Basis componenten hebben geïnstalleerd kunnen ze gebruik maken van de centrale componenten om de verschillende gegevensstromen te bedienen. Daar hoeven zij verder niets voor in te richten - er moeten enkel afspraken gemaakt worden over wie wanneer onder welke voorwaarden gegevens mogen opvragen.

Of bronhouders gebruik maken van de centrale componenten die nodig zijn om de verschillende gegevensstromen te bedienen, is een beleidsafweging. Voor zover deze componenten niet in wet- en regelgeving zijn opgenomen en (nog) niet op de pas-toe-of-leg-uit lijst staan, is het de bronhouders vrij om eigen componenten te gebruiken.
Zo kan voor het uitgeven van geattesteerde attributen (EUDI-Wallet) ook een eigen PubEAA-provider gebruikt worden, of afspraken met QTSP's gemaakt worden om QEAA's uit te geven. En voor aansluiting op OOTS kunnen ook eigen voorzieningen gebruikt worden, zoals in de onderwijswereld al gebruik gemaakt wordt van EMREX.

Gebruik van bestaande stelsels¶

GBO zal gebruik maken van bestaande afspraken, standaarden en voorzieningen, maar daar ook een aantal aan toevoegen of uitbreiden. De afspraken, standaarden en voorzieningen die ontwikkeld worden, moeten landen in bestaande afsprakenstelsels en/of beheerorganisaties. Als er sprake is van een doorontwikkeling is de keuze voor dat afsprakenstelsel of die beheerorganisatie eenvoudig: dat blijft bij de huidige organisatie en de doorontwikkeling wordt zoveel mogelijk met of zelfs door die organisatie doorgevoerd. Maar voor nieuwe afspraken, standaarden of voorzieningen moet een geschikte organisatie gevonden worden.
In de onderstaande tabel is per stelselfunctie aangegeven waar de bijbehorende afspraken, standaarden en voorzieningen naar verwachting kunnen landen. Daarbij is onderscheid gemaakt tussen inhoudelijke governance, standaardbeheer en operationeel beheer van voorzieningen. Voor onderdelen waarvoor nog geen bestaande beheerorganisatie evident is, is het open besluitpunt expliciet gemaakt.

Stelselfunctie / beheerobject	Werkpakket / relatie	Aard	Beoogd afsprakenstelsel / governance	Beoogde beheerorganisatie(s)	Toelichting	Status / besluitpunt
GraphQL-profiel voor bronontsluiting	GBO Basis / S07	Standaard / profiel	Digikoppeling voor koppelvlaknormering; FDS voor gebruiksafspraken	Logius, in afstemming met FDS/IBDS en Kennisplatform API’s	GraphQL is het beoogde generieke koppelvlak voor bronontsluiting. Het profiel hoort qua technische API-governance logisch bij Digikoppeling/API-standaarden, maar het gebruik ervan binnen gegevensdeling — bijvoorbeeld query-governance, autorisatie en onboarding — hoort bij FDS.	Besluiten of GraphQL formeel een Digikoppeling-profiel wordt, een FDS-profiel, of een combinatie van beide.
FSC-bronontsluiting: Inway, Outway en aansluitvoorwaarden	GBO Basis / S07	Afspraak + voorziening / component	FDS	FDS/IBDS voor stelselafspraken; RINIS voor operationeel beheer	FSC is de beoogde transport- en vertrouwensinfrastructuur voor federatieve bronontsluiting. De afspraken over één generieke ontsluiting per bronhouder, onboarding en aansluiting moeten landen in FDS.
Query Template Registry en query-registratie	GBO Basis / S07	Voorziening + beheerproces	FDS	FDS/IBDS; uitvoeringsbeheer nader te bepalen, mogelijk Logius of beheerder van een FDS-catalogus/developerportaal	Query-registratie is essentieel om generieke GraphQL-ontsluiting beheersbaar en autoriseerbaar te maken. Dit is meer dan een technische repository: het raakt governance op welke gegevensvragen zijn toegestaan.	Nog expliciet beleggen; ontbreekt nu als afzonderlijk beheerobject.
Federatieve Toegangsverlening: PEP/PDP/PIP-profiel	GBO Basis / S05	Architectuurafspraak + standaardprofiel	FDS / GDI-governance	Ontwikkeling via Realisatie IBDS/FDS; structureel beheer bij Logius of een GDI-beheerlijn	De PEP/PDP/PIP-keten is de generieke autorisatieketen voor alle gegevensstromen. Het profiel moet voorkomen dat EDI, OOTS en DvTP elk een eigen autorisatiemodel krijgen.	Structurele beheerrelatie tussen FDS, GDI en Logius expliciteren.
GBO-AuthZEN-profiel	GBO Basis / S05	Standaard / profiel	FDS / GDI	Logius/FDS, met IBDS als ontwikkelomgeving	Het profiel concretiseert hoe autorisatiebesluiten worden gevraagd en genomen binnen de GBO-keten. Het hoort bij de FTV-afspraken en moet generiek bruikbaar zijn voor meerdere gegevensstromen.	Status van draft naar beheer expliciet maken.
PAP, Policy Store en OPA Bundle Server	GBO Basis / S05-S06	Voorziening + beheerproces	FDS / FTV-governance	FDS/IBDS; operationeel beheer nader te bepalen, mogelijk Logius	Policybeheer is een aparte stelselfunctie en moet niet impliciet onder “toestemming” of “FTV” verdwijnen. Het gaat om beleidstemplates, wijzigingsprocedures, distributie van policies en versiebeheer.	Als aparte rij opnemen; besluit nodig over eigenaar van policy-governance en technisch beheer.
Beleidstemplates en RFC-procedure voor afnemersdiensten	DvTP / S05-S06	Afspraak + beheerproces	FDS, mogelijk aangevuld met sectoraal afsprakenstelsel of TIP voor private partijen	FDS/IBDS; betrokkenheid van sectorale stelsels en private vertrouwensstelsels	Voor DvTP moet worden vastgelegd wie welke gegevens mag opvragen, onder welke grondslag, voor welke dienst en met welke geldigheidsduur. Dit vraagt inhoudelijke governance, niet alleen technische policy-distributie.	Besluit nodig over verhouding tussen FDS, sectorale stelsels, TIP en wettelijke DvTP-kaders.
Logboek Dataverwerkingen en traceerbaarheid	GBO Basis / S09	Standaard + verplicht gebruik	FDS / GDI	Logius	LDV is het logische generieke kader voor logging van dataverwerkingen. Voor GBO moet worden vastgelegd dat alle componenten LDV-conform loggen en dat cross-component correlatie mogelijk is via trace-identifiers.	Aanscherpen naar verplicht gebruik voor alle GBO-componenten en opnemen van correlatie-eisen.
OpenTelemetry en W3C Trace Context-profiel	GBO Basis / S09	Technisch profiel	FDS / technische architectuurgovernance	Logius/FDS, eventueel in afstemming met beheerder LDV	Naast de functionele LDV-logging zijn technische traceerbaarheid en correlatie nodig tussen portaal, PEP, FSC, bronhouder en adapters.	Beleggen als technisch profiel bij de logging- en observability-afspraken.
Semantische standaarden: DCAT-AP NL, NL-SBB, RDF/SHACL, herkomstmetadata	GBO Basis / S10	Standaard / semantische governance	Federatief: FDS voor gebruik, Geonovum voor semantische standaarden waar passend	Geonovum voor relevante semantische standaarden; domeinbronhouders voor domeinmodellen	Semantiek moet federatief worden ingericht: centrale kaders voor vindbaarheid, beschrijving en validatie, maar domeinen blijven verantwoordelijk voor hun eigen begrippen en gegevensmodellen.	Verduidelijken welk deel standaardbeheer is en welk deel domeinverantwoordelijkheid.
GBO Schema Registry	GBO Basis, EDI, OOTS / S10	Voorziening	FDS-catalogusgovernance, met semantische kaders vanuit Geonovum	Operationeel beheer nader te bepalen; inhoudelijke verantwoordelijkheid bij bronhouders/domeinen	De Schema Registry is nodig voor canonieke schema’s per bronhouder en vormt de basis voor serialisatie naar EDI- en OOTS-formaten. Dit is geen zuivere semantische standaard, maar een beheerde voorziening.	Nieuwe voorziening; beheerder en financiering expliciet bepalen.
Serialisatie-service GraphQL → EDI/OOTS	GBO Basis, EDI, OOTS / S10-S11-S08	Voorziening / referentiecomponent	FDS voor generiek gebruik; EDI- en OOTS-governance voor specifieke doelmodellen	Operationeel beheer nader te bepalen; inhoudelijke mapping onder verantwoordelijkheid van bronhouders en betreffende stelsels	De serialisatie-service vertaalt generieke brondata naar specifieke attestatie- of evidence-formaten. Dit is een cruciale brugfunctie tussen generieke bronontsluiting en domeinspecifieke Europese stelsels.	Apart beleggen; niet automatisch onder Geonovum of Logius schuiven zonder besluit.
Centrale vertaallaag REST/SOAP → GraphQL	GBO Basis / deployment-optie C	Tijdelijke voorziening / overgangscomponent	Projectgovernance tijdens pilot; daarna FDS of uitfaseren	Tijdelijk GBO-project; structureel beheer alleen als overgangsvoorziening expliciet wordt toegestaan	De vertaallaag helpt bronhouders die nog geen eigen GraphQL-API kunnen aanbieden. Omdat de doelarchitectuur ligt bij bronhouder-eigen GraphQL-ontsluiting, moet deze voorziening een tijdelijk karakter houden.	Besluit nodig over beheerduur, exitcriteria en voorwaarden voor productiegebruik.
PuBEAA-provider voor publieke attestaties	EUDI-wallet / S11	Voorziening + wettelijke rol	EUDI-Wallet-governance / nationale eIDAS-governance	Nader te bepalen; RvIG logisch voor PID/BRP-gerelateerde attributen; mogelijk federatief model voor domeinattributen	PuBEAA-uitgifte vraagt certificering, opname op relevante vertrouwenslijsten en duidelijke bronhouderverantwoordelijkheid. RvIG is logisch voor persoonsidentiteitsgegevens, maar niet automatisch voor alle publieke attributen.	Besluit nodig over centraal, decentraal of federatief uitgiftemodel.
Attestation Rulebooks per attribuuttype	EUDI-wallet / S11	Afspraak / inhoudelijke governance	EUDI-Wallet-governance, met bronhouder- en domeingovernance	BZK voor nationale regie; bronhouders/domeinen voor inhoud; technische beheerder nader te bepalen	Per attribuuttype moet worden vastgelegd welke bron leidend is, welke gegevens worden uitgegeven, welke binding en intrekking gelden en welke betrouwbaarheidsniveaus van toepassing zijn.	Apart beleggen naast de technische PuBEAA-provider.
ASI-provider / verificatiedienst	EUDI-wallet / S11	Voorziening	EUDI-Wallet-governance / nationale eIDAS-governance	Nader te bepalen; Logius mogelijk voor generieke technische infrastructuur	De ASI-providerfunctie betreft het kunnen verifiëren of opvragen van gegevens bij authentieke bronnen. Logius kan logisch zijn voor generieke infrastructuur, maar de inhoudelijke verantwoordelijkheid blijft bij bronhouders.	Verduidelijken verschil tussen technische ASI-infrastructuur en inhoudelijke bronhouderverantwoordelijkheid.
Mapping GraphQL → EDI-attestaties	EUDI-wallet / S10-S11	Semantische mapping + beheerproces	EUDI-Wallet-governance, gekoppeld aan GBO Schema Registry	Bronhouders/domeinen inhoudelijk; technische ondersteuning via beheerder Schema Registry/Serialisatie-service	De mapping bepaalt hoe brongegevens worden vertaald naar SD-JWT VC, mdoc of andere attestatieformaten. Dit raakt zowel semantiek als juridische betekenis van attributen.	Beleggen per attribuuttype; koppelen aan Attestation Rulebooks.
OOTS-basisinrichting: Domibus Access Point en SMP	OOTS / S08	Voorziening + aansluitafspraak	OOTS-governance	BZK/bNC-SDG voor nationale regie; RINIS logisch voor basisinrichting en technische OOTS-aansluiting	Voor OOTS ligt het beheer van de AS4-toegangspoort, Domibus-inrichting en SMP-registratie dichter bij de bestaande OOTS-basisinrichting dan bij generieke GBO-governance.	Expliciet maken dat dit geen generieke GBO-voorziening is, maar aansluiting op OOTS-basisinrichting.
GBO OOTS-adapter XML ↔ GraphQL	OOTS / S08-S10	Voorziening / adapter	OOTS-governance + FDS voor achterliggende bronontsluiting	Operationeel beheer nader te bepalen; nationale SDG-regie opdrachtgever	De adapter vertaalt OOTS-verzoeken naar GraphQL en terug naar OOTS-EDM. Dit is een specifieke gegevensstroomadapter bovenop de generieke GBO-basis.	Beheer apart beleggen; niet laten verdwijnen onder “semantische vertaling”.
Mapping GraphQL → OOTS Evidence Types	OOTS / S10	Semantische mapping + inhoudelijke governance	OOTS-governance, met semantische kaders vanuit Geonovum waar passend	bNC-SDG/BZK als nationale opdrachtgever; bronhouders voor inhoud; Geonovum mogelijk voor methodiek/standaarden	De mapping naar OOTS Evidence Types is deels technisch-semantisch, maar ook inhoudelijk: welke Nederlandse gegevens bewijzen welk Europees evidence requirement?	Besluit nodig over nationale regie en goedkeuringsproces per evidence type.
Toestemmingsportaal voor burgerinteractie	DvTP / S02	Voorziening + UX-afspraken	GDI-governance / DvTP-governance	Logius/MijnOverheid als kandidaat; BZK voor wettelijke en beleidsmatige regie	Het portaal moet burgers inzicht geven in doel, afnemer, gegevensset, geldigheidsduur, intrekking en gevolgen van weigering. De functie sluit aan bij MijnOverheid, maar vraagt zwaardere juridische en UX-eisen dan alleen tonen van overheidszaken.	Besluit nodig over centrale of decentrale portaalvariant.
Toestemmingsregister / grondslagregister	DvTP / S01	Voorziening + juridisch beheerproces	GDI-governance / FDS / DvTP-governance	Logius of IBDS als kandidaat; BZK als opdrachtgever vanwege Wdo-grondslag	Het register fungeert als PIP voor PDP-besluiten en moet grondslag, doelbinding, geldigheid, intrekking en bewijsbaarheid vastleggen.	Juridische grondslag en beheerder moeten vóór productie zijn vastgesteld.
GBO PIP-profiel voor toestemming en grondslag	DvTP / S01-S05	Standaard / profiel	FDS / FTV-governance	FDS/IBDS; structureel beheer mogelijk bij Logius	Het PIP-profiel bepaalt hoe PDP’s toestemmings- en grondslaginformatie opvragen en interpreteren. Dit moet generiek genoeg zijn voor meerdere trajecten, niet alleen DvTP.	Als apart profiel opnemen naast het toestemmingsregister zelf.
BSNk PP, Transform/Close en pseudonimisering	DvTP / S03	Voorziening + aansluitafspraken	GDI / BSNk-governance	Logius/BSNk, onder regie van BZK	De BSN-koppeling en pseudonimisering zijn randvoorwaardelijk om te voorkomen dat private dienstverleners het BSN ontvangen. Integratie met PEP/FSC moet expliciet onderdeel zijn van de GBO-architectuur.	Aansluiting en PEP-integratie uitwerken.
Organisatie-authenticatie en trust anchors	DvTP / S04	Vertrouwensafspraken + standaarden	FDS voor publieke partijen; aanvullend stelsel voor private partijen, bijvoorbeeld TIP/eHerkenning waar passend	FDS/IBDS, Logius/eHerkenning, sectorale of private vertrouwensstelsels	Voor private dienstverleners moet worden vastgesteld welke organisaties mogen aansluiten, hoe zij worden geauthentiseerd en welke trust anchors worden geaccepteerd.	Besluit nodig over verhouding tussen FDS, eHerkenning, TIP en sectorale stelsels.
FDS Poortwachter en Marktmeester	DvTP / S04	Stelselrol / governancefunctie	FDS	FDS/IBDS; structureel beheer nader te bepalen	Poortwachter- en marktmeesterfuncties zijn nodig voor toelating, toezicht, registratie en beheer van deelnemers. Zonder deze functies blijft het vertrouwensstelsel onvoldoende operationeel.	Nog inrichten; opnemen als expliciete afhankelijkheid voor productie.
Dienstenregister voor DvTP-afnemersdiensten	DvTP / S05-S06	Voorziening + governanceproces	DvTP-governance / FDS / mogelijk TIP voor private diensten	Nader te bepalen; inhoudelijke verantwoordelijkheid bij toelatende overheid of sector	Het dienstenregister is nodig om policies te kunnen baseren op concrete diensten: wie vraagt gegevens op, voor welk doel, onder welke grondslag en met welke toegestane gegevensset.	Ontbreekt nu als expliciet beheerobject; toevoegen aan beheerlandingsmatrix.
Deployment-packages en referentie-implementaties	Alle werkpakketten	Referentiecomponenten / pre-productie artefacten	Projectgovernance tijdens ontwikkeling; structurele landing per component	GBO-project tijdelijk; uiteindelijke beheerder verschilt per component	Tijdens pilots kunnen componenten onder projectverantwoordelijkheid worden ontwikkeld. Voor productie moet per component vooraf duidelijk zijn bij welk stelsel of welke beheerorganisatie deze landt.	Per referentiecomponent overdrachtsplan en acceptatiecriteria opstellen.