ADR-0005: BSNk PP polymorphic pseudonyms for private-sector access¶
- Status: accepted
- Date: 2026-08-24 (updated 2026-11-02: BSNk only at consent time)
- Satisfies: P-04, S03, PSA open decisions: choice of BSNk PP
- Deliberation: Reference architecture v0.6.2, decision 4 (archived and unpublished), BSNk preconditions, F-75, demo #364, PR #469, PR #477
- Implemented in: consent-portal-backend/bsnk (activate, transform, BSN authorization list), consent/portal.go (values per party), services/bsnk-mock (mock of the BSNk interface, also the sources' decryption component)
Context and problem statement¶
Private parties are not allowed to process the BSN. But DvTP lets them request data from government sources about a specific citizen. Plain encryption of the BSN still gives them a universal correlation key.
Decision¶
GBO uses the BSNk PP polymorphic pseudonym infrastructure and calls it only at consent time. The decision has these parts:
- The consent facility (toestemmingsvoorziening) activates the BSN of the citizen once, into a PI and a PP. These belong to the consent facility only (BSNK-03). ADR-0040 (proposed) describes how the consent facility recognizes the citizen later.
- At each consent, while the citizen is logged in
(BSNK-04), the consent facility asks BSNk to transform the PI and the PP. BSNk returns values
for each recipient OIN:
- an encrypted pseudonym (VP) for every source
- an encrypted identity (VI) only for a source on the BSN authorization list (BSNK-06)
- The consent facility splits the call into requests of four parties at most (BSNK-05).
- The values travel in the consent proof (ADR-0032). After the allow, each recipient decrypts its own value locally, with its own keys (ADR-0033).
- BSNk is not in the query path. The consumer gets no identifier.
Consequences¶
- The values of different parties cannot be linked. No party outside government can derive the BSN.
- The consent facility must be a recognized BSNk participant (BSNK-01, F-75, Q-26).
- At consent, the parties, the key versions, and the form of the proof become fixed for the whole validity period (F-78).
- Every recipient needs its keys in advance, as a step of admission (BSNK-09, #467).
- A pseudonym for the consumer itself is optional. The demo does not build it (#478, Q-01).
- The demo mock follows the BSNk interface, but uses JSON instead of SOAP (BSNK-11). The mock enforces the requester-only PI, the BSN authorization list, and the four-party limit. The mock does not encrypt, so anyone can read the values. The three demo sources share one OIN and one decryption component.
- For the identifier flow at each boundary, see Pseudonymization.