Digitally verifiable certificates have emerged as a solution to help open up businesses and travel globally during the ongoing COVID-19 pandemic. There are four major COVID-19 certificate schemas popularly used in the world today:
ICAO-VDS
As the interoperability of these certificate schemas is critical to streamline the international travel process, DIVOC has added the ability to issue digital certificates in the EU-DCC and SmartHealthCard formats, in addition to the native DIVOC COVID-19 certificate format. This will enable citizens of a country, which is using a DIVOC certificate system, to export their native certificates in a format that is acceptable in the travel destination country.
Note: DIVOC will also add the capability to export the certificates in the ICAO-VDS format in 2022.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
This section covers the following:
Certificate generation process
Certify APIs
API structure
It involves the following steps:
Recording of a health event against a unique beneficiary, either in the source eHealth system (or in the DIVOC vaccination module, if used by a country, for their vaccination campaign). This results in the creation of the dataset for the specific event.
The event records all transactions associated with it (e.g. beneficiary demographics, vaccinator/facility details, certificate metadata, and timestamp, among others).
Marking the completion of the "event" in the system triggers a DIVOC certificate generation API (or “Certify” API), with the event data populated as per the defined API structure.
DIVOC’s certificate module receives the event data.
A digital certificate, encompassing both a QR code and a human readable document (e.g. PDF) is then issued, which holds the event data for the beneficiary, along with a unique certificate ID.
The QR code is signed with the issuing authority (e.g. national/provincial health agency) private key.
A summary of the health event is then used to populate the “human readable” part of the digital certificate.
The generated output has two parts:
It has a human-readable document (e.g. the PDF) and the machine-readable QR (the signed QR).
The digital certificate can be presented back to the source system in either of the ways (i.e. either just the signed QR as an image file, or the entire PDF output with the signed QR).
A sample DIVOC certificate output is further illustrated in the image below:
The DIVOC certificate generation service provides a “Certify” API for other eHealth systems, to generate digital certificates for specific events. Currently, DIVOC provides two certify APIs for a “COVID-19 vaccination certificate” and “COVID-19 test result certificate” respectively.
“Certify” for vaccination events
“Certify” for test result events
The API structure for the Certify API includes the following:
Recipient information: This section contains information about the beneficiary of the specific health event (e.g. COVID-19 vaccination or test event).
Vaccination event information: This includes details about the vaccination event such as name, batch, and vaccination date, as well as the vaccinator.
Issuer information: It contains information about the issuing authority.
Certificate information: It includes details such as certificate ID and expiry date, among others.
Meta: This part is used to populate related information about a previous event in the human-readable PDF twin of the digital certificate that can be used by the verifier for cross-reference. It contains additional information, which is not part of the current QR code (the QR code only contains information about the current event), such as the number of past doses taken. For example, If a QR code is generated for the final dose certificate, the QR code will contain all information about the final dose. If a country wants to show information about the previous dose, that can be populated from meta in the certificate PDF.
The purpose of this document is to provide information about the certificate generation service of DIVOC. It has the following sections:
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
DIVOC’s W3C-based digital certificate consists of three core components:
Credential metadata (schema version credential/certificate ID, etc).
Claim (vaccination event details).
Proof (issuer details, date of issue, time stamp, signature, etc).
The DIVOC digital certificate QR code includes the following data structure:
To illustrate the data structure of DIVOC certificate outputs, a sample certificate payload is outlined below:
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
All content on this page by is licensed under a .
Credential metadata
Certificate context
Sets the context, which establishes the special terms.
Certificate identifier
Specifies the identifier for the credential.
Credential type
Declares what data to expect in the credential.
2. Claim
Credential subject
Assertion about the subjects of the credentials.
Event block
When the credential was issued.
Issuer details
The entity that issued the credential.
3. Proof
Signature type
Digital proof that makes the credential tamper-evident. Cryptographic signature suite that was used to generate the signature.
Date of signature
When the signature was created.
Digital signature value
Identifier of the public key
That can verify the signature.
Using the DIVOC certificate generation service, a country can issue a QR code-based digitally verifiable certificate, which serves as proof of the health event, such as the COVID-19 vaccination. It involves an issuer (for example, a government department), a holder (for example, the citizen of a country), and a verifier (for example, security personnel at the airport).
All DIVOC issued digital certificates are based on the globally accepted W3C-Verifiable Credential Data Model 1.0.
DIVOC uses this data model for encoding the event data into the digital certificate’s QR code. DIVOC also uses a PKI mechanism to cryptographically sign all QR codes in the issued digital certificates.
Popular cryptographic signing algorithms (like RSA, EDDSA) are adopted in the DIVOC certificate QR signing process.
A. Holder: Someone who possesses one or more verifiable credentials as a proof of an event/identified use case and is responsible for generating presentations from them. In DIVOC’s vaccination use case, it is the vaccine recipient or beneficiary.
B. Issuer: Reefers to a legal entity that asserts claims about the holder or subject about a verifiable event or an identified use case by issuing a verifiable credential to a holder. Issuers may include central/state governments, authorities, corporations, etc. For instance, in the COVID 19 vaccine scenario, the issuer could be the issuing country or legal authorities.
C. Subject: An entity about which the verifiable claim is made by the issuer, for example, beneficiary or vaccine dose recipient.
D. Verifier: An entity who is responsible for verifying an issued credential. In the COVID-19 travel scenario, verifiers are the arrival country authorities that require a verifiable COVID-19 vaccine proof for allowing access to services and border entries.
E. Verifiable data registry: This refers to a role that a system may perform by mediating the creation and verification of identifiers, keys, and other relevant data, such as verifiable credential schemas, revocation registries, issuer public keys, and so on, which may be required to use verifiable credentials.
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
