As the shift to a digital society continues, the questions about your digital identity become more and more important. In the current system a user only has the choice to go with one of the large centralized organizations or have a fragmented identity over all services. With the rise of crypto currencies another decentralized approach has the chance to change the game. Self-sovereign identity enables easy access to services without much friction, while maintaining full control over the identity by the user.

What is digital identity?

The problems around identity appear in many different shades. From philosophical questions ("Who am I?" or "What am I?") to more practical appliances like passports or online accounts. For digital identity it is often referred to a collection of your usernames, files, browsing history, metadata and information derived from your online activities. This leads us to the core problems of persistence and evidence. Your digital identity needs to store your collection of data that accumulated over the years and the ability to verify to a service or another user the identity belongs to you and not somebody impersonating you.

Self-sovereign identity

This method of digital identity puts the users in control of their identity. This means the amount of information shared with others, the ability to access services and managing their connections are independent from big (or small) organizations. With the advent of blockchain technologies many of us had their first experience with self-sovereign identity in the form of non-custodial wallets. It brought new light into the realm of decentralized identity with public key cryptography. Many projects started working on this issue and to gain adoption across different services a standard that allows for innovation was necessary. The W3C approved the specification of DID (decentralized identifiers) in 2022.

What are Decentralized identifiers (DID)

A decentralized identifier is a unique text in the form of "did:method:unique-id" that resolves to a DID document. How to resolve a did is specified by the method and gives developers the possibility to innovate with different approaches. For the more technical people, the DID document is based on a JSON file with some mandatory attributes:

{
    "@context": [
        "https://www.w3.org/ns/did/v1",
        "https://w3id.org/security/suites/ed25519-2020/v1"
    ],
    "id": "did:vinyai:123456789abcdefghi",
    "verificationMethod": [{
        "id": "did:vinyai:123456789abcdefghi#keys-1",
        "type": "Ed25519VerificationKey2020",
        "controller": "did:vinyai:123456789abcdefghi",
        "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
    }],
    "authentication": ["did:vinyai:123456789abcdefghi#keys-1"],
    "service": [{
        "id":"did:vinyai:123456789abcdefghi#profile",
        "type": "Profile", 
        "serviceEndpoint": "/orbitdb/zdpuB3VvBJHqYCocN4utQrpBseHou88mq2DLh7bUkWviBQSE3/profile"
    }]
}

In this example the "@context" field contains relevant information on which standards are used by the DID. Then we have the "id" section which is the DID URL by which you can retrieve the DID document. In the "verificationMethod" all public keys are stored. Those keys are then used to verify all actions taken belong to the person managing the DID. It also holds the public encryption keys, so anyone communicating with the DID owner can do it in an encrypted and secure way. The "authentication" field contains all keys that can be used to authenticate the DID to a service like most of use do it with passwords today. At last there are services that are linked to the DID. For VINYAI we connect the profile and access control for the encrypted file system.

The problem with DIDs

One major issue with decentralized identifiers comes form of potentially being a permanent identifier. If all your activity is linked to that DID it is possible to build a detailed profile about an individual. All contacts you have had, your search history, browsing history, and other online activity build up over time, together with a cryptographic proof.

To prevent this from happening a user needs to have a lot of different DIDs. Those only contain the minimum information that possibly needs to be linked together. A new DID for every service you use or a different DID for every other user you interact prevent such a permanent record to be created. The management of those identities needs to be hidden from the user, otherwise it would be a usability nightmare.

The user controlĺing those DIDs is the piece that connects those fragmented parts of the identity with a very protected DID. This identifier is completely encrypted and linked DIDs can only be accessed by the user. For further security it is only used for a certain amount of time before it gets discarded and replaced with a new one. This concept of DID rotation is borrowed from a encryption best practice called key rotation. In the worst case of a leaked DID it only is useful for an attacker for a given period of time and after the rotation it is secure again. Regularly rotating the DIDs is also an opportunity to upgrade the encryption algorithm whenever it becomes relevant.

