Proof of Vax

More than you've ever wanted to know about how "vaccine passports" actually work in the wild, how they're powered by FHIR, and why trust is still a challenge

Pre-script: I’m one of the co-founders of Automate Medical. We recently published an open letter on health data. We’re building an open source FHIR tools to make health data interoperability easier than ever before and we just released a set of TypeScript definitions for FHIR. FHIR is the future of health data and Automate Medical builds FHIR tools.

Any especially popular topic becomes difficult to speak about, if only because you have to compete with all of the other voices. Imagine trying to write anything about vaccines. Take vaccine “passports”. You’ve heard the politicians speaking about them: promotion as a means to “some kind of normal”. Concerns from privacy regulators. How realistic are these ideas? Is this another example of political over-imagination? Why do people talk about it inevitable terms?

Let’s take a step back from the normative or, in Andrew’s words, the Jurassic Park question. Instead, let’s take a look at what’s being proposed in plain terms.

You may be surprised to learn that there are a number of specific, publicly accessible implementations of what we might more accurately call vaccine credentials or what I’ve been calling “proof of vax” (surely I’m not actually the first to think of this).

New York’s Excelsior Pass is an example “proof of vax” implementation based on the SMART Health Cards framework we will discuss.

Vaccine credentials pre-date the current pandemic. Proof of vax is an existing travel requirement in many circumstances. Domestic political struggles will play out differently everywhere, but international travel seems certain to require some kind of proof in the future.

There is a distinctly new degree of interest in digital vaccine credentials. Perhaps even cryptographic vaccine credentials. In general, the idea is to cryptographically sign a structure representing some facts of vaccination. The signer may be a known public health authority or not. Existing interoperability challenges, like those highlighted in Automate Medical’s recent open letter on health data, are sure to be a major factor in penetration.

Let’s dig into the technical aspects of how digital “proofs” of vax work.

What is a vaccine credential and who defines it?

Vaccine Credentials Initiative (VCI) is a public/private partnership with major players like MITRE, Microsoft, Epic, Cerner, and others. Their core mission is to produce vaccination credential standards and definitions. They produce two:

1. The SMART Health Cards Framework Implementation Guide based on the World Wide Web Consortium (W3C) Verifiable Credential and Health Level 7 (HL7) SMART on FHIR standards, and;

2. The SMART Health Cards: Vaccination & Testing Implementation Guide.

These efforts are laser focussed on generating implementation artefacts for systems that need to deal with patients, health care providers who distribute vaccines, and interested verifiers.

They’re also relatively easy to understand as specific proposals and protocols.

FHIR is front and center

The core piece of data in a SMART Health Card is a FHIR Bundle (a list of FHIR Resource documents) inside of a Verifiable Credentials structure influenced by the W3C working group design of the same name. In this framework, there are three distinct actors involved: credential issuers (health care providers), credential holders (you and me), and credential verifiers (the proof requesters).

This implies two very important features:

1. The actual data model for the immunization event is a FHIR Resource (encoded as a JSON document)

2. The FHIR Resources are cryptographically signed with credentials that can be verified (this is the Verifiable Credentials piece)

There’s actually an entire working end-to-end demo c19.cards, but it’s only really helpful as a way of understanding the end-user workflow. It doesn’t really help us make technical sense of what’s going on. The simplest description might just be that Health Cards are a set of JSON-formatted documents signed with a public-private key-pair. But what does that mean?

Let’s walk through it.

You show up to a health care provider and receive a vaccine. The health care provider here is the “issuer” of the vaccine credentials.

The issuer generates their own public-private key pair. Then they generate a FHIR representation of the immunization record event. That looks something like this:

A FHIR representation of an Immunization record

This is fairly readable even to a non-technical audience. The vaccineCode field refers to a CodeableConcept and specifically to CVX#207 and CVX#208 for the current Moderna and Pfizer-BioNTech vaccines. We can also read values like patient (which in this example is a reference to another resource) and details like the date of the immunization and the health care provider who performed it.

Next, these FHIR documents are inserted into a Verifiable Credential structure. This JSON-encoded document looks very similar to a JWT (JSON Web Token), containing a reference to both the issuer and a valid “from” time.

The entire bundle of Verifiable Credentials structure plus FHIR resources is encoded via JWS (JSON Web Signatures) compact serialization. Critically, the issuer uses the private portion of their public-private key pair to sign this structure. This results in a final “health card” to present to the holder (you and me) that is both: 1. verifiable in the sense that another party could validate that, yes, a particular issuer really did create this immunization record, and 2. compact enough to be represented as a QR Code (they have practical data limits).

You scan the QR code presented to you at the end of your vaccination, and save it to your mobile wallet, or sync your wallet with the hospital system later.

There’s an end to end Jupyter notebook walking through the code necessary to do this all end to end: SMART Health Cards.ipynb.

“Passport please”

Now that you’ve got your proof of vax, you can use it by presenting it to a verifier. A verifier is any party who asks you to show proof of vaccination.

The verifier uses software to read the data represented in the QR Code that you’ve kept safe in your mobile wallet. They read out the JSON Web Signature compact data structure. They validate that the actual content of Verifiable Credential really is an immunization record. Then, they validate that the signature itself is correct and could have been derived only from the private key corresponding to the public key of the issuer.

There’s no network requests or database connections here. The verification can happen very quickly.

What does this actually verify though?

In this scheme, there’s no central co-ordination server or database of all of the vaccine credentials ever generated. Anyone can create a technically valid immunization record payload, and represent it as a QR Code. What is impossible to forge is the signature of a particular issuer.

Further, there’s a difference between a “known valid” issuer and an “unknown valid” issuer. A hospital or health care provider from a foreign country for example may produce both technically valid and actually true immunization records. But without knowing that that particular hospital owns this particular issuer key, a verifier can’t know if a particular record is valid and real or valid and fake.

This is the double edged sword of not needing to co-ordinate on generating the records. How do we know to trust a particular issuer or not if anyone can be an issuer?

Issuer registries will have to emerge in order for verifiers to have confidence that particular issuers are trustworthy or not. But how will different state-level actors co-ordinate internationally on this problem? Surely someone will attempt a root certificate scheme, but health data could become a national security issue for many.

This presents an interesting paradox though, because it means that really only domestic co-ordination and use will be immediately tractable. If we can’t co-ordinate on ways to trust issuers, your proof of vax may really be no better than a paper document. Was it worth the trouble?

---

Thanks to Andrew Arruda, Thomas Hamilton, and Jason Dowlatabadi for reading drafts of this.

PS.: I’m one of the co-founders of Automate Medical. We recently published an open letter on health data. We’re building an open source FHIR tools to make health data interoperability easier than ever before and we just released a set of TypeScript definitions for FHIR. FHIR is the future of health data and Automate Medical builds FHIR tools.