Ga naar inhoud

ADR-0040: Citizen recognition and the BSNk participant: route D

Context and problem statement

The consent facility (toestemmingsvoorziening) needs two things from a citizen who logged in:

  1. A stable key for its own administration. With this key, the service shows and revokes the consents of the citizen without a BSN (REQ-20, REQ-40).
  2. A PI and a PP. With these, the service makes the values for the parties at a new consent (BSNK-03).

A stored PI or PP is not a stable key. BSNk gives other values at every activation, and the service cannot compute these values from a BSN. Every activation goes into the BSNk access register (Inzageregister) (BSNK-10). Only a recognized BSNk participant can activate and transform (BSNK-01).

Two points are open (Q-49):

  • Are the consent register (toestemmingsregister) and the consent portal (toestemmingsportaal) backend one system?
  • Which of them is the BSNk participant?

The working assumption puts the BSNk calls at the register. The demo puts them at the backend. The TO removed the earlier requirement on this point (REQ-22) until a decision on Q-49.

Proposed decision

The proposal is route D, under the working assumption that MijnOverheid passes the BSN:

  • The consent facility recognizes the citizen by an HMAC of the BSN, with a secret, versioned key:
    • The key is in an HSM or KMS.
    • The input has a fixed prefix and nine digits with leading zeros.
    • The result is at least 128 bits.
    • Every record keeps the key version.
  • At the first consent, the service activates once at BSNk. It stores PI and PP under that reference. At a later consent, the service only lets BSNk transform values.
  • To show and revoke consents, the service needs no BSNk call.

In the demo, the portal backend derives the reference and activates. The register stores PI and PP. This split fits only if both are one BSNk participant (Q-49).

Considered options

BSNk preconditions describes the routes in full. The design weighed four options:

  1. Route D: an own pseudonym from the BSN (proposed). BSNk is necessary only at the first activation. The route needs the BSN from MijnOverheid and a legal basis (grondslag) for the register.
  2. Route A: an own pseudonym through BSNk. The service activates and transforms at every login, also to show consents. Every login goes into the access register.
  3. Route B: a pseudonym through the login. MijnOverheid passes a VP for the register. The route depends on DigiD and MijnOverheid.
  4. Route C: a reference from MijnOverheid. MijnOverheid must have such a reference and must be allowed to pass it on.

Consequences

  • The register stores PI and PP. It stores no BSN and no value per party (REQ-69, REQ-23). This deviates on purpose from FR-35, criterion 1 (F-98).
  • The service processes the BSN briefly at every login, and that needs a legal basis. For every BSN, the service can compute whether consents exist, without a trace elsewhere.
  • The secret key is the whole protection. Without the key, anyone can compute every reference back from the small BSN space.
  • A new key gives every citizen a new reference. A migration of existing records is not built (Q-56).
  • The consent facility must become a recognized BSNk participant (F-75, Q-26).

These points are open:

  • Q-49: one system, and which participant.
  • Q-50: how the backend gets the verified identity.
  • Q-57: the protection of the stored PI and PP.
  • Q-58: does the register authenticate the backend?
  • Q-63: retention.

When Q-49 has a decision, this ADR becomes accepted, or another route replaces it.

Traceability