Ga naar inhoud

ADR-0023: Organization identity from the certificate, and separate EUDI certificate roles

Context and problem statement

The first version of this ADR had one goal: a single "converged" trust and identity story. That story had three parts:

  • PKIoverheid as the basis for all certificates.
  • One common anchor for all organization identifiers.
  • The production BSNk PP.

GO and PSA dropped that goal. P-07 does not name PKI any more (Q-07). Two separate questions remain.

Question A is: who is this organization? The demo had three identity carriers side by side: the FSC Peer ID, a configured OIN, and the certificate. One field mixed two identities, and the runtime held CA private keys (F-60). Simulation Peer IDs are not OINs (0000009950HYPBV00000).

Question B is: which certificates does EUDI issuance need? The analysis first confused the PuB-EAA seal and the access CA with PKIoverheid (F-66). Since August 2026, PuB-EAA issuance falls under ETSI TS 119 471. That standard has its own registration and certificate profile (F-81).

The BSNk production part of the first version is not in this ADR. ADR-0005 covers pseudonymization. ADR-0040 covers citizen recognition and the BSNk participant.

Decision

Part A: organization identity (accepted)

The decision for organization identity has five parts:

  1. The legal identity of a bronhouder (OIN and organization name) comes from its verified certificate material. It does not come from configuration (REQ-67). The OIN is the 20-digit serialNumber. The name is exactly one O attribute.
  2. GBO refuses a configured OIN or name that differs from the certificate. GBO also refuses a certificate without a 20-digit OIN, or without exactly one organization name.
  3. The configuration holds the FSC Peer ID separately from the OIN (provider_peer_id). One peer can offer services of more than one bronhouder.
  4. The runtime gets leaf material and public CA certificates, never CA private keys. A separate privileged command does the provisioning.
  5. FSC participants use PKIoverheid certificates (ADR-0003).

Part B: EUDI certificate roles (proposed)

GBO issues attestations for a bronhouder. Each such bronhouder needs its own certificates, one per role. One certificate never fills two roles. The roles are as follows:

Role Purpose Issued by Trust anchor
Organization or system certificate mTLS for FSC, and organization identity (OIN, name) PKIoverheid PKIoverheid root
Access certificate Authenticates the issuer to the wallet (OpenID4VCI) An access CA (ETSI TS 119 411-8) The access CA that the member state notified
Registration certificate Proves the registration of the service, one per registered service (since Implementing Regulation (EU) 2026/1730) A provider of registration certificates that the member state appoints Published by the member state
Qualified certificate for electronic seal Seals the PuB-EAA. The profile is ETSI TS 119 412-6 clause 8. It names the authentic source and the legal basis (eIDAS art. 45f(1)(b)). The key is in a QSCD A QTSP Open: Q-30
Status-list certificate Signs the status list for revocation Open: Q-17 Open

PKIoverheid is not an EUDI access CA. It is also not the seal infrastructure for PuB-EAAs. An access CA issues access certificates only, and it never signs attestations. REQ-58 makes the certificate set per source fail-hard (ADR-0016).

Consequences

  • An attestation and a decision record name the bronhouder with an identity that an operator cannot fill in freely.
  • Consents are bound to the identity of the consumer. If that identity changes, the consents become unusable. The migration in PR #244 and PR #277 showed that the binding is real.
  • In the default demo onboarding, the demo publishes RvIG through the Belastingdienst peer with the Belastingdienst OIN. That is a demo shortcut, so it does not show one OIN per bronhouder. The certificate sets still differ per source.
  • The demo development CA stands in for all EUDI roles at once. Production separates the roles.
  • The choice of the party that operates the Dutch access CA depends on Dutch EUDI governance. That choice is outside the decision scope of GBO.

Open points

These points are open:

  • Can policy read the FSC Peer ID of a consumer as its OIN, or must policy take that link from the register (Q-68)?
  • On which trust list do PuB-EAA providers appear: a List of Trusted Entities (ETSI TS 119 602) or the trusted lists (ETSI TS 119 612)? The specifications contradict each other (Q-30).
  • Who holds the keys of the seal and status-list certificates: the bronhouder, or the central issuance facility (Q-17)?
  • How does the migration from the self-generated CAs of the demo work?

Traceability