With the arrival of the COVID 19 vaccine, governments are facing multiple challenges: such as sourcing the vaccine, delivering it to the right people, creating vaccine programs, roadmaps and finally tracking who has received the vaccine.
To reduce the risk of different performance of vaccines for different groups; governments have been sourcing the vaccine from multiple providers, which also adds more complexity on the ground for the teams to properly track who has received what vaccine doses from which batches.
Furthermore, all of that needs to be executed in a short time, while respecting the privacy, security, and compliance laws, increasing the demand on the IT teams to develop a solution.
Tracking is critical to the systematic execution of the vaccination programmes; and being able to access vaccine information quickly might be one of the keys to restoring life to what it was before COVID, by allowing people to participate to social activities if they are adequately immunised.
The resuming of international travel and its direct links to the global economy is complicating the issue even more: how will we communicate between countries when someone has been inoculated? For Instance, attending seminars or professional gatherings such as the World Economic Forum in Singapore?
Synchronising that amount of data between cross border segregated systems is complex. There are currently no clear standards between countries to exchange this kind of data quickly, and when there is, it is usually limited to a specific region (e.g. HISA/ISO 12967, mainly used in Europe).
The other issue with trying to synchronise multiple systems, is developing the multiple secure interfaces required, to be able to do so without compromising an individual’s security and confidentiality. For instance, how might we provide secure and specific access to the vaccination programme system, to the people managing access to a concert or a nightclub?
This privacy and access challenge is precisely where self-sovereign identity (SSI) shines.
By providing a common ground, with clearly defined protocols and behaviours. SSI allows the secure and trustable exchange of data between different parties, with full control from the end-user.
The end-user directly controls data exchanged, and can choose how much of the data is shared. From the point of view of the person validating their credential, as long as the issuer of the said credential is trusted, then the credential is trusted. Hence, the government can act as an issuer and decide how much data they would wish to keep on the signed credential.
For instance, consider this scenario: John goes to the nearest hospital to get a vaccine for COVID 19. His identity is checked through the current procedures (e.g. identity card, passport,…). His vaccine data is stored on the hospital’s internal systems. In parallel, he receives from the hospital a credential indicating the date of his vaccination, vaccine batch number, dosage information, hospital name, etc.
That credential is stored in an SSI application of his choice, either provided by his government, or another generic SSI application.
The credential is signed by the hospital, and its public key is stored on a public blockchain as a public Decentralized IDentifier (DID).
Now, John wants to go to a concert. He purchased a ticket online but needs to prove that he is adequately inoculated. To do so, he scans a QR code on the concert ticket platform and receives the notification on the app that the ticket platform wants to get access to his vaccination credential.
The concert in its proof request can only trust a list of hospitals. If John’s hospital is part of that trusted list he can select the information that he wants to be shared and allows the sharing of the credential. Once his vaccination credential is proven, the concert can then issue an entrance credential to John.
Once he arrives at the concert, the concert hall can admit him by seeing his ticket credential. Therefore proving John is vaccinated without revealing his personal details or giving the concert employees access to a central database. Or he could use a standard ticket and prove his vaccination information only using a QR code once he’s at the concert.
If John then decides to go for a conference in another country, the same application can be used regardless of the destination he is going to.
The beautiful part for all the technology people reading is, is that all of that is already developed, and is open source. Of course, this might need some tweaking, and perhaps a rebranding of the application, but the back-end and even front-end application exists today (even with biometric authentication!). And the technology is already in use by some governments.
With SSI being an entirely distributed system, all updates to it are synced automatically, and in close-to real-time, across the globe. If and when there is an increase in load, adding new nodes will immediately solve the problem.
Furthermore, compliance and security are baked inside the system by design.
The digital-first approach means that the entire process can be fully automated, either from the issuers, the end-user, or from the validation side.
The protocol permits the cancellation of a credential. For instance, in the unlikely event that a vaccine batch has an issue, it’s possible to revoke all the vaccination claims for this batch. The same tool can also be used with other types of credential, like negative COVID tests, and this can evolve depending on the needs that will come in the future.
For instance, as the vaccine does not prevent people already infected from transmitting the disease (even if it might reduce the symptoms), in some instances, a pre-vaccine test might be required to access certain events or depart to another country. Serology tests could also be required in the future, depending on the vaccine. All of it can be stored as new credentials on an SSI-based system.
And because the basic principle is the trust between the issuer and the person checking that credential, it’s up to each government to decide what kind of vaccine, countries or hospitals are approved for travel, with as much granularity as they require.
Because it may take some time for hospitals to integrate a new SSI technology, and because some of the countries may not be part of the system, it is imperative to keep the existing procedures and systems, and concurrently allow people to get a digital certificate on SSI, as long as the existing system shows that the person is vaccinated correctly.
We would suggest keeping both systems working together, instead of trying to remove the existing platform, to avoid any delay while everybody is on-boarding the system.
Keeping existing platforms and integrating them with an SSI-based system will also benefit the end-user. As no data is stored outside of the end-user encrypted wallet (on the mobile phone and its back-ups), in case the phone is lost, the issuer will need to issue the claim once more. Having the records available in a separate system is then absolutely critical.
Introducing a new system is always challenging. Keeping the SSI-based system synced on the back-end with existing systems would reduce the impact of the change. For smaller clinics or practicians that might not have a full-fledge back-end system, though, providing an SSI option can provide a very cost-effective approach.
Using open-source software has a lot of benefits over closed source software, and certainly over a closed (or proprietary) platform, especially when dealing with personal or medical information.
As the code is available for everyone to see, it’s easier to spot potential issues or vulnerabilities, that would be hidden away in a proprietary or closed source software.
Specifically for SSI, open-source software gives the guarantee that data is never stored outside of the end-users’ wallets. Where a platform would have EULA or other “click to approve the transfer of your data” that you have to approve to be able to use the platform, SSI open-source software ensures that the principles of confidentiality are baked into the system, instead of being treated as a mandatory add-on to an existing software.
The code also does not belong to a single company or entity whose interest may not always align with the end-users’ best interests.
Using open-source software also means that for certain developing countries, where the cost of creating a new system of paying for the license of a closed source platform might be prohibitive, open source would provide an alternative, bringing a way to create internationally recognised digital certificates to virtually everyone.
There is, of course, a little choice to make: which SSI platform to use?
At PALO IT, we have been mainly working with SSI provided by Sovrin, but other platforms are applying the same principles, like Microsoft’s ION or Ethereum’s ERC725.
In this case, we would suggest to go for an open-source system, where the code can be validated by each government, without belonging to a single enterprise, and thus being under the jurisdiction of a single country.
It is always possible to create a bridge between SSI providers. Even if these bridge does not exist natively, it’s always possible to create a new SSI claim (“claim” is the actual “SSI” name for credential) on another platform and even automated feature on a website. For instance, using a claim on Sovrin to generate a claim on ESSIF/eIDAS for Europe.
SSI has many other features and capabilities. Most of the SSI enthusiasts are focusing a lot on Freedom, and the philosophy of identity. For this article, we are coming from a more pragmatic approach: why reinvent the wheel, when one is freely available?
With limited resources and a very short timeframe to come up with a working solution that can scale dramatically, both in the number of users and in the number of countries, going for a tested and validated SSI system will be the most efficient, globally accessible and secure solution.
For more information about SSI: ssi@palo-it.com
Dimitri Baikrich - CTO PALO IT Singapore has been leading the Innovation Lab which did a project on Self-Sovereign Identity, working on a new decentralized communication protocol,WebAgent, improvement on the OSMA open-source project, and inter-operability, connecting the app with IIWbook developed by the Govt of British Columbia. The Innovation Lab work on SSI was presented in events including MyData 2019 in Finland, Identity Week Asia, and Singtel Innofest.