Decentralized Identity Made Easy
By: Riley Chu, Data Engineer of ArcBlock
“Decentralized Identity” is one of the most mysterious concepts associated with Blockchain, but it really shouldn't be. The benefits of DID can have a significant impact for users by enabling them to control their data and manage their online and digital interactions easily. Even after Microsoft recently published a high profile DID solution built on blockchain, most of the public is still confused about this new word and the meaning behind it.
In short, DID is a unique identity address calculated from a set of credentials. The owner of a DID can use this DID to perform various actions, including authentications, transactions, etc.
The process of generating DID is very similar to that of preparing a dish. We need a set of cookware, some ingredients, and the secret recipe. All of these are pre-built in Forge SDK.
Like using pots and pans when its time to cook, the first step of generating your DID is to pick the right set of cookware and in the case of DID you need the following roles types Signer, Hasher, and Role.
The Signer is a signature system, which refers to the algorithm used to calculate your secret and public keys. Currently Forge SDK supports two signature system options: Secp256k1 and Ed25519 which is the default.
Hasher is a hash function, which refers to the algorithm used to calculate the hash of your data. Hash functions are like black boxes, which convert any arbitrary length of data to a fixed size. For the same input, a different type of hasher will have different output. Unless otherwise specified, Forge SDK uses SHA3 256 as the hash function.
After you have picked your cryptographic algorithms, the last cookware to pick is your DID role type. This specifies the role of your DID, whether it’s for an application, a person, or a device, etc. Below are the role types we currently support.
Now you should have a sense of the cookware we use. Let’s see what the ingredients are for generating DID. Generally, a DID is calculated from a public key, but since the public key is calculated from the secret key, DID can also be calculated if given only the secret key. So what does that mean?
A secret key is a set of data that you keep to yourself. Anyone with your secret key can re-generate your wallet and gain full access to it, including transferring money and approving transactions. So you want to be very careful with it.
The Public Key is a set of data that is calculated from your secret key and is usually used by external parties or the public to verify your signature. However, without the secret key, the public key alone does not grant any access to your private information.
Now you are familiar with the basic cookware and ingredients needed to create a DID. Let’s now take a look at the recipe focusing on how we combine all of the above elements together.
By now, you should have picked your hasher type, signer type, role type and have your set of secret keys and public keys ready. So, let’s put it all together now by following a few key steps.
Use your hasher to get a hash of your public key as hash1
Take the first 20 bytes of hash1. Set them aside for later use as hash2.
Add the DID type bytes in front of the hash1, as hash3.
Get the hash of the extended hash in Step 3 as hash4
Step 5 Append the first 4 bytes of hash 4 to hash3 as hash 5.
Encode hash5 by using the Bitcoin Base58 method. Note, we are using IPFS's multibase to encode as base58_btc type. Done!
Now you have been through the entire process of generating a DID and while the mechanics on the back-end are technical in nature, a user will simply create and obtain their own unique DID based on an easy to use onboarding process. For example, if you look at ArcBlock’s recently launched ABT Wallet the onboarding process consists of 4 simple steps to create a fully decentralized wallet that leverages the described DID process keeping a users data safe, secure and completely decentralized.