Ga naar inhoud

Runtime view

The runtime view shows how the building blocks work together at runtime. Each page covers one scenario or a small group of scenarios. Each page has these parts:

  • a sequence diagram with numbered steps,
  • the data that each hop carries,
  • the error and failure paths, with links to the tests in gbo-demo v0.9.0,
  • the main observations, with links to requirements, findings, and open questions.

A built scenario is a scenario that gbo-demo v0.9.0 implements, with the error paths that its page lists. A design-level scenario has no implementation. A design-level page describes the intended sequence and names the open points.

Two planes

The scenarios fall into two planes:

  • Data plane. A request reads source data about a citizen. Every request takes the same route (ADR-0004, ADR-0002), in this order:

    1. the FSC Outway of the consumer (afnemer),
    2. the FSC Inway of the source, as PEP,
    3. the PDP of the source,
    4. the source gateway,
    5. the source API.

    The scenarios differ in the evidence that the request carries.

  • Management plane. No citizen data travels. The scenarios in this plane admit parties, take sources into use, and bring policy to the PDP. These scenarios come before the first request.

Scenarios

Scenario Page Route Actor Status Main ADRs
Citizen grants consent DvTP consent DvTP Citizen at a service provider (dienstverlener) built 0032, 0005, 0040
Consumer requests data under consent, directly or through an integrator DvTP query DvTP Consumer or integrator built 0031, 0032, 0033, 0034, 0013
Citizen views and revokes consents DvTP citizen access DvTP Citizen built 0032, 0040
Citizen receives an attestation (PuB-EAA route) EUDI issuance EUDI issuance Citizen with a wallet built 0018, 0016, 0017, 0028
QTSP verifies or retrieves attributes ASI verification ASI verification QTSP, citizen built 0037, 0038, 0039, 0041
Contract admission and source activation Admission and activation all (management plane) Consumer, FSC Manager of the provider, operator built 0015, 0034, 0016, 0023
Policy distribution Policy distribution all (management plane) Operator of the bronhouder built (bundle mode is opt-in) 0021, 0002
Government consumer requests data under a legal basis Gov-to-Gov Gov-to-Gov Government consumer design-level 0031, 0004
Cross-border evidence request SDG-OOTS SDG-OOTS Competent authority in another member state design-level 0020, 0031
Citizen presents an attestation to a relying party Relying-party presentation EUDI presentation Citizen, relying party design-level (no GBO runtime) 0018, 0028, 0023

Routes

A route is a path from a source to a party that uses the data. The PDP of the source judges each request under one regime. The evidence in the request selects the regime (ADR-0031, Authorization).

Three routes are built in gbo-demo v0.9.0:

  • DvTP. A private consumer reads source data with the consent of the citizen. The request carries a signed consent proof, so the PDP uses the consent regime. The consumer never gets a BSN (Consent).
  • EUDI issuance. The GBO issuance facility reads source data for a citizen who discloses a PID from the wallet. The request carries no consent proof, so the PDP uses the PID regime. The bronhouder is the PuB-EAA provider. GBO operates the technical facility (ADR-0028).
  • ASI verification. A QTSP verifies or retrieves attributes at the ASI provider (ASIP). The ASIP calls the source over FSC under the PID regime. The QTSP itself is not an FSC participant (F-87).

Three routes exist only at design level:

  • Gov-to-Gov. A government consumer reads source data under a legal basis. The regime needs its own positive evidence. No rule set for this regime exists.
  • SDG-OOTS. A competent authority in another member state requests evidence through the Once-Only Technical System. AS4 exists only at the edge. No implementation exists.
  • Relying-party presentation. The citizen presents a wallet attestation to a relying party. No GBO decision component and no source take part.

Data classification

The data-per-hop tables use the tags of the classification table in Consent: what travels where. That table gives each data item (for example the consent proof, VI, VP, subject_ref, and BSN) a meaning, a sensitivity, and the hops where it occurs. The runtime pages add only items that the table does not have, for example contract proposals, admission records, and policy bundles. Those items carry no citizen data.

The error tables give administrator codes. The consumer gets only a coarse code (REQ-06, Authorization).

Traceability