This post describes some of the technologies that are or may be used, as well as the ideas of improving the privacy stance of such a certificate/passports technology. Treat it as a standardisation and food-for-thoughts consideration, with a view towards privacy-preserving Covid19 health certificates or ‘passports’. It seems that covid health passports are approaching in some manner.

I am still impressed with the quick progress of the mRNA technology and how quickly we may benefit from the Covid vaccines. But it appears that our societies soon face some decisions. Entire societies had to go into lockdowns/etc, curtailing fundamental rights and freedoms. Decision-makers wonder whether vaccines could not help unlocking societal access to some aspects of life activities. Among the spectacular examples would be allowing the entrance to a plane only for the vaccinated, based on showing an appropriate proof.

Such digital certificates are interesting concepts. They may offer ways to prove the authenticity of credentials. Such as the status of test-result, of being vaccinated, the user’s identity, or both, etc. Since perhaps soon many (all?) people might be enrolled in this system, let’s have a look at the design options and some risks. Such solutions might come in the form of mobile apps or be used via the web browser.

Vaccination proofs...

Let’s put aside the speculations over the uses-in-practice. The actual and real, technical problem raised is how to reliably inform others about health status, including the status of being infected (i.e. the result of a recent PCR-RT test), or a certificate of being vaccinated -- or both. Naturally, one may create a print-out certificate on a piece of paper, much like the old-technology of vaccination books.

But it so happens that this time technology-driven solutions are mentioned from the start of the debate in the Spring of 2020.

Digital health passports or certificates, whether app-based or not, are becoming relevant. Even if merely as proofs of receiving the vaccination for Covid-19. Furthermore, apps are being created to facilitate the provision of the status to some verifiers. Some health authorities maintain their own systems already. Proofs are being given (for example, QR codes). This raises many privacy, data protection, and technology concerns. There are legitimate questions over the used standards, technologies, guarantees, risks, the need to interoperate, etc.

This is sensitive data

GDPR designates health data as sensitive, and prohibits its processing unless explicit consent is given (unless some special cases apply such as “processing is necessary for reasons of substantial public interest…”). Such apps or systems definitely process the data and therefore check all the boxes about processing sensitive data. All GDPR principles apply. Just to mention the need to conduct a data protection impact assessment (DPIA). Such a DPIA must be made with regard to technology and privacy. This is not the time for filing the standard legalese-compliance forms. I would even advise making the DPIA related to such a system public. Some people point to the risks of publishing the DPIAs, but DPIAs are being published. In some cases in the past, when even the European Data Protection Board recommended the publication of a DPIA. This of course only raises the stakes over making such a DPIA with good quality.

After these obligatory scene-setters, let’s return to the technology needs of health passports. In the abstract, at a very high level, not a big amount of information needs to be stored or processed. We may imagine the following:

  • For tests, the type of the test (PCR-RT?), the result, and the date
  • For vaccination status, the type of the vaccine (vendor, etc.), the vaccination date

The passport is simply a type of credential. It’s of course linked to the user’s identity (separate data point). One would wonder if the identity must always be shown to verifiers of the passports. If a privacy-preserving system is well designed, it could prove the health status, in ways not needing to disclose the identity. Such systems exist.

Use open standards?

One particular way to design the data representation is to use the full spectrum offered by the Fast Healthcare Interoperability Resources standards stack. It is very likely that the practical use may be much simplified. Targeted and consciously limited (minimisation!) practical deployments do not necessarily need to deploy a big framework to the task. After all, the ‘health passport’ might be as simple as signaling the status and validity of the vaccination and/or of the PCR-RT test result. At the end of the day, this is a very simple setup, potentially involving the identity, identifier, the status or result (of vaccine or test), the date, perhaps the type (of vaccine used), and the date. Issued by a standard authority, and verified by interested parties (i.e. at the airport?). After realizing this, one may attempt to think about designing this system with privacy. There are a number of interesting cryptographic techniques

