I’ve been meaning to post about verifiable credentials for a while now. Having worked on the ins and outs I thought it would help a lot of individuals out there to share my experience and methods.

So I sat to put thought to paper and had the awesome idea to use the very current situation of the COVID vaccine as an example. A patient will get the COVID vaccine from their doctor and will receive a verifiable credential that can be presented and verified.

Decentralized Identity

To begin with, the patient needs to have a decentralized identity that will represent them digitally. Decentralized Identity or DIDs are created using a public/private key pair similar to cryptocurrency addresses.

These addresses can be generated using a 12/24 word seed which the patient will keep secret. Using this seed, a public/private key pair and an address can be derived. This is usually done with an app or a browser wallet such as MetaMask. Here is our patient’s address:

0xee21b6289624e98d8712cc810fcf608c5d72d2a6

It looks like an Ethereum address because it is! The patient could use this address to store ether, tokens or interact with smart contracts.

To create a decentralized identity identifier, we prepend did: to the address.

did:ethr:rsk:0xee21b6289624e98d8712cc810fcf608c5d72d2a6

This is the digital decentralized identity of the patient. They can prove they are the owner of this DID by signing a piece of data with their private key! This example is using the RSK blockchain network, but it doesn’t have to be.

Declarative Details

Now that the patient has a DID, the next step in verifiable credentials is the individual declaring information about themselves. In our example, the patient will declare their name and their government Id number.

name: Jesse Clark
id: 1234567890

Now they are ready to be vaccinated!

At the Doctor’s Office

After receiving the shot from their doctor, they present their declarative details. The doctor’s office should verify the details are correct against a government-issued id. Better yet, they could also verify the patient’s identity against a verifiable credential issued from the government, but we’re getting ahead of ourselves!

The doctor or the doctor’s office would also have a DID Identifier created in the same fashion as the patient’s.

Doctor’s DID:

did:ethr:rsk:0x2958042047eA3D67FFF3ec45d0E222349EA1a044

The patient’s declarative details would be combined with data vaccine (i.e. manufacture, lot number, shot #1, etc). The doctor signs this combined data with their private key and creates a verifiable credential.

This credential is represented as a JSON Web Token (JWT). Because of the cryptographically signing process, if you change any character in the JWT, the entire string is invalid. You can test decrypting this process by using jwt.io, scroll down to Debugger.

Raw Credential (JWT)

eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NksifQ.eyJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSJdLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiVmFjY2luZVJlY29yZCJdLCJjcmVkZW50aWFsU3ViamVjdCI6eyJuYW1lIjoiSmVzc2UgQ2xhcmsiLCJpZCI6MTIzNDU2Nzg5MCwidmFjY2luZU5hbWUiOiJQZml6ZXItQmlvTlRlY2ggQ09WSUQtMTkgVmFjY2luZSIsInNob3ROdW1iZXIiOjEsImxvdE51bWJlciI6IjU5MjY3LTEwMDAtMDEifX0sInN1YiI6ImRpZDpldGhyOnJzazoweGVlMjFiNjI4OTYyNGU5OGQ4NzEyY2M4MTBmY2Y2MDhjNWQ3MmQyYTYiLCJuYmYiOjE2MTAzNjQ4NzksImlzcyI6ImRpZDpldGhyOnJzazoweDI5NTgwNDIwNDdlQTNENjdGRkYzZWM0NWQwRTIyMjM0OUVBMWEwNDQifQ._7ZAY4qg_BDM2JtMufrwHS6_6utfTF4IdtYKazta4-sBOOx6UcviTVbFiyn9fe4N7adwxcy2YsnkK5rfP_dC7w

Decoded Credential

When decoded, it renders this:

{
  "vc": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1"
    ],
    "type": [
      "VerifiableCredential",
      "VaccineRecord"
    ],
    "credentialSubject": {
      "name": "Jesse Clark",
      "id": 1234567890,
      "vaccineName": "Pfizer-BioNTech COVID-19 Vaccine",
      "shotNumber": 1,
      "lotNumber": "59267-1000-01"
    }
  },
  "sub": "did:ethr:rsk:0xee21b6289624e98d8712cc810fcf608c5d72d2a6",
  "nbf": 1610364879,
  "iss": "did:ethr:rsk:0x2958042047eA3D67FFF3ec45d0E222349EA1a044"
}

Decrypt it yourself using jwt.io.

Under credentialSubject is the declarative details and the vaccine information. Here are the other details:

• sub is the subject, i.e. the patient,
• nbf “not valid before”, which in this case is when the shot was given. This is represented in seconds since January 1st, 1970. 1610364879 is Monday, January 11, 2021 at 1:34 PM (EEST)
• iss: “Issure”, the did of the issuer, i.e. the doctor

The credential is given to the patient and it will be their responsibility to keep it safe. Alternatively, a database of credentials could be created to store this information as a backup. This goes beyond the scope of this introduction.

A few weeks later the patient goes back to their doctor’s office to get the second vaccine shot. The process above happens again, and the patient now has two credentials from their doctor. One for the first shot and one for the second. Both are cryptographically signed by the doctor and timestamped.

Raw Credential #2 (JWT)

The credential from the second shot.

eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NksifQ.eyJ2YyI6eyJAY29udGV4dCI6WyJodHRwczovL3d3dy53My5vcmcvMjAxOC9jcmVkZW50aWFscy92MSJdLCJ0eXBlIjpbIlZlcmlmaWFibGVDcmVkZW50aWFsIiwiVmFjY2luZVJlY29yZCJdLCJjcmVkZW50aWFsU3ViamVjdCI6eyJuYW1lIjoiSmVzc2UgQ2xhcmsiLCJpZCI6MTIzNDU2Nzg5MCwidmFjY2luZU5hbWUiOiJQZml6ZXItQmlvTlRlY2ggQ09WSUQtMTkgVmFjY2luZSIsInNob3ROdW1iZXIiOjIsImxvdE51bWJlciI6IjU5MjY3LTEwMDAtMDIifX0sInN1YiI6ImRpZDpldGhyOnJzazoweGVlMjFiNjI4OTYyNGU5OGQ4NzEyY2M4MTBmY2Y2MDhjNWQ3MmQyYTYiLCJuYmYiOjE2MTIxODA0ODMsImlzcyI6ImRpZDpldGhyOnJzazoweDI5NTgwNDIwNDdlQTNENjdGRkYzZWM0NWQwRTIyMjM0OUVBMWEwNDQifQ.JgmJLSqWc6Qva082zQPrrCW0SbGmCKoIDJJPTxoCUJYg_QonGx0pch_ErnXk-GF9BOtomYf_9wQ6fBzdlfqmMw

Decoded Credential #2

{
  "vc": {
    "@context": [
      "https://www.w3.org/2018/credentials/v1"
    ],
    "type": [
      "VerifiableCredential",
      "VaccineRecord"
    ],
    "credentialSubject": {
      "name": "Jesse Clark",
      "id": 1234567890,
      "vaccineName": "Pfizer-BioNTech COVID-19 Vaccine",
      "shotNumber": 2,
      "lotNumber": "59267-1000-02"
    }
  },
  "sub": "did:ethr:rsk:0xee21b6289624e98d8712cc810fcf608c5d72d2a6",
  "nbf": 1612180483,
  "iss": "did:ethr:rsk:0x2958042047eA3D67FFF3ec45d0E222349EA1a044"
}

Decrypt it for yourself

The differences here is that the not valid before date is different: 1612180483 is February 1st, 2021 at 1:54PM (EEST), and the shot and lot number are now 2. This is an example, with a real vaccine the lot numbers would probably be very different!

Verifiable Presentations

In our example, the local government requires all travelers to have both shots before traveling and our patient is has now decided to fly to the Maldives for a well deserved luxurious break.

At the airport, the traveler goes to check-in and is requested to prove they are vaccinated. Rather than showing the credentials issued by the doctor, they can create a Verifiable Presentation that combines both credentials. This process requires the traveler to sign the credentials which creates a presentation of the two credentials. The process also adds an extra layer of security. The traveler adds an expiration time of 2 minutes to the presentation so it can’t be stolen or reused by someone else.

This presentation, which is a JWT, is transmitted to the airport official to verify. Presentations can be quite large so Bluetooth or NFC is a good way to transmit. A single QR code can’t hold all the information, but multiple could but wouldn’t be user friendly.

The airport official now has the verifiable presentation and can see the doctor’s DID, the vaccine lot number, the date, and where it was administered. Because of the cryptography involved with the signing process by both the doctor and patient, the airport official can ensure the credential is valid and has not been tampered with.

The airport official does need to check two things:

1. The issuer DID (aka the Doctor) is a known DID associated with a doctor.

This could be accomplished with a list of doctors and linked to their DID. It could be kept in a centralized database or better yet, could be stored on a public blockchain. The Government, with their known DID, through a smart contract, could publish a list of official Doctor’s DIDs.

2. The traveler that is presenting the verifiable presentation is in control of the public/private keys for that DID

The second thing they need to check is that the DID belongs to the traveler. In the very beginning, the patient declared their details which are cryptographically signed into the presentation. The airport official could match this to the traveler’s passport.

You could also imagine where the Government issues IDs via verifiable credentials in a similar approach as the doctor. In that scenario, the traveler would go to a government office, present their declarative details and the Government would verify them. The traveler receives a verifiable credential stating they are the owner of this DID. In this case, the traveler would need to prove to the airport official that they are in control of the public/private key the DID is associated with. The airport could give the traveler a value and ask them to sign it with their private key. If they are able to do this, then it shows they are in control of the DID.

If the issuer DID belongs to a doctor that is trusted to administer vaccines, the traveler is allowed to board the flight. Before they know it they are sipping margaritas from a coconut!

In closing

This was a very simplistic example of how verifiable credentials could be used to present proof of a patient receiving a vaccine. You could imagine multiple Government and Private organizations issuing various verifiable credentials could be combined.

Here’s to margaritas in coconuts, cheers!

Photo by Daniel Schludi on Unsplash

• blockchain
• credentials