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
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
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
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.