UZI Certificate Credential

Abstract

This proposal describes a method for issuing Verifiable Credentials by leveraging the existing chains of trust provided by X.509 certificates.

Status of this document

This document is in 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 quite new and we find ourselves in a tipical chicken-egg situation: personal or company wallets can be the solution for SSI authentication needs, but without available credentials, these wallets have no real value. Issuers howeverare won'treluctant startwith issuing credentials until wallets are a tried and proven technology. How can we bypassovercome this catch-22?

Digital trust is not new. There are already a lot of parties who actsact as a QTSP and provide trust attributes in the form of X.509 certificates. In the Netherlands for the care domain this is done by the CIBG who issues UZI certificates for individuals and systems.

This specification introduces a method of bridging this the gap by issuing UZI Verifiable Credentials based on the did:x509 method. With this we leverange the existing trust in the certigicate issuing proces and translating this into a Verifiable Credential.

Chain of trust

The goal of this method is creating a verifiable chain of trust from the UZI Verifiable Credential back to the trusted UZI certificateCertificate authority.Authority.

The

Often certificatea subjectdid identifies an person or organisation this is not limited to those. Everything can issuebe identified by a credentialdid. using the private key which corresponds to the UZI Certificate. It issues this credential to its usual did such as a did:web. The issuer of this credential is an identity ofWith the did:x509 method, the certificate subject is the issuer of the credential. It can sign the credential using its private key. A verifier can resolve and containsverify the relevantcertificate by parsing the certificate chain, checking the validity and checking the values given in the id.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:x509:0:sha256:abc:sha512:3oeULL9TgHNiKTamKoYdWnJXuxV_5ICu0sA8SGYUwerek-xY4Zgr5vaFuMwMPkAomtHOnHQRk5oVYpXcFgBLOg::san:otherName:2.5.5.5:value16.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: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.