Security and privacy must  be paramount in such a sensitive system, especially if intended to be in mass use. Sensitive health status is processed. Some data is disclosed to the verifiers. As a result, control over this data could be lost. Of particular attention should therefore be the accountability (who has the data and how it’s used?). Especially knowing the true examples of the ‘vilification’ of the people who unfortunately happened to contract the disease with this information being disclosed in some ways.

Another issue is consent. Users would always need to mediate and explicitly allow or deny the provision of their data to the verifiers. It is imaginable that it could still potentially be possible to deidentify some of the data quite well, design-permitting. Data minimisation may be simply realised by sending the smallest amount of data possible. So sometimes without the data about the user identity included, sometimes without the date of test/vaccination (just the proof of its validity).

Privacy-preserving certificates?

The simplest privacy-enabled information flow (use case) or the scenario of use may be as follows. You swipe the medical passport near the reader at the airport (or something) and the reader checks that the vaccination status is acceptable (done, and valid). So proving with cryptography that something is valid, without necessarily offering the user identity, would be useful. Some form of verifiable credentials or a cryptographic commitment scheme facilitating anonymous credentials. While one may imagine the use of other technologies or cryptographic techniques, I decided to focus on a single one.

Fortunately, there are some notable ones like this paper from 2001 shows (or some other similar).

credential system is a system in which users can obtain credentials from organizations and demonstrate possession of these credentials. Such a system is anonymous when transactions carried out by the same user cannot be linked. An anonymous credential system is of significant practical relevance because it is the best means of providing privacy for users

Or this:

We define and propose an efficient and provably secure construction of blind signatures with attributes.

Or others.

This may be  the thing to the task. The user can prove the status - and nothing else needs to be shared. There is no way to link it back to the user, at least in some use cases, leaving no trace. Nothing needs to ever be on any public blockchains. In such a system you still need authority. The ultimate source of trust. While I can understand the motivation to seek decentralised solutions, even in this case someone still needs to provide the source of trust (and this is not that simple, especially when  adversaries are included in the risk model). In general, such certificates, or credentials, must be 1) issued by some authority, 2) stored somewhere, 3) used to create a proof of something, 4) being verified when in need.

I imagine that some of the mentioned stuff may well be used to create a fixed construction, with privacy built-in. The apps, the verifier applications, the infrastructures.

Source of trust

Someone needs to maintain and guarantee such a system, to constitute the source of trust (that would be issuing and validating the check of certificates). The simplest solution here is to delegate this task to the laboratory or medical authority. There are also proposals of open standards that offer some of the functionality of verifiable credentials in practice. The use of these should be very simple (what a coincidence that this standard is ready now, isn’t it). This technical standard introduces interesting functionalities, though at times it subscribes to the wishful-thinking trust model. For example:

