Assuming you already know how I got past Denial, Anger & Bargaining let's move on to...
Depression: Help! They're too complicated!
(Source: https://dinosandcomics.com/)
Now let's address the T-Rex in the room - what the hell are VCs? How do they work?
I could tell you VCs aren't complicated - but that'd be a lie. Unless you know all about cryptography and blockchain already. I'll assume you don't (since I don't) and present an oversimplified picture.
What are VCs?
Think of all the documents you use in the physical world to prove who or are or what you did - your driving license, your passport, your employment ID, even the coveted degree your mom framed on the wall.
Now think of their digital equivalents. Images of these documents? Easy to fake - I could make myself a fake Nobel prize certificate within minutes. Your Google / Facebook ID? Doesn't work with everything (phew!). Your Linkedin testimonials? Don't even get me started!
Point is, there isn't really a good enough substitute in the digital world. Which is the reason bank applications need to be screened for document tampering and compared against multiple databases before you're cleared for an account. All this takes time, effort and money.
Enter VCs.
An analogy that's been flogged to death is the wallet analogy - you can think of a mobile app as a digital wallet and VCs as digital "identity cards" in the wallet. Just like you show an ID when requested by, say a bouncer at a club, you can show you digital ID on demand in the internet.
Who're the parties involved?
When you've been dealing with VCs for as long as two weeks, three terms you hear very often are issuer, holder (or prover) and verifier. Simply put,
Issuer is the entity that gave you the credential (driving license, COVID vaccine certificate, Linkedin endorsement you traded with a friend)
Holder is the person who the credential is meant for (you, your delighted friend)
Verifier is anyone who wants to verify the certificate (traffic police, an airline, unsuspecting recruiter).
Language is important here, but you get what I mean. Look here or here for a more formal definition.
How does it all work?
Kinda like email. If you're not sure how encryption in email works, take a look at this. If you already know, let's move on.
Most of your email communication is encrypted by default. This encryption and secure transmission of data works using something called Public Key Infrastructure (PKI). VCs use the same concept of PKI to preserve privacy and security.
The only difference is, instead of checking public keys from Certificate Authorities, VCs fetch the public keys from a different trusted source - like a blockchain or a secure website. Read more details of the comparison here.
Coming back to our Issuers, Holders and Verifiers, a VC
Is issued by an Issuer. It contains three things:
A location where the Issuer's public keys can be found. Like a URL https://... or a blockchain location (called DID).
The data (or meat) of the credential - could be anything like a degree, a medical record or just kudos for being a swell guy!
A digital signature of the issuer. The signature is "made" from the credential content & the issuer's public key. If either of them are changed later, you can find out from the signature.
Is issued to a holder / prover. Holder is the one trying to make a "claim" called a Verifiable Presentation (VP).
The claim might contain all or some of the information in the credential. For example, if the credential is an MBA, you can generate a VP saying you're a MBA without exposing your grades, specialization or college. Unless you REALLY want to (looking at you, IIM people).
This's an example of zero-knowledge proof. Sharing only essential information, nothing more, nothing less. Apparently it's got some people quite stoked.
Is verified by a Verifier
Verifier looks at a claim presented by a Holder, checks the following
If the holder is the right one
If the issuer is the right / acceptable one
If the claim is NOT revoked
The VP creation and verification usually happens via a QR code in a few secs.
Here's what the flow looks:
(Source: https://tykn.tech/verifiable-credentials/)
And that's it. That's how VCs & VPs work! Simple!
Ok maybe I skipped a few details. So here's some more for our eagle-eyed viewers:
How does holder H know that a credential came from Issuer I?
By looking at the signature in the credential. How does that work? Again, math!
How does Verifier V know the credential came from Issuer I?
Same, by looking at the signature in the credential?
How does Verifier V know the credential belongs to holder H?
Generally by checking the details in the credential, in case of a vaccination certificate for example. Alternatively, the holder H could "sign" the VP using her private key. When Verifier V is able to decrypt the VP using H's public keys (assuming they're shared), V knows the VP came from H.
How does Holder H know Verifier V is the one requesting the check?
Paranoid, are we? Good! Anyway this's easy too - holder H uses Verifier V's public keys to encrypt the VP. Now only verifier V can decrypt it using their private key.
Now we know what VCs are and how they work. So we move on to...