X509Credential with UZI server certificates

PKI

Care overheidorganizations &authenticate with an X509Credential, created from their UZI server certificatescertificate.

TheThis Dutchpage governmentexplains has a Public Key Infrastructure (PKI) that is used to establish trust between parties. The PKI framework is currently in place and makes use of PKI Overheid Certificates issued byhow the rootcertificate CAsends of the Dutch government. In healthcare a specific instance of PKI overheid certificates are issued: the UZI certificates. These certificates are used to establish trust between partiesup in the healthcarecredential, sector.and Thewhat a use case's Discovery Service and policy definitions need to check.

For the X509Credential and did:x509 in general, see RFC023. For how to create one, see "Get an X509Credential from a UZI certificate" in Implementing a Nuts v2 Use Case.

Which CA to trust: the CA tree

UZI server certificates are issued by the UZI register,register which(CIBG), under the PKIoverheid hierarchy. The X509Credential's issuer is a trusteddid:x509 partyDID, thatwhich iscontains capablethe fingerprint (ca-fingerprint) of verifyingone CA in the identitycertificate's chain. A definition trusts a CA by listing its fingerprint.

Use the fingerprint of the holderUZI CA: the CA that issues the UZI server certificates. Not the root or intermediate CA above it: those also issue certificates through other providers (e.g. KPN, DigiCert), which don't contain a URA.

Production G1
Staat der Nederlanden Private Root CA - G1
└── Staat der Nederlanden Private Services CA - G1
    ├── UZI-register Private Server CA G1                ◄ ca-fingerprint
    │   └── UZI server certificate
    └── KPN, DigiCert, QuoVadis, ... (other providers, no URA)

Production G4 (from 12 November 2026)
Staat der Nederlanden - G4 Root Priv G-TLS - 2024
└── Staat der Nederlanden - G4 Intm Priv G-TLS SYS - 2024
    ├── UZI Server - G4 PKIo Priv G-TLS SYS - 2025       ◄ ca-fingerprint
    │   └── UZI server certificate
    └── KPN, DigiCert, Digidentity, ... (other providers, no URA)

Test G1
TEST Zorg CSP Private Root CA G1
└── TEST Zorg CSP Level 2 Private Services CA G1
    └── TEST UZI-register Private Server CA G1           ◄ ca-fingerprint
        └── UZI server certificate

Acceptance G4
ACCEPTATIE Zorg CSP - G4 Root Priv G-TLS - 2024
└── ACCEPTATIE Zorg CSP - G4 Intm Priv G-TLS SYS - 2024
    └── ACCEPTATIE UZI Server - G4 Priv G-TLS SYS - 2025 ◄ ca-fingerprint
        └── UZI server certificate

UZI CA Environment ca-fingerprint (SHA-256, base64url) UZI-register Private Server CA G1 Production vdhg746H4rLH67NN1unhdxo6PF3shQunCA4-KQTb2Jc UZI Server - G4 PKIo Priv G-TLS SYS - 2025 Production, from 12 November 2026 sDTL__yv54TtrvSf7601TtvHgj2NZSLT2m-Okf8oqkI TEST UZI-register Private Server CA G1 Test GwlhBZuEFlSHXSRUXQuTs3_YpQxAahColwJJj35US1A ACCEPTATIE UZI Server - G4 Priv G-TLS SYS - 2025 Test, acceptance svKzNxhS07V1dKkekWOZV0d6Ao7_qvjqXegWB32YjZE

CIBG starts issuing G4 certificates on 12 November 2026; G1 certificates stop working on 12 November 2028. Until then, definitions should trust both.

From certificate to credential

These certificate fields end up in the X509Credential:

Certificate field Credential field Contains subject.O credentialSubject.subject.O Name of the certificate.care Theorganization UZI registersigns the certificate with its own private key. The holder of the certificate can then use the public key of the UZI register to verify the signature of the certificate. This way the holder of the certificate can prove that the certificate is valid and that the information in the certificate is correct. The UZI certificates are issued to:

Individuals that work in healthcare, such as doctors, nurses, etc. They hold this certificate on a UZI card. Organisations that work in healthcare, such as hospitals, pharmacies, etc. They hold this certificate as server certificates.

UZI certificate structure for organisations

