key: cord-0234138-biupe66r
authors: Eisenstadt, Marc; Ramachandran, Manoharan; Chowdhury, Niaz; Third, Allan; Domingue, John
title: COVID-19 Antibody Test Certification: There's an app for that
date: 2020-04-15
journal: nan
DOI: nan
sha: 152a62edb20b9cda73328d1ad305248a95ce999f
doc_id: 234138
cord_uid: biupe66r

Goal: As the Coronavirus Pandemic of 2019/2020 unfolds, a COVID-19 'Immunity Passport' has been mooted as a way to enable individuals to return back to work or be admitted to current off-limits locations. While the quality of antibody testing and the likelihood of even attaining COVID-19 immunity continue to be researched, we address the issues involved in providing tamper-proof and privacy-preserving certification, both for COVID-19 immunity and in general. Methods: We developed a prototype mobile phone app and requisite distributed server architecture that facilitates instant verification of tamper-proof test results. Personally identifiable information is only stored at the user's discretion, and the app allows the end-user selectively to present only the specific test result with no other personal information revealed. Behind the scenes it relies upon (a) the 2019 World Wide Web Consortium standard called 'Verifiable Credentials', (b) Tim Berners-Lee's decentralized personal data platform 'Solid', and (c) a consortium Ethereum-based blockchain. Results: Our mobile phone app and distributed server architecture enable the mixture of verifiability and privacy in a manner derived from public/private key pairs and digital signatures, generalized to avoid restrictive ownership of sensitive digital keys and/or data. For the test certificate Holder, Issuer (e.g. doctor, pharmacy) and Verifier (e.g. employer), it is 'just another app' which takes only minutes to use. Conclusions: The app and distributed server architecture offer a prototype proof of concept that is readily scalable, applicable generically, and in effect 'waiting in the wings' for the biological issues, plus key ethical issues raised in the discussion section, to be resolved.

the presence of antibodies could offer a way for people who can prove COVID-19 immunity to go back to work [2, 3] . There are, however, challenges concerning the biological premise of 'immunity': the strength and longevity of COVID-19 immunity after infection are matters of current debate and research, as are the sensitivity and robustness of the relevant tests [4, 5] .

Given the scale of the pandemic and financial fallout, it is plausible that 'COVID-19 antibody test certification' (henceforth 'CATC'), if shown to be robust, will be in great demand. Bearing in mind the possible ethical implications of such certification, raised in [6] and our Discussion, we feel that for either the current pandemic or a pandemic of the future, the concept of certification has a place, particularly when the recipient is employed in healthcare or other key sectors.

But what form should certification take? A signed or stamped letter is the centuries-old default, and straightforward to roll out at scale, as long as there is some point-of-test proof of identity. But paper certificates have two problems: (a) recent studies show that SARS-CoV-2 can survive on plastic, stainless steel and cardboard (and presumably paper) for a number of hours, facilitating transmission via paper certificates [7] ; (b) for such a sensitive and likely high-value certificate, a paper version is too vulnerable to alteration or forgery. A digital certificate would make considerably more sense, provided that it can be:

• Privacy-preserving • Un-forgeable • Easy to administer • Easily verifiable while still preserving privacy • Scalable to millions of users • Cost-effective • Approved by an ethics watchdog • Acceptable to the public Modern smartphone apps and several key technologies such as public key cryptosystems and immutable blockchain records offer some tantalizing prospects, if they can satisfy the above criteria. Below, we look at the methods by which this can be achieved, assuming a scenario involving testing by a known authority (e.g. doctor or pharmacist).

There's an app for that Marc Eisenstadt, Manoharan Ramachandran, Niaz Chowdhury, Allan Third, John Domingue* This work has been submitted to the IEEE for possible publication. Copyright may be transferred without notice, after which this version may no longer be accessible.

Verifiable Credentials [8] , is a W3C standard that builds upon Public Key Infrastructure (PKI), the public/private key pairs that facilitate digital signatures in widespread use today. The W3C extensions standardize the definitions of document formats to make them machine-readable and communicable, and to generalize PKI, which tends to be costly and highly centralized. The generalization involves a distributed registry for cryptographic keys, typically residing in a blockchainthis allows every public key to have its own unique address, known as a Decentralized Identifier (DID). The key roles and transactions are illustrated in Fig. 1 .

