Admission and connection requirements¶
These requirements cover who can connect to a source. The first part holds requirements on the admission register (toelatingsregister) and the contract decision. The second part holds candidate connection conditions for the parties that connect. For the design, see Admission of parties.
This page has the following parts:
Admission register and contracts¶
The admission requirements cover the step before a request. They answer three questions: can this party connect, to which bronhouder, and who decides that. The requirements are generic. They apply to every party that connects through FSC: in DvTP, EUDI issuance, and the ASI route. Authorization covers the authorization of one request.
Admission is a registration and is not a policy rule. An automatic "no" stays reversible (F-55). The contract proposal that the PDP judges is thin. It tells who connects, but it does not tell to what (F-56). The governance side (who runs the register, and which legal protection a refused party has) is in Q-22. The design decision is ADR 0015.
REQ-61: Admission comes from a register and not from decision policy¶
The admission of a participant MUST come from a participant register that the PDP consults as an information source. Admission covers whether a party is allowed to connect, to which bronhouder, and whether that admission is active. If a party is not actively admitted there to the bronhouder, it MUST NOT get a new contract. It MUST be possible to add, suspend, extend, or withdraw an admission without a change of decision policy and without a restart of the PDP. The reference policy MAY co-sign only for grants that the admission decision covers. These grants are a service connection, or a delegated service connection with a registered representation (REQ-106).
| Case | Outcome |
|---|---|
| Party actively admitted to this bronhouder | contract co-signed |
| Party not in the register | refused: PARTY_NOT_IN_REGISTRY |
| Party suspended | refused: PARTY_NOT_ACTIVE |
| Party admitted, but not to this bronhouder | refused: SOURCE_NOT_ALLOWED |
| Register gives no data | refused: ADMISSION_REGISTER_UNAVAILABLE |
| Proposal with another kind of grant, with both kinds at the same time, or without a grant | refused: GRANT_TYPE_NOT_ALLOWED. The proposal stays pending (code) |
- Status: ready for review
Source, evidence and notes
- Source: design:
- PSA S04 (participation needs a prior admission decision, "deelname vereist een voorafgaande toelatingsbeslissing", and the facility is a participant register, "deelnemersregister").
- PSA S05 (the PDP consults the participant status, among other sources).
- FR-30 criteria 1 and 2, and FR-16 criterion 2.
- P-16.
- Addressee: GBO-delivered component: the admission register, its link to the PDP, and the reference policy for co-signing.
- Evidence: PR #239,
PR #228. Code and tests:
- The register and the PIP link.
- The refusals are in
autosign.rego#L166-L175, tested inautosign_test.rego#L126-L141. - PR #579: the policy
tells a missing register apart from an empty register in
autosign.rego#L50-L52, tested inautosign_test.rego#L86-L99.
- Related: REQ-62, REQ-106, REQ-110, F-55, Q-22, Q-68, ADR 0015.
- Notes:
- The register uses the FSC Peer ID as key. It is thin: name, active, admitted sources, and mandates.
- The register has no accounts. Whoever can reach the management interface locally is administrator.
- Production needs administrator authentication and a shielded or mTLS-protected pull endpoint. The form of the data does not change for that.
- The register deactivates a participant and does not delete it.
- The pull replaces entities but does not remove them. So a record that disappears leaves the old admission in place.
REQ-62: The admission decision on a contract is its own rule set, separate from request policy¶
A separate rule set MUST decide whether a contract proposal gets a co-signature. This rule set MUST stay apart from the policy that decides on single requests. The two MUST NOT share rules or deny reasons. They MAY read the same admission data from the register.
- Status: ready for review
Source, evidence and notes
- Source: design. PSA S04 (the setup handles technical identity and admission status apart from the role and authority in one interaction: "de inrichting behandelt technische identiteit en toelatingsstatus apart van de rol en bevoegdheid in een concrete interactie").
- Addressee: GBO-delivered component: the reference policy.
- Evidence: PR #228. The
rule set is its own package without an import, in
autosign.rego#L1-L10. The request policy reads the same register for the mandate inengine.rego#L253-L267(PR #464). - Related: REQ-61, REQ-106, F-52, F-55, F-56, ADR 0015.
- Notes:
- Design choice: the contract decision runs as an AuthZEN evaluation
through the same PDP as the requests
(
fsc-infra/docker-compose.yml#L701,#L773). So both decisions are in the same decision log. - The FSC Manager selects the policy on
doelbinding = "auto_sign_contract". A renamed package switches the policy off without a signal, and every contract stays pending (F-52). - The proposal names no service and no direction of delegation. So the decision is about who connects. It does not cover what the party connects to (F-56).
- Design choice: the contract decision runs as an AuthZEN evaluation
through the same PDP as the requests
(
REQ-63: An automated refusal of a contract proposal is recoverable¶
An automated negative decision on a contract proposal MUST leave the proposal pending. A final refusal MUST be a separate, deliberate action. After a correction of the admission data, the submitting party MUST be able to submit again without an action of the other party. The new submission MUST get a new assessment.
| Case | Outcome |
|---|---|
| Policy refuses the proposal | the proposal stays pending, no co-signature |
| Admission corrected, proposal submitted again | new assessment, co-signed if allowed |
- Status: draft
Source, evidence and notes
- Source: derived. The requirement serves P-16 and PSA S04. An automatic "no" that nobody can correct turns an error in the register into an exclusion.
- Addressee: interface agreement: the observable behavior of the admission process.
- Evidence: PR #228,
tested by hand. The co-signature follows only on allow, in
autosign.rego#L3-L5. No automated test. - Related: REQ-61, F-55, Q-22, ADR 0015.
- Notes: in the FSC Manager in use, this is product behavior. A refusal by the PDP leaves the proposal at proposed. A new submission is a new proposal with a new contract hash. So the requirement binds the configuration: do not configure an automatic refusal. Q-22 covers the procedural side (reasons, objection).
REQ-110: A suspended or departed consumer gets no more data, even with a valid consent¶
If a consumer is suspended or terminated, it MUST receive no more data within a set period, even with a valid consent. A suspension or termination MUST NOT change any consent. After a suspension ends, the existing consents MUST be usable again.
| Case | Outcome |
|---|---|
| Active consumer, valid consent | allowed |
| Consumer suspended | denied within the period, consent unchanged |
| Suspension ended | allowed again, without a new consent |
| Consumer terminated | denied |
| Consent expires during the suspension | expires as always |
- Status: draft
Source, evidence and notes
- Source: design. PSA S04 (a suspension or termination leads in time to a withdrawal of access: "schorsing of beëindiging leidt tijdig tot intrekking van de toegang"), made stricter: the consent does not change. Also FR-31 criterion 2 and FR-36 criterion 4.
- Addressee: interface agreement between source and management organization: who closes the access, and how fast. The consent function does not need to do anything.
- Evidence: not built. The demo issue follows after
Q-53. Partly built: a
suspended party gets no new contract
(
autosign.rego#L172). At a request, the policy checks only the status of an integrator (engine.rego#L263). So a suspended consumer with an existing contract can still call the source. - Related: REQ-61, REQ-106, REQ-123, Q-53.
- Notes:
- The requirement fixes the effect and leaves the mechanism open. A status check at every request meets it, and so does the withdrawal of the FSC contract. With the withdrawal, an issued access token stays valid until it expires. A new contract is then necessary after the suspension ends. The deny reason depends on the mechanism (Q-53).
- In the demo, a status change in the register reaches the PDP within
the pull interval of 5 s
(
dvtp-onboarding.yaml#L9). - A suspension or departure does not revoke the consents. The citizen sees them as active (shown as "Actief") while the party cannot use them.
- A consumer with a new OIN is a new party. Old consents become unusable and do not move to the new party.
- New consent requests of a suspended consumer belong to the check of the initiator (ICTU/GBO-demo#427).
REQ-123: Every change to an admission, mandate, or activation is traceable¶
A GBO-delivered component that records who is allowed to take part, or what is in use, MUST record every change of that data. The record MUST hold who made the change, when it took effect, what changed, and the value before and after. This covers the admission register (admissions and mandates), the activation of sources in issuance, and the client registration of the ASI authorization server. A change MUST be possible only for an authenticated, authorized administrator, or for a check that the component runs itself. The component MUST protect the record in the same way as the audit records of REQ-32.
| Case | Outcome |
|---|---|
| Administrator suspends a party | record: administrator, moment, active → suspended |
| Change without an authenticated, authorized administrator | refused, nothing changed |
| Client deactivated after a re-check (REQ-89) | record with the re-check as actor |
| Source activated or rolled back (REQ-65, REQ-66) | record with the version before and after |
- Status: draft
Source, evidence and notes
- Source: design:
- PSA S09 (each component records the events that are relevant to its responsibility, and measures protect log data against unauthorized change and deletion: "iedere component legt de gebeurtenissen vast die voor zijn verantwoordelijkheid relevant zijn", "maatregelen beschermen loggegevens tegen ongeautoriseerde wijziging en verwijdering").
- PSA S04 (a suspension or termination leads in time to a withdrawal of access: "schorsing of beëindiging leidt tijdig tot intrekking van de toegang").
- D-11 (management rights are limited, temporary, and provably granted: "beheerrechten zijn beperkt, tijdelijk en aantoonbaar toegekend").
- P-12.
- Addressee: GBO-delivered component: the admission register, the activation in the EUDI adapter, and the authorization server of the ASI.
- Evidence: not built. The register has no accounts (notes of REQ-61).
- Related: REQ-61, REQ-110, REQ-65, REQ-66, REQ-88, REQ-89, REQ-32, Q-53, Q-74.
- Notes:
- These records are data about organizations. They are no LDV processing of a data subject.
- How the administrator authenticates is a choice of the configuration. The requirement asks only that a change can be attributed to an authorized person or to a check.
- The component does not delete a record (REQ-61: deactivate, do not delete).
- Without this record, nobody can test REQ-110 ("within a set period"), because nobody knows when a suspension took effect.
Connection conditions (candidates)¶
The demo asks participants for certain behavior to make the chain work. The TO records these demands as candidate connection conditions (AV-NN). They cover every channel: GBO Basis, DvTP, and EUDI. None of them is an approved condition.
PSA S04 names connection conditions per participant group ("aansluitvoorwaarden per deelnemersgroep") as an agreement that is still open. FR-30 lets the operator of the DvTP facility check selection criteria and connection conditions. The framework falls under PSA open decision B-09.
Why the items are candidates and not requirements¶
A connection condition puts an obligation on a party that is not GBO. The management organization sets the condition. GBO does not. For that reason, each item is a candidate, written as SHOULD. Each candidate has its basis in the demo, the PSA, or the FR, as input for the decision. A candidate can refer to a requirement (REQ) that enforces the same behavior on the GBO side.
The connection conditions name three participant groups: private consumer, integrator, and bronhouder. Each channel puts its candidates on one of these groups:
| Channel | Obliged party | Candidates |
|---|---|---|
| All channels | bronhouder | AV-07 |
| DvTP | private consumer | AV-01, AV-02, AV-03, AV-04, AV-05, AV-14, AV-15 |
| DvTP | integrator | AV-06 |
| DvTP | bronhouder | AV-09 |
| EUDI | bronhouder | AV-08, AV-10, AV-11, AV-12, AV-13 |
AV-01: Consumer sends trace context and records the transaction ID¶
A private consumer SHOULD send W3C Trace Context with every call to a source, and SHOULD record the
Fsc-Transaction-Id.
- Status: candidate, normative minimum according to S09
Source, evidence and notes
AV-02: Consumer records its processing according to LDV¶
A private consumer SHOULD record its processing according to LDV, with
dpl.read.nextLogbookIdfor each call to a source.
- Status: candidate
Source, evidence and notes
- Obliged party: private consumer
- Channel: DvTP
- Source: the LDV read extension (the chain starts at the application that started the processing), F-68, and Q-24 option 3. The demo does this (PR #366).
- Related: REQ-72, REQ-75
- Notes: LDV does not bind private parties itself. The chain-wide starting point can also come from the records of the register (REQ-75).
AV-03: Consumer uses the consent facility and BSNk PP¶
A private consumer that takes part in DvTP SHOULD use the central consent function and BSNk PP.
- Status: candidate, already in the GO
Source, evidence and notes
- Obliged party: private consumer
- Channel: DvTP
- Source: the table of facilities in the GO (section 5). A participating private service provider (dienstverlener) must use the consent facility (toestemmingsvoorziening) and BSNk PP, and must meet the connection conditions: "Een private dienstverlener die deelneemt, moet de toestemmingsvoorziening en BSNk PP gebruiken en aan de aansluitvoorwaarden voldoen."
AV-04: Consumer has its own FSC peer with PKIoverheid certificate and OIN¶
A private consumer SHOULD connect with its own FSC peer, with a PKIoverheid certificate, and SHOULD use the OIN as its legal identity.
- Status: candidate
Source, evidence and notes
AV-05: Consumer sends the consent proof unchanged¶
A private consumer SHOULD send the consent proof unchanged, including the identifier of the citizen as it is in the proof.
- Status: candidate, depends on the outcome of #377
Source, evidence and notes
- Obliged party: private consumer
- Channel: DvTP
- Source: REQ-68 (the policy binds the query subject to the proof). With a real BSNk, a PI is randomized. So only the exact value binds (ICTU/GBO-demo#377, consequence 1).
- Related: REQ-68, REQ-80
- Notes: from demo increment SL-51 on, the proof carries an encrypted value for each source (REQ-80). The query names the subject only with a placeholder.
AV-06: Integrator is admitted separately and acts as processor¶
An integrator SHOULD be admitted separately, with its own organization identity means. It SHOULD have a processing agreement with the service provider, and SHOULD NOT store personal data persistently. It SHOULD have a registration for each service provider and use case.
- Status: candidate
Source, evidence and notes
AV-07: Bronhouder publishes a machine-readable description for each data service¶
A bronhouder SHOULD publish a machine-readable and versionable description at the fixed location. It SHOULD publish one for each data service and for every data flow in which it offers that service. The description contains the schema and its version, a reference to the concept framework, the error messages, and the availability properties. It also contains quality properties and provenance information. It also holds the mappings that the bronhouder fixes for that flow, and the URL of the LDV read API of its logbook. Where possible, the description SHOULD refer to managed objects (the service in the catalog, the schema, the mapping) instead of repeating them.
- Status: candidate
Source, evidence and notes
- Obliged party: bronhouder
- Channel: all channels
- Source:
- PSA S07 (published information describes schemas, versions, error messages, and availability properties: "gepubliceerde informatie beschrijft schema's, versies, foutmeldingen en beschikbaarheidskenmerken").
- PSA S10 (a reference to a managed schema and concept framework, a machine-readable and versionable form, quality properties and provenance information, and references to managed objects where possible: "verwijst naar een beheerd schema en begrippenkader", "machineleesbaar en versieerbaar", "kwaliteitskenmerken en herkomstinformatie", "verwijst waar mogelijk naar beheerde objecten").
- F-68.
- Related: REQ-64
- Notes: the candidate applies to every data flow: DvTP, EUDI issuance, ASI, and OOTS.
AV-08: Bronhouder without its own endpoint provably agrees with a taken-over description¶
A bronhouder that publishes no metadata endpoint of its own SHOULD provably agree with the service description that the operator keeps on its behalf.
- Status: candidate
Source, evidence and notes
AV-09: Bronhouder keeps decryption keys of an older version while proofs for that version are valid¶
A bronhouder SHOULD keep the keys with which it decrypts the values in a consent proof. It SHOULD keep a key version as long as valid proofs made with that key version exist.
- Status: candidate
Source, evidence and notes
AV-10: Bronhouder logs every living data subject of a relation attestation¶
An attestation can hold data about someone other than the requester. For such an attestation, a bronhouder SHOULD record in its processing log every living data subject whose data it supplies. A record of the requester alone is not enough.
- Status: candidate
Source, evidence and notes
AV-11: Bronhouder tests its view for relation attestations¶
A bronhouder can supply a relation (for example a marriage) through a view of its own. It SHOULD then prove with tests that this view returns only the relation of the identified citizen.
- Status: candidate
AV-12: Bronhouder as provider has a public validity and revocation policy¶
A bronhouder that has attestations issued SHOULD have a written and public policy for validity and revocation. It SHOULD publish the validity period for each attestation type in its configuration.
- Status: candidate
Source, evidence and notes
AV-13: Bronhouder gives the instruction to revoke an attestation¶
If the data in an issued attestation is no longer correct, a bronhouder SHOULD tell the issuance function that the attestation must be revoked.
- Status: candidate
Source, evidence and notes
AV-14: Consumer has registered contact details for GDPR rights¶
A private consumer SHOULD have contact details registered at its admission, where the citizen can exercise their GDPR rights. A consumer without those details SHOULD NOT be admitted.
- Status: candidate
Source, evidence and notes
AV-15: Consumer declares an equivalent alternative at admission¶
At its admission, a private consumer SHOULD declare provably that it offers an equivalent alternative next to the digital consent route. It SHOULD also declare that a refusal of consent gives the citizen no disadvantage. It SHOULD describe that alternative so that the consent screen can name it.
- Status: candidate
Source, evidence and notes
- Obliged party: private consumer
- Channel: DvTP
- Source:
- Related: REQ-117