- Credential metadata
Note: DIVOC will also add the capability to export the certificates in the ICAO-VDS format in 2022. [](http://creativecommons.org/licenses/by/4.0/)*All content on this page by* [*eGov Foundation*](https://egov.org.in/) *is licensed under a* [*Creative Commons Attribution 4.0 International License*](http://creativecommons.org/licenses/by/4.0/)*.* # Distributing a DIVOC Certificate ## Purpose The purpose of this document is to outline the features of DIVOC's certificate distribution service. ## **Overview** * DIVOC offers several ways in which countries can distribute certificates at scale. * The platform is designed to facilitate multiple certificate distribution methods, which includes: \- Printed paper certificate with QR code. \- Digital certificate distribution - download and share QR code via URL link, email attachments, smartphone with user authentication. \- By integrating with a country's vaccination portal, health wallets, PHR, consumer, or travel applications. \- Countries can also distribute certificates for a health event via DIVOC’s Citizen Portal.  * After a health event such as vaccination, citizens can log in to the Citizen Portal with their registered mobile number, and they are given the option to securely download the certificate in PDF or other formats with added user authentication. * If using DIVOC’s citizen portal, the home screen of the Citizen Portal has a “Download” button in the “Download your Vaccination Certificate” section. Citizens can click the button and they will be asked to log in using their registered mobile number to download the certificate. To understand how it works, you can check our demo section on [**downloading certificates**](https://divoc.egov.org.in/divoc-demo/citizen-portal#2.-for-downloading-a-certificate). ## Certificate API The DIVOC certificate distribution service provides a get API so that certificates can be downloaded or printed for specific events. For fetching the right certificate, the get service requires a “pre-enrollment code,” and the latest certificate is fetched. ### **How does it work?** * The get certificate receives the preEnrollmentCode (beneficiary id) as input: {% hint style="info" %} GET {domain}/certificate/api/certificatePDF/{beneficaryId} {% endhint %} * Once it receives the input, it, 1. gets all certificates associated with preEnrollmentCode from the database. 2. gets the latest dose certificate by grouping the certificates by dose, and order\ them by their timestamps. 3. creates the QR code from signed certificate data. 4. using the above-generated QR code and certificate information, it creates a PDF. * Similarly, there are APIs in certificate-api service which can return the QR code as a png image, which follows the same step as above (till the third point): {% hint style="info" %} GET /certificate/api/certificateQRCode/{beneficaryId} {% endhint %} * We also have an API to check if a beneficiary has a certificate generated, which follows the same step as above (till the second point): {% hint style="info" %} HEAD {domain}/certificate/api/certificatePDF/{beneficaryId} {% endhint %} [](http://creativecommons.org/licenses/by/4.0/)*All content on this page by* [*eGov Foundation*](https://egov.org.in/) *is licensed under a* [*Creative Commons Attribution 4.0 International License*](http://creativecommons.org/licenses/by/4.0/)*.* # Updating a DIVOC Certificate ## Purpose The purpose of this document is to outline the features and workflow of DIVOC's “Update Certificate” service. ## **Overview** * DIVOC provides an “update certificate” feature to help beneficiaries make changes in a certificate if any information was captured incorrectly during the beneficiary registration or vaccination process. * For this purpose, DIVOC provides an “*Update Certificate API*,” for a source system (e.g. a vaccination platform) to update the vaccination as well as beneficiary details in digital certificates issued by DIVOC. * There are multiple ways of using this service. The issuing authority can enable a self-service portal, or set up a call centre, or the source system can capture the update requests directly, which can then call the Update API to facilitate the updates/corrections to the specific certificates. The key requirement here is that the “Update Certificate API” is called by the source system(s) to update an issued certificate. Using this API, the source system can update a beneficiary’s latest as well as previously issued digital certificates. ## **Update Certificate API** As outlined earlier, DIVOC’s “Update Certificate” API is used by source systems to perform updates to already-issued certificates. You can refer to the update API specification link [**here**](https://github.com/egovernments/DIVOC/blob/main/interfaces/vaccination-api.yaml#L722)**.** ## **Sample API Payload** ``` [ { "preEnrollmentCode": "987456126", "recipient": { "name": "John Doe", "dob": "1987-04-21", "nationality": "Dutch", "identity": "872550100V", "contact": [ "tel:1691742639" ] }, "vaccination": { "name": "Covishield", "batch": "41202025", "manufacturer": "astrazeneca", "date": "2021-10-17T13:10", "effectiveStart": "2021-10-25", "effectiveUntil": "2022-10-24", "dose": 1, "totalDoses": 2 }, "vaccinator": { "name": "Bartjan Verduijn" }, "facility": { "name": "MOH Gothatuwa" } } ] ``` ## **What can be updated/corrected?** 1. An issued certificate’s QR code contains the two categories of information: \- **Personal information**, for example: * Beneficiary name * Gender * Date of Birth \- **Event details**, for example: * Vaccine type/prophylaxis * Vaccine name/brand * Manufacturer Vaccine batch * Vaccination date * Facility ID/name * Country of issuance * Issuer * Dose number * Total dose count 2\. Any or all of the above fields can be corrected/updated by calling the Update Certificate API by a source system. 3\. The Update Certificate API requires beneficiary ID/enrollment code and dose number as an input to fetch the right certificate that needs to be updated. 4\. Once the certificate is fetched, the update API updates the information against the certificate ID as provided in the API payload input. 5\. Once the certificate is updated, a new certificate is issued with a new certificate ID and updated information. The older certificate gets revoked by an automated revocation workflow using DIVOC’s “Revoke API.” 6\. The revoked certificate is moved to the Certificate Revocation List (CRL). If the older revoked certificate is scanned by a verifier, the verification screen will show “certificate revoked.” 7\. For update scenarios, DIVOC can also enable configuring a custom message for beneficiaries trying to verify the older corrected and revoked certificate as: “certificate revoked, please download the updated certificate from the portal.” 8\. Updates/corrections can be made in the provisional and final certificate for any of the fields present in the QR code as per the issuing authority’s requirements and approved flow. 9\. It is strongly recommended that an issuing authority should allow information correction/updates only after verifying the required proofs uploaded by the beneficiary. [](http://creativecommons.org/licenses/by/4.0/)*All content on this page by* [*eGov Foundation*](https://egov.org.in/) *is licensed under a* [*Creative Commons Attribution 4.0 International License*](http://creativecommons.org/licenses/by/4.0/)*.* # Revoking a DIVOC Certificate ## Purpose This document refers to the revocation of a digital certificate issued to a person. DIVOC’s certificate revocation service will help stakeholders of a program to revoke digital certificates, according to the issuing authority’s predefined policy. For example, during a COVID-19 vaccination campaign, the vaccination certificate issued to a person, as digitised proof of the event, can get revoked due to multiple reasons like: * errors in the information encoded in the digital certificate. * wilful tampering of the digital certificate (QR or PDF output) by external entities who have gained unauthorized access to the certificate data contents. * or if a specific batch of vaccines is found to be faulty, among others. The purpose of this document is to provide an overview of the certificate revocation service offered by DIVOC. It describes the steps involved in the revocation process, as well as the maintenance of the revoked certificate list for verifiers. ## **What is DIVOC’s certificate revocation service?** ### **Revocation API** * DIVOC has enabled a “Revoke API” that can be used to revoke an issued certificate for manual revocation use cases. * The API uses a “beneficiary ID/pre-enrollment code” and either the “dose number(s)” or the “all doses” flag as input parameters to search and fetch the certificate(s) that need to be revoked from the certificate registry. * If the “dose number(s)” parameter is passed, it must be a sequential list of doses that includes the latest dose. * DIVOC stores the revoked certificate ID within a centrally-maintained “certificate revocation list (or CRL).” ### Revocation List * DIVOC maintains a certificate revocation list to store certificate IDs of the revoked certificates. The revocation list can be hosted by an issuing authority (either inside or outside its central certificate registry) or can be periodically downloaded as a file and stored by a verifier application. * When a revoked certificate’s QR code is scanned using the DIVOC’s online verification service, the service searches the CRL for the certificate ID to check if the certificate is a valid or revoked certificate. * If the certificate ID is found in the CRL of the scanned QR code, the verification screen displays the certificate as revoked.  * Each CRL has a serial number, time, and date on which the certificate was revoked. * It includes the date and time when the CRL was published, and when the next update to the CRL will be published. ## How does it work? * A revocation is triggered when the revocation API is called by the source system (for example, a vaccination platform), on specific transactions (for example, the correction or update of a certificate). * As input parameters from the source system, the revoke API receives beneficiary ID/enrollment code and dose number(s) or the all doses flag. * The relevant certificate is fetched and DIVOC performs a “soft delete” of the certificate (also referred to as the “revocation” process). * The revoked certificate’s "certificate ID" is then moved to the certificate revocation list. * Certificate IDs of all revoked certificates are maintained in the CRL within the certificate registry. The revoked certificate IDs can be indexed in chronological order against the respective unique certificate ID, along with its revocation date and time. * The certificate revocation list will be regularly updated to support the verification flow by approved domestic and international verifiers. * If the certificate was revoked, the same information will be displayed to the third-party verifier application in real-time. On scanning, the verifier application will display the result as an “Invalid certificate.” * DIVOC’s certificate revocation list can be configured to support both offline and online verifications flows. For instance, \- On scanning a revoked certificate, a third-party verifier application can call the APIs (i.e. fetch APIs provided by DIVOC to the country’s issuing authority) to fetch the certificate revocation list to validate the “revoked” status of the digital certificate. \- The certificate revocation list can be downloaded by the third-party verifier application (in their local system) on a periodic basis. [](http://creativecommons.org/licenses/by/4.0/)*All content on this page by* [*eGov Foundation*](https://egov.org.in/) *is licensed under a* [*Creative Commons Attribution 4.0 International License*](http://creativecommons.org/licenses/by/4.0/)*.* # Verifying a DIVOC Certificate The verification component of the DIVOC certificate service checks for two things: 1. An issued certificate is valid (that is, the document is currently ‘live’ and is not a revoked document). 2. The document is authentic (that is, the document has not been tampered with). ## **For verifying authorities** ### **Offline verification:** DIVOC supports offline verification of the QR code-based digital certificates to support verification of certificates in connectivity restricted regions and make it more user-friendly. The QR code can be verified by third-party authorised verifier applications to enable domestic and cross-border verification of DIVOC-issued certificates. Use the following steps to verify a DIVOC certificate: 1. Scan to detect the QR code. 2. The verification component uses the QR code reader libraries to read the contents of the QR code embedded in the certificate. 3. Once the QR code is detected by the camera, it reads the binary data encoded in the QR code. (the binary data will be in zipped format). 4. The decompressed Json in the QR code is authenticated using a signing method mentioned in the proof section of the QR code content 5. After unzipping it, you will get a certificate.json file (certificate.json will have the signed, json-ld formatted VaccineCertificate). 6. Json-ld signature will be verified against the public key that is issued by the issuing authority. 7. On successful verification, the revoked API is called to check if a certificate has been revoked or not. 8. Once the signature and revocation are verified, the success screen is shown with beneficiary and vaccine details. 9. Since it is offline verification, the verifier will need to download the CRL within the verifier application. The verification service will also go through the CRL and check for the certificate's revoked status. 10. Please note: In addition to supporting verification by third-party verifiers, DIVOC also provides a verification portal. The portal works on a web browser as well as on a mobile phone browser, and it can be also used by verifying authorities to verify DIVOC-certificates in an “offline” capacity. ### **Online verification:** * DIVOC provides a public portal that allows verifiers (including self-verification by beneficiaries) to verify certificates. * Certificates can be scanned and verified on the following URL: [**https://demo-divoc.egov.org.in/**](https://demo-divoc.egov.org.in/) and clicking on “Verify.”  Next, * Scan the QR code. * On successful verification, certificate details will be shown on the screen. * On unsuccessful verification (unauthenticated/fraudulent certificates), the message will be shown as “Certificate Invalid.”  [](http://creativecommons.org/licenses/by/4.0/)*All content on this page by* [*eGov Foundation*](https://egov.org.in/) *is licensed under a* [*Creative Commons Attribution 4.0 International License*](http://creativecommons.org/licenses/by/4.0/)*.* # DIVOC's Native COVID-19 Certificate Specification When the “Certify API” is called by a vaccinating system, a unique QR code is generated for that specific event. This document specifies the data structure that can be used to generate a QR code-based digitally verifiable certificate for a registered health event. ## QR payload structure The payload structure follows the JSON Web Token (JWT) digital signature and is defined in [**RFC 7519**](https://datatracker.ietf.org/doc/html/rfc7519). The payload is transported in a DIVOC certificate. JWT includes the following: * Header * Payload * Signature algorithm ### Header This contains the information about the certificate, which is based on the [**W3C verifiable credentials data model**](https://www.w3.org/TR/vc-data-model/). The header also indicates the type of certificate being issued. ### Payload This is divided into several parts: * The first part contains the details of who is issuing the certificate along with the timestamp. * The second part contains the details of the beneficiary to whom the certificate has been issued. * The final part contains details on the event for which the certificate has been generated. The event part has details of the health event (such as vaccination) along with a timestamp, which includes information on the type of vaccine, dose details, and location of the vaccination. ### Signature algorithm DIVOC is capable of self-generating a public-private key pair. It also supports a signing configuration where the country has onboarded a CA (certificate authority) responsible for generating the keys. In the latter case, DIVOC will use the private key issued by the CA and sign the QR code. * The DIVOC certificate is flexible and multiple signing algorithms can be used. * Self-generated keys or the keys from a country’s PKI service provider can also be used. DIVOC currently uses two default signature algorithms: 1\. PS256 - Using "crit" with "b64" ([**https://w3c-ccg.github.io/security-vocab/#RsaSignature2018**](https://w3c-ccg.github.io/security-vocab/#RsaSignature2018)) 2\. ES256 ([**https://w3c-ccg.github.io/security-vocab/#EcdsaSecp256k1Signature2019**](https://w3c-ccg.github.io/security-vocab/#EcdsaSecp256k1Signature2019)) * Click [**here**](https://github.com/egovernments/DIVOC/blob/f3c524ff0e8e9a2f09193a37758a67e9b7198c31/public_app/src/utils/credentials.json) to see the various versions of the algorithm. * The public key along with the method of signing will be provided to verifiers to authenticate certificates. * Based on the algorithm that is being used for certificate generation, the certificate can be verified by the verifier. ### Sample Payload ``` { "@context":[ "https://www.w3.org/2018/credentials/v1", "https://cowin.gov.in/credentials/vaccination/v1" ], "type":[ "VerifiableCredential", "ProofOfVaccinationCredential" ], "credentialSubject":{ "type":"Person", "id":"19882120590", "refId":"77889950", "name":"Juan Dela Cruz ", "gender":"Female", "age":"33", “dob”:””, "nationality":"India", "address":{ "streetAddress":"114/1/15,Horahena Road, Kottawa", "streetAddress2":"", "district":"colombo", "city":"", "addressRegion":"Western", "addressCountry":"IN", "postalCode":"121212" } }, "issuer":"https://cowin.gov.in/", "issuanceDate":"2021-06-28T07:21:39.684Z", "evidence":[ { "id":"https://cowin.gov.in/vaccine/448086902", "feedbackUrl":"https://cowin.gov.in/?448086902", "infoUrl":"https://cowin.gov.in/?448086902", "certificateId":"448086902", "type":[ "Vaccination" ], "batch":"batch-01", "vaccine":"Pfizer", "manufacturer":"US", "date":"2021-06-28T05:30:28.187Z", "effectiveStart":"2021-04-21", "effectiveUntil":"2022-04-21", "dose":1, "totalDoses":2, "verifier":{ "name":"ss" }, "facility":{ "name":"MOH Gothatuwa", "address":{ "streetAddress":"df", "streetAddress2":"", "district":"wew", "city":"", "addressRegion":"w", "addressCountry":"IN", "postalCode":"121212" } } } ], "nonTransferable":"true", "proof":{ "type":"RsaSignature2018", "created":"2021-06-28T07:21:39Z", "verificationMethod":"did:india", "proofPurpose":"assertionMethod", "jws":"eyJhbGciOiJQUzI1NiIsImI################4v_Gq6tIkDfhQQ" } } ``` * Click [**here**](/v2-2/platform/divocs-verifiable-certificate-features/what-information-goes-into-a-qr-code) to know more about what data set goes inside the QR code. [](http://creativecommons.org/licenses/by/4.0/)*All content on this page by* [*eGov Foundation*](https://egov.org.in/) *is licensed under a* [*Creative Commons Attribution 4.0 International License*](http://creativecommons.org/licenses/by/4.0/)*.* # DIVOC’s EU-DCC Adapter Service Conversion utility for generating EU-DCC compliant QR code ## **What will it cover?** * [What is DIVOC’s EU-DCC adapter service?](#what-is-divocs-eu-dcc-adapter-service) * [How does the conversion utility work?](#how-does-the-conversion-utility-work) * [References:](#references) [1. DIVOC’s EU-DCC adapter service: Technical details ](#1.-divocs-eu-dcc-adapter-service-technical-details) [2. EU’s technical specification for third-countries](#eu-technical-specifications-for-third-countries) ## **What is DIVOC’s EU-DCC adapter service?** DIVOC is an open-source platform that can be used to issue and verify certificates that are consistent with WHO’s minimum data set specifications. Digital certificates issued by DIVOC are based on the globally accepted [**W3C Verifiable Credential Data Model**](https://www.w3.org/TR/vc-data-model/)**.** Besides the native DIVOC COVID-19 certificate format, DIVOC has enabled an adapter that can convert a native W3C DIVOC issued certificate QR into an EU Digital COVID Certificate (DCC)-compliant QR code. ### **Need for the EU-DCC adapter service** * The EU has published technical and operational [**specifications**](https://ec.europa.eu/health/system/files/2021-07/covid-certificate_equivalence-decision_en_0.pdf) for third countries to onboard the EU gateway and facilitate smooth travel for their citizens by enabling digital verification of citizens’ COVID-19 vaccine certificates issued by the home country. * The key design principles on which DIVOC has been built are 'interoperability' and 'coexistence.' The EU-DCC adapter has been developed to ensure interoperability and verifiability of the DIVOC’s natively issued certificates with EU verifier apps. * This utility was required to facilitate restriction-free travel for residents from DIVOC’s adopter countries by enabling conversion of a DIVOC-issued vaccine certificate to an EU-DCC QR code. ### **Sample EU-DCC certificate PDF template**  ## How does the conversion utility work? * The utility is an on-demand service enabled by the DIVOC platform. The service can be triggered by using an “export as” function or calling an API for the EU adapter service. The service uses DIVOC’s “fetch service” to fetch an already issued, digitally signed DIVOC certificate post the holder authentication. Once the W3C JSON is fetched, the adapter takes inputs on holder details, vaccine event, and issuer information from the JSON and converts it into an EU-DCC QR code. The EU-DCC QR payload is then digitally signed using the ECDSA cryptographic signature algorithm. DIVOC facilitates the digital signing of the QR via a self-signing process, by using a DIVOC generated public-private key pair. Alternatively, it also supports signing the QR code using a public-private key pair issued by a country’s root certificate authority. ### **Steps to generate an EU-DCC compliant QR code** 1. To generate a valid EU-DCC compliant COVID-19 certificate for travel into the EU member states, the authorised user (certificate holder) can first provide the enrollment code (of his/her COVID-19 certificate that was generated by the issuing authority) via the national system used by the country to download these certificates. 2. To ensure the privacy and security of the certificate holder, DIVOC authenticates the user via a “mobile OTP” or a “user-password” authentication method. 3. DIVOC’s certificate fetch service uses the enrollment code to fetch the correct certificate from the certificate registry. 4. DIVOC then uses the EU-DCC conversion utility to convert the original W3C JSON payload into an EU-DCC compliant payload. 5. The payload is structured and encoded as a CBOR with a COSE digital signature. This is commonly known as a “CBOR Web Token (CWT)” and is defined in [**RFC 8392**](https://datatracker.ietf.org/doc/html/rfc8392). The payload is transported in a hcert claim. 6. This payload is encoded in a QR code and signed using the ECDSA signing method. 7. DIVOC also supports the generation of a PDF template, as defined by the adopter country. Hence, after a successful conversion process, an EU-DCC certificate document (encompassing both, the EU-DCC QR code as well as the PDF template) is generated. 8. The user can then download the EU-DCC certificate onto their mobile phone or export the same to an integrated digital wallet platform, authorised by the adopter country. ### **Sample EU payload** ``` { 1: "IN" 6: 1635179074, 4: 1735179074, -260: { 1: { "ver": "1.0.0", "nam": { "fn": "Doe", "gn": "John" }, "dob": "1986", "v": [{ "tg": "840539006", "vp": "1119349007", "mp": "Covishield", "ma": "ORG-100001981", "dn": 1, "sd": 2, "dt": "2021-10-17", "co": "IN", "is": "Govt Of India", "ci": "URN:UVCI:01:IN:331936150" }] } } } ``` ## **References** ### 1. DIVOC’s EU-DCC adapter service: Technical details * Click on the following URL to see the API details: [**https://egovernments.github.io/DIVOC/developer-docs/api/admin-api.html#../../main/interfaces/certificate-api.yaml**](https://egovernments.github.io/DIVOC/developer-docs/api/admin-api.html#../../main/interfaces/certificate-api.yaml) * [**https://github.com/Path-Check/dcc-sdk.js**](https://github.com/Path-Check/dcc-sdk.js) SDK has been used to generate a CBOR/COSE-based verifiable QR credential from the EU certificate payload. ### 2. EU technical specification for third-countries: * Click [**here**](https://ec.europa.eu/info/live-work-travel-eu/coronavirus-response/safe-covid-19-vaccines-europeans/eu-digital-covid-certificate_en) to know more about the EU digital green certificate. * You can check the EU specifications for onboarding third-countries by clicking on the following link: [**https://ec.europa.eu/health/system/files/2021-07/covid-certificate\_equivalence-decision\_en\_0.pdf**](https://ec.europa.eu/health/system/files/2021-07/covid-certificate_equivalence-decision_en_0.pdf). * Click [**here**](https://ec.europa.eu/health/publications/third-country-covid-certificate-equivalence-decision-checklist_en) to see third country COVID-19 certificate equivalence decision checklist. * List of all EU specifications are given [**here**](https://ec.europa.eu/health/ehealth-digital-health-and-care/ehealth-and-covid-19_en). * To check the JSON specifications, click on the link mentioned below: [**https://ec.europa.eu/health/system/files/2021-06/covid-certificate\_json\_specification\_en\_0.pdf**](https://ec.europa.eu/health/system/files/2021-06/covid-certificate_json_specification_en_0.pdf)**.** * For QR code specifications, click on the following link: [**https://ec.europa.eu/health/system/files/2022-02/digital-covid-certificates\_v3\_en\_0.pdf**](https://ec.europa.eu/health/system/files/2022-02/digital-covid-certificates_v3_en_0.pdf). * To know the value sets for EU Digital COVID Certificates, click [**here**](https://ec.europa.eu/health/publications/value-sets-eu-digital-covid-certificates-update_en). * Guidelines on verifiable vaccination certificates - basic interoperability elements, can be accessed [**here**](https://ec.europa.eu/health/publications/guidelines-verifiable-vaccination-certificates-basic-interoperability-elements_en). [](http://creativecommons.org/licenses/by/4.0/)*All content on this page by* [*eGov Foundation*](https://egov.org.in/) *is licensed under a* [*Creative Commons Attribution 4.0 International License*](http://creativecommons.org/licenses/by/4.0/)*.* # DIVOC’s SHC Adapter Service Conversion utility for issuing a Smart Health Card (SHC) compliant QR code ## What will it cover? * [Overview of the Smart Health Card specification](#overview-of-the-smart-health-card-specification) * [What is DIVOC’s Smart Health Card adapter?](#what-is-divocs-shc-adapter-service) * [How does the conversion utility work?](#how-does-the-conversion-utility-work) * [References:](#references) \- [Technical specification](#technical-specification) ## **Overview of the Smart Health Card specification** A Smart Health Card (SHC) is a globally popular HL7 FHIR (Fast Healthcare Interoperability Resources) and [**W3C verifiable credential standards**](https://www.w3.org/TR/vc-data-model/) - based open standard for generating tamper-proof health credentials. * An SHC provides a framework that facilitates the generation, storing and verification of the SHC holder’s clinical information. * To enable people to access a digital record of their COVID-19 vaccine history, SHCs ascertaining an individual’s vaccination and test result status, have been rolled out in US-States (California, Colorado, Connecticut, Delaware, Hawaii, Illinois, New York, and 9 others), Canada, and Japan. * You can find the registry of verified Smart Health Card issuers for vaccinators [**here**](https://www.commontrustnetwork.org/verifier-list) and [**here**](https://smarthealth.cards/en/issuers.html). | Information an SHC can contain | Information an SHC cannot contain | | -------------------------------------- | --------------------------------- | | Legal name and date of birth | Phone number | | Clinical information | Address | | Tests: Date, manufacturer, and result | Government-issued identifier | | Vaccinations: type, date, and location | Any other health information | *(Information courtesy* [***SMART Health Card***](https://smarthealth.cards/en/)*)* * To understand how they work and where they can be used, click [**here**](https://smarthealth.cards/en/) and [**here**](https://smarthealthit.org/health-cards/). ## What is DIVOC’s SHC adapter service? Besides it’s native COVID-19 certificate schema, the DIVOC platform has also developed an adapter service to convert a native DIVOC W3C-JSON certificate into a Smart Health Card-compliant QR code. ### **Need for the SHC-Adapter service** * This utility was required to facilitate restriction-free international travel for residents from DIVOC’s adopter countries by enabling conversion of a DIVOC issued vaccine certificate to an SHC-QR code. * The key design principles on which DIVOC has been built are “interoperability” and “coexistence.” The SHC adapter service has been developed to ensure interoperability and verifiability of the DIVOC’s natively issued certificates with the multiple verifier apps used in the SHC adopter countries. ## **How does the conversion utility work?** DIVOC’s adapter issues a digital certificate, as per the SHC data model, and is presented as a signed-QR code. When a source system calls DIVOC’s SHC adapter API, the following steps are undertaken; * DIVOC first checks within the certificate registry (using the beneficiary enrolment code, passed from the source system) to see if a certificate is present for the given beneficiary. * If present within the certificate registry, it fetches the respective certificate and then converts the native DIVOC W3C certificate to a SHC-certificate ([**https://build.fhir.org/ig/HL7/fhir-shc-vaccination-ig/**](https://build.fhir.org/ig/HL7/fhir-shc-vaccination-ig/)) using a custom-built npm module. * This SHC-certificate payload is then signed and the resulting JWS is used to create a QR code (using the open-source [**https://github.com/Path-Check/shc-sdk.js**](https://github.com/Path-Check/shc-sdk.js) library). * It returns the generated QR code or the full-certificate PDF (including the signed-QR), based on type parameters. * The source system can then allow the download of the generated SHC-QR certificate onto a beneficiary’s mobile phone or allow the export to a beneficiary’s digital wallet platform. ## **References** ### **Technical specification** * To know more on SHC specification, click [**https://spec.smarthealth.cards/**](https://spec.smarthealth.cards/). * You can check the SHC vaccination and testing implementation guide [**here**](https://build.fhir.org/ig/HL7/fhir-shc-vaccination-ig/). [](http://creativecommons.org/licenses/by/4.0/)*All content on this page by* [*eGov Foundation*](https://egov.org.in/) *is licensed under a* [*Creative Commons Attribution 4.0 International License*](http://creativecommons.org/licenses/by/4.0/)*.* # Adding a User Type in DIVOC ## Overview The document will cover steps on how to add a new user. ## Steps to add a user ### Step 1: Login to keycloak (demo URL: [**https://demo-divoc.egov.org.in/auth**](https://demo-divoc.egov.org.in/auth/)). Click on the administration console and enter the username and password. Next, click on the "sign in" button.  ### Step 2: Go to the 'manage' section, and click on 'users.'  ### Step 3: Click on "add user" to create a new user.  ### Step 4: Enter your mobile number as the user name, and click on save.  ### Step 5: Click on 'attributes' and add the required attribute (mobile\_number) by clicking on the 'add' button. Next, click on 'save.'  ### Step 6: Click on "role mappings" and select the type of role you want to add from the list of "client roles."  ### Step 7: Select the role you want to add from the list of "available roles" and click on "add selected." Once you have completed this step, you will see the new user in the "assigned roles" section.  [](http://creativecommons.org/licenses/by/4.0/)*All content on this page by* [*eGov Foundation*](https://egov.org.in/) *is licensed under a* [*Creative Commons Attribution 4.0 International License*](http://creativecommons.org/licenses/by/4.0/)*.* # Printing Certificates at a Facility The document will cover steps on how to print certificates at a facility. ## Create a user type The facility/system administrator can print the certificates. The administrator can also create a user type (from the list of available roles) for a person who will print the certificates. Click [**here**](/v2-2/platform/divocs-verifiable-certificate-features/adding-a-user-type-in-divoc) to add a user type in DIVOC. ## Steps to print certificates at a facility ### Step 1: Once the user has been created, the person can log in to the portal using the following URL: [**https://demo-divoc.egov.org.in/portal**](https://demo-divoc.egov.org.in/portal). Enter the registered mobile number, and the OTP, and click on "login to portal."  ### Step 2: Enter the phone number and the date of birth given during registration. Next, click on the search button.  You will see the name(s) displayed on the screen.  ### Step 3: Click on 'print' to print the certificate. To save it on your desktop/laptop, click on 'save.'  ### Step 4: Log out once you have printed the required certificate(s).  [](http://creativecommons.org/licenses/by/4.0/)*All content on this page by* [*eGov Foundation*](https://egov.org.in/) *is licensed under a* [*Creative Commons Attribution 4.0 International License*](http://creativecommons.org/licenses/by/4.0/)*.* # Normal QR Code Versus Signed/Verifiable QR Code You have likely seen a lot more QR codes over the last two years due to the pandemic. At many restaurants, for example, which are keen not to share physical menus, customers scan a QR code with their phone camera to open a website for the online menu. ## **What is a QR code?** * Short for Quick Response, a QR code stores all kinds of information that can be scanned and accessed by a digital device such as your smartphone. * The machine-readable format can also be printed on a piece of paper. * While barcodes are one-dimensional, which means that information can be scanned only horizontally, QR codes are two-dimensional. Hence, information on a QR code can be read both horizontally and vertically, allowing it to store more data. * QR codes allow you to download applications, join WiFi networks without having to key in any password, scan coupons, and much more. They can be embedded on a company’s website to gather feedback, facilitate registrations, collect customer data, and order details. QR codes can be used on physical products as a way to provide more information. * QR codes are also used for document verification to check if a credential is genuine. This has gained popularity during the pandemic with some countries opting for QR code-based vaccination certificates to open up travel and business. ## Normal QR Code vs Signed/Verifiable QR Code | Normal QR Code | Signed/Verifiable QR Code | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | A normal QR code contains information that can be read and understood by any QR code viewer. They typically carry a URL and a scan of such QR codes reroutes to a separate site. | A signed QR code encodes the verifiable data set or information within the QR itself, rather than on any website. | | In a normal QR code, information can be edited and altered, making the verification process untrustworthy and vulnerable to hacking. To address this issue, a signed or verifiable QR code is used, particularly in the case of sensitive information. Sensitive data could be your bank details, educational details, and medical information, among others. | The information is secure and cannot be altered or tampered with, nor can it be scanned and accessed by everyone. This is because the original data/information in the QR code is digitally signed. | | | **Example:** In the case of COVID-19 vaccination certificates, for example, data identifying the vaccination event and the beneficiary is encoded within a QR code and then digitally signed, making it tamper-proof. Only a verifying authority with a secure key can validate this information accurately by matching it with the signing key of the QR code. | [](http://creativecommons.org/licenses/by/4.0/)*All content on this page by* [*eGov Foundation*](https://egov.org.in/) *is licensed under a* [*Creative Commons Attribution 4.0 International License*](http://creativecommons.org/licenses/by/4.0/)*.* # What Information Goes Into a QR Code? A vaccination certificate is a proof that a person has received the shot to protect them from an infectious disease such as COVID-19 or the flu. We have given below the type of information (mandatory and optional) that should be there in a QR code-based COVID-19 vaccination certificate, as specified by the World Health Organisation (WHO).
| Requirement status for proof of vaccination | DDCC label | DIVOC label | Description and definition | Data type/format | Examples |
|---|---|---|---|---|---|
| Mandatory | Name | recipientName | The full name of the vaccinated person. | String | John Tom Brown |
| Mandatory | Date of birth | recipientDOB | The vaccinated person's date of birth (DOB) if known. If unknown, use the assigned DOB for administrative purposes. | Date | 1998-01-05 |
| Mandatory | Unique identifier (primary identifier of the beneficiary) | preEnrollmentCode | Unique identifier for the vaccinated person, according to the policies applicable in each country. There can be more than one unique identifier used to link records (example: national ID, health ID, immunisation information system ID, and medical record ID). All the certificate IDs will be linked to the beneficiary's preEnrollmentCode. | UUID | |
| Optional | recipientIdentity | To be used only if there is a need to share/print an additional national ID. By default, it is set as 'null' in DIVOC's case. The above field covers this as well. | Alpha number | Driving license | |
| Optional | Sex | recipientGender | Documentation of a specific instance of sex information for the vaccinated person. | Male/female/other | |
| Optional | recipientMobileNumber | Numeric | 18767778888 | ||
| Mandatory | Vaccine type or prophylaxis | Need to incorporate in the payload. | Generic description of the vaccine or vaccine sub-type, such as COVID-19 mRNA vaccine, HPV vaccine. | Coding - ICD 11 | |
| Mandatory | Vaccine brand | vaccinationName | The brand or trade name used to refer to the vaccine received. | String | Pfizer |
| Optional | Vaccine manufacturer | vaccinationManufacturer | Name of the manufacturer of the vaccine received, such as Serum institute of India, or AstraZeneca. If the vaccine manufacturer is unknown, a market authorisation holder is needed. | String | ABC company |
| Optional | Vaccine market authorisation holder | Name of the market authorisation holder of the vaccine received. If the market authorisation holder is unknown, a vaccine manufacturer is required. This is needed only if the manufacturer is not listed in the WHO EUL (Emergency Use Listing Procedure) list. | String | ||
| Mandatory | Vaccine batch number | vaccinationBatch | Batch number or lot number of the vaccine. | String | 4121Z104 |
| Mandatory | Date of vaccination | vaccinationDate | Date on which the vaccine was administered. | Date | 2021-11-30 |
| Mandatory | Dose number | vaccinationDose | Vaccine dose number. | Quantity | 1, 2 |
| Mandatory | Total doses | vaccinationTotalDoses | Total expected doses as defined by a member state's care plan and immunisation programme policies. | Quantity | For Pfizer and BioNTech, the total expected doses are two. |
| Mandatory | Country of vaccination | facilityCountry | The country where a person was vaccinated. | Code | JAM = Jamaica |
| Optional | Administering centre | facilityName | The name or identifier of the vaccination facility responsible for administering the vaccination. | String | Falmouth Health Centre |
| Optional | Health worker identifier | vaccinatorName/ID | If the country does not have a national identifier, you can share the name of the vaccinator. | ID | National ID of the vaccinator |
| Optional | Disease or agent targeted | Available as a certificate header and not as a data element in the current certificate API payload. | Name of the disease vaccinated against (such as COVID-19). We recommend that you can have it as a data element within the payload. | Coding | Certificate header: COVID-19 Vaccination Certificate. |
| Optional | Due date of the next dose | Only implemented for India. | Date - YYYYMM/DD | ||
| Mandatory | Certificate issuer | Issuer (available in the output) | The authority or authorised organisation that issued the vaccination certificate. | String | Ministry of Health & Wellness, Jamaica |
| Mandatory | Health certificate identifier | Certificate ID (available in the output) | Unique identifier used to associate the vaccination status represented in a paper vaccination card. | ID | 378855845 |
| Optional | Certificate valid from | vaccinationEffectiveStart | Date on which the certificate became valid. No health or clinical inferences should be made from this date. | Date | 2021-11-30 |
| Optional | Certificate valid to | vaccinationEffectiveEnd | Last date on which the certificate is valid. No health or clinical inferences should be made from this date. | Date | 2022-11-30 |
| Optional | Certificate schema version | Only if schema versions are maintained. |
## What will it cover? ### A. [Skills needed to set up DIVOC](/v2-2/platform/installation/skills-needed-to-set-up-divoc) ### B. [Implementation Checklist](/v2-2/platform/installation/implementation-checklist) ### C. [Setting up DIVOC](/v2-2/platform/installation/setting-up-divoc-in-k8-cluster) ### D. [Backup & Restore: Postgres, Clickhouse, and Kafka](/v2-2/platform/installation/setting-up-divoc-in-k8-cluster/backup-and-restore-postgres-clickhouse-kafka-and-redis) ### E. [Infrastructure Recovery](/v2-2/platform/installation/setting-up-divoc-in-k8-cluster/infrastructure-recovery) ### F. [Server Hardening](/v2-2/platform/installation/setting-up-divoc-in-k8-cluster/server-hardening) ### G. [Certificate and Verification Component](/v2-2/platform/configuration/configuring-the-certification-and-verification-component) ### H. [Platform Policy Guidelines](/v2-2/community/about-project-team/platform-policy-guidelines) ### I. [Privacy Policy Recommendations](/v2-2/community/about-project-team/privacy-policy-recommendations) Each country will have its own set of requirements in line with globally accepted standards for issuing certificates. The guides will walk you through: * [How to configure the certificate component?](/v2-2/platform/configuration/configuring-the-certification-and-verification-component/configuring-certificates) * [How to set up the verification portal for your implementation?](/v2-2/platform/configuration/configuring-the-certification-and-verification-component/how-to-set-up-the-verification-portal-for-implementation) * [How to configure the update certificate API?](/v2-2/platform/configuration/configuring-the-certification-and-verification-component/how-to-configure-the-update-certificate-api) [](http://creativecommons.org/licenses/by/4.0/)*All content on this page by* [*eGov Foundation*](https://egov.org.in/) *is licensed under a* [*Creative Commons Attribution 4.0 International License*](http://creativecommons.org/licenses/by/4.0/)*.* # Skills needed to set up DIVOC The technical skills required by DIVOC adopters vary and are based on the level of changes they intend to make to the core DIVOC platform. ## What does this section cover? * Skills needed for a simple setup scenario * Skills needed for a complex setup scenario ## **Simple setup: Only setup and configuration** This includes: 1. Setting up infrastructure on cloud or on-premise. 2. Deployment of application components/services. 3. Configuration of components to connect to work as a single system: \- Configure templates, such as data import templates for facility registry. \- Keycloak to change OTP-based login in keycloak to password-based login. \- Configuration of certificate templates. ## Skills the team should have: * Experience in setting up Kubernetes cluster / Docker-based deployment. * Experience in setting up and configuring platforms such as Kafka, Redis, Postgres, and Keycloak. * Experience in HTML templates design. ## Complex setup: Setup, configuration, and customisation Customise DIVOC as per the country-specific requirements and its implementation need, such as: 1. Changes in registry schema: This includes changes in the type of information being captured on various events. 2. UI: This includes applying country-specific branding on the various UI pages of the portal. 3. Add and Update APIs: This includes the introduction of new API calls within as well as with third-party applications, such as integration with the supply chain system to provide updates on the stock used at the facility level. It also involves updating existing APIs, such as changing mandatory fields to non-mandatory in API payloads and changing response structure, among others. ## Skills the team should have: * Experience in technologies such as HTML, Jquery, React, JavaScript for UI level changes. * Experience in technologies such as Go for API-related changes. * Experience in OpenSaber and Postgres for registry-related changes. * Experience in integrating platform services used in selected components for customisation and implementation. [](http://creativecommons.org/licenses/by/4.0/)*All content on this page by* [*eGov Foundation*](https://egov.org.in/) *is licensed under a* [*Creative Commons Attribution 4.0 International License*](http://creativecommons.org/licenses/by/4.0/)*.* # Implementation Checklist ## Overview This checklist can help you plan your implementation. Besides technical and operational details, it covers server setup, QR code, certificate template changes, and updating and verifying certificates. ## QR code
| Section | Checklist | Description |
|---|---|---|
| Create QR code | Change the value in context section. |
|
| Create QR code | The Id field in "credentialSubject" should be in a URI format. |
|
| Create QR code | The date value passed in the payload in the 'vaccination' section should match with the value in the 'evidence' section of the QR code and it should follow the YYYY-MM-DD format. |
|
| Create QR code | The 'issuer' is mapped correctly as per the requirement. |
|
| Create QR code | The vaccine list provided by a country is available in the master list. |
|
| Create QR code | The vaccine and prophylaxis mapping is as per the country requirements. |
|
| Create QR code | Vaccine 'manufacturer,' 'batch' values shared in the payload are getting reflected in the QR code. |
|
| Create QR code | The addressCountry value in the evidence section captures the 3-digit country code from here. |
|
| Create QR code | 'dose' and "totalDoses" value shared in the payload are getting reflected in the QR code. |
|
| Create QR code | The 'Id' part in the evidence section is in a URI format. |
|
For example, the verification page should include following messaging/guidelines/ information:
- How to scan the QR code?
- The possible reason for showing a certificate as invalid or revoked?
- What steps to follow if a certificate is shown as invalid or revoked, such as information of the contact person.
- The possible reason if the verification component is not able to scan the QR code? Click here for more details.
The production environment should support the following recommendations:
- Data backup policy.
- Authentication and password management.
- Error handling and logging.
- System configurations.
- Click here to know more.
Back up of the following:
- DB/server setup.
- Online/offline line.
The section should cover activities to be performed to ensure security of data and application.
For example,
- Restrict all the non-essential ports on the public network. Ports of DB/other inter-components should only be accessible within the application. Click here for the list of ports.
- Firewall controls should also be in place, such as user management, for better access control.
Sample certificate
Sample certificate
Sample certificate
Sample certificate
| Program Registry | Vaccine Registry | Facility Registry | Vaccinator Registry | |
|---|---|---|---|---|
| Vaccination programs | Approved vaccines | Approved facilities | Trained vaccinators | |
| Active status | Active status | Location | Active status | |
| Allowed vaccines | Vaccination schedule | Active status | Training certificate | |
| Start and end dates | Batch deny list | Vaccination daily rate | Associated facilities | |
| Certificate templates | Max retail price | Total supply | Rating and feedback | |
| Vaccination method | Rating and feedback |
](
| Feature | Description |
|---|---|
| Manage multiple tenants | Services to manage multiple tenants and their respective schema. |
| Create verifiable credentials (VCs) from multiple issuers | Ability to create VCs with different schemas for one tenant and to create VCs from multiple issuers. |
| Ability to update schema | Ability to make changes or updates to available schemas. |
| Service to generate and send only QR code (SVG) with provided dimensions | The tenant/issuer system can fetch images of QR codes in provided dimensions. The image can be shared with the beneficiary directly or can be embedded in the certificate template designed by the issuer/tenant system. |
| Services to update certificate | Capability to update/modify already generated certificates. |
| Revocation and suspension | Capability to revoke or suspense already issued certificates upon expiry, issuance of a newer version, or violation of terms and conditions. |
| Notification services | Capability to notify beneficiaries on the generation of certificates. |
| Enabling multi-lingual certificate | Functionality to manage certificate templates in multiple languages and generate certificates based on selected templates. |
| Feature | Description |
|---|---|
| Common verification portal | A common verifier portal for verifying VCs created by multiple schemas and from multiple issuers. The portal will have a UI that will be accessible to the public, or those with credentials to access them. For example, a doctor with a VC for council registration created by the DIVOC platform submits the same to an employer (a hospital). The hospital can then go to the common verification portal URL and verify the VC. The verification portal can verify the following: 1. Authenticity (If the certificate has been tampered with). 2. Status (The certificate is revoked/suspended/is valid/is not valid). |
| Tenant onboarding user interface | A use interface through which the source system admin can: 1. Log in to the DIVOC platform with the credentials received. 2. Reset the password if not accessible. 3. Generate tokens to connect the source system and DIVOC platform. |
| Tenant creates schema user interface | A user interface through which the source system admin can define and create schemas for different provider types, and also test and publish the schemas. |
| Speaker | Duration |
|---|---|
| Welcome address: Thiam Hee Ng, Director, SARC | 2 mins |
| Opening Remarks: Sungsup Ra, Chief Sector Officer, SDCC | 3 mins |
Presentation: Viraj Tyagi, CEO, eGov Foundation Pradipta Kundu, Health Mission Lead, eGov Foundation | 30 mins |
Comments and Discussion: Patrick Osewe, Chief of Health Sector Group, SDSC Thiam Hee Ng, Director, SARC | 23 mins |
| Closing Remarks: Gi Soon Song, OIC, SAHS | 2 mins |
| Launched at Scale: India | Now live in… | Coming soon… |
|---|---|---|
| Over 2 billion digitally signed vaccinated certificates via Cowin. | DIVOC’s certificate component went live with digital vaccination certificates in Sri Lanka in July 2021, in the Philippines in September 2021, and in Jamaica and Indonesia in December 2021. | Indonesia and Jamaica are currently planned for Covid-19 vaccination certificate roll-outs. |
DIVOC has enabled the Indian Council of Medical Research (ICMR) to issue digitally-signed COVID-19 test reports. | Plans are underway to issue COVID-19 test result certificates in both Sri Lanka and Philippines. |
| Field name | Type | Description | Mandatory |
|---|---|---|---|
| Registration no. | Alphanumeric | This is the registration number issued to a health professional | Yes |
| Feature | Description |
|---|---|
| APIs for tenant and schemas | Multiple tenants can now create and manage schemas through the platform. |
| APIs for tenant and schemas | A single tenant can create multiple schemas required for issuing VCs through the DIVOC platform. |
| Ability to update the schema | This will give you the capability to update schemas that are already created. |
| Service to generate and send only QR code (SVG) with provided dimensions | Issuers can fetch QR codes through the DIVOC platform and this can be shared with the beneficiary directly or can be embedded on the certificate template. |
| Services to update a certificate | We have added the capability to update/modify content on already generated certificates. |
| APIs for revocation and suspension | An issued certificate may need to be revoked/suspended due to validity expiry, issuance of a new certificate, or violation of terms and conditions. With this release, issuers can revoke and suspend certificates that are already issued. |
| Notification services | The beneficiaries (holders of the VC) will receive an SMS when the certificates are generated. |
| Enabling multi-lingual certificate | We have added the capability to create and issue certificates in multiple languages. |
| Feature | Description |
|---|---|
| Add support in DIVOC to use S-RC in async mode | The DIVOC platform has been updated for the services to work in async mode to avoid any data loss during the exchange of high volumes of data. |
| Modifications in the response codes for error messages* | Error codes have been defined and included in the response along with their corresponding error messages. |
| Modify Keycloak services for tenant management services | Configured Keycloak services to support the creation of multiple tenants. |
| Feature/enhancement | Description |
|---|---|
| Verification portal | This will enable verifiers to check the authenticity and validity of VCs issued from different issuers by scanning the QR codes through an interface. |
| UI for tenant onboarding portal | An interface through which source system administrators can log in to the DIVOC platform and connect it with the source system. |
| UI for tenant multiple schema creation | An interface through which source system admins can create and manage different schemas required for the issuance of VCs. |
| Error code | Message |
|---|---|
| 400 | Invalid input provided. |
| 401 | Unauthorised (in case the token has expired or is invalid). |
| 403 | Forbidden (if any required headers/auth header is not available). |
| 404 | Not found (in case of any unavailable resources). |
| 406 | Specific for failed verification (during scanning of the QR code). |
| 500 | Any other internal server error (usually in case the error is not from the list above). |
| 502 | Thrown by the gateway when a service is not reachable. |
- Credential metadata