The 'Issuer', which might be a bank, company, or Government body such as the UK National Health Service (NHS), can issue credentials such as certificates and licenses. 'Holders' (typically citizen end-users) can store them in their own preferred way, for example in digital wallets that are part of a mobile phone app. 'Verifiers', such as employers, or establishments seeking proof of some attribute, can ask the Holder to present such proof concerning these credentialsknown as 'verifiable presentations', which are collections of evidence (such as credentials or pieces of data derived from credentials). Verifiers also check digital signatures against what is known as a 'verifiable data registry': this is the blockchain where the DIDs mentioned above reside.

We pointed out in [9] that the over-centralization of data, particularly its consolidation into 'silos' by name-brand IT services and social network providers, is of increasing concern. Decentralization is an ideal starting point for storing sensitive data, including medical, financial, and other personal data -but only if security and privacy are significantly better than what can be offered by traditional centralized systems.

We identified a promising approach to widespread deployment, known as Solid, initiated by Sir Tim Berners-Lee [10, 11] . Solid aims to decentralize the Web by transferring control of data from a central authority to users, thereby allowing users to retain complete ownership of their data, which they store in what are called 'Solid Pods' -analogous to a personal web server that is hosted either locally on a mobile phone, or hosted with a cloud provider of the individual's choice, or both. The key distinction from centralized approaches is that even in the provider-hosted case, the provider's access to the data is limited by the user's preferences.

In [12] we proposed an approach combining Solid Pods and distributed ledgers, of the type familiar to the blockchain community, to facilitate the complete decentralization of data.

The key ingredients of this combination are illustrated in Fig.  2 . Our methods give users total control over their data while maintaining the integrity of the stored information through blockchain-based verification.

As in Fig. 1 , 'Holder' is the primary individual who is selfmotivated to obtain the certificate of COVID-19 immunity in order to be admitted to a workplace or other location. Holders own, manage, and control their own Solid Pods, which contain their personal data. In Fig. 2 , our Holder's Solid Pod contains a scanned image of a physical ID such as a driving license and the Holder's signed and countersigned certificate of COVID-19 Immunity certification -represented in Fig. 2 as a 'document' in which is embedded a special QR code. The Holder is free to store the Solid Pod data on his/her mobile, on a personal favorite cloud provider, or both, as shown in the 'Hosted' arrows in Fig. 2 . At any time, Holders can move or delete data, as it remains under their ownership. One-way encoded 'hashes' of the data (only a few bytes in size) are held, as shown by the dotted arrow in the upper right of Fig. 2 , on a blockchain to support independent verification. In our design, we use a 'Consortium blockchain', shown in the red circle in Fig. 2 : this is not a fully public blockchain like Ethereum or Bitcoin, but rather a blockchain shared specifically by a consortium of known providers who have signed up to the Ethics Guidelines we describe in the Discussion Section. The Open University-led Consortium blockchain is a private Ethereum network known as OpenEthereum (formerly Parity Ethereum) [13, 14] which uses a 'Proof of Authority' consensus mechanism [15] wherein several nodes can be in the mutually-agreed privileged position of being allowed to confirm transactions. This contrasts with Bitcoin and other early blockchains which use the slow and ecologically unfriendly Proof of Work, wherein massive computing power enables nodes to have a better chance of confirming transactions. This gives us the kind of distributed scalability that increases security, but without the specter of international public availability that may serve as a disincentive for individuals to participate.

Our 'COVID-19 antibody test certification' (CATC) app builds upon the Verifiable Credentials approach mentioned above, plus our own expertise developed over the past 5 years in the area of blockchain-based certification [16, 17] . The result combines the following characteristics:

• Wholly resident on the end-user's smartphone, yet usable as an optional augmentation of a plain paper printout (analogous to train e-tickets augmenting printed tickets). • Converts printed output (via next item) from a 'CATC Authority' which could be either the UK NHS or a trusted pharmacy. • One-tap scan of the above printed QR code to store antibody test results. • One-tap display of CATC evidence on request to show to employer or authority. • One-tap verification of the above by employer or authority. • CATC result is owned by the user.

• The app only reveals verifiable CATC results without revealing any personally sensitive information, at the discretion of the user. • The details of Verifiable Credentials, Solid Pods, and Ethereum blockchain are hidden: From the user's point of view, it is 'just another app'.

