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 burger om gegevens via wallet te delen¶
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) doet dit.
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. Ook de autorisatiedienst die door de Pub-EAA-dienst en de verificatiedienst aangeroepen wordt, kan door de bronhouder aangeboden worden, maar het biedt schaalvoordeel om dat te centraliseren in een GBO dienst.
Gegevensverzoek van Europese overheidsdienst aan Nederlandse overheidsbron¶
Een Europese overheidsdienst vraagt een gegeven (Evidence Request) aan een Nederlandse overheidsbron om een dienst aan een Nederlandse burger in het buitenland te kunnen leveren.
sequenceDiagram
autonumber
participant BRG as Burger<br/>(rechthebbende)
participant EU as EU dienst<br/>(SDG/OOTS)
participant RINIS as Basisinrichting OOTS NL<br />(BZK/RINIS)
participant GBO as GBO<br/>(GBO voorziening)
participant BRH as Bronhouder<br/>(BRP / BD / …)
rect rgb(250, 241, 251)
Note over BRG,EU: ① Burger neemt dienst af
BRG->>EU: Verzoek dienst
Note over EU: Gegeven Bronhouder nodig
end
rect rgb(230, 241, 251)
Note over EU,RINIS: ② OOTS-verzoek<br />(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 (REST/JSON)
Note over RINIS: eDelivery → REST ontkoppeling
end
rect rgb(225, 245, 238)
Note over GBO,BRH: ④ Bronontsluiting (GBO generieke API)
GBO->>BRH: API-aanroep (GBO-formaat)
BRH->>GBO: Gegevens (REST/JSON)
end
rect rgb(225, 245, 238)
Note over GBO: ⑤ Semantische mapping & logging (intern GBO)
Note over GBO: GBO-formaat → SDG Evidence type · audit log · doelbinding
end
rect rgb(250, 238, 218)
Note over GBO,RINIS: ⑥ Terugkoppeling naar OOTS basisinrichting
GBO->>RINIS: Evidence Response (REST/JSON)
Note over RINIS: REST → eDelivery 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<br />(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
Interactiepatroon gegevensverzoek Europese overheidsdienst via SDG/OOTS
BZK heeft RINIS aangewezen als nationaal OOTS-toegangspunt (AS4/eDelivery), waar de OOTS basisinrichting in beheer is. Die geeft het Evidence Request als REST/JSON door aan GBO. GBO verzorgt de bronontsluiting en de semantische mapping naar het SDG Evidence-formaat. Bronhouders zien uitsluitend de GBO-API en hoeven geen OOTS-kennis te hebben.
De terugkoppeling volgt de omgekeerde route: GBO retourneert aan de OOTS basisinrichting, waar het bericht in AS4 wordt verpakt. Na de toestemmingsinteractie met de burger wordt het bericht als Evidence Response teruggestuurd naar de Europese overheidsdienst.
Gegevensverzoek van private partij met toestemming aan bronhouder (DvTP)¶
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.