This document describes a system for “validating” claims in W3C Verifiable Credentials. Validation, for this document, means ensuring that a claim conforms to a set of business rules. (In our terminology, verifying a claim simply means that the signature checks out).

The motivation for this proposal is that even if we standard claim types, we still have to deal with

  • multiple coding systems for describing vaccinations (EU, Canada, US…)
  • different passport types: Vaccination, Tests…
  • rules being changed over time by jurisdiction

Ideally we’d be able to update these business rules without pushing…

In rough chronological order. Draw your own conclusions.

  • Bronze over Leather
  • Horse over Farmers
  • Iron over Bronze
  • Guns over Iron
  • Steam over Sail
  • AC over DC
  • Cars over Horses
  • Cars over Pedestrians
  • Tanks over Trenches
  • Tubes over Relays
  • Transistors over Tubes
  • ICs over Transistors
  • Calculators over Slide Rules
  • CD over LP
  • Cassette over 8-Track
  • VHS over Betamax
  • VHS over Laserdisk
  • TCP/IP over ISO/OSI
  • RFC822 over X.400
  • Ethernet over TokenRing
  • The Web over Xanadu
  • Modem over X.25
  • MP3 over Cassette
  • PC over VAX
  • HTML over SGML
  • HTML over NAPLPS
  • HTML over Minitel
  • HTTP over FTP
  • DVD over VHS
  • XML over SGML
  • Google over Altavista
  • USB over Firewire
  • JSON over XML
  • REST over SOAP
  • BluRay over DVD
  • Google over Classifieds
  • Twitter over RSS
  • Streaming over BluRay
  • Facebook over Privacy
  • GraphQL over REST

As I was writing this paper “Vaccination Passports — Survey” one unusual thing stood out: more or less every single system claimed they’re using W3C Verifiable Credentials (W3VC). Not how they’re using it, but that they are using it. It’s not even clear for some of them if they’re using HTTP or TCP/IP (kidding, sort of) — but every one of them says they’re using a somewhat esoteric W3C spec.

W3C Verifiable Credentials are (in their own worlds) “a standard way to express credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable”. A credential…

I was listening to Oscar Santolalla’s excellent Let’s Talk About Digital Identity podcast the other morning — I believe this one, but won’t swear on it — and an interesting claim came up: that we could verify someone’s university graduation claim using the blockchain.

Why should we do that?

If you were to go to the (entirely hypothetical) URL and it told you I am a MUN graduate, and it was digitally signed by MUN, with a X.509 certificate chain that rooted at the Government of Canada, would this not be:

A Verifiable Credential is a way to “express [credentials] on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable”.

The W3C spec seems somewhat loosey-goosey around the edges, but there’s a fair bit of consensus in the Covid Credentials world that this is the way to go.

Note we added a new Credential Type called vc:HealthCredential. I've opened an issue on W3C, but who knows whether this will go anywhere - they don't seem to have the types nailed down, though Health/Medical are mentioned in their use cases.


All the verifiable credential semantics are indicated as…


The official version of this document is on GitHub.

What is an Information Passport?

An Information Passport is a signed digital document that makes some claim, for example “So and so was Vaccinated against COVID-19 on a certain date”. If the signature matches the public key of the digital document, the document is Verified. If the Claim made in the document checks against a set of (use-defined) rules and the “fingerprint” of the public key is known, we say the document is Validated.

A Vaccination Passport is an Information Passport that provides digital proof of a Vaccination. …

Image from The Noun Project

This document describes a compatible Type for a Vaccination Record, that is:

Likely this will be extended to include “by a particular doctor / nurse / health practitioner”, though that is not critical for what we are trying to accomplish right now.


"@type": "schema:MedicalRecord-Vaccination",
"schema:name": "David P Janes - Moderna COVID-19 Vaccine",
"schema:patient": <Patient>
"schema:permit-healthCard": <HealthCard>
"schema:location": <HOSPITAL>,
"schema:primaryPrevention": <VACCINATION>,
"schema:treatmentDate": "2021-01-06",

which fully expanded looks like

"@context": {

Image from The Noun Project

This is a straight instantiation of schema:Patient.

It would be nice if there was a straight forward way to indicate data has been redacted, but we’re OK with this for now.


"@type": "schema:Patient",
"schema:additionalName": "P",
"schema:birthDate": "••••-••-01",
"schema:familyName": "Janes",
"schema:givenName": "David"

Image from The Noun Project

This is a straight instantiation of schema:Hospital. Nothing clever is needed here at all, except that we recommend you use codes for Country and Region (if possible).


"@context": {
"schema:": ""
"@type": "schema:Hospital",
"schema:name": "General Hospital",
"schema:address": {
"@type": "schema:PostalAddress",
"schema:streetAddress": "21 Wingbat Way",
"schema:addressCountry": "CA",
"schema:addressRegion": "BC"

The ConsensasRSA2021 is based on W3C’s Linked Data Proofs. The core difference is that ConsensasRSA2021 does not depend on Linked Data or JSON-LD, though fully compatible with it.

This “official” version of this article is here:


Canonical JSON

Canonical JSON is defined by RFC8785. It ensures that given any JSON message, we can create exactly the same representation.

QName Compacted JSON-LD

The proof SHOULD (maybe MUST?) be encoded using QName Compacted JSON-LD.


Javascript Object Signing and Encryption is used for JSON Web Signatures RFC 7515.

Also see Node.JS implementation.


Signing Algorithm

  • ensure “@context” contains "security": ""
  • remove security:proof from message
  • make a canonical version of message

David Janes

Entrepreneur. Technologist. CTO / Co-founder of; founder Discover Anywhere Mobile.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store