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 https://claims.mun.ca/KOP4UI4YK4 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.
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. …
This document describes a schema.org 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.
"schema:name": "David P Janes - Moderna COVID-19 Vaccine",
which fully expanded looks like
This is a straight instantiation of
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.
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).
"schema:name": "General Hospital",
"schema:streetAddress": "21 Wingbat Way",
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: https://github.com/Consensas/information-passport/blob/main/docs/Signing.md
Canonical JSON is defined by RFC8785. It ensures that given any JSON message, we can create exactly the same representation.
The proof SHOULD (maybe MUST?) be encoded using QName Compacted JSON-LD.
Also see Node.JS implementation.