Ga naar inhoud

Constraints

Four sources set the constraints for this design: the PSA, the law, the GDI standards, and the functional requirements for DvTP. Each constraint links to its normative text, and the TO does not restate that text. If a design element conflicts with a constraint, one of these records the conflict:

Architecture principles (PSA)

The 16 architecture principles of the PSA bind this design. The PSA page has no anchor per principle. For this reason, each link opens the principles page. The following principles constrain the technical design most directly:

ID Principle Bearing on the TO
P-01 Legal basis before exchange Before data flows, the PDP judges every request under a regime. The evidence in the request selects the regime (ADR-0031).
P-02 Minimal data processing The PDP decides on each field of the GraphQL query (REQ-17).
P-04 BSN-free for private consumers In DvTP, the consumer holds no citizen identifier. After the allow decision, the source decrypts its own value (ADR-0033). See Pseudonymization.
P-06 Support for the EUDI wallet The PSA treats this principle as a hook outside version 1. The demo still proves EUDI issuance and ASI verification.
P-07 Trust through recognized admission and trust anchors (until September 2026: "trust framework based on PKI") Every FSC connection uses mTLS with PKI certificates. Admission comes from a register (REQ-61). The legal identity comes from the certificate (REQ-67). See Identity and trust.
P-09 Open standards and vendor independence The design uses FSC, AuthZEN, OpenID4VCI and OpenID4VP, GraphQL, OPA, LDV, W3C Trace Context, and OAuth 2.0.
P-10 Data sovereignty: the bronhouder keeps control Sources own their schema, service description, decryption keys, and policy. PAP and PDP are at the bronhouder (ADR-0021).
P-12 Logging and non-repudiation The design has three authoritative records, one per Logius standard. The ADL holds the authorization decisions (ADR-0036). The LDV logbook of each controller holds the processings (ADR-0026). FSC-Logging holds the transport. The W3C trace ID joins the three records, and the FSC transaction ID is recorded next to it (ADR-0035). See Logging, audit and traceability.
P-13 Transparency and access for the citizen The citizen views and revokes consents (REQ-38). Each controller can answer an access request from its LDV logbook.
P-14 Separation of generic and specific functions GBO has one generic chain. Route-specific adapters are at the edge (REQ-44).

For the full list (P-01 to P-16) and the status of each principle in the demo, see the matrix.

Design principles (PSA)

The 14 design principles govern how the GBO components are built. Each link opens the design principles page. The following design principles constrain the TO most directly:

ID Principle Bearing on the TO
D-01 Decentral where possible, central where necessary Each bronhouder has its own PDP and PAP. Each provider issues its own tokens. GBO has central components only where they are necessary: the consent facility (toestemmingsvoorziening) and the admission register.
D-03 Use national generic facilities (GDI) unless GBO reuses FSC, FTV, BSNk PP, DigiD, and PKIoverheid and does not rebuild them. The demo mocks DigiD, BSNk, and MijnOverheid.
D-07 Open source unless All GBO components and the demo are open source (EUPL).
D-08 Comply or explain: mandatory open standards A deviation from a mandated standard is an explicit ADR or risk.
D-09 API-first All interfaces (koppelvlakken) are specified APIs. See Context and scope.
D-11 Least privilege Authorization is closed-world: without a rule, there is no access. Only the FSC Inway reaches the source gateway (REQ-81).
D-13 Standardize where possible, make exceptions explicit Exceptions to a standard are visible in the data and in the ADR log. An example is the file metadata transport (AV-08).

For the full list (D-01 to D-14), see the matrix.

Requirements

The requirements state testable demands on what GBO builds and on the interfaces between GBO and other parties. Each requirement names its source. The source is a passage in the GO, the PSA, or FR-DvTP, or a principle for which a demo finding showed the need. The arc42 sections explain how the design meets the requirements. The status of each requirement is one of these words: draft, ready for review, approved, covered, or withdrawn.

The requirements page also lists the guidelines for bronhouders (RL-01 to RL-05). A guideline is a recommendation for bronhouders. It puts no demand on GBO.

Connection conditions (candidates)

Some demands fall on the parties that connect to GBO, and GBO itself does not carry them. The TO collects these demands as candidate connection conditions (AV-01 to AV-15). They are input for the management organization, which sets the real connection conditions (PSA S04).

The candidates apply to three types of party:

Party Candidates
Consumer AV-01 trace context, AV-02 LDV, AV-03 consent facility and BSNk PP, AV-04 own FSC peer. AV-05 proof sent unchanged, AV-14 contact details for GDPR rights, AV-15 equivalent alternative.
Integrator AV-06 admitted separately, acts as processor
Bronhouder AV-07 to AV-13: service description, consent to a taken-over description, old decryption keys, LDV for relation attestations, and validity and revocation policy

BSNk preconditions

BSNk PP sets preconditions that the DvTP design must respect (BSNK-01 to BSNK-11). These preconditions are facts about an external facility. They are not requirements on GBO. Three of them shape the design most:

  • Transformation is possible only while the citizen is logged in (BSNK-04). As a result, the consent facility makes all values at consent time, and the proof freezes at consent (F-78).
  • Only a recognized party can activate and transform (BSNK-01). It is open whether the consent facility can be such a party (Q-26, Q-49).
  • The interfaces are SOAP with PKIoverheid (BSNK-11). The demo mock offers the same operations as JSON.

How the register finds a returning citizen is an open design choice. The working assumption is route D (ADR-0040, proposed).

Functional requirements DvTP (FR-DvTP v0.9)

FR-DvTP v0.9 contains the functional requirements FR-01 to FR-39 for the DvTP route. The document is not public. For this reason, the TO names a criterion without a link, for example "FR-34, criterion 1". The matrix gives the demo status per FR.

FR-DvTP v0.9 has known contradictions. If the text and a decision conflict, the requirements follow the decision. The known contradictions are:

  • FR-22 to FR-24 name the same consent statuses with different words. The rationale of FR-23 contradicts its criteria (F-97).
  • FR-39 puts policy at a central authority, and FR-26 puts it at a central authorization component. FR-25 ties the GDPR pointer to "revocation no longer possible". FR-35 describes a register content that the design does not use (F-98).

The PSA groups its principles by legal framework. The following frameworks constrain this design:

Constraint Source Bearing on the TO
AVG (GDPR) PSA architecture principles, framework 1 Data minimization, purpose limitation (doelbinding), and legal basis (grondslag). Each controller (Verantwoordelijke) logs its own processing (ADR-0026).
Digital Government Act (Wdo) and PKIoverheid PSA framework 3 Organization identity through PKI certificates and the OIN.
eIDAS2 and ARF PSA framework 4 EUDI wallet support. Article 45e: the Authentic Source Interface (ADR-0037).
eIDAS implementing regulations of 2026 (ASI) CIR (EU) 2025/1569 art. 9, CIR (EU) 2026/1735 Annex IV Art. 9 applies from August 19, 2026. From January 1, 2027, the verify interface follows ETSI TS 119 478 clause 6.1.1, clause 6.2.3, or both. From that date, every result is sealed. The authorization part stays a national choice (F-80).
eIDAS implementing regulations of 2026 (PuB-EAA) CIR (EU) 2026/1735 (ETSI TS 119 471), CIR (EU) 2026/1731 (ETSI TS 119 412-6, TS 119 472-3), CIR (EU) 2026/1730, and CIR (EU) 2025/848 PuB-EAA issuance falls under the same standard as QEAA issuance. The issuer needs designation and a registration with entitlement PUB_EAA_Provider. It also needs an access certificate, a registration certificate, and a qualified seal certificate with its own profile (F-81, Q-28).
BSN legislation (Wabb) PSA framework 6 Private parties must not process the BSN. This rule drives pseudonymization and the BSN exception for the QTSP (F-86).
Single Digital Gateway Regulation (EU 2018/1724) GO interaction patterns The OOTS connection over AS4 is an obligation under EU law, and GBO has no choice in it (ADR-0020).

Standards

The capabilities chapter of the PSA lists the agreements, standards, and facilities (voorzieningen) per capability, with their gaps. See capabilities S01 to S11. The design builds directly on the following standards:

  • Connectivity and authorization: OpenFSC, OpenFTV with OpenID AuthZEN 1.0 and the FTV GraphQL profile, OPA/Rego, GraphQL, and PKIoverheid.
  • Pseudonymization: BSNk PP.
  • EUDI issuance: OpenID4VCI, OpenID4VP, and SD-JWT VC.
  • ASI verification: ETSI TS 119 478, OAuth 2.0 with PKCE, DPoP (RFC 9449), and JWT access tokens (RFC 9068). ASI verification also uses dynamic client registration (RFC 7591), authorization server metadata (RFC 8414), resource indicators (RFC 8707), rich authorization requests (RFC 9396), and problem details (RFC 9457).
  • Logging and traceability: LDV 1.0.0 (Logboek Dataverwerkingen), ADL (Authorization Decision Log), FSC-Logging (draft), W3C Trace Context, and OpenTelemetry.

If the demo deviates from a standard that the PSA names, a risk entry records the deviation. For example, the demo uses Rego instead of ODRL as policy language (R16).

Traceability