Implementation Checklist
Last updated
Last updated
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.
| Section | Checklist | Description |
|---|---|---|
| Section | Checklist | Description |
|---|---|---|
| Section | Checklist | Description |
|---|---|---|
| Section | Checklist | Description |
|---|---|---|
| Section | Checklist | Description |
|---|---|---|
| Section | Checklist | Description |
|---|---|---|
| Section | Checklist | Description |
|---|---|---|
All content on this page by eGov Foundation is licensed under a Creative Commons Attribution 4.0 International License.
Create QR code
Change the value in context section.
This value indicates the release version of the certificate schema. This versioning will support in introducing validations (if required) on certificates generated in previous schemas such as "revoking/invalidating certificates with previous schema."
For example: For release 1 - It could be "https://moh.prod/credentials/vaccination/v1" and for release 2 - It could be "https://moh.prod/credentials/vaccination/v2"
For more details and sample QR code content, click here.
Create QR code
The Id field in "credentialSubject" should be in a URI format.
If certify request payload contains “identity,” set it to “did::”
Else, use the “preEnrollmentCode” and set it to “did::”
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.
The format is as per the WHO-DDCC data standard.
Validate the date value as it may have impact due to the vaccination system (external), and DIVOC is deployed in servers with a different timezone (UTC). Border cases to be checked as day/date may change.
Create QR code
The 'issuer' is mapped correctly as per the requirement.
This value indicates the certificate issuing authority. The issuer field is configured in the platform. For more details, click here.
The value of this change to be added here: https://github.com/egovernments/DIVOC/blob/main/docker-compose.yml#L295.
Create QR code
The vaccine list provided by a country is available in the master list.
The vaccines provided in the platform are listed here.
Validate and add to the list if a new vaccine needs to be added in the list - https://github.com/egovernments/DIVOC/blob/main/default-configuration/etcd/ICD.json and https://github.com/egovernments/DIVOC/blob/main/default-configuration/etcd/VACCINE_ICD.json.
Create QR code
The vaccine and prophylaxis mapping is as per the country requirements.
The vaccines provided in the platform are listed here.
Validate and add to the list if a new vaccine need to be added in the list - https://github.com/egovernments/DIVOC/blob/main/default-configuration/etcd/ICD.json and https://github.com/egovernments/DIVOC/blob/main/default-configuration/etcd/VACCINE_ICD.jso.
Create QR code
Vaccine 'manufacturer,' 'batch' values shared in the payload are getting reflected in the QR code.
The sample payload and the QR code is mentioned here.
Create QR code
The addressCountry value in the evidence section captures the 3-digit country code from here.
The values are set here: https://github.com/egovernments/DIVOC/blob/main/docker-compose.yml#L214.
Create QR code
'dose' and "totalDoses" value shared in the payload are getting reflected in the QR code.
For more details, click here.
Create QR code
The 'Id' part in the evidence section is in a URI format.
For example, 'id' - "https://divoc.dev/vaccine/<certificateId>" Where - certificateId is unique for each certificate. If the certificate gets updated, a new certificate will be generated with a new certificate Id for the same event. For more details, click here.
Update a certificate
Update limits are set according to a country's requirement. The details to configure the update limit are available here.
Revoke a certificate
The system should be able to generate a certificate for a revoked dose.
For example, if the dose 2 certificate has been removed from the system, the user should be allowed to generate another/correct dose 2 certificate. Click here to know more on DIVOC's revocation services.
Revoke a certificate
The system is only revoking the earlier certificate which existed for the specified dose value.
For example, If dose 2 certificate has been removed from the system, the user should be allowed to generate another/correct dose 2 certificate.
Create certificate template
QR code size is 2.5x2.5 inch on a printed A4 size paper.
Click here to see a sample certificate.
Create certificate template
Does the printed certificate show the minimal values based on the WHO-DDCC standard?
Click here to see the list of minimal data set as per the WHO-DDCC standard.
Create certificate template
If the certificate template has a table which shows the current and the previous dose details (if available), then the table should be configured to be scalable to capture details of both the current and the previous dose details in required combinations.
For example, the certificate template should have only one template file to refer to for the generation of certificates with a combination of dose 1, dose 1 and 2, dose 1, 2, and 3, etc. This should be up to a maximum feasible limit based on the template design.
Verify a certificate
SSL certificate has been applied to the verification page.
The SSL certificate is required to open the camera in the browser.
Verify a certificate
The verification page has been configured to provide the necessary guidance to the user for the verification component.
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.
Server setup
Infrastructure estimation guide.
For example, if the load goes up, then the system should be configured for scalability.
Server setup
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.
Server setup
System is configured to handle network crash or infrastructure crash.
For example, if the master/slave nodes go down, are they configured to autostart/auto-deploy? Click here to know more.
Server setup
The system should be configured to backup. Click here to know more.
Back up of the following:
DB/server setup.
Online/offline line.
Server setup
Click here to read the server hardening guidelines.
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.
Sign key generation
It is done as per the standard.
Click here for more details.
Sign key generation
Keycloak configuration related to DIVOC.
Click here for more details.
Privacy policy
Privacy policies are based on the recommendations made to implementing partners. They are advised to share it with citizens regarding their personally identifiable information and how it is managed in DIVOC.
As the application contains citizen data, access rights (read/write) should be agreed between parties for staging/production/other environments. Click here to know more.
