My own Decentralised Identifier (DID) implementation

W3C has approved the decentralised identifiers (DID) specification on late June this year. DID is considered as one of the pillars in enabling the concept of self-sovereign identity, which is expect to be the identity model in Web 3.0.

There are 149 DID methods listed on the did spec registry as of 11th October 2022. Hyperledger Indy is the most popular among the existing implementations so far. However, most of the the existing implementations that I tried out were not able to cater the set of requirement that I had (maybe I didn’t get them fully). Therefore, I have decided that it would be worth spending some time to come up with my own implementation. As a result, I have started implementing MyDID

MyDID

According to the DID specification a DID should follow the following convention

<scheme>:<method>:<method specific identifier>

where scheme is did. Method name and the method specific identifier are decided by the implementers.

My MyDID implementation uses the following format when generating DIDs, where method name is ttd

"did:ttd:"(namespace":")identifier
namespace: idchar*
identifier: base58char+
idchar: ALPHA / DIGIT 
base58char: 123456789ABCDEFGH JKLMN PQRSTUVWXYZabcdefghijk mnopqrstuvwxyz

MyDID Identifier Generation

I used the same approach that Indy uses when generating DIDs, which is base58 encoding of the first 16 bytes of the SHA256 of the Verification Method public key
e.g. did <- Base58(Truncate_msb(16(SHA256(publicKey))))

How to use MyDID

MyDID implementation is far away from the 100% spec complete status. However, it can be use to generate DIDs and corresponding DID documents. Also, DID documents can be stored on Algorand blockchain and query existing documents that are on the chain.

Sample usage of the MyDID can be found on the Main.java file that is available in the repository.

First you need to generate a key pair. General EC curves and edward curves are supported at the moment. I’ve tested the code with following KeyPairGeneration methods

KeyPairGenerator generator = KeyPairGenerator.getInstance("EC");
KeyPairGenerator generator = KeyPairGenerator.getInstance("EC", "BC");
KeyPairGenerator generator = KeyPairGenerator.getInstance("Ed25519");

For the example I’m using the bouncy castle as the provider. Therefore, you need to add the BouncyCastleProvider as a security provider.

Security.addProvider(new BouncyCastleProvider());

Once the provider is added, we can use the provider to generate a elliptic curve based KeyPair

Here I have used a fixed secure random based on a Mneomic code to ensure the deterministic nature of the generated key pair.

The generated key pair is then used to generate a DID as follow

createDid method generates a DID and returns the DIDDocument corresponding to the generated DID. By default the controller is assumed to be the same as the id and the key pair that is used to generate the DID is set as the default verification method.
Generated DID and the DIDDocument looks as follows

DID
did:ttd:zJZQR1SNtHwmLfQN477yabW

DIDDocument

Similarly, another DID can be generated to represent the receiver.

Then these generated DID documents need to be stored somewhere. Distributed file systems such as IPFS is the default choice for this. However, in this example, I’m going to store them directly on a blockchain. More specifically, I’m using Algorand (a public blockchain) to store the document. So, anyone can get the document if they knows the DID.

For local testing purposes, I have used Algorand sandbox, which is available on https://github.com/algorand/sandbox. You can clone the Algorand sandbox repo and start the sandbox using the command
./sandbox up
This will start the Algorand private node on the local machine. Sandbox also provide option to connect to different nodes including the public chain. You can refer to Algorand documentation on that.

Then we need to create a client to connect to the Algorand node. I have defined a sort of a wrapper class named AlgorandUtil.java to group all Algorand related functionalities. This class can be used to generate a client as follows (or you can refer to Agorand java-sdk sample).

We need an Algorand user to initiate the transaction of storing DID document on the chain. By default, the sandbox comes with 3 accounts.
I’m using the first account in this example. In order to use that account, we need to access its private key. We can get the private key of that default user using the Algorand KMD. Then that private key is used to construct a Account object as follows

Once we have an Algorand account we can store the document using storeDID method in AlgorandUtil

We can access existing DID documents that are stored on the chain using the getDIDDocument method. It will return DID document of a given DID as a JSON object. We can use either a DID object or a string representation of (full qualified) DID to query documents.
Note that, updates on a document will result multiple documents on the chain for the same DID. Thus we need to get the latest one from the chain.
We can then parse the JSON object to a DIDDocument using the jsonToDIDDocument method

Given that both sender’s and receiver’s DID documents are on the chain, they can use the their private key and other party’s public key (which is on the DID document) to start the key exchange process. Here, I’’m using elliptic curve Diffie–Hellman (ECDH) and generate a AES key

Sender can sign any message using their private key and the receiver can verify the message authenticity using the sender’s public key that is on the DID document

We can use the mutually generated AES key for encryption and decryption

The complete example is on https://github.com/thusithathilina/MyDID/blob/master/src/main/java/org/ttd/Main.java