Design to demo matrix¶
This matrix lists the design elements of four sources:
- the Globaal Ontwerp (GO),
- the Projectstartarchitectuur (PSA),
- the functional requirements for DvTP (FR-DvTP v0.9),
- the EUDI regulation.
For each element, the matrix records if the GBO demo covers it, and gives the evidence. The findings and the open questions give the reverse direction, from demo to design.
Each row has a status, an evidence link, and a note on the state of the demo. The notes link to the requirements, findings, open questions, demo increments, and ADRs that explain the row. The port to the TO on November 2, 2026 brought the evidence and the notes up to demo v0.9.0. No status changed.
Coverage summary¶
The summary counts the rows on this page. It does not count the historical rows of the reference architecture.
| Group | ✓ | ◐ | ○ | In scope | Hook or out | Rows |
|---|---|---|---|---|---|---|
| P: architecture principles | 2 | 12 | 1 | 15 | 1 | 16 |
| D: design principles | 4 | 8 | 2 | 14 | 0 | 14 |
| F: generic functions | 1 | 4 | 3 | 8 | 0 | 8 |
| S: capabilities | 3 | 7 | 0 | 10 | 1 | 11 |
| PAT: interaction patterns | 1 | 1 | 0 | 2 | 1 | 3 |
| EUDI: EUDI wallet and regulation | 0 | 8 | 3 | 11 | 0 | 11 |
| B: open decisions | 0 | 12 | 2 | 14 | 5 | 19 |
| FR: FR-DvTP v0.9 | 8 | 22 | 7 | 37 | 2 | 39 |
| Total | 19 | 74 | 18 | 111 | 10 | 121 |
Of the 111 in-scope rows, 17% are covered, 67% are partial, and 16% are not covered.
Most partial rows can become covered only after a governance decision or with production infrastructure. Three examples of such rows are:
- the LDV schema and retention (Q-08),
- the link of organization identifiers in PSA S04,
- PKIoverheid certificates instead of the demo CA (the direction is answered in Q-07).
Three items of concrete demo work are open in demo v0.9.0:
- validate a policy set before activation (F-52),
- admission per service (#382),
- the BSN in the ASI token (#595).
Legend¶
The status column uses five symbols:
| Status | Meaning |
|---|---|
| ✓ | Covered: the feature works end to end in the demo, with evidence. |
| ◐ | Partial: some parts are covered, and the rest is open. |
| ○ | Not covered: in scope, but not built. |
| — | Out of scope or hook: deliberately not in v1. |
| ? | To be checked against the demo. In demo v0.9.0, no row has this status. |
The scope column uses five values:
| Scope | Meaning |
|---|---|
| Base | The shared foundation for all routes: PEP, PDP, PIP, connectivity, audit, and semantics. |
| DvTP | Specific to the consent route (data sharing with third parties). |
| EUDI | Specific to the EUDI wallet routes: issuance (PuB-EAA) and verification for QTSPs (ASI). |
| Hook | Not in v1, but the demo keeps an extension point open. |
| Out | Not relevant for the v1 demo. |
The evidence column follows three rules:
- A status is valid only with evidence. The evidence is a link to the demo at v0.9.0, a demo pull request or issue, or a requirement that carries the evidence.
- Some links pin an older demo commit. They are historical evidence for the state at the time of the check.
- FR-DvTP v0.9 is not public. The matrix names its criteria without a link.
Architecture principles (P-01 to P-16)¶
Source: PSA architecture principles. These principles are invariants: the demo must not break them.
| ID | Title | Scope | Status | Evidence | Notes |
|---|---|---|---|---|---|
| P-01 | Legal basis before exchange | Base | ◐ | REQ-68, REQ-14, REQ-19 | Before an allow, the PDP checks that the consent is valid, unexpired, and not revoked. A legal-basis path (government to government) is out of scope. |
| P-02 | Minimal data processing | Base | ◐ | REQ-08, REQ-17 | The PDP decides each field of the parsed query (SL-03a). Under a consent, the subject comes only from the proof (REQ-79). |
| P-03 | Privacy by design and by default | Base | ◐ | REQ-80, REQ-21, REQ-23, REQ-69, REQ-82 | The register holds no BSN. The proof carries an encrypted value per source, and the consumer gets no identifier (SL-51). In the demo, BSNk is a mock, and the pseudonym form is open (Q-01). |
| P-04 | BSN-free for private consumers | DvTP | ✓ | consent_token.go#L47 (no plain BSN in the proof), decryption.go#L76 (the source decrypts its own value) |
The consumer has no identifier at all: it sends a placeholder, and the source replaces it after the allow (REQ-79, REQ-80, SL-51). F-76 describes the effects on logging and recognition. |
| P-05 | Recognized authentication means at an adequate level of assurance | Base | ○ | DigiD mock in the consent portal (toestemmingsportaal) (DigiDAuth.tsx), ASI authorization server with DigiD mock and NL Wallet (client.go#L119) |
The demo has no real means at a set level of assurance. Real means are out of scope. Q-36 asks which level ETSI TS 119 461 requires for the ASI route, and if DigiD meets it. |
| P-06 | Support for the EUDI wallet | Hook | — | — | The principle row stays a hook. The wallet routes are in the EUDI rows. |
| P-07 | Trust through recognized admission and trust anchors | Base | ◐ | fsc-infra/pki, REQ-67 |
The demo runs real OpenFSC with mTLS and its own CA (SL-34a). The certificate carries the legal identity (SL-49, F-60). Open: PKIoverheid certificates instead of the demo CA (direction answered in Q-07). Also open: the issuing model, with one certificate set or a set per source (#225). |
| P-08 | Record once, use many times | Base | ◐ | REQ-11 | The source stays authoritative, and GBO components keep no copy. The demo does not show reuse explicitly. |
| P-09 | Open standards and vendor independence | Base | ◐ | docker-compose.yml |
GraphQL, OPA, AuthZEN, OpenFSC with mTLS, OTel, OpenID4VCI, and OpenID4VP are open standards. The GraphQL profile for FSC is a proposal and has no standard status (B-02). |
| P-10 | Data sovereignty: the bronhouder keeps control | Base | ◐ | source_metadata.go#L101 (validation of the source description), dvtp-onboarding-register, autosign.rego#L171 |
The source decides who connects (SL-45), what is available (REQ-64, F-57), and when (REQ-65). The PDP behind the source Inway checks each request (F-06 closed). In demo v0.9.0, REQ-64 is built for EUDI and the ASIP (#592). It is not built for DvTP. |
| P-11 | FAIR principles for data | Base | ◐ | REQ-64, AV-07 | Findable and accessible: each source publishes a versioned description at a fixed location. Not interoperable or reusable: the mapping is per source, with no canonical model (Q-11). |
| P-12 | Logging and non-repudiation | Base | ◐ | docker-compose.yml#L125 (ADL), adl.go, ldv-logboek |
The ADL is the audit source (REQ-71), with an LDV logbook per system (REQ-72) and one trace ID (REQ-55). Open: the BSN in both decision logs (REQ-60, F-54, #368), field detail only in the console log (F-72), and production guarantees (Q-08, F-07). |
| P-13 | Transparency and access for the citizen | DvTP | ✓ | REQ-38, REQ-39, REQ-40 | For each consent, the citizen sees who, what, purpose, and duration, and can revoke the consent (SL-06a, SL-06b). Missing: usage status (F-19) and processing per consent (Q-25). |
| P-14 | Separation of generic and specific functions | Base | ◐ | REQ-44, REQ-92 | Each capability is a service of its own, and the front ends call it directly (SL-11, SL-15). The EUDI adapter holds no use-case knowledge (SL-46). The generic chain also runs behind the ASIP (F-87). |
| P-15 | Decoupling for agility | Base | ◐ | gbo-pdp.yaml |
Policy changes reach the PDP as a bundle, without a new PDP image (SL-44, RL-01). Mostly covered. |
| P-16 | Transparent access for private parties | Base | ◐ | dvtp-onboarding-register, autosign.rego#L171 |
Admission is a registration, and each contract proposal gets an explicit decision with reasons (REQ-61, REQ-62, REQ-63). Missing: the grounds (FR-30), an objection procedure, and admission per service (F-56, #382). Q-22 gives the answer on grounds and granularity. |
Design principles (D-01 to D-14)¶
Source: PSA design principles.
| ID | Title | Scope | Status | Evidence | Notes |
|---|---|---|---|---|---|
| D-01 | Decentral where possible, central where necessary | Base | ◐ | fsc-infra/docker-compose.yml#L773 (one shared PDP) |
One shared PDP behind all Inways is a demo shortcut. A PDP per source is possible with bundles (SL-44). Q-02 is answered: federated, per bronhouder. |
| D-02 | Agreements before standards before facilities | Base | ○ | — | This is governance, and the demo cannot show it. |
| D-03 | Use national generic facilities (GDI) unless | Base | ○ | — | DigiD, BSNk and MijnOverheid are mocks. Real GDI facilities are out of scope. |
| D-04 | Robust, modular, and flexible design | Base | ◐ | services/ |
The services are modular. Some services run in memory or as a mock. |
| D-05 | Data at the source, no unnecessary copies | Base | ✓ | REQ-11 | GBO components fetch per request from the source and keep no copy. |
| D-06 | Component-based working | Base | ✓ | services/ |
The services are separate and reusable. |
| D-07 | Open source unless | Base | ✓ | docker-compose.yml |
All components are open source. |
| D-08 | Comply or explain: mandatory open standards | Base | ◐ | — | The demo uses GraphQL, JWT, OTel, and FSC with mTLS. The GraphQL profile for FSC is open (B-02). |
| D-09 | API-first | Base | ✓ | graphql-server, openftv-pdp |
All interaction goes through APIs. |
| D-10 | Information security and privacy by design | Base | ◐ | PR #242 (CA keys outside the runtime), PR #222, PR #220, REQ-69, REQ-66 | The demo has mTLS over FSC, CA keys outside the application runtime, no per-party values in the register, and source metadata that fails closed. Open: there is no penetration test or audit (D-12), and the demo uses its own CA instead of PKIoverheid (Q-07). |
| D-11 | Least privilege | Base | ◐ | REQ-48, REQ-81 | The demo limits the fields per scope and takes the subject from the proof. Every rule names its services (REQ-97), and only the Inway reaches the source gateway. F-08 is closed: no source requires a certificate-bound token. |
| D-12 | Demonstrable security: audit and penetration testing | Base | ◐ | policies/gbo (policy tests), etsi-ts-119478.yaml |
Policy unit tests and an ETSI conformance matrix with a check in CI. No penetration test or audit. |
| D-13 | Standardize where possible | Base | ◐ | dvt0001.rego#L65 |
The scope convention bd:ib:<year> is ad hoc. |
| D-14 | Interoperability: semantic and technical alignment | Base | ◐ | graphql-server |
The source schemas follow the gbo-semantiek v0.3 source profiles. There is no canonical semantic model. |
Generic functions (F1 to F8)¶
Source: PSA generic functions and section 4 of the GO.
| ID | Title | Scope | Status | Evidence | Notes |
|---|---|---|---|---|---|
| F1 | Identity and trust | Base | ◐ | fsc-infra, dvtp-onboarding-register |
Organizations connect as real FSC peers with mTLS, and a register admits them (REQ-61). Transport identity and legal identity are apart (REQ-67). The citizen login is a mock. The demo uses its own CA, and production uses PKIoverheid (Q-07). |
| F2 | Access and interaction | Base | ✓ | REQ-04, REQ-46 | The chain FSC Outway → Inway → PDP → source works end to end. |
| F3 | Data provision | Base | ◐ | REQ-11, REQ-97 | Three sources answer over FSC: BD, BRP, and LVG. Each DvTP consent and each request reaches only one source (FR-38). |
| F4 | Semantics and common language | Base | ○ | — | No canonical model. The mapping is per source. |
| F5 | Data quality and validation | Base | ○ | — | The demo has no validation layer. |
| F6 | Legal basis and policy | Base | ◐ | REQ-68, REQ-14, REQ-19 | Consent works as legal basis, and policy management runs (SL-44). The demo has no legal-basis path. |
| F7 | Orchestration and integration | Base | ○ | — | The demo has no orchestration or integration layer. An integrator can call under FSC delegation (REQ-106), but there is no FDS broker. |
| F8 | Management and continuity | Base | ◐ | openftv-manager-ui, openftv-manager/authz |
Policy management has roles and a management interface (RL-02, RL-03). Continuity is weak: one bad rule stops every decision (F-52, RL-05). |
Capabilities (S01 to S11)¶
Source: PSA capabilities.
| ID | Title | Scope | Status | Evidence | Notes |
|---|---|---|---|---|---|
| S01 | Consent registration | DvTP | ◐ | consent_token.go#L47, postgres_store.go |
The register issues the signed proof (REQ-68) and keeps the polymorphic values under its own reference (REQ-69). It signs the value per source and does not store it (REQ-80, F-78, REQ-82). The local stack runs in memory (SL-12). |
| S02 | Consent portal (citizen interaction) | DvTP | ✓ | REQ-38, REQ-39, REQ-40 | The portal has its own backend and front end on a government origin, a DigiD mock token, and an ownership check on revoke (SL-11, SL-06b). Not built: the acknowledgment that the citizen read the text (REQ-107), and the export (REQ-108). |
| S03 | Citizen identification and pseudonymization | Base | ✓ | bsnk.go#L65 (activate), bsnk.go#L106 (transform), decryption.go#L76 |
The portal backend activates and transforms at the consent. The source decrypts its own value after the allow (REQ-21, REQ-81). The BSNk mock follows the BSNk interface. |
| S04 | Organization authentication and trust framework | Base | ◐ | fsc-infra, autosign.rego#L171 |
A register admits organizations to the system, and the PDP decides on contracts (REQ-61, REQ-62). Transport and legal identity are apart (REQ-67, F-60). Open: PKIoverheid certificates in place of the demo CA (Q-07). |
| S05 | Authorization (PEP/PDP/PIP) | Base | ◐ | engine.rego#L173 (regime), consent.rego#L268 (status), ftvgraphql.go |
The regime follows from the evidence (REQ-74, F-70). The policy verifies the proof and asks for the status (REQ-68). The subject must be a placeholder (REQ-79, F-77), and every rule names its services (REQ-97). The contract decision has a policy tree of its own (REQ-62). |
| S06 | Policy management and distribution (PAP) | Base | ◐ | gbo-pdp.yaml, seed-openftv-manager.py |
The PAP runs at the source side and distributes versioned bundles (RL-01 to RL-04). These RL items are guidelines: management stays with each bronhouder (Q-21). Open: validation before activation (F-52, RL-05), push distribution (F-51), and the policy version in the decision record (REQ-59). |
| S07 | Data access (source access API) | Base | ✓ | REQ-17, REQ-97 | GraphQL source access works for three sources. PSA S07 asks for pre-registered selective queries. The DvTP path lets the consumer send free queries within a field allowlist (Q-14). |
| S08 | OOTS adapter | Hook | — | — | Not in v1 (ADR-0020). |
| S09 | Logging, audit and traceability | Base | ◐ | adl.go, ldv-logboek, request-flow.json |
The ADL is the audit source (REQ-71). Each system has an LDV logbook (REQ-72), and the trace comes from traceparent (REQ-55, F-67). Open: the BSN in the decision logs (REQ-60), and the record behind the Inway without a trace (#369). Also open: the read route to the consent log (Q-25, F-68), and the register of processing activities (Q-08). |
| S10 | Semantics and data catalogue | Base | ◐ | gbo-source-metadata-v1.schema.json, source_metadata.go#L101 |
The source owns its service description on /.well-known/gbo, and GBO validates and activates it (F-57, REQ-64). In demo v0.9.0, this is built for EUDI and the ASIP. DvTP scopes come from rule files on the GBO side (F-17). There is no DCAT-AP-NL reference and no central findability. F-74 covers the DvTP catalogue per FR-32. |
| S11 | Attestation issuance (PuB-EAA / QEAA) | EUDI | ◐ | eudi-issuance-server, eudi-adapter, eud0002.rego |
Issuance works for products of two sources (SL-43, REQ-57, REQ-58). Missing: a qualified seal and a trust list. F-80 and F-81 cover the regulation, F-82 covers change notification, and Q-30 covers the trust list. |
Interaction patterns¶
Source: PSA interaction patterns and section 3 of the GO.
| ID | Title | Scope | Status | Evidence | Notes |
|---|---|---|---|---|---|
| PAT-A | Citizen uses the EUDI wallet | EUDI | ◐ | REQ-45, REQ-64 | The route works end to end against a pre-production wallet, with products from offers that the sources publish (SL-46). Missing: a seal, trust lists, and an authenticated adapter callback (#133). For more information, see EUDI-3 to EUDI-5. |
| PAT-B | Cross-border SDG/OOTS | Hook | — | — | Not in v1 (ADR-0020). |
| PAT-C | Data request by a private service provider (dienstverlener) in DvTP | DvTP | ✓ | REQ-68, REQ-14, REQ-19 | Consent, query, allow or deny, and revoke work end to end, for the BD and LVG sources, and through an integrator (PR #464). |
EUDI wallet and regulation (EUDI-1 to EUDI-11)¶
The EUDI rows have five sources:
- the GO sections on attestation issuance and on the verification service for QTSPs,
- PSA S11,
- eIDAS article 45e,
- the implementing regulations (EU) 2025/1569 and 2026/1735,
- ETSI TS 119 478.
The EUDI-NN IDs belong to this matrix.
| ID | Title | Scope | Status | Evidence | Notes |
|---|---|---|---|---|---|
| EUDI-1 | PuB-EAA provider and OpenID4VCI issuance | EUDI | ◐ | REQ-58, REQ-64, REQ-77 | Issuance works against mock trust (ADR-0018). PuB-EAA issuance falls under ETSI TS 119 471 and needs designation (F-81, Q-28). |
| EUDI-2 | Authentic Source Interface (QTSP verification, art. 45e) | EUDI | ◐ | seal.go#L45, registration.go#L222 (re-check), asi0001.rego#L23, etsi-ts-119478.yaml, asi-route.md |
SL-28 is done. It built sealed verify and retrieve, its own authorization server, and the chain behind the ASIP over FSC. It also built discovery, a reference QTSP, and login with a DigiD mock and the NL Wallet. The GBO profile is in the ASI profile: REQ-83 to REQ-115. Open: the BSN in the token (#595, F-86), and an external QTSP (#594). The ASIP has no certification and seals with a development certificate. |
| EUDI-3 | PID presentation and signature verification | EUDI | ◐ | client.go#L119 (ASI route) |
ASI route: the nl-wallet verifier verifies the PID against a fixed list of issuers (REQ-102). Issuance route: the issuance server verifies the PID. The callback to the adapter has no authentication, so nothing binds the BSN to the verified disclosure (#133, REQ-45, F-70). |
| EUDI-4 | Qualified seal and signing infrastructure (eIDAS2, ARF) | EUDI | ○ | — | The demo has no qualified seal. The ASIP seals with a development certificate (REQ-83). For more information, see FR-27. |
| EUDI-5 | Trusted lists and trust anchors | EUDI | ○ | — | The demo uses mock trust. The list on which PuB-EAA issuers appear is open (Q-30). |
| EUDI-6 | Attestation schemas and serialization (SD-JWT VC, mdoc) | EUDI | ◐ | PR #224 (schemas published by the source, fixed per version) | Each source publishes its schemas, and GBO validates and activates them (REQ-64). An integrity reference binds the schema to the credential. Q-20 (closed) covers the claim shape for related-person data. |
| EUDI-7 | Self-service access basis (subject = resource owner) | EUDI | ◐ | engine.rego#L173, eud0001.rego |
The regime follows from the evidence (REQ-74). If a request carries no consent proof, it enters the PID regime. The PID regime has no positive evidence of its own (F-70, REQ-45). |
| EUDI-8 | Thin channel adapter / protocol translation | EUDI | ◐ | source_metadata.go#L272 (query plan from the source description) |
The adapter cannot hold use-case knowledge: query, parameters, mapping, and offers come from the validated source description (REQ-64, REQ-44). It projects with gbo-simple-v1. If a result is ambiguous, the adapter fails closed (ADR-0017). |
| EUDI-9 | Issuer role and liability (PuB-EAA or QTSP) | EUDI | ○ | — | This is governance (Q-17). The reference QTSP issues a test attestation after an ASI verification (SL-28, part 13 of epic #336). Role and liability stay a governance matter. |
| EUDI-10 | Shared authorization service for both routes | EUDI | ◐ | engine.rego#L173 |
One AuthZEN endpoint for DvTP, EUDI issuance and the ASI route. The regime follows from the evidence (REQ-74). Approval in the wallet is not a legal basis (F-83). |
| EUDI-11 | Related-person credential (subject of the claim is not the discloser) | EUDI | ◐ | eud0002.rego, brp-graphql-server |
A surviving partner discloses his PID and gets the death certificate of the partner (SL-43). The source fixes the relation, and the PDP limits the output fields. REQ-57 prefers the relation as enforceable filters in the schema (#425). For more information, see F-47. |
Open decisions (B-01 to B-19)¶
Source: the PSA decision register. The status shows how far the demo tries out or follows the preferred direction of the PSA. Governance and organization decisions that the demo cannot try out have the status "—".
| ID | Title | Scope | Status | Evidence | Notes |
|---|---|---|---|---|---|
| B-01 | Governance of GBO agreements | Base | — | — | PSA direction: FDS as the base, with GDI and domain governance. This is governance. For more information, see Q-16. |
| B-02 | API profile for source access | Base | ◐ | ftv-graphql-profile.md |
PSA direction: GraphQL, comply or explain. The demo uses GraphQL over FSC for all routes. The profile is a GBO proposal in the OpenFTV working group (#331). For more information, see Q-14. |
| B-03 | Service catalogue | Base | ◐ | REQ-64 | PSA direction: federated content, with a common profile for central findability. EUDI and ASI are federated. DvTP scopes are on the GBO side, without a ceiling per use case (#382, F-74). The demo has no central findability. |
| B-04 | PDP placement | Base | ◐ | fsc-infra/docker-compose.yml#L773 |
PSA direction: several variants under one PEP-PDP interface. Demo shortcut: one shared PDP. A PDP per source works with bundles (SL-44). For more information, see Q-02 and Q-10. |
| B-05 | Policy governance | Base | ◐ | RL-03 | PSA direction: content ownership apart from technical management. The PAP splits read, write and publish (SL-44). Management stays with each bronhouder (Q-21). |
| B-06 | Consent in DvTP | DvTP | ◐ | REQ-68 | PSA direction: a central or nationally coherent facility, anchored in law, with an equivalent alternative. The demo has a central register and portal. Missing: the alternative (AV-15). For more information, see Q-05 and Q-13. |
| B-07 | Pseudonymous identity | DvTP | ◐ | bsnk.go#L65, decryption.go#L76 |
The register holds no BSN (REQ-69). The demo follows the BSNk PP model on a mock (SL-51, REQ-80, BSNK-01 to BSNK-11, F-75). Open: recognition (Q-26), and a consumer pseudonym (Q-27, #478). |
| B-08 | Identity matching | EUDI | — | — | Not in v1: the PID carries the BSN, so no match is necessary (Q-18). |
| B-09 | Trust framework for private parties | Base | ◐ | dvtp-onboarding-register |
PSA direction: FDS functions plus a legal and organizational framework. Demo: an admission register and FSC peers with certificates (SL-45, SL-49). The connection conditions are candidates for the framework. Q-07 and Q-22 give the answered direction. The PSA decision B-09 is open. |
| B-10 | Logging and citizen access | Base | ◐ | REQ-55, REQ-71, REQ-72 | PSA direction: logs stay decentral, correlation is federated. Open: the read route from ADL to LDV (Q-25) and the access model for the citizen (F-65, F-68). |
| B-11 | Semantic governance | Base | ○ | — | The mapping is per source, without shared concepts (F4, S10). For more information, see Q-11. |
| B-12 | OOTS function boundaries | Hook | — | — | Not in v1 (PAT-B). |
| B-13 | PuB-EAA issuance model | EUDI | ◐ | REQ-58 | The demo has a central issuance facility with a certificate set per source. Key management and seal are open (Q-17, #225). The issuer is the bronhouder or a designated body (F-81, Q-28). |
| B-14 | ASI provider | EUDI | ◐ | see EUDI-2 | The ASIP mock and the authorization server are two roles, each with its own keys. Neither is certified. Each source has one data service (REQ-94, F-89), and each data service has a discovery record (REQ-99, F-91). The interface and the seal are law from January 1, 2027 (F-80). Q-37 covers the role of GBO. |
| B-15 | Start of attestation issuance | EUDI | ◐ | — | PSA direction: several standardized start routes. The demo has one route: a QR code from the developer portal. |
| B-16 | GBO translation layer | Base | ○ | — | Not in the demo: all sources use GraphQL. |
| B-17 | Management of reference components | Base | — | — | Organization decision. The demo cannot try it out. |
| B-18 | Report of errors or suspected inaccuracies | Base | — | — | Not in v1. The PSA does not describe it in detail. |
| B-19 | Representation and authority credentials | Base | ◐ | integrator.md |
First case: an integrator under FSC delegation. The decision uses the acting and the represented party (PR #464, F-73, REQ-106). Q-46 covers the integrator in the proof, and Q-73 covers citizen representation. |
FR-DvTP v0.9 (FR-01 to FR-39)¶
Source: the functional requirements for DvTP, v0.9. This version is a draft of July 6, 2026, and it is not public. FR-06 and FR-19 lapsed in v0.9. FR-DvTP is not in the document hierarchy of the GO. If they differ, the GO and the PSA lead.
| ID | Title | Scope | Status | Evidence | Notes |
|---|---|---|---|---|---|
| FR-01 | Citizen authentication with a recognized means | DvTP | ◐ | REQ-24 | The DigiD mock gives a token, and the backend takes the identity only from that token. Real DigiD and level of assurance are out of scope. |
| FR-02 | Configuration-driven delegation check | DvTP | ○ | — | The demo has no delegation check. FR-DvTP v0.9 lets a service allow or exclude delegation (REQ-118). For more information, see B-19. |
| FR-03 | Authentication of the private service provider with eHerkenning | DvTP | ○ | — | FR-03 is about the person who logs in for onboarding and management. The admission register has only a local operator. FR-33 and FR-34 cover system identity. |
| FR-04 | Access through a trusted government domain | DvTP | ✓ | MijnOverheidLayout.tsx |
The consent screens are inside a MijnOverheid shell on their own origin, apart from the service provider (SL-06a, SL-11). |
| FR-05 | Consent details shown to the citizen (scope) | DvTP | ◐ | PortaalConsent.tsx |
The portal shows who, purpose, source, valid until, and a choice per data set. Criterion 5 (the citizen adjusts the validity within bounds) is not built (#380). REQ-117 covers plain language. |
| FR-06 | Transparency about the integrator (lapsed) | DvTP | — | — | Lapsed in v0.9. The integrator role is in FR-18 and FR-37. |
| FR-07 | Understandable information (language level) | DvTP | ✓ | scopeGroups.ts |
All texts are at language level B1. The citizen sees no technical terms. |
| FR-08 | Acknowledgment of understanding (force to read) | DvTP | ○ | — | The demo asks for no acknowledgment. When the citizen chooses one data set, the button becomes active. REQ-107 is the requirement, and #598 tracks the build. Q-51 asks what must be provable. |
| FR-09 | Specific consent only | DvTP | ✓ | REQ-12 | Each consent is bound to a consumer, a service, and a data scope. |
| FR-10 | Atomicity per indivisible data set | DvTP | ◐ | REQ-10 | The citizen gives consent per data set, as v0.9 asks (Q-03). Missing: a fixed minimal mandatory set with a legal check (Q-45, #382). |
| FR-11 | Validity period (configurable) | DvTP | ◐ | consent.rego#L138 (valid_until must equal exp) |
The validity is enforced and signed in the proof (REQ-19, REQ-68). Reuse within the validity conforms to v0.9 (Q-04). Missing: a default per service, adjustment by the citizen (Q-13, #380), and the status "retrieved" (Q-42). |
| FR-12 | Initiation from the private environment | DvTP | ✓ | Start.tsx, buildPortalUrl.ts |
The mock service provider website redirects the citizen to the portal, with context (REQ-37). |
| FR-13 | Smooth transfer of context | DvTP | ✓ | buildPortalUrl.ts, useRedirectContext.ts |
The redirect carries the consumer OIN, the service ID, the purpose, the data sets, and the return address (REQ-37). What the citizen sees must come from the registration (REQ-111). |
| FR-14 | Automatic return | DvTP | ◐ | PortaalBevestiging.tsx, redirectValidation.ts#L26 |
The portal returns the citizen with the signed proof in the URL fragment, without BSN. Only the front end checks the return address, against fixed origins (#427, REQ-111). The cancel button (shown as "Annuleren") does not return the citizen (#599, Q-44). |
| FR-15 | Support for web and app | DvTP | ◐ | — | The demo supports web only. App switching is out of scope. |
| FR-16 | Reliable identification of the requesting party and its authority | DvTP | ◐ | REQ-68, REQ-74 | Identity (FSC peer with mTLS), admission (SL-45), and consent binding work. An integrator can act for a service provider (REQ-106). Missing: admission per service (#382). |
| FR-17 | Fetch data only within a valid consent | DvTP | ✓ | consent.rego#L268, consent_token.go |
The consumer sends a signed proof. The policy verifies it and checks the status online on every request (REQ-68, F-61). |
| FR-18 | Integrator as processor | DvTP | ◐ | service.go#L50 (acts_for) |
The integrator calls under FSC delegation with a registered mandate, and the consent binds the service provider (REQ-106, F-73). Not enforced: the processor agreement and the rule of no storage (AV-06). Q-46 covers the integrator in the proof. |
| FR-19 | Verification of received data (lapsed) | DvTP | — | — | Lapsed in v0.9. Transparency goes through FR-20 and FR-31. |
| FR-20 | Central overview of consents | DvTP | ◐ | MijnToestemmingenOverview.tsx |
The citizen has an overview under MijnOverheid with active and expired consents (REQ-40, REQ-69). Not built: the processing per consent from the LDV (Q-25, Q-27) and the export (REQ-108, Q-52). |
| FR-21 | Detail view per transaction | DvTP | ◐ | REQ-38 | Each consent has a detail page. There is no transaction view. |
| FR-22 | Status of the consent shown to the citizen | DvTP | ◐ | REQ-38 | The statuses active, expired, and revoked are visible. FR-DvTP v0.9 also asks for "retrieved", and the demo does not have it (F-19, F-97, Q-42). |
| FR-23 | Revocation of a valid consent | DvTP | ✓ | portal.go#L269, RevokeModal.tsx |
Revoke works, and the next request gets a deny (REQ-14). In demo v0.9.0, the backend also accepts a revoke of an expired or revoked consent (REQ-109, #600). |
| FR-24 | Revocation works forward: data already retrieved | DvTP | ✓ | consent.rego#L268 (status per request) |
Revocation works forward and is possible while the consent is valid. Same gap as FR-23 (REQ-109). |
| FR-25 | Reference to GDPR rights | DvTP | ○ | — | The user interface has no reference to these rights. REQ-120 and AV-14 give the requirement. |
| FR-26 | Verification of consent at the source | DvTP | ◐ | REQ-04, REQ-68 | Criteria 1 to 3 run at the source. The PDP behind the source Inway verifies the proof and checks the scope. A request without a valid consent gets a deny (F-06 closed). Open: the check does not use the service catalogue (#382). |
| FR-27 | Sealing of personal data | DvTP | ○ | — | The demo has no qualified seal. Q-75 covers one seal for each source response. |
| FR-28 | Connection through common source access | DvTP | ◐ | — | This is a meta requirement, and the chain exists. |
| FR-29 | Digital registration and onboarding | DvTP | ◐ | dvtp-onboarding-register |
The operator can admit, pause, widen and reconnect a service provider without a policy change (REQ-61). Missing: the applicant side (Q-74). Q-22 answers the grounds. |
| FR-30 | Validation of connection conditions | DvTP | ◐ | autosign.rego#L171 (reason codes) |
The demo validates at the contract proposal (REQ-62) and at source activation (REQ-65, F-58). Missing: the conditions themselves (connection conditions) and criterion 3 (status "trusted" visible to the citizen). |
| FR-31 | Compliance and auditing | DvTP | ◐ | ldv-logboek, adl.go |
Each system has an LDV logbook (PR #366), the ADL is the audit source (PR #373), and the admission register can pause a party. Open: a chain-wide index (F-68), audit guarantees (F-07), and suspension that ends contracts (REQ-110, Q-53). |
| FR-32 | Process for setting up data needs | DvTP | ◐ | dvt0001.rego |
Scopes are configurable. There is no legal ceiling per use case and no link to service providers (F-74, #382). |
| FR-33 | Acquisition and registration of a connection certificate | DvTP | ◐ | REQ-58, REQ-67, AV-04 | Certificate material is registered, validated, and decisive. Missing: connection certificates of consumers, and the model for issue, rotation, and revocation (F-60, Q-07, #225). |
| FR-34 | Identification of the requesting party during use | DvTP | ◐ | REQ-74 | The runtime identity comes from mTLS and the contract. There is no regime header and no default regime (SL-48). Open: criterion 1, because nothing proves that the browser start comes from the service provider (#427, REQ-111, Q-60). |
| FR-35 | BSN-free delivery to a private service provider | DvTP | ◐ | consent_token.go#L47 |
The register stores no BSN. The consumer gets only a placeholder and no identifier (SL-51). The values come from a BSNk mock. The demo does not use the real BSNk PP (Q-01, Q-26). |
| FR-36 | Voluntariness and an equivalent alternative | DvTP | ○ | — | The consent screen does not say that the route is voluntary and names no alternative (AV-15). |
| FR-37 | Onboarding of an integrator or software party | DvTP | ◐ | service.go#L50, autosign.rego#L171 |
The register lists the integrator with its mandates. If a delegated contract has no registration, it stays proposed (DELEGATION_NOT_REGISTERED) (REQ-106, AV-06). The integrator is not in the service catalogue, and there is no digital onboarding. |
| FR-38 | Multi-source scope of a consent | DvTP | ○ | main.go#L83 (one source per backend) |
The demo does not try out one consent with a rule per bronhouder. Each consumer backend calls one source (BD or LVG). For more information, see F-68 and Q-76. |
| FR-39 | Central policy management and distribution | DvTP | ◐ | gbo-pdp.yaml |
The demo has a PAP and bundles with split roles (SL-44). It has no signed bundles and no policy authority. Management stays with each bronhouder (Q-21). |
Reference architecture (historical)¶
Two earlier sources of this matrix were the GBO reference architecture v0.6.2 and the PSA open issues of April 2026 (VR-1 to VR-8). The reference architecture is archived and was never published. Its decisions and gaps became TO architecture decisions. The PSA decision register replaced the VR issues. The summary does not count these rows.
Each historical row gives its last status in the analysis and the TO decision that it was ported to:
| ID | Title | Last status | Ported to | Notes |
|---|---|---|---|---|
| CDD-1 | GraphQL over REST | ✓ | ADR-0001 | The PDP decides per field on the parsed query. Q-14 covers pre-registered queries. |
| CDD-2 | Access basis: consent (PIP) or legal basis (bundle) | ◐ | ADR-0006 → ADR-0032, ADR-0031 | The path follows from the evidence (REQ-74). A legal-basis path is out of scope. |
| CDD-3 | Consent model: multi-source, service catalogue, integrator | ◐ | ADR-0008 → ADR-0009, ADR-0034 | The data model is multi-source, but each request reaches one source. An integrator acts by mandate (REQ-106). |
| CDD-4 | BSNk PP for pseudonymization | ✓ | ADR-0005, ADR-0010 → ADR-0011 → ADR-0033 | The demo calls BSNk only at the consent, and the source decrypts (SL-51). BSNk is a mock. |
| CDD-5 | Five-factor authorization, federated PDP | ◐ | ADR-0004 | Organization identity: mTLS, no certificate-bound token. Organization permission: admission and contract. Access basis: consent. Scope: ✓. Constraint: the subject is a placeholder from the proof (REQ-79). Request validity: only presence checks. The demo has one shared PDP. |
| CDD-6 | FSC-primary connectivity | ◐ | ADR-0003 | All routes run over OpenFSC with mTLS. The sector-pip is removed (#378). |
| CDD-7 | AS4 bridge for SDG-OOTS | — | ADR-0020 | Not in v1. |
| RAGAP-1 | Authorization policy lifecycle | ◐ | ADR-0021 | The demo has bundles, versions, and retirement (SL-44). Open: validation before activation (F-52). |
| RAGAP-2 | Identity convergence and BSN pseudonymization | ◐ | ADR-0023 | The path has pseudonymization (REQ-80). The demo does not model convergence of sector pseudonyms. |
| RAGAP-3 | Semantic mapping | ○ | ADR-0024 | The demo has no canonical model. |
| RAGAP-4 | GraphQL standardization within FDS | ◐ | ADR-0025 | The GraphQL profile is a GBO proposal in the OpenFTV working group (#331). |
| RAGAP-5 | Traceability correlation | ✓ | ADR-0026, ADR-0035 | One trace ID per request (REQ-55). |
| RAGAP-6 | Bronhouder onboarding toolkit | — | ADR-0027 | Not in v1. Source metadata and activation cover a part of it (SL-46). |
| RAGAP-7 | PuB-EAA provider | — | ADR-0028 | The demo built issuance anyway (EUDI-1). |
| RAGAP-8 | Authentic Source Interface | — | ADR-0029 → ADR-0037 | Built in SL-28 (EUDI-2). |
| VR-1 | Identification and authentication of private parties | ◐ | B-09, B-19 | See the open decisions. |
| VR-2 | Authorization central or distributed | ◐ | B-04, B-05 | See the open decisions. |
| VR-3 | Citizen identification and the BSN | ◐ | B-07, B-08 | See the open decisions. |
| VR-4 | Trust framework | ◐ | B-09 | See the open decisions. |
| VR-5 | Consent facility SDG-OOTS | — | B-12 | Not in v1. |
| VR-6 | Qualified EAA | — | B-13, B-14, B-15 | See the open decisions. |
| VR-7 | Central components | ◐ | B-04, B-06, B-13, B-14, B-16 | Q-10 (answered) covers which functions must be central. |
| VR-8 | Transformation architecture | ◐ | B-16, B-12, B-11 | The source describes its mapping, and GBO validates it (REQ-64). There is no canonical model. |
Traceability¶
- Requirements: each row links its requirements.
- Findings: each row links its findings. For all findings, see Findings.
- Open questions: each row links its open questions. For all questions, see Open questions.
- Demo increments: each row links its increments. For all increments, see Demo increments.