In November 2015, a group of internet security experts met in San Francisco to discuss the future of trust mechanisms on the internet. This event was known as the Rebooting Web of Trust (RWOT) design workshop.
Participants were motivated by a desire to redesign the trust frameworks which had been in place for 25 years prior, known as Pretty Good Privacy (PGP). Email addresses, usernames, and website domains were (and still are) borrowed or "rented" through DNS, X.509, and social networks. What the participants hoped to do was to create a fully decentralised Public Key Infrastructure (DPKI) that would return control of online identities from the siren servers of Apple, Facebook, Google and others to the individual entities they belong to.
Rebooting Web Of Trust meeting in Barcelona, March 2019
In the years since 2015, RWOT events have provided a regular forum for discussion of decentralised identity, and this work eventually led to efforts to standardise. The work was formalised by the World Wide Web Consortium (W3C), an international community where member organizations, a full-time staff, and the public work together to develop Web standards. The first standard to come out of this work was the Verifiable Credentials Data Model, the initial draft of which was published in August of 2017.
Need For A Data Format
When individuals are in control of their digital identity and are no longer reliant on trusted third parties, they face an immediate challenge in sharing selective portions of their identity. Supposing that a bank requests proof of your assets before granting a loan, how would you provide this proof in a manner that it did not disclose too much but just enough to satisfy the request. Additionally, how would you assure the relying party that your asset proof is reliable without performing additional inquiries?
Cryptocurrency was young, but contributors to the standards effort were well aware that a blockchain can act as a decentralised registry, and that by retrieving the hash of some document, then comparing it to the hash generated from a copy, a relying party can easily verify if the copy is authentic. Conversely, issuers can create an attestation document, record its hash on a blockchain, and this establishes authorship, provenance and immutability of claims made in the document. The original document does not get stored on the blockchain, only the hash, which is just a string of 64 characters. So privacy is not compromised.
This realisation led to the killer app which is Verifiable Credentials (VCs). Implementers can rely on a standard definition for VC documents and then create their own certificate issuance applications and verification services. This opened up the market for a number of first generation certificate issuance services such as the BlockCerts project let by MIT.
The really wonderful thing about VCs is that the relying party can verify a document cryptographically, without referring back to issuers. This means that employers don't need to check with educational institutions. Medical authorities can rely on personal medical records without checking with the hospital where a patient was originally treated. This was a big breakthrough!
The VC ecosystem - relying parties don't need to query the issuer.
Anatomy of a Verifiable Credential
JSON files are human-readable, but such a raw document is not user-friendly. What users want to see is a digital representation which looks similar to the paper documents they are replacing. This can be achieved by creating a graphical overlay, referred to as a 'template' or 'layout', and populating it with data from the VC. To make this compound document verifiable, a QR code is overlaid onto the layout, and when scanned it will return the digital VC.
Verifiable Credentials Data Model is now a W3C standard. VCs can represent information found in physical credentials, like a badge or a license, or new things that have no physical equivalent, such as ownership of a bank account. VCs are extensible. Any new property can be added to VCs, as determined by the issuer. However one limitation hindering adoption of VCs is that there is no standard for verification methods.
In this document we use the terms 'certificate' and 'credential' interchangeably.