Introduction into Decentralized Identity

A Little Background

I got a new job more than four months ago. I was laid off from my previous company. I was very lucky! I found my new job before my last day in previous company. I am happy because it’s an early stage startup with focus in future technologies. It means that I can do what I love to do most, learning. But, in a commercial company, any learning has to have a purpose. It has to have impact on company’s profitablility, directly or indirectly.

But, if everything is truly about profit, the founders should probably open a grocery store and sells rice and vegetables instead. They don’t. They want to do digital business. They choose the valuable things they want to sell to their customers. So, my job should be about amassing these valuable things. For me, it’s deep knowledge in the domain we want our products to build upon. That domain is "decentralized digital identity".

I also believe in "fake it until you make it" principle. It’s okay if our early products aren’t perfect and only partially works. We want to know as early as possible if our customers really love our products and want to pay for it. If they do, we can build on top of it. We should never forget our end goals. We have to do our work as if our product will be released next month or even next week. We should be customer focused since the beginning.

Introducing ourselves to Decentralized Identity

Few months ago, we evaluated three libraries we want to use to bootstrap our products. They are:

  1. Veramo

    It’s a Javascript framework for application developers who want to build digital identity applications. They are the team behind DID ETHR, a DID method based on EVM.

  2. Spruce

    They have a cross platform Rust library called didkit that provides basic capability of DID and Verifiable Credential.

  3. Hyperledger Aries

    Hyperledger Aries provides a shared, reusable, interoperable tool kit designed for initiatives and solutions focused on creating, transmitting and storing verifiable digital credentials. One of their framework is Hyperledger Aries Framework Go. They develops DIDComm, a secure protocol to send messages between identity agents.

Long story short, we picked Aries. It’s almost a tie with Veramo. But, we especially choose Aries because it has some qualities that we like:

  1. It has DID Comm

    Any two identity agents should be able to communicate securely. W3C hasn’t come up with the solution for this, but Aries push DID Comm to be the standard through Decentralized Identity Foundation

  2. It is written in Go

    We have bias towards Go language. If other things doesn’t really matter, picking Aries to makes the team that uses it happy is a good decision.

  3. It has extensive documentation

    They write a lot of docs, especially architectural docs. You can look at Aries RFCs.

  4. There is opportunity to be cross platform

    They use gomobile to be able to compile to mobile platforms. So, there should be a little problem if we want to make products that share the same logic.

However, Aries is not perfect. It comes with its own troubles:

  1. It doesn’t come with default VDR

    Without VDR, we can’t save public keys in decentralized manners.

  2. It doesn’t support EcdsaSecp256k1RecoverySignature2020 verification method

    The minimal ETHR DID document contains this verification method. But, it seems that Aries pretends or doesn’t care that this verification method exists even though it’s mentioned in DID Specification Registries. We love Ethereum, EVM, and Polygon. That’s why we like to go with DID ETHR route.

  3. It’s an OOP mess

    There are a lot of small packages. Some interfaces from different packages share the same name within the same context. There are a lot of tight coupling between packages. The abstraction level is not uniform. It makes sense actually. All code are messy, except my code. :)

I ended up writing our code from scratch. I took a lot of inspiration from Aries Framework. But, this complicated beast makes it much easier to develop our own solution rather than writing codes that can be plugged into it.

Dumping The Content of My Head

I learned a lot from Aries. They do have an awful code. But, I increasingly gain new understanding about DID and Verifiable Credential in the last four weeks. This is what I love most about Aries, its learnability. Without using it as a reference, we will be like a tourist in unfamiliar city who trust his guts instead of Google Maps. He said, "Google Maps isn’t always correct!". Well, …​ . At least, we can trust that Aries will behave correctly! Their developers are decentralized identity pioneers and experts. Yes, we write our own code. So, it’s more like a tourist using a Google Maps instead of following itinerary by a travel agent from the city.

Decentralized Identity Domains

Learning is like putting a lot of things randomly into our brain. They are a mess. Now, it’s time to tidy up the mess. I need to have a good mental model about how SSI works. I categorize decentralized identity into three domains

  1. Decentralized Identifier (DID)

    An identity needs unique identifier. DID is that unique identifier. A DID always refers to a person, organization, or even a device. SSI relies heavily on public key cryptography. So, a DID keeps one or more private keys with it while also publishing their public keys. The list of public keys a DID owns is called a DID document. The controller of the DID is most probably the identity owner. A DID method describes how these public keys stored, retrieved and updated. Most DID methods relies on blockchain to be able to store public keys in decentralized way. Some other DID methods store public keys in traditional centralized DB over the web or in non-blockchain decentralized registry.

  2. Verifiable Credential

    A verifiable credential is collection of claims about an identity. These claims are are cryptographically signed by the issuer using private key for which the public key is put on public registry. Examples of credential are university degree, driving license, or even exclusive club membership.

  3. DID communication

    A DID needs to communicate with another DID. One proposed implementation is through DID comm. DID comm is a communication protocol created by Decentralized Identity Foundation to enable DID to securely communicate with each other over an existing network protocols.

Decentralized Identity Navigation Map

I don’t want to talk about DIDComm yet. I will only take what my brain allows me. So, I only take a little bit of DID and VC. I created a navigation map to understand what is inside DID and VC. This is the first step before I can write any code about it.

svg

Decentralized Identity Components

I am the type of programmer who throw things at the wall and see what sticks. Decentralized identity is not a small topic, and keeping ideas floating in my head will only make them vaporizes. So, I did some prototyping to gain deeper understanding. Unfortunately, I can’t share you the details. Even if I can, showing you thousands of lines of code is much more boring than reading this article. Let’s just skip it.

After some amount of prototyping, the architecture slowly emerges and taking shape. Now, it’s time to capture that architecture into some models. I still need to make some changes in my current prototype, but that’s alright. Most of the code are already in place. I am not worried about breaking change. That’s why we have version 0.X. We keep breaking our API until it feels right. I think I am ready to have my 1.0. Let we see what I have here.

svg

What Was That?

Ups, sorry. In essence, decentralized identity by means of DID and VC is pretty simple. DID is a number that inherently attaches to a thing or a person. That thing or person prove the ownership of this identity by cryptographic means, called DID Method. A credential is a claim about a thing or person by another thing or person called an Issuer. The thing being talked about is a Subject. Verifiable Credential is a digital claim that can be proved cryptographically that it is indeed from Issuer. A Verifier is anything that wants to know whether a Verifiable Credential is valid, determined by its origin, expiry, and whether the credential has been revoked or not. That’s it! That’s pretty much the gist of it. Easy, right?

svg

What It Is Used For?

Actually, DID and VC is very useful! We can implement anything! Club membership, car ownership, academic certificates, citizenship cards, medical records, driving license, anything! Each of them can be easily proven authentic. It’s interesting, but also sad. Its use cases are unlimited, but very few businesses sees its immediate applicability.

What Next?

That’s all. That’s pretty much what is in my head.