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

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

In rough chronological order. Draw your own conclusions.

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

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