Securing the DID registry

As in the DID specification of the W3C you should be able to retrieve a DID document from a DID URL. For a truly decentralized registry this needs be done on a blockchain. If done incorrectly it could lead to a place where anyone can see all available DIDs that are ever created together with all public keys, services and connections to other DIDs. To prevent this scenario from happening all DID URLs point to an encrypted address where the also encrypted DID document is located. An attacker who stores all encrypted addresses to the documents and waits years or even decades until the encryption can be broken, will have no success anymore, because after that amount of time the address points to nowhere due to DID rotation mentioned before.

A more practical approach to a decentralized DID registry

But with a lot of DIDs it gets very expensive to make that amount of transactions on a blockchain like Ethereum even with the latest of scaling solutions. That´s why only the main DID is stored in this registry. All other DIDs that are controlled by the main one are stored and resolved from within the file system. Those DIDs inherit the security properties from the blockchain and offer better privacy by being only resolvable by the involved parties. An example would be a shared file between two persons. The DID representing the connection between the two people is only stored in their file systems. For anyone else it is not possible to retrieve the DID.

To even go one step further our DID registry can run on multiple blockchains to offer flexible solutions in terms of transaction cost, censorship resistance and decentralization. A base registry on Ethereum stores the contract addresses and versions of the deployed DID registries on each network.

DID management with cryptography

Another important aspect of the registry is the management of the DIDs. A user should be able to create, update and revoke a DID, but only if the user has access to the given DID. The access control is build upon public key cryptography. Each entry in the registry has corresponding public keys that can manage the DID. Actions can be performed if enough keys sign it. This is implemented with a given threshold that is required to make a change. In practice a user often has more than one device and every device has its own DID management key. To update the DID when a new device is added or some old device is removed, for instance 2 out of the 3 devices approve the change.

Those are not the only keys a device stores. Besides the DID management keys there are encryption and authentication keys too. These two public keys are only in the encrypted DID document to better protect the users privacy, but not in the public registry. As an example the public encryption key is used by another user to encrypt a file shared with you. To verify that it is indeed this user, you get the authentication key from the users DID and verify the file is signed by this public key.

As the last piece in the puzzle of creating a secure DID registry on a blockchain, there needs to be an option for you to create a DID without linking your wallet and with that your transactions to the DID. The registry can accept signatures of management keys by any address, so you can use a burner wallet or some service that put the transaction on the blockchain for you. Those signatures are verified within the registry itself to prevent manipulation of your DID.

The future of decentralized identity

Since this is a very new technology we still explore what other useful applications can be build on top of a decentralized identity system. One big problem many try to solve is sybil resistance. A sybil attack is basically one identity creating multiple accounts to manipulate votes or create an false impression of a communities public discourse.

Two projects exploring a solution are BrightID and Proof of Humanity. The main issue with those is privacy, since all information is stored publicly. They create this permanent identifier mentioned above. This can also raise some legal issues in some jurisdictions for example with the GDPR from the EU or the California Consumer Privacy Act. Another problem is faking the attestations via deep fakes and other artificial intelligence models.

But zero knowledge proofs can add privacy to such services, but this still takes time to build in a way that is scalable and easy to use. Another controversial implementation of a proof-of-personhood is by Worldcoin with their iris scanning technology. It creates a hash of your iris. Those hashes differ from the hashes used in crypto currencies in a way that allows them to be similar when they come from the same iris. When there is no hash with under a given similarity threshold, the hash belongs to a new human that is not part of the system yet. To verify that you are a unique human being you can create a zero knowledge proof that you belong to the group of scanned people without revealing your identity. As it uses specialized hardware it poses risks to centralization. Trusting that the hardware works as described is another issue with these kinds of identity proofs.

Zero knowledge reputation systems can also contribute to better sybil resistance, but they will not solve the problem of proof-of-personhood. The most promising way for a better identity system will be combining those different technologies to deal with their shortcomings.