In the scenario below, we assume that the main 'interested party', i.e. the 'Credential Holder' or 'End User', is someone who wants to get tested for the presence of COVID-19 antibodies, with the hope of obtaining a COVID-19 Antibody Test Certificate. The actions of this person follow the 'Holder' starting in the top middle of Fig. 3 . In the top left of Fig. 3 we see the 'Credential Issuer', in this case a trusted pharmacy that is capable of carrying out the required blood test and issuing a certificate with the result of the test, in both paper and digital form. Beginning at the top right of Fig. 3 we see the actions of the 'Credential Verifier', in this case an employer in a key industry such as an NHS Hospital, keen to re-admit staff back to work after a period of illness. The sequentially numbered steps are explained below:

1. 'Onboarding' step: Prior to the blood test and subsequent steps, we assume that everyone has the mobile phone app installed and ready to go. The Issuer, Holder, and Verifier use the same app, but tap on their role at the beginning. Issuers enter pre-assigned codes to receive their DID, based on the UK Pharmacy Registry 1 , and can use the app across multiple mobile phones. Verifiers similarly download the app, but a DID is not necessary for one-way verification.

2. The Issuer needs to authenticate that the Holder is who they say they are, and thus requests that the Holder display both a physical document and a digital document as explained in step 3.

3. The Holder presents (a) a physical ID, such as a Driving License or a Passport, to be specified by the Pharmacy (this is allowed Physical Evidence as described in [8] ), and (b) a QR code 'QR 1' which is scanned by the Issuer using the Issuer's 1 Our prototype simulates the official Pharmacy registry -enquiries about API access are underway. mobile phone app. At this point there is a choice: the Issuer can (a) tap to accept the ID, in which case the Holder's photo will be 'burned' into the upcoming steps so that at the final step of verification (step 8), there will be no need to display the same physical ID, or (b) leave the Holder to display the physical ID once again at verification time. 4 . The blood test is performed, with results available within approximately 2 hours. 5. Assuming a positive outcome for this example, the Issuer prints the result and scans the printout QR code 'QR 2'. This step ensures that the Issuer retains control of a familiar testing and certification sequence.

6. The Issuer taps the app button to generate a digitallysigned test result as a new QR code 'QR 3' for transmission to Holder, who in turn scans this new QR code and with one tap digitally counter-signs it as acknowledgement of receipt, creating Holder's own 'QR 4'.

7. The Holder now has the signed and counter-signed COVID-19 Antibody Test Certificate ready for showing to any Verifier ('QR 4') -and the paper version from step 5 as a fallback.

8. The Holder can now present a provably valid certificate of immunity to the Verifier. To avoid someone else impersonating the Holder, the Holder must present not only the certificate, but also some proof of identity. There are several ways to proceed:

• If the Holder's ID photo had been 'burned' into the digital certificate at Step 3, then the Holder needs to present only the QR code 'QR 4' created at Step 6. • Alternatively, the Verifier can confirm the identity of the Holder by visually inspecting a physical ID card, and then scanning the QR code 'QR 4' to verify the certificate. • The physical printout from Step 5 is also shown in Step 8: this is always available as a fallback option in case of mobile phone loss or a preference of the Holder or Verifier. 9. The Verifier's app automatically verifies both signatures and confirms acceptance of the COVID-19 Antibody Test Certificate, at which point the Verifier can announce a successful result and safely admit the Holder, for example, to work.

Time to complete steps 2-9: approximately 3 minutes endto-end, plus duration of blood test.

For a full-scale rollout, it would be necessary to 'stress-test' our prototype, and ideally be joined by a major IT partner and Pharmacy as well as other universities, appropriate NHS departments, hospitals, and GP practices acting as participating entities in the consortium blockchain. The technology itself is inherently scalable: transactions on the consortium blockchain typically take under 5 seconds to be confirmed after entry by the Issuer, after which other steps such as verification are instantaneous. This scales well, as the architecture is inherently distributed across both servers and mobile phone apps. Collaborative possibilities are promising, as new initiatives in this niche are rapidly emerging [18] .

The app and distributed server architecture are readily scalable and applicable generically. For example,

• Workers in key industries (such as delivery drivers) could demonstrate that they are authorised to do their jobs. • People could avoid over-reliance on paper e.g. for picking up pre-ordered goods. • Utility/building/repair staff seeking access to a place of residence, even in 'normal' healthy times, could 'prove their roles'. • People could demonstrate that they are eligible to use different methods of transport or to visit public places such as libraries, theaters, or holiday destinations. • Passenger Pick-Up Drivers (as 'Holders') could be authenticated by passengers (as 'Verifiers') with a quick QR scan, independently of dedicated companyspecific apps. • Diverse loyalty cards could have a digital wallet incarnation with far less 'friction' to set up, and lower likelihood of personal information being hijacked.

