Ga naar inhoud

Introduction and goals

The Technisch Ontwerp (TO) is the technical design of Gemeenschappelijke Bronontsluiting (GBO). It describes the GBO facilities (voorzieningen) and interfaces (koppelvlakken). The TO goes one level deeper than the Globaal Ontwerp (GO) and stays within the frameworks of the Projectstartarchitectuur (PSA).

The TO uses the arc42 template. It records how the GBO components are built. For why GBO exists and what it must do, see the PSA introduction and the GO solution direction.

Baseline: the demo at v0.9.0

The reference implementation gbo-demo is the ground truth for the behavior of GBO. This version of the TO is pinned to demo tag v0.9.0 (November 2, 2026). Every statement about behavior links to code or a test at that tag. Each divergence between the design and the implementation has a record in one of these places:

Earlier work in the TO

The TO is the standalone reference for the technical design of GBO. It absorbs two earlier bodies of work:

The IDs did not change (REQ-NN, RL-NN, AV-NN, BSNK-NN, F-NN, Q-NN, SL-NN). A reader who knows an old ID finds it under the same number.

How this document is organized

The TO has three parts:

Part Content
arc42 sections 1 to 12 The design: constraints, context, strategy, building blocks, runtime scenarios, deployment, crosscutting concepts, decisions, quality, risks, and glossary.
Requirements Testable demands on what GBO builds and on its interfaces (REQ), guidelines for bronhouders (RL), candidate connection conditions (AV), and BSNk preconditions (BSNK).
Traceability The chain from design to demo: the matrix, demo increments (SL), findings (F), open questions (Q), and feedback to standards bodies (E1 to E10).

Each arc42 page and each ADR ends with a "Traceability" section. This section lists the requirements, findings, open questions, and demo increments that the page explains or depends on.

Routes

GBO gives bronhouders one technical backbone for several data flows. A bronhouder is a government organization that holds an authentic source. A bronhouder exposes a GraphQL API behind an FSC Inway. Every request passes the same chain: the FSC Inway as PEP, the PDP of the source, the source gateway, and the source API. The routes differ at the consumer edge and in the evidence that a request carries. The evidence selects the authorization regime (ADR-0031).

gbo-demo v0.9.0 implements three routes end to end:

  • DvTP (Delen van gegevens via Toestemming met Private dienstverleners). A citizen gives consent, and a private consumer requests source data under that consent. The consumer never holds a citizen identifier. An integrator can call on behalf of the consumer under FSC delegation (ADR-0034). A second consumer pilot runs on the same chain: the Installatie Register asks the LVG source about ownership (rule LVG0001). See DvTP query.
  • EUDI issuance (PuB-EAA route). A citizen discloses a PID from the EUDI wallet and gets an attestation from a government source. The bronhouder is the PuB-EAA provider. GBO operates the technical issuance facility (ADR-0028). The demo proves this route, but the PSA treats wallet support (P-06) as a hook outside version 1. See EUDI issuance.
  • ASI verification (eIDAS Article 45e). A QTSP verifies or retrieves attributes at the Authentic Source Interface, as specified in ETSI TS 119 478 clause 6.1. The QTSP is an OAuth client and does not take part in FSC. The ASI provider calls the source over FSC (ADR-0037). The route is demo grade: it uses a stub register, development certificates, and a DigiD mock. See ASI verification.

Three routes exist at design level only (design-level scenarios):

  • Gov-to-Gov: exchange between government parties on a legal basis. The legal-basis regime needs its own positive evidence. No rule set exists for this regime.
  • SDG-OOTS: cross-border evidence exchange through an AS4 bridge (ADR-0020).
  • Relying-party presentation: the citizen presents a wallet attestation to a relying party. This route has no GBO runtime.

For the interaction patterns (interactiepatronen) behind these routes, see the GO.

Quality goals

The technical design has five main quality goals, in order of priority. Quality requirements refines them into testable scenarios. Each goal has the following effect on the design:

Priority Quality goal What it means for the design
1 Data minimization The query of the consumer is the authorization object. The PDP decides on each requested field. It denies a field that no rule of the active regime covers (REQ-17, REQ-48). See P-02.
2 Privacy (BSN-free) In DvTP, the consumer gets no BSN and no other citizen identifier. The query names the subject with a placeholder. As a result, the PDP input and the decision logs hold no identity (REQ-20, REQ-79). EUDI and ASI are an exception: the plain BSN is in the PDP input and in both decision logs (REQ-60 not met). ADR-0043 (proposed) records the fix. See P-04.
3 Verifiable authorization A policy engine decides every data request. Application code does not make this decision. Each decision is allow or deny with a reason code. The consumer and the decision record get a coarse code. The operator gets the rule code per field (REQ-06, ADR-0036). See S05.
4 Traceability One W3C trace ID links the processing records of all controllers. Next to it, the records hold the FSC transaction ID, which links the transport records (REQ-55, ADR-0035). In demo v0.9.0, the link to the decision record behind the FSC Inway is missing (risk R23). See P-12.
5 Bronhouder autonomy Sources own their schema, their service description, their decryption keys, and their policy. PAP and PDP are at the bronhouder (ADR-0021). GBO keeps no copy of source data (REQ-11). See P-10.

Stakeholders

For the parties involved and the impact of GBO on them, see GO chapter 6. The TO has three primary audiences:

  • Engineers who build or integrate GBO components.
  • Bronhouder teams that connect a source.
  • Reviewers who check that the implementation stays within the PSA frameworks.

Document chain

The TO is level 3 in a chain of five documents:

Level Document Role
0 GBO site Entry point and context
1 Globaal Ontwerp System-level solution shape and interaction patterns
2 Projectstartarchitectuur Normative principles, frameworks, capabilities, and open decisions
3 Technisch Ontwerp (this document) Technical design of components and interfaces, with requirements and traceability
4 gbo-demo at v0.9.0 Reference implementation, ground truth for the behavior of GBO

Traceability