OOTS channel¶
In the OOTS channel, a public authority in another EU member state gets evidence from a Dutch source. The authority needs the evidence for a procedure under the Single Digital Gateway Regulation. The Basisinrichting OOTS handles the European transport and the interaction with the citizen. GBO adds an OOTS adapter in front of GBO Basis, so the bronhouder sees a normal FSC request. This is interaction pattern B of the Globaal Ontwerp. The channel is design only: it is not built in demo v0.9.0.
Overview › OOTS channel
Inside the channel¶
Figure 1: The OOTS channel. Dashed: design only (not built in demo v0.9.0). Grey: parties outside GBO.
The channel has these parts:
| Part | Role | Zoom in |
|---|---|---|
| Basisinrichting OOTS | Delivered by RINIS for the Ministry of the Interior (BZK) and the Ministry of Economic Affairs (EZK). Its part OOTS-V receives evidence requests and has the citizen authenticate again. It checks for a mix-up of identities, fetches the data, and shows them to the citizen before it sends them. Not a GBO component | GO pattern B |
| Protocol adapter | Translates the OOTS request into a GraphQL query over FSC and passes it on. It decides nothing about source data (REQ-44) | ADR-0020 |
| Semantic mapping | Maps the source format to the SDG Evidence Data Model, if the bronhouder configures a mapping. Optional for the bronhouder | ADR-0024 |
| GBO Basis | Decides at the source, field by field, and only then asks the source. The same chain as for every other channel | GBO Basis |
One evidence request¶
The Globaal Ontwerp describes the request in this order. The OOTS process steps stay with the Basisinrichting OOTS:
Figure 2: One OOTS evidence request, after GO pattern B. The runtime page Design-level scenarios has every hop.
OOTS-V sends the data only after the citizen agrees. The member states use eDelivery, AS4, ebMS and RegRep. OOTS-EDM specifies the request and response messages, and SDG-EDM describes the evidence. The bronhouder applies none of these standards itself.
Two designs for the edge¶
The Globaal Ontwerp and the design decision of this TO put the AS4 edge in different places:
Figure 3: Where the AS4 edge sits in the two designs.
In both designs, AS4 exists only at the edge, and the bronhouder sees a normal FSC request through the standard PEP and PDP chain. The difference is who builds the protocol translation. It is open whether GBO builds the adapter, or the OOTS-V operator extends its facility with the GBO interface (Q-79, PSA B-12).
What the adapter reuses from GBO Basis¶
The adapter is a protocol adapter in front of GBO Basis. It reuses every part of GBO Basis and adds no decision of its own:
| Part of GBO Basis | Use for OOTS | State |
|---|---|---|
| FSC connection and admission | The adapter calls the source as an FSC consumer, with a contract after admission (REQ-46) | Design |
| PDP and policy | The PDP of the source decides on every field. OOTS needs a regime, evidence and a rule of its own | Not designed |
| Source gateway | Without a consent proof, the gateway passes the query on unchanged | Built for other channels |
| Source configuration | The Globaal Ontwerp takes the mapping configuration from the bronhouder. The source document has no OOTS capability | Not designed |
| Records | ADL, LDV and the FSC txlog record the request like any other request | Built for other channels |
A channel adapter that GBO delivers does only protocol translation (REQ-44). It does not decide which data a party gets. It does not fetch decision information such as consent or admission. It carries no knowledge of a source in code. It uses the source access that the source offers for all interaction patterns, and never an interface (koppelvlak) for one channel.
The mapping depends on a canonical model per source. The proposed decision makes the GraphQL schema of the source profile that canonical model (ADR-0024, proposed). GBO then derives the OOTS-EDM evidence-type mappings from it. No central canonical model exists. Bronhouders and domains own their models (Q-11).
What demo v0.9.0 does¶
The demo does not touch OOTS. It has no adapter, no access point and no rule for OOTS. The following figure shows what happens if a peer sends an OOTS-like request today:
Figure 4: An OOTS request in demo v0.9.0 ends in a deny.
The request carries no consent proof, so it enters the PID regime. The PID rules admit only named callers, and an OOTS adapter is not one of them. The regime follows from the evidence in the request (REQ-74). Without evidence of its own, an OOTS request cannot get an allow. Risk R2 tracks the missing bridge.
Compared with the Globaal Ontwerp¶
The TO design follows pattern B in the main line. It differs in the edge, and the demo has no part of it:
| Topic | Globaal Ontwerp | TO design | Demo v0.9.0 |
|---|---|---|---|
| AS4 access point | In the Basisinrichting OOTS | Domibus at the GBO edge (ADR-0020) | None |
| Protocol translation to GraphQL | A translator in the Basisinrichting OOTS. OOTS-V must also support GraphQL | The FSC translator of the GBO adapter | None |
| Semantic mapping | An optional GBO facility, configured by the bronhouder | An OOTS-EDM adapter, based on the canonical model per source (ADR-0024) | None |
| Basis for the request | Policy checks a basis other than consent | A legal-basis path in the Gov-to-Gov style, needed and not built | No rule: the PDP denies |
Open points¶
The main open points in the OOTS channel are these:
- Who builds the adapter, and where the boundary between OOTS-V and the mapping function is (Q-79).
- The regime and the evidence for an OOTS request. A request without evidence of its own enters the PID regime (F-70).
- Whether the service description of the source must refer to a managed schema and concept framework, as PSA S10 asks (Q-11).
- The mapping to SDG-EDM needs traceable versions, as REQ-124 asks for issuance. The requirements register has no OOTS requirement (Q-79).