Fundamentals of Decentralized Identity: Free Certification Course

To understand how decentralized identity works, it's important to look at what's currently happening and what has happened in the past so we can understand why people in this Decentralized Identity or Self-Sovereign Identity space, as it's also called, are so excited about what this new technology can bring.

Centralized

So what we have today is a centralized model where we, as users, sign up for an online service, often using something like email and password to create an account. But when we go to another online service, we have to go through the same process again, create another account, and so on. The user ends up with many passwords and credentials that they need to manage.

And as we're all told, all passwords should be different for security reasons. So that creates a bit of a user experience headache and a potential security risk. We've got all of these different passwords, and if we're not using password managers, we're probably reusing the same passwords for all these different accounts.

Federated

To try and solve this UX problem, we moved to a Federated model. 

You might have seen this when you go to a site, and you can reuse login credentials that you've created with other companies. For example, Login with Facebook or Sign up with Google. Federated models like these remove some of the user experience headaches because they reduce the number of credentials a user needs to manage.

But a Federated model also erodes user privacy. When logging in to a website using your Google account, that service can see your behaviour online outside of their platforms. What other services are users accessing? When are they accessing them? That is eroding your Privacy. And, of course, these companies' business model is often based on knowing more about you and then selling that knowledge to advertisers. Or giving advertisers access to you based on your preferences and how you behave online.

Having companies that are highly motivated to know more about you and then can monetize that data is a very dangerous mix.

Decentralized Identity Management

Then we moved into the decentralized model. In this model, only the user manages and stores their credentials. 

Credentials are not stored on centralized databases. They are kept with the user, typically in a digital wallet. 

The users can then use those credentials, those digital identities, to access other systems. All the while, they are retaining control over their credentials. The users decide who gets access to their data and what parts of it they access.

The user can also attach different attestations, or what we'd also call claims, to those identities. We'll get further into this later when we discuss Verifiable Credentials.

Verifiable Credentials are digital representations of achievements, claims, licenses, permits, university degrees, etc. They're effectively credentials, but they are verifiable. A third party can check these credentials and know with certainty who issued the Credential and to whom they issued it.

This immediate verification is very powerful and, of course, very necessary online. 

In the past, all our credentials were physical. When we went for a job interview, we would potentially take a physical copy of our achievements, passport or ID document to the meeting. This is how we used to present our credentials and prove things about ourselves.

In recent years, things have rapidly moved online, and now we need digital and highly portable credentials. We need to be able to take them with us. But with digital credentials comes the problem of forgeries and tampering.

How do you know that a digital PDF document, for example, hasn't been photoshopped with a different name, photo or achievement title? 

The need for credentials that can be verified will increase the further our lives go into the online world. 

That's what Verifiable Credentials are for.

Verifiable credentials are credentials that can be verified. What does that mean? With Verifiable Credentials, you take all the data you want to present as your credentials - your name, degree name, birthday, for example - and digitally sign it.

What does it mean to digitally sign something?

When a University is issuing you a Credential, they take all the information they want the Credential to contain and pass it through a very complex cryptographic algorithm. That produces a cryptographic hash. A hash is a long string of numbers and letters.

This hash is "deterministic". If you always make the same data go in, you'll always get the same hash out. But if you make any changes to the data that goes in, the hash that comes out will be different. If someone changes the name or date on a credential in the university example, the hash will be different.

Because of that, we can very quickly verify that the data in a credential hasn't been changed. 

When someone presents a credential to a Verifier, the Verifier runs that cryptographic algorithm and can verify if the hash is the same. Verifiable Credentials allow you to start using cryptographic methods and algorithms to prove that the data hadn't changed from what it was when it was originally issued.

A Verifier can always know if the data was modified, which provides excellent protection against fraud and forgeries.

A Decentralized Identifier, or DID, is an identifier that belongs to you. It's like an ID, like your employer or student ID, and you can have more than one.

But the big difference is this: the University gives you your Student ID. You generate the Decentralized Identifier for yourself. You own it, and you control it.

When you use Dock to create your DID, that DID is written on the Dock blockchain. It becomes your representation on the blockchain. It's recorded forever there and can't be changed. 

It's important to note that this DID has no personal details about you. A DID is a string of "crazy" characters, not meaningful to anyone when they see it.

Cryptography and DIDs

With Decentralized Identifiers come keys. 

There are two different types of keys: the Public Key and the Private Key.

Here's an analogy to explain how these two keys work: You sometimes receive a "valet key" when you buy a car. So you'll have your regular key, which gives you full access to the car, the trunk, the glove box, everything like that. But then you can also have a valet key, which is a key that you can give to the garage, a hotel that has valet service, etc.

The valet key gives them access to open the door and start the car, but it doesn't give them access to the trunk or the glove box. So they only have restricted access with that key. 

Private and Public Keys are sort of like that. The Private Key would be like the key that gives you full access to the whole car. And the Public Key would be like the valet key that provides you partial access to things.

You never share your Private Key! You never share your master key to the car.

So what happens is when an Issuer issues you a Credential, they use their Private Key to sign that Credential. Like they could sign it with their pen and ink, they can sign it digitally using these keys. This signing process uses advanced cryptographic math to produce a hash value.

After signing the Credential with that Private Key, that master key, the Issuer sends the Credential to the Holder.

When the Holder wants to present it, whoever verifies it can know who the Issuer was. The Verifier goes to the blockchain, gets the Public Key from the Issuer's Decentralized Identifier on the blockchain, and uses that Public Key to verify that the Credential was indeed cryptographically signed by the Issuer.

This is how Decentralized Identifiers come into play with Verifiable Credentials. That signing is the proof of authenticity. Like the rubber stamp from the olden days, the wax seal on the King's letter that proves the King sent it.

The blockchain is effectively just a public ledger or a public kind of storage of all transactions between several parties. 

All data is available publicly or through a block explorer if it's a public blockchain. You can also have private blockchains, where only entities that have been granted permission can read it or write on it.

A blockchain is also immutable, and the transactions registered on it in the past cannot be removed or changed. As a result, you have this audit trail that all the parties can trust.

Blockchain technology was effectively shipped in early 2009. You have probably heard of Bitcoin by now, so that was when blockchain was available. The whitepaper for Bitcoin, which was called a "peer to peer electronic cash system", was published in 2008.

As the lore goes, no one knows which people or "peoples" worked on it. It was authored by a pseudonym, Satoshi Nakamoto, and Satoshi's identity remains unknown.

Interestingly, the original concept of something similar to what we now know as a blockchain goes back a long time. One cryptographer called David Chaum designed a blockchain-like protocol. It's not exactly how it is today, but he put the idea forward in his 1982 dissertation called "Computer Systems Established, Maintained, and Trusted by Mutually Suspicious Groups". 

People have been trying to work out how to make a blockchain or a decentralized ledger system for a while, but it really came into being in 2009.

At the highest possible level, blockchain was trying to solve the issue of having parties process transactions without using a trusted central intermediary. 

Usually, in a bank transaction, you would have a bank in the middle who you would trust to debit and credit your account correctly. If you're transacting with a third party, you would again be trusting the bank as an intermediary to process the payments as you ask them to. What Bitcoin was solving through blockchain was the ability for peers to transact without the central intermediary.

So, for example, if we sent you some bitcoin, you would receive it pretty quickly compared to how international Swift payments are. Only we would know about it, and the transaction fees would be minimal because there's no intermediary involved. So that's the main problem that they initially set out to solve. 

With blockchain, they were also able to solve the double-spend problem. You obviously can't double-spend physical cash. If I have a ten Euro note and pay a shopkeeper with it, he now has the ten euro note. I can't spend that twice because I can't clone it, reproduce it, and give it to someone else. 

But with an electronic cash system that has no intermediary guaranteeing that an account is credited and the other is debited, how do you stop that digital currency from being spent twice? And so, a big problem that Bitcoin and blockchain solved was the ability for digital cash not to be spent multiple times, to only be spent once.

There are three main actors involved in the Decentralized Identity ecosystem.

• The Issuer: someone who is sending out the credentials.
• The Holder: someone who is receiving a credential.
• The Verifier: someone who verifies a piece of information contained in a credential.

If we use the example of a University degree, the Issuer would be the University.

The University would issue that degree, that Credential, to the second actor, which is the Holder. The Holder is essentially a student. And then you have a third actor, which is a Verifier. For example, a future employer.

Their interaction would look like this: The University has a public identity (a Decentralized Identifier and an associated Public Key) on the blockchain. They would also publish that identity (and Public Key) somewhere - their website, for example - to allow people to find out what it is. Because of cryptography, everyone knows that only the University can issue a Credential from that public identity and respective Public Key. Only the University would know the Private Key corresponding to the Public one.

The University then issues a Credential to the student, the Holder, and they can store it in their digital wallets.

When the student finishes the University course and decides that they want to seek employment, the possible employer, a Verifier, would ask the student to send them a presentation of a Credential. This presentation would prove that the student is qualified or sufficiently qualified as they claim to be for the job. 

The employer would receive a digital presentation of the Credential, digitally signed by the Issuer and the Holder. So the Verifier can then know with certainty who issued the Credential and to whom they issued it.

Anchoring

Aside from who issued it and who it was issued to, a Verifier can also know when a credential was issued. For that to happen, the Issuer needs to Anchor the Credential.

Anchoring is like putting a timestamp on a blockchain.

Note that the Credential itself - its contents, the Holder's identity, the qualifications achieved, et cetera - are not put on the blockchain. All that personal data is only stored by the individual in their wallet. This maintains privacy and security for users while allowing Issuers and Verifiers to guarantee that this digital document has not been tampered with and has not been forged.

Anchoring merely puts a hash of the Credential on the blockchain.

The benefits of using Verifiable Credentials depend upon who you are. 

For an issuer - a University, for example - the benefit is offering their students a new, portable, and tamper-resistant documentation of their achievements. This is not possible with the current paper-based credentials.

Verifiers also have significant benefits. Let us look into the employer example. In many cases, employers spend money hiring companies that do identity and background verification.

An employer can remove that cost with Verifiable Credentials because they can instantly verify the credentials by checking their digital signatures. They don't have to phone or email the University or contact an overworked administrator to confirm if "John Smith" did get a medical degree during a specific year. 

An employer can "look" at the Credential and know if John did or didn't. That's a very powerful thing, and it saves a lot of time. Some of those Credential verification processes can take several days, which can really slow up recruitment. Recruitment is super fast-paced, particularly in certain industries, and losing those few days can often cost you an applicant, which can be tough. 

Also, there's a lot of money involved in having your team manually verify credentials. Verifiable Credentials remove those processes.

On the credential holders' side, individuals are getting control over their credentials and their data. When they need to prove that they have a degree, they don't have to contact the University to get the certificate. Or request a duplicate if they lost it. Individuals will have their credentials in a convenient digital wallet on their computer or smart device, and they can quickly send this Verifiable Presentation to a Verifier. Knowing that when it's received on the other end, the person verifying that Credential can quickly confirm it's legit.

The entire experience gives much more control to the credential holder and speeds up any verification process as well.

Another significant benefit is Privacy. There's very minimal information that's actually on the blockchain. The actual contents of the Credential - whether that's a driver's licence, a degree certificate or some other form of identity - are held and stored by the holder in their digital wallets. 

The users' data is not stored on a centralized database that serves as a honeypot for hackers.

You control and own Verifiable Credentials. You're the one that possesses them at all times, and you have control over who sees its contents. That's the first reason.

With Verifiable Credentials, you can also do Selective Disclosure. When you present your credential for verification, you can choose a specific part of that credential to share. 

For example, someone wants to know how old you are. You can choose your "Birth Certificate Credential" but only share the birthdate attribute from that credential. They don't need to know anything else about you. They don't need to know where you were born or what country it was. All they need to know is that your birthdate proves your age. So you can limit how much information you share with whoever is asking you to verify things. Selective Disclosure is a great feature to increase your Privacy.

There's also a next step beyond that. You want to prove you have a certain age, but you don't want to give people your actual birthdate. You just want to say, "I am over 21, or I am over 18. Can I vote?". Whatever the situation might be. You can do that using Zero-Knowledge Proofs in what we call Anonymous Credentials. These allow you to build up a proof to say, "Yes, I have whatever you're asking for", but without revealing the data that supports that proof.

Let's use a voting example. Michael Scott needs to be 18 to vote. So when he arrives at the poll, the people managing the poll would say, "Prove to me you're over 18". Michael could give them a credential that proves it, but he doesn't want the person sitting there to know exactly how old he is, just that he's over 18. 

Using Anonymous Credentials and Zero-Knowledge Proofs, Michael generates a cryptographic proof that verifies that he meets their standard based on whatever they asked for. In our example: that he's over 18, and he does this without showing them his age or birthday.

If he's not over 18, they will get a "failure proof" that says, "No, he's not over 18".

People are often concerned about what is stored on the blockchain. This is for a good reason. Blockchains are publicly readable, so you want to be careful what information you put on there.

In the Verifiable Credentials world, we don't actually put the full Credential onto the blockchain. 

Verifiable Credentials are verifiable without storing their data on the blockchain. Verifiable Credentials are verified through their DIDs and Public Keys.

Schemas

When you're designing a Credential - for example, if you're a University - you're deciding what a degree looks like and what fields should be included. It has got a date, a name, a place, the University name, and a degree name. All that is what we call a Schema. You can think of it as a template in your Word or text processing software.

The schema defines what fields are required for the Verifiable Credential, and that definition can be stored on the blockchain.

Expiration and Revocation Registries

Many times, Verifiable Credentials are only meant to last a short amount of time.

For example, in some countries, Driver's Licenses have to be renewed every few years. So the government would issue a Driver's License Credential, and that Credential can have an expiration date. That expiration date can be built into your Credential. 

Now let's say you got into too many car accidents or did something that made the government decide to take away your Driver's License. The government would use the Revocation Registry for that.

On the blockchain, there's a Revocation Registry, which lists all the credentials that have been revoked. So if an Issuer decides that the Credential they gave you is no longer valid, or they want to take away that Credential from you, they would write to the blockchain that "this credential is no longer valid". 

The Revocation Registry is a registry of IDs that contains no personal information, but that is checked whenever a Verifier wants to verify a credential. 

After verifying that a valid issuer issued the Credential and that it passed all the cryptographic tests, the Verifier goes to the Revocation Registry to check if the Credential was revoked. 

Anchoring

An Issuer can also choose to Anchor a credential to the blockchain to effectively timestamp it.

Anchoring stores one of those cryptographic hashes on the blockchain.

As we've explained before about hashes, if you rerun the same cryptographic algorithm later with the same input data, you should get the exact string back that matches the one on the blockchain.

Note that there's nothing personally identifiable in it. None of your personal information - date of birth, address, etc. - is written to the blockchain. Just cryptographic hashes are.