"termsOfUse": [{
"type": "HolderPolicy",
"id": "",
"profile": "",
"prohibition": [{
"assigner": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"assignee": "",
"target": "",
"action": ["3rdPartyCorrelation"]
"proof": [ ... ]

In the example above, the holder (the assigner), who is also the subject, expressed a term of use prohibiting the verifier (the assignee, from using the information provided to correlate the holder or subject using a third-party service. If the verifier were to use a third-party service for correlation, they would violate the terms under which the holder created the presentation.
This feature is also expected to be used by government-issued verifiable credentials to instruct digital wallets to limit their use to similar government organizations in an attempt to protect citizens from unexpected usage of sensitive data.

This means that the verifier of the credential (such as the health passport status) is expected to voluntarily abide by these rules. It is of course not a hard limitation. The verifier of the credentials may still try misusing the data -- if they so choose. One particularly interesting feature to maybe counter this risk would be the use of zero-knowledge proofs to prove that the user has a credential, without revealing any details of it. This would be more privacy-preserving. This specification is also a bit worrying at ties -- it seems to conflate anonymity and pseudonymity, which are two different matters. Additionally, it lists an impressive number (17) of privacy risks relevant to the use of this solution. What this means is that any practical solution should assess the risks seriously. This should be reflected in the data protection impact assessment. But please note that proofing the application/client is not enough. The whole system must be vetted.

Function creep or a global ID system?

In general, such standards allow the presentation of arbitrary credentials. Assuming that digital health passports proliferate, it might in the future be potentially possible to extend their functionality to “offering proofs” also other things. So this is a risk of function creep on the design layer. Digital health passports must be standardised, defined, and advertised as a thing that is doing one single thing. To avoid the risk that someone will want to use it in the future as a, say, proof of having a driver's license. Or, why not, evolving it to be a mandatory global ID system. This brings us to the inconvenient aspect. To some extent, a health passport would already constitute a global ID system. The vaccination/test status is linked with the identity. This is a simple technical fact. There is little way around it.

This brings us to profiling risks. These should already be on the radar of potential privacy misuses.

Privacy-by-design considerations may include the delinking of identity from the credential, but also perhaps the use of the credential in ways that would be unlinkable. This would be the highest data minimisation effort imaginable. This may be done using selective disclosure (using zero-knowledge protocols?).

Voluntary or not?

Here comes another batch of inconvenient news. Would such certificates be voluntary? Likely not because we have a huge power imbalance here when States already enact mandatory limits on fundamental rights and freedoms.

The core issue is whether passports/certificates would be expected to function as means to unlock access to some of these limited freedoms to their holders (the citizens), for example to the ability of more seamless movement or travel. If such means as passports turn out to be required by, say, airlines, employers,  medical doctors - what real choice would there be? Not to mention that in some countries there already are registers of vaccinated, so people are being enrolled in some system anyway. What is left is the proof system. But the fundamental realisation should be that such systems might be hardly voluntary anyway, and then what? The part that may still be voluntary is how the system is in use, for example, the choice of disclosure of some information to some parties. In the end, the big elephant in the room - a problem - will be the processing of this data, and the potential future use in profiling. These are difficult decisions to make.

Another big challenge of privacy-proofing is interoperability. So how to guarantee this system works on an entire country scale, or a block scale (European Union), or a world scale. This will be complex to solve, but I leave this for now.

Scientific grounds considerations

Another elephant in the room. It seems that there is now a lack of scientific evidence that vaccinated people do not contribute to the transmission of the disease. More research is needed to understand this. As such, some of the ‘privileges’ granted to the vaccinated may be hard to reconcile with this lack of scientific proof. Unless of course we accept the risk and allow the entrance to some places (i.e. a plane?) to only those vaccinated.

Another issue is it is unclear for how long is the vaccination valid for. There is no data available as of today, but it is expected that the immunity will not be long-lasting (as with other coronaviruses). It makes little difference for the health passport technology, outside the need to track the date of the vaccination and possibly immunity tests. Since it is unclear what would be the validity of the vaccine, if one would use verifiable credentials then the use of the fields such as ‘expirationDate’ or ‘validUntil’ would make little sense. Scientific backing is important - it is the pillar to guarantee that the actions taken are justified. This is part of the proportionality assessment (are the means taken proportional well chosen to the task? Do they actually achieve the desired outcome?).


Lastly, when you deploy a certificate system that grants some privileges, counterfeit material will be a problem. Such fake certificates are already a growing problem but in general, such systems guarantee unforgeability (caveat about trust).

Health passports might change user habits at a scale

The systematic and broad requirement to use such an application would definitely familiarise many people with the technology of digital identity proofs. In a similar way, initial Covid19 consequences resulted in a massive uptick of contactless payments in use. As a consequence, user habits might change permanently.


Certificates or health passports are interesting concepts. Their design and operation should involve important considerations related to privacy, data protection, but also other fundamental rights and freedoms. These are types of impact assessments.

In the end, societies need to understand the long-term implication and potential civilisational consequences.

Did you like the assessment and analysis? Any questions, comments, complaints or offers for me? Feel free to reach out: