The last blog in this series discussed DIDs and their importance to a decentralized ecosystem. DIDs are entirely functional on their own and genuinely remarkable––unfortunately, they are still semi-limited in their use cases. Introducing verifiable credentials (VCs) is where the utility comes into play.
What is a verifiable credential?
VCs are simple documents that make some claim about an entity. An entity can be a person, organization, physical or digital thing. A claim is a statement of fact about the entity. The technical terms can be confusing because usually, we would not speak like this.
Opening your wallet is the best explanation of what a verifiable credential is. Pull out an ID, driver's license, insurance info, or credit/debit cards––all of these documents are verifiable credentials. They are not digitized, but they are credentials. More often than not, they have security features, like holograms, unique printing methodologies, or security codes to help ensure their authenticity.
The other difference between these documents and verifiable credentials is the personally-identifying information. This info is a problem because it can lead to identity theft or vulnerability to leaking compromising personal info. Decentralized identity solves this problem by adding anonymity to DIDs, and by not storing the information publicly on the blockchain.
How they work
The way VCs work is that first, a connection between two parties is established . After the link is made, then VCs can be issued––VCs are not usually issued randomly. A credential will have information on it and potentially personal info––depending on the type of credential and who is issuing it. VCs are unrestrictive about the data put on them––just like the credentials in your wallet today.
When you share a VC, that party can only view information that you choose to share. For example, if we were in a car accident, we could share the insurance company name, policy, and our name but nothing else needs sharing, like home address, which policy we have, etc.
Assurance
So far, we have focused on the credential part of the term verifiable credentials. Verifiable means that a party can verify the information is authentic in some manner. What determines authenticity will vary depending on the level of assurance required for a specific use case.
An example is what assurance is required to verify we are old enough to patronize a pub, which is much lower than proving our citizenship status. Why is this? It is because of what information needs to be verified. Proving we are of age to consume alcohol is much more straightforward than proving citizenship. The consequences are usually much higher when we need to prove our citizenship.
Let's break this example down. What information exactly does the pub need to know? They do not need to know our age or date of birth. They need to verify if we meet the minimum requirements to drink. Instead of sharing our personal information, we can prove we are old enough through zero-knowledge-proofs (ZKPs).
A ZKP is a cryptographic method that encrypts data. It is a method that allows us to prove facts without disclosing them––in our case, if we are old enough. A plethora of mathematical equations could apply to make this determination, but for the sake of argument, let's say it adds one to our birth date. When the pub decrypts it (reversing the arithmetic), they would receive a simple "yes" or "no" response that we meet the minimum requirement.
Another thing that would happen during this process is verifying the issuer of the credential. This process would validate that the issuer of the VC has the proper authority to issue a document with our proof of date of birth on it––most likely a government ID, driver's license, or birth certificate. Without negatively impacting the interaction, this verification would happen in seconds. This process proves that the credential is valid because the issuer is authorized to issue these documents (and not a high school student pretending to be a government issuer), and we are old enough to patronize the pub.
This process would not work for proving citizenship because the level of assurance is much higher. An excellent example is a passport, where we must prove our citizenship in order to enter a country. The consequences of getting this wrong can be enormous (allowing unauthorized people in with fake documents). The verifier wants high assurance that the information has not been tampered with and that it was issued by the proper authority. Getting to this point with most documents (remember being able to travel internationally with a driver license; or hearing about people that used to travel with only a birth certificate) is really hard. It takes a long time and is not worth it in many cases. With VCs you get all of this as a basic capability.
Assurance is tricky. Finding the sweet spot for what is required and applicable for each use case requires careful consideration. It is important to keep in mind the principles of self-sovereign identity (SSI) when deciding what info should be included on a credential. The beauty of using VCs is that you can get a lot of range - that sweet spot is pretty big.
Wrap up
VCs are incredible. Imagine if we could digitize our wallets and interact with a tap or two from a digital wallet. It would simplify our daily interactions and allow us to have exchanges more effectively with the ever-expanding digital world.
We touched on a few topics in this post that we will expand on in upcoming posts, like who has the authority to issue credentials and verifying credentials. These are complex subjects themselves that require more thorough explanations. Once through the heavy lifting of concepts, we will examine a variety of use cases and the benefits of them. Keep following this blog series to get clarity on these and many other SSI topics.
