UZI certificates as a source of identity

Abstract

UZI

Thiscertificates proposalfrom describesCIBG acan method for issuingback Verifiable CredentialsCredentials. byThe leveragingcredential is signed with the existingUZI chainsprivate ofkey, trustand providedits byissuer X.509is certificates. For this it uses thea did:x509 did-method.

DID

Statusderived from the certificate. This reuses CIBG's identity checks instead of thissetting document

This document has the status draft.

Introduction

With the introduction of the Self Sovereign Identity approach and thechniques, high trust application can leverage the possibility of combining several identity claims. This allows for more flexible and fine grained authorization rules and thus data protection. These techniques however are quiteup new andissuers. weIt find ourselves inbreaks a tipical chicken-and-egg situation: personal or company wallets can be the solution for SSI authentication needs, but without available credentials, theseproblem: wallets have no realvalue value.without Issuerscredentials, areand reluctantissuers with issuing credentialswait until wallets are ain tried and proven technology. How can we overcome this catch-22?use.

DigitalCredential trust is not new. Theredefinitions are already a lot of parties who act as a QTSP and provide trust attributes in the formcredential ofcatalog X.509(normative). certificates. InFor the Netherlandsserver-certificate credential used in production, including examples, see X509Credential with UZI server certificates.

Principles

Reuse CIBG's checks. CIBG checks organizations (URA) and persons (UZI number, role) before it issues a certificate or card. A credential backed by that certificate needs no new issuer. The key holder vouches for the claim. Whoever holds the private key makes the claim: the care domainorganization this(or isits donevendor) for a server certificate, the person for a smartcard. Binding. Credentials are bound together by an identifier they share, such as the CIBGURA. whoBinding issuesworks UZIwithin certificatesone forVerifiable individualsPresentation, or across presentations that belong together, e.g. one from the vendor and systems.one

Thisfrom specificationthe introducescare organization. All credentials are issued to the care organization's did:web; a methodserver-certificate ofcredential bridgingbinds thisits URA to that did:web.

Trust the gap by issuing UZI VerifiableCA, Credentials based oncheck the did:x509pass method.type. WithCIBG this we leverange the existing trust in the certigicate issuing proces and translating this intohas a Verifiableseparate Credential.CA

Chainper ofpass trust

type

The(UZI-register goalZorgverlener ofCA, thisMedewerker methodop isnaam creatingCA, aMedewerker verifiableniet chainop ofnaam trustCA, fromServer the UZI Verifiable Credential back to the trusted UZI Certificate Authority.

Often a did identifies an person or organisation this is not limited to those. Everything can be identified by a did. With the did:x509 method, the certificate subject is the issuer of the credential. It can sign the credential using its private key.CA). A verifier cantrusts resolvethe CA that issues the pass type it accepts, and verifychecks the certificatepass by parsing the certificate chain, checking the validity and checking the values giventype in the did string. If this checks out, the verified knows that there exists a valid certificate, issued by a specified CA which contains certain values.

Example did:

did:x509:0:sha512:3oeULL9TgHNiKTamKoYdWnJXuxV_5ICu0sA8SGYUwerek-xY4Zgr5vaFuMwMPkAomtHOnHQRk5oVYpXcFgBLOg::san:otherName:2.16.528.1.1007.99.2110-1-88899801-S-88899901-00.000-11122201

The above did specifies that the certificate should be issued by a CA with the fingerprint 3oeULL9TgHNiKTamKoYdWnJXuxV_5ICu0sA8SGYUwerek-xY4Zgr5vaFuMwMPkAomtHOnHQRk5oVYpXcFgBLOg and the certificate should contain a field san:san.otherName.

with the value 2.16.528.1.1007.99.2110-1-88899801-S-88899901-00.000-11122201.

When resolving the credential, the complete chain should be provided. The resolve operation can be interpreted as follows: resolve a DID document for a x509 certificate where the issuer ca can be identified a fingerprint and contains certain fields with certain values.

UZI Server certificatestypes

The UZI production chain is described on the zorgcsp website. The UZI test chain is described here

Issuer

Server certificates are issued by the UZI-register Private Server CA G1 CA intermediate.

The sha256 fingerprint of these intermediate CA's can be generated by making a sha256sum of the DER encoded files. WARNING: don't trust the values on this page, they are for

Test: 1b0961059b841654875d24545d0b93b37fd8a50c406a10a89702498f7e544b50

Production: bdd860ef8e87e2b2c7ebb34dd6e9e1771a3a3c5dec850ba7080e3e2904dbd897

Claims

The goal is to create a credential to uniquely identify a care organisation. We want to use the following relevant fields from the certificate:

ClaimUZI type	pathPass type	oidKey held by

Proves Credential Status OrganisationServer namecertificate subject.OS Care organization, often managed by the vendor The care organization and its URA X509Credential; HealthcareProviderCredential (next version) Production; draft Zorgverlenerspas 2.5.4.10Z Care professional, on a smartcard A named care professional, with UZI number and role HealthcareProfessionalDelegationCredential, PatientEnrollmentCredential Draft, LSPxNuts pilot Medewerkerspas op naam N Named employee, on a smartcard A named employee of the care organization PatientEnrollmentCredential Draft, LSPxNuts pilot Medewerkerspas niet op naam M Employee, on a smartcard Only that the holder works for the care organization None: the catalog's credentials reject this pass type -

Pass type codes as defined by CIBG, see e.g. the UZI reader of the Ministry of VWS.

How the credentials fit together

The URA binds the credentials together. Example from LSPxNuts, all presented by the care organization:

Credential Signed with States HealthcareProviderCredential Server certificate (S) This URA belongs to this did:web CityHealthcareProfessionalDelegationCredential Zorgverlenerspas (subject.LZ) 2.5.4.7This professional delegates these actions to this URA IdentifiersPatientEnrollmentCredential Zorgverlenerspas (san.otherNameZ) or medewerkerspas op naam (N) 2.5.5.5This patient is enrolled at this URA

The identifiersverifier fieldchecks:

is

unfortunatelyeach acredential's bitissuing cumbersomeCA sinceand itpass containstype; athat concatenatedthe string of a lot of relevant identifiersdid:web in the followingHealthcareProviderCredential form:is

<OIDthe CA>presenter;

that all credentials name the same URA.

Issuance

UZI type How the credential is created Server certificate With the certificate's key file, no smartcard needed: with the (Go) go-didx509-toolkit or the Java library. Done by someone at the care organization or its vendor, or automated. Smartcard The card holder signs with card and PIN, on a workstation with a card reader. In LSPxNuts this runs through the ZORG-ID SDK; see lspxnuts-pilots.

Governance

Decision Who Where Which credential types exist, and which pass types and CAs they accept Credential catalog Credential catalog Which credentials a use case requires Use case owner Discovery Service and policy definitions Who holds the server certificate's private key Care organization, or vendor by agreement Contract between them Who signs a person-backed credential The card holder, personally -<version-nr>-<UZI-nr>-<pastype>-<Subscriber-nr>-<role>-<AGB-code>

Example

Who gets a certificate or card CIBG UZI register

Limits and dependencies

Server certificate key held by the vendor: ideally only the care organization holds the private key of aits san:otherName:server

2.16.528.1.1007.99.2110-1-900030787-S-90000380-00.000-11223344

certificate.

ResolvingIn practice the vendor often holds it, because the same certificate is used for TLS client authentication to other services. The vendor can then create the care organization's credential. This is why Nuts wants to move towards credentials that aren't backed by a DIDTLS document

certificate

The(see DIDOutlook).

documentCIBG canand bePKIoverheid: resolveda CA change affects every definition that trusts it, e.g. G1 to G4 for server certificates. Workstations: smartcards need a card reader and software on every workstation where people sign. URA in a combined string: credentials based on X.509 fields need a pattern to extract the DIDURA from san.otherName. The HealthcareProviderCredential contains the URA as a separate field. Personal data: person-backed credentials contain a name and UZI number.

Outlook

Credentials not backed by a certificateTLS chain.certificate:

trust Checkservice ifproviders (TSPs) could issue care organization credentials directly, so the CA-fingerprintorganization's ofidentity theno DIDlonger matchesdepends withon thea rootkey orthat oneis ofalso theused intermediatefor certificates.TLS. Validate the chain such as is common practice: validity, cryptography, hiarchy, revocation status etc. Check if the leaf certificate contains all policy keys and values from the DID Create the DID document with the id field set to the DID and a assertionMethod containing the correctly encoded public key from the leaf certificate.

Example DID document:

{
    "@context": [
        "https://www.w3.org/ns/did/v1",
        "https://w3id.org/security/suites/jws-2020/v1"
    ],
    "id": "did:x509:0:sha256:1b0961059b841654875d24545d0b93b37fd8a50c406a10a89702498f7e544b50::subject:O:De%20Regenboog:L:Hengelo::san:othername:2.16.528.1.1007.99.2110-1-900030787-S-90000380-00.000-11223344",
    "verificationMethod": [{
        "id": "did:x509:0:sha256:1b0961059b841654875d24545d0b93b37fd8a50c406a10a89702498f7e544b50::subject:O:De%20Regenboog:L:Hengelo::san:othername:2.16.528.1.1007.99.2110-1-900030787-S-90000380-00.000-11223344#0",
        "type": "JsonWebKey2020",
        "controller": "did:x509:0:sha256:1b0961059b841654875d24545d0b93b37fd8a50c406a10a89702498f7e544b50::subject:O:De%20Regenboog:L:Hengelo::san:othername:2.16.528.1.1007.99.2110-1-900030787-S-90000380-00.000-11223344",
        "publicKeyJwk": {
            // JSON Web Key
        }
    }]
}

}

Creating a Verifiable Credential

The credential can only contain fields which are also part of the issuer did. The names must match.

Example credential:

{
  "issuer": "did:x509:0:sha256:1b0961059b841654875d24545d0b93b37fd8a50c406a10a89702498f7e544b50::subject:O:De%20Regenboog:L:Hengelo::san:othername:2.16.528.1.1007.99.2110-1-900030787-S-90000380-00.000-11223344",
  "credentialSubject": {
    "subject": {
      "O": "De Regenboog"
      "L": "Hengelo",
    },
    "san": {
      "otherName": "2.16.528.1.1007.99.2110-1-900030787-S-90000380-00.000-11223344"
    }
  }
}

Credential format

In order forDezi: the credential tocatalog containalso has a DeziUserCredential, which identifies healthcare workers through Dezi. Whether Dezi will replace UZI cards for this is still open.

GIS-VN: the certificatecatalog chain,names wefuture needGIS-VN itintermediate toCAs beas intrust theanchors jwt_vcfor format.personal The header of the JWT must contain the x5c field with the complete chain.

Verifying a credential

Extract the certificate chain from the credential proofpasses. Resolve the issuer did document based on the certificate chain Resolve the public key from the DID document Check the credential signature Check the credential validity Check if the fields and values of the credentialSubject match the issuer did Check if the issuer fingerprint matches the list of trusted issuers