The UZI certificate is used to identify the holder of the certificate. The UZI certificate contains information about the holder of the certificate. This information is used to identify the holder of the certificate. The UZI certificate contains the following information (of intrest):

The subject.CN The full FQN. The subject.O the name of the holder of the certificate. The subject.serialNumber  The URI number The subject.C The subject country The subject.ST The subject state The subject.L credentialSubject.subject.L City san.otherName credentialSubject.san.otherName UZI number, URA and more, see below

The subjectURA locality (city)

The subject.CN the full FQN. Thein san.otherName a

san.otherName is one string containingwith seven parts, separated by -:

<OID CA>-<versie-nrversion>-<UZI-nrUZI number>-<pastypepass type>-<Abonnee-nrURA>-<rolrole>-<AGB-AGB code>
2.16.528.1.1007.99.2110-1-900025039-S-90000382-00.000-00000000
,

where:

• <Part Example Meaning

OID CA> is the OID of the CA that issued the certificate, 2.16.528.1.1007.99.2110 forThe CIBG.CIBG Version <versie-nr>1 isVersion theof versionthis format UZI number 900025039 Number of the certificate.certificate <UZI-nr> is the UZI number of the holder of the certificate,holder, same as subject.serialNumber. <pastype>is thePass type ofS the holder of the certificate, alwaysAlways S. (server) URA <Abonnee-nr>90000382 isThe thecare subscriberorganization's URA of("abonneenummer") the holderofRole the00.000 certificate. Always <rol>00.000 is theroleAGB ofcode the00000000 holderThe ofcare the certificate, always "0.00" <AGB-code> is theorganization's AGB code of the holder of the certificate.

Mapping UZI certificate to X509Credential

TheTo mapping of certificates to did:x509 depends on the UZI X.509 Certificate structure.

The ROOT G3

The did:x509 specification dictates that the fingerprint of the Root CA is part of the did:x509. For mapping an UZI certificate to an X509Credential the ROOT CA MUST match one of the certificates in the UZI ROOT CA register hierarchy. For G3 this is:

        ┌────────────────────────────────────┐        
        │ Staat der Nederlanden Root CA - G3 │        
        └────────────────┬───────────────────┘        
                         │                            
┌────────────────────────▼───────────────────────────┐
│ Staat der Nederlanden Organisatie Services CA - G3 │
└────────────────────────┬───────────────────────────┘
                         │                            
    ┌────────────────────▼───────────────────────┐    
    │ UZI-register Medewerker niet op naam CA G3 │    
    └────────────────────────────────────────────┘    

Field mapping of the UZI credential

The following fields are commonly used for mapping UZI certificates to X509Credentials

The subject.O the name of the holder of the certificate. Maps to subject.O in the X509Credential. The subject.L The subject locality (city) The san.otherName a string containing <OID CA>-<versie-nr>-<UZI-nr>-<pastype>-<Abonnee-nr>-<rol>-<AGB-code>, where:

<OID CA> is the OID of the CA that issued the certificate, 2.16.528.1.1007.99.2110 for CIBG. <versie-nr> is the version number of the certificate. <UZI-nr> is the UZI number of the holder of the certificate, same as subject.serialNumber. <pastype> is the type of the holder of the certificate, always S. <Abonnee-nr> is the subscriber URA of the holder of the certificate. <rol> is the role of the holder of the certificate, always "0.00" <AGB-code> is the AGB code of the holder of the certificate.

The use of UZI server certificate in the Nuts network or identifying organizations

The focus on trust in the NUTS network for organizations lies primarily onget the URA numberin identifieda asdefinition, use a pattern with a capture group on this field. The node then returns only the <Abonnee-nr>captured onpart, the UZI certificate. This number is used to identify the subject of the certificate within the Dutch healthcare ecosystem . The subject of the certificate can use the UZI certificatee.g. in combinationsearch with the private key to proof the ownership of the URA number. The diagram below shows how the UZI certificate can be used to transfer the trust from the UZI register acting as "authentieke bron" into the NUTS ecosystem using the did:x509 methodresults and thetoken X509Credential Verifiable Credential.introspection:

{
  ┌─────────┐"id": ┌──────────┐"organization_ura",
  │"path": Keypair["$.credentialSubject.san.otherName"],
  ┼───────┤"filter": did:x509{ │"type": └────┬────┘"string", └────┬─────┘"pattern": │"^[0-9.]+-\\d+-\\d+-S-(\\d+)-00\\.000-\\d+$" │}
│                 │                                              
┌───────────┐            ┌───────┴───────┐         │                                              
│  ROOT CA  │            │     UZI       │ ┌───────────────────┐            ┌────┐                
└─────┬─────┘            │  Certificate  │ │ X509Credential    ┼────────────► VP │                
      │                  └───────────────┘ └───────────────────┘            └─┬──┘                
      │                          │                 │  │    ┌────────────┐     │     ┌────────────┐
┌─────┴─────┐ 1.Request  ┌───────┴───────┐         │  │    │            │     │     │            │
│ Authentic ◄────────────┼   Holder of   ┼─────────┴──┼────►   Wallet   ┼─────┴─────►  Verifier  │
│ Source of ┌────────────►     Trust     │   3.Issue  │    │            │ 4.Present │            │
│   Trust   │  2.Issue   └───────────────┘            │    └──────┬─────┘           └────────────┘
└───────────┘                                         │           │                               
                                                      │           │                               
                                              ┌───────┴─┐    ┌────┴────┐                          
                                              │ did:web ├────┤ Keypair │                          
                                              └─────────┘    └─────────┘}

This diagram represents the process of establishing trust, based on the use of X.509 certificates, the X509Credential and did:x509 within a trust network. Below is a step-by-step explanation of the diagram:

Key Components

Root CA:

The starting point for trust. The Root Certificate Authority (CA) is a trusted source that issues and signs certificates to intermediate or end-user entities.

UZI Certificate:

A specific X.509 certificate issued by the Root CA (or its intermediaries) to establish trust for the holder (e.g., an organization or an individual).

Keypair:

Generated by the certificate holder, this is the private-public key pair required for signing and authentication processes.

did:x509:

A Decentralized Identifier (DID) based on an X.509 certificate. It links decentralized systems with the trust of traditional X.509 certificates.

X509Credential:

A Verifiable Credential (VC), such as a "X509Credential," which is issued by the certificate holder using its did:x509 identifier and signed with the corresponding keypair. This credential is stored in the holder's wallet.

Wallet:

A secure digital storage system for holding the X509Credential. It manages credentials and is used for presenting them to verifiers.

Verifier:

An entity that validates the presented credential and establishes the holder's identity based on its associated trust components (e.g., did:x509, certificate chain, etc.).

did:web:

Another Decentralized Identifier (DID) the holder may use to represent their identity and interact within the decentralized trust ecosystem.

Process Steps

Step 1: Keypair Generation and Request

The holder generates a keypair (private and public key) to represent their identity. They submit the public key as part of a Certificate Signing Request (CSR) to the Root CA (or intermediate CA). Within the CSR terminology, the holder is the subject of the CSR.

Step 2: Certificate Issuance

The Root CA (or its intermediate CA) verifies the request and issues an X.509 certificate (e.g., a UZI certificate) to the subject. This certificate includes information about the subject (e.g., subject name and organization) and is signed by the CA. This guarantees the authenticity of the certificate. Note that the holder and subject are the same concepts but are named differently between the different terminologies.

Step 3: X509Credential Issuance

The holder uses their X.509 certificate to create a X509Credential or Verifiable Credential. The process includes:

Using the certificate's did:x509 identifier as the credential's issuer. Signing this credential with the holder's private key (from the keypair). Storing the credential securely in the Wallet for future use.

Step 4: Credential Presentation

When the holder needs to prove their identity to a verifier (e.g., during authentication), they present the X509Credential from their wallet to the Verifier. This process includes:

The presentation of the digital credential as a Verifiable Presentation (VP). Signing the presentation with the holder's private key to ensure it hasn't been tampered with.

Step 5: Verification

The Verifier validates the credential and presentation. This includes:

Checking the integrity of the credential and presentation signature. Confirming the certificate chain back to the Root CA to ensure the issuer of the X.509 certificate is authentic and trusted. Validating the use case-specific attributes in the credential (e.g., fields like organization, UZI number, or other subject information). Ensuring the credential has not been revoked using methods like CRL.

Trust is Established:

If all checks pass, the Verifier trusts the credential presented by the holder. The credential's trustworthiness is derived from:

The Root CA that anchors trust. The validity of the X.509 certificate and the associated DID (did:x509). Alignment of attributes between the X509Credential and the certificate.