New technologies bring new challenges for society. Commentators have argued (e.g. in [5] ), that certification of the type we have envisaged, even when totally private and tamper-proof, would entail multiple risks, notably: (a) disenfranchising the poor and others who do not have access to the technology or the tests, or have access but 'fail' the test, (b) motivating the disenfranchised to catch the disease deliberately in the hope of getting back to work sooner, or (c) becoming a stepping-stone for future governments to deploy the same concept either to enable or to enforce discrimination based on immunity and other arbitrary conditions. To avoid this technology becoming 'weaponized' for discriminatory purposes, we advocate several measures including optional rather than mandatory use, adherence with UK NHS Information Governance guidelines [19, 20] and oversight by an Ethics Committee. This issue is analyzed in detail in the Supplementary Materials.

The perceived need for a COVID-19 Antibody Test Certificate, if shown to be biologically robust and to conform to proposed ethical guidelines, has motivated us to develop a mobile phone app based around Verifiable Credentials, distributed storage of cryptographic public/key pairs, and the decentralized verification of data with confidentiality. This has enabled us to provide a facility that is 'just another app' from the viewpoint of the end-user, healthcare professionals, employers and other relevant authorities -thereby providing a tamper-proof record owned entirely by the end-user, and allowing the end-user selectively to reveal solely the proof of test results without surrendering other personal information, and requiring only mobile phone app downloads from everyone in the loop. This app and its secure digital certificate thus become a powerful adjunct/enhancement to traditional paper-based certification from the NHS or Pharmaceutical testing authority -and without the need for the costly installation of special 'e-ticket reader' hardware: the same mobile phone app is sufficient for the task at hand, regardless of which of the three roles is involved. Many other uses of secure and private certification via mobile phone app and distributed servers are additionally made possible. 

N this supplementary paper we first discuss the underlying premise of immunity, and then, in the Materials and Methods section, provide details of how we deal with privacy and the design of key aspects of onboarding, certification, and verification. In the Results section, we describe 'How we did it' behind the scenes. In the Discussion section, we expand on rollout and the complex ethical issues raised by the research.

The premise of immunity: Throughout most of the COVID-19 pandemic, the World Health Organisation (WHO) has advocated a 'test-isolate-trace' approach [21] . In parallel, there has been a worldwide cooperative effort to develop a vaccine [22] and to develop numerous serological tests for the presence of antibodies [23] . If immunity is strongly implied by the outcomes of these latter tests, then individuals could be allowed to get back to work, particularly in healthcare and other key areas [2, 3] . The WHO, however, has warned that the very premise of COVID-19 immunity is itself uncertain: 'With regards to recovery and then reinfection ... we do not have the answers to that. That is an unknown' [24] . Some immunologists have indeed argued that COVID-19 immunity could be very weak, because 'reinfection is an issue with the four seasonal coronaviruses that cause about 10% to 30% of common colds' [25] . Others in that same discussion argue that immunity could be valid for 'a year or two', a view shared by Male, who with Golding and Bootman has written a clear exposition on the life-cycle of infection, antibody detection, and likely immunity to COVID-19 [26] . A related challenge is the quality of the testing: test sensitivity (% positive detection for the right antibodies, so high sensitivity means few false positives) and specificity (% negatives correctly detected, so high specificity means few false negatives) are undergoing great scrutiny even as we write this [27] , and are naturally a matter of concern, because they must be sufficiently high to make the approach worthwhile. In the meantime, our research aims to find an approach to achieve highly robust certification, so that it is ready to deploy as-and-when the ongoing biological research satisfies the necessary quality criteria.

Several important guidelines concerning privacy were set out by the Sovrin Foundation, a nonprofit organisation with over 70 corporate partners including IBM, Cisco and others, which has the aim of 'driving greater interoperability and a new trust model for securely sharing private information' [28] . We adopt a variation of the three principles set out in the Sovrin.org White Paper [29], in particular modifying their item 2 as shown below. 

According to [29] , no private data should be stored on the ledger, even in hashed form, to make it future-attack-proof. Sovrin accepts, as do we, the need for pseudonymous identifiers (DIDs), pseudonymous public keys, and agent addresses (e.g. the mobile phone app endpoints) to be stored in a decentralized ledger, but in addition we offer the user a choice regarding whether and where to host personal information (mobile phone, favorite cloud provider, or both), plus the barest minimum for verification purposes, namely hashes (irreversible encodings) of private data. This has the following benefits:

• Serves as a user-storage 'vault' for later recovery in case of loss. • This 'vault' (i.e. the Solid Pod) can reside on the user's phone, or on a favorite cloud provider, or both -it is always the user's choice. • To facilitate later independent verification, it uses a blockchain with distributed nodes run by a consortium of trusted providers so that there is neither a single point of failure nor a single 'owner' even of the hash of the certificate. • Even so, it only stores a hash on the aforementioned consortium blockchain -a non-reversible but provably correct encoding of the certificate rather than the certificate itself.

Marc Eisenstadt, Manoharan Ramachandran, Niaz Chowdhury, Allan Third, John Domingue* I This is a powerful privacy-preserving and tamper-proof approach that we call Minimum and Encoded Data Storage / User's Choice. Verborgh [30] has a deeper discussion of the nature and importance of these types of emerging paradigm shifts.

It is essential that users (certificate Holders) should only have to reveal just the portions of their own personally-held private data that are relevant to specific transactions (e.g. proving that you are 18 years of age or older, in order to make certain purchases or access certain locations, but without revealing your actual age or date of birth). This is made possible by the technology known as cryptographic zero knowledge proofs [31, 32, 33] , so named because they provide, to the Verifier who wishes to know, proof of something specific (such as 'Age ≥ 18'), but with the Verifier having no knowledge of any other details, in this case actual age or date of birth. The 'secret sauce' of zero knowledge proofs, as illustrated in [32, 33] , is that a mathematical function works through a proof of some fact (such as age being greater than or equal to X, or the existence of a certain credential), in such a way that the actual steps involved in executing the proof only reach a positive outcome if the fact is true (for example, the positive outcome may require a certain number of steps to execute): so the proof is valid, but still only indirect (e.g. counting the steps executed) without touching the raw data [31, 32] .

This section describes the operations that underpin the functioning of the scenario described in the main paper. For simplicity, the processes are divided into three broad categories: onboarding, specifying how entities open their accounts and verify their identities; certification, explaining how the test is conducted followed by issuing the certificate; and verification, describing how the obtained certificates are verified.

There are three entities involved in the operations: Issuers, Holders and Verifiers. The onboarding process lets all of them install the app and configure. The configuration process for each of them is distinct and requires specific documentation.

Issuers: The onboarding of a potential Issuer (Fig. S1 ) begins with the person downloading and installing the app. The app then instructs the Issuer to complete an in-app form. Because the Issuer has the ability to test, validate and issue certificates to individuals, the app employs two factor verification for all potential Issuers. We anticipate using the API provided by the General Pharmaceutical Council, or an equivalent, to cross-check the registration and the branch information of the likely Issuer (this is simulated in our prototype -enquiries about API access are underway), followed by email verification. The former requires the person to input appropriate information into the form, while the latter asks the potential Issuer to provide a valid official email address at the company's registered domain name. The app requires the person to tap on a link that it sends to that email address to complete the registration. Data provided by the potential Issuers resides on each Issuer's Solid Pod.

Holders: The process of onboarding Holders (Fig. S2 ) involves adding an identification document such as a driving license or passport. The document number is used to generate the DID that acts as the anchor for the Holders. A potential Holder first downloads and installs the app followed by adding a photo of the identification document. This document resides in the Holder's Solid Pod. This photo document is deemed permanent (but remains on their personal Solid Pod) and once submitted, cannot be changed again. The app then provides the Holder with the DID, leaving the owner of the account ready for testing and certification.

Verifiers: Amongst three entities, the process of onboarding the Verifiers is the most straightforward. Anyone willing to act as a Verifier can download the app and start verifying. There is no need to create an account for verifying a Holder's certificate. As the Verifier submits no data, the steps of the Verifier onboarding timeline (Fig. S3) do not involve Solid Pods.

The certification process requires a Holder to visit an Issuer with the exact document used for identification at the time of onboarding. At this point there is a choice: either (a) The Issuer matches this document with the copy stored in the Holder's Solid Pod, viewing it on the app and tapping to accept the ID, in which case the Holder's photo will be 'burned' into the upcoming steps so that at the final step of verification, there will be no need to display the same physical ID, or (b) simple visual inspection of the physical ID, which means that the Holder will need to display the physical ID once again at verification time. In Fig. S4 , we see the 'behind the scenes' view of certification, including the Holder's Solid Pod with the ID.

The app is designed to work in a completely decentralized environment. Its functionalities run across the Issuer's, Holder's, and Verifier's phones as well as on the hosting servers, but does not have access to the user's data from a central database. Every time the app needs to execute an operation, it reads the data from a particular user's Solid Pod (and only with the user's permission). In Fig. S4, at (A) we see that the app reads the data (certificate) from the Holder's Solid Pod, and at (B) compares the certificate's hash with its hash on the blockchain and confirms that on the Issuer's phone display.

Once the identity is confirmed, via physical document checks and Verifiable Credentials demonstrating ownership of the relevant DIDs, the Issuer conducts the immunity test and initiates the process of generating a certificate at (C). A certificate is a set of data in RDF format 2 containing the test results and a Verifiable Credential for that successfully tested Holder. While the hash of the certificate goes onto the blockchain at (D), the original document resides in the Solid Pod (E). It is notable that neither the blockchain nor a thirdparty centralized server stores the personal data of the Holder.

The Holder reserves the right to keep a copy of the certificate in a cloud server of his or her choice. In the event of losing the phone, the Holder can retrieve the data from the cloud and restore the certificate in the regenerated local Solid Pod of the replacement phone. This certificate is visible on the Holder's app in the form of a QR code, giving an easy-to-scan option for Verifiers.

The process of verifying a certificate is an on-demand action. A Verifier cannot validate a certificate unless requested. It requires a Holder to go to a Verifier for this 2 Resource Description Framework: the W3C standard model for data interchange on the Web [34] . purpose. A Verifier can be an employer or other individual or organisation to whom the Holder wants or needs to present the certificate. Fig. S5 shows the main data flows involved in Verification.

In Fig. S5 , we see that once requested, at (A), the app reads the QR code from the Holder's phone. This QR code (which is generated from the data that itself is stored in the Solid Pod) has two components: the certificate and a URL pointing to the hash on the blockchain. At (B), the app extracts these components and at (C) locally generates a temporary hash of the certificate. Finally (D), the app fetches the hash stored on the blockchain and compares it with the local hash. The matching of the hashes indicates the validity and the authenticity of the certificate stored in the Solid Pod of the Holder. At the same time, the physical identity of the Holder can be confirmed by the Verifier by means of visual inspection of a physical ID card, if that is the route the Holder prefers, or alternatively the Holder's photo ID will already have been 'burned' into the mobile phone app certificate because that was the path elected at the time of the Holder interacting with the Issuer, as mentioned previously. The digital identity of the Holder can be confirmed by verifying the Verifiable Credential (embedded in the certificate) based on the relevant Holder DID.

The components of our implementation communicate with each other via current or in-development Web standards -Hypertext Transfer Protocol Secure (HTTPS), RDF (primarily in the JSON-LD format), Verifiable Credentials, and Decentralized Identifiers -and via blockchain protocols (specifically, Ethereum protocols). The volumes of data and computational requirements are typically small and can be handled by a mobile device (full blockchain nodes are an exception, due to the potential size of the full chain data).

The main software functions required by the implementation are as follows, and represented as lozenges in Fig. S6 : Generate QR codes: Implemented using standard libraries on a mobile phone to generate QR codes for identity and immunity certificates.

Generate hashes: Implemented using standard libraries on a mobile phone. Certificates are transformed into a canonical RDF format before hashing, in order to ensure robust reproducibility of hashes, for verification. 

The Parity library is used to communicate with our consortium blockchain. A light client library can handle read/write interactions with the blockchain without requiring a phone to maintain a full copy of the blockchain. This is shown using the thin dotted lines in Fig. S6 .

Solid takes place using the Solid REST API [35] , to read and write personal data regarding the Holder to and from their Solid Pod with user permission. This is shown in thick dotted lines in Fig. S6 , just for a few cases (one between the mobile phone app in the upper right and a cloud hosted Solid Pod; one between the locally hosted Solid Pod on the left and that same cloud hosted Solid Pod; one between the locally hosted Solid Pod on the left and the locally hosted Solid Pod on the lower right).

Holder credentials are stored in public/private key wallets containing DIDs. The authorization for an Issuer to create certificates can be represented as a Verifiable Credential issued by the relevant regulatory authority to the Issuer, which any participating party can verify. Currently we use Streetcred ID [36] to generate DIDs for the Issuers, Holders and Certificates.

Certificates are created at issue time, and their contents asserted as the Claim elements in Verifiable Credentials to be stored in the Holder's Solid Pod, with metadata describing the relevant blockchain records forming the Proof. This provides a sharable data structure which permits anyone to check its authenticity. B. How we did it, Part 2: The mobile phone app

The mobile phone app can provide all the necessary UI elements for the Issuer, Holder and Verifier to perform their actions. At the time of writing, the main functionalities of the mobile phone app include the ability to scan and generate QR codes and generate hashes for text and images. For the QR code scan and generate functions to work, the mobile phone app is packed with necessary libraries to support QR code functions and only works on smartphones with built-in camera functionality. The mobile phone app also contains the hashing libraries. As the mobile phone app needs to communicate with a server, an active internet connection is necessary for HTTPS server calls.

For speed of implementation for the current prototype, a Node.js Express server does all the heavy lifting for the app, with the functionalities explained above. This is a temporary solution, however, given the urgency of the current situation.

The architecture presented in the main paper and Supplementary Material above is all built on standard library modules, and therefore joining a consortium blockchain to help roll this out at scale is relatively straightforward, subject to suitable testing and deployment. The key hurdles are primarily Issuer credentials and the critical mass of the consortium blockchain. In the case of Issuer credentials, we mentioned in section II.B.1 about Onboarding that we use two factor authentication for Issuers, and an API provided by the General Pharmaceutical Council to cross-check registrationthis of course is subject to approval, and enquiries are already underway. As for the consortium blockchain, a strong consortium of industrial and academic partners needs to be established, after which addition of new members is just a matter of approval by the existing consortium and the distribution of training and instruction materials. Alternatively, 'parallel' consortia can be created by cloning our approach. Given related ongoing work [18] that we mentioned in the main paper, we are optimistic that critical mass can be achieved.

It should be clear from the previous sections that the concepts underlying Verifiable Credentials and Decentralized Verification of Data with Confidentiality are diametrically opposed to any kind of central data storage or 'Big Brother'style snooping and data collection, and indeed provide excellent and agreed standards for avoiding such snooping and data collection. How is it possible that no personal information is stored in a database? What about the certificate itself? That's the beauty of Verifiable Credentials, Zero Knowledge Proofs and our approach of Minimum and Encoded Data Storage / User's Choice: taken together, this combined approach offers cryptographically signed, verifiable, un-tamperable proof that the certificate being shown was really granted by a known testing authority to the person in question, even without showing the name, address, phone number or even UK NHS number of the person holding it.

Everything in this app is decentralized. Anyone wishing to abandon involvement in this kind of certification can just delete the Verifiable Credentials stored on their Solid Pods. There will be no records whatsoever, as if they had never been on the system. Deleting data on the Solid Pods will also turn the hashes on the blockchain into 'orphans' (no data pointing to the hash), i.e. the hashes will become meaningless: it is not possible to recover the original data from a hash.

This almost-too-good-to-be-true approach does raise a fresh concern, raised briefly in the main paper: the same techniques we are advocating seem to open up what we call the 'Private Verifiable Credentials Paradox': your digital mobile phone app certificate is so much more private and tamper-proof than the old paper or database versions that it could (deliberately or accidentally), be weaponized for discrimination against your fellow citizens. In other words, the problem, according to critics, is not that the architecture is too poor, but that it is too good.

Clearly, the more powerful methods of today and tomorrow have the potential to open up a Pandora's Box of Bad Use, if not by the modern democracies in which we may have grown up, then by some authority in another time or place -as the world has witnessed all too tragically in the past. We started this project with the noble aim of facilitating a way to get people back to work and heading towards recovery from the devastating impact of the Coronavirus Pandemic of 2019/2020. If COVID-19 antibodies can indeed be shown reliably to confer immunity, and the overwhelming support for the 'test-test-test' mantra of the World Health Organization continues to hold, then people are going to get tested, in overwhelming numbers, and certificates are going to be issued in one form or another.

But we are not adopting a 'give-up-and-accept-our-fate-inthe-hands-of-bad-actors' approach. Yes, a secure digital certificate could hypothetically be weaponized to a greater degree than a paper one, but the actual degree could be something of a mind-set illusion. Any certification method has such potential, and therefore, rather than casting the technology in terms of 'good vs evil' we think our approach is best considered as something that involves a trade-off between (a) the advantages of getting people back to work using good privacy-preserving fraud-prevention methods and (b) the disadvantages of discriminatory (mis)use of such methods. Our approach to this trade-off is strongly to nudge things towards (a), and therefore we propose the following concrete steps to achieve this:

• App usage should be strictly opt-in/optional: a paper certificate must always be allowed by default, just as with, say, train or airline tickets. This helps introduce the concept and technology in a gentle manner: people will ultimately decide what they prefer for themselves. • Implementations must comply with UK NHS Information Governance (IG) guidelines [19, 20] . Compliance should in principle be straightforward, because (a) in our approach, personally identifiable information is stored entirely under the Holder's control, and additionally for later verification purposes in minimal hash-encoded form on a consortium blockchain, and (b) the app allows the user selectively to present only the specific test result, with no other personal information revealed. Even so, the UK NHS IG documents provide a strong guiding framework for ensuring continuing compliance, particularly with respect to relevant EU GDPR requirements such as 'Right to erasure' and 'Right to data portability': our architecture by its very design avoids database storage of personally identifiable information, but oversight of possible misuse/abuse of this and related technologies needs to be maintained, as the next three bullet points suggest. • COVID-19 Antibody Test Certificates should only be applied to workers in healthcare and other comparable key sectors, as defined by the appropriate UK Parliamentary process (for example, the list of key exceptions to mandatory business closure during the current pandemic was specified by the UK Ministry of Housing, Communities, and Local Government), with input from an Ethics Committee mentioned next. • An Ethics Committee, comparable in scope and composition to the UK NHS Research Ethics Committees, should have oversight of actual deployment of the approach advocated herein. • The approach should be reviewed on a 3-monthly basis.

Ethical standards are a challenge to uphold, but uphold them we must, as we see this as the best way to negotiate a path towards a 'pandemic end game' in a manner acceptable to the widest possible audience.

Will such an app be suitable as part of a 'pandemic exit strategy' for helping get people back to work in key sectors? There are many issues to be addressed first, including the rigorous scrutiny and approval of antibody tests, agreement concerning ethical oversight and acceptance by the public. Our approach is intended to ensure that the procedures for creating tamper-proof, verifiable, privacy-preserving certificates are 'ready to go' while waiting for antibody/immunity tests to achieve the required state of robustness and acceptance. We believe that, just as with train e-tickets, end-users will 'vote with their feet' and deploy the app in large numbers once its benefits have been demonstrated. To take a stance against what we call the 'Pandora's Box of Bad Use', we proposed ethical guidelines at the end of the Discussion, which we believe are essential for the principled development and deployment of the prototype described in this paper.

Coronavirus COVID-19 Global Cases by the Center for Systems Science and Engineering

Immunity passports' could speed up return to work after Covid-19 BBC News

No 10 seeks to end coronavirus lockdown with 'immunity passports' The Guardian 3rd

Will antibody tests for the coronavirus really change everything? Nature (News) 18

How Does The Human Body Fight A Viral Infection?

The Guardian view on immunity passports: an idea whose time has not come | Editorial The Guardian

Aerosol and Surface Stability of SARS-CoV-2 as Compared with SARS-CoV-1

Verifiable Credentials Data Model 1.0 W3C.org

The FAIR TRADE Framework for Assessing Decentralized Data Solutions

Solid: A Platform for Decentralized Social Applications Based on Linked Data

Towards Complete Decentralized Verification of Data with Confidentiality: Different ways to connect Solid Pods and Blockchain

Fast and feature-rich multi-network Ethereum client

Transitioning Parity Ethereum to OpenEthereum DAO

What is Proof of Authority Consensus? (PoA) Staking Your Identity

The Blockchain and Kudos: a Distributed System for Educational Record

Blockchain Applications in Lifelong Learning and the Role of the Semantic Blockchain

COVID-19 'Immunity Passport' Unites 60 Firms on Self-Sovereign ID Project

NHS Information Governance

SUPPLEMENTARY MATERIALS REFERENCES

Our key message is: test, test, test' BBC News

The COVID-19 vaccine development landscape

Developing antibody tests for SARS-CoV-2

WHO officials say it's unclear whether recovered coronavirus patients are immune to second infection

If You Get Coronavirus And Recover, Do You Develop Immunity? NPR Radio/Web

How Does The Human Body Fight A Viral Infection

Global Progress on COVID-19 Serology-Based Testing

Paradigm shifts for the decentralized Web

Zero-knowledge proof

Zero Knowledge Proof of Age Using Hash Chains

Verifiable Auctions for Online Ad Exchanges

Getting Started with Streetcred ID