Decentralized Identity is failing us. Welcome to the Web3 Mullet.
We need better identity infrastructure to bring Web3 mainstream.
Decentralized Identity is a foundational concept that should underpin the majority of Web3 projects. However, the current implementations are flawed and need to be fixed to achieve mainstream adoption.
The vast majority of “Web3” applications provide the perception of decentralization by asking you to login with a blockchain address, but in reality they are centralized behind the scenes. These applications don’t enforce end-to-end encryption of user data or guarantee data is stored on decentralized infrastructure.
As a result, in many instances users do not own or control their application data.
We are swimming in a sea of “Mullet Web3”. Decentralized at the front, but centralized at the back.
What is a Decentralized Identity?
A decentralized identity is a concept which can be multiple things depending on the context. At a basic level a decentralized identity can be created by anyone, is anonymous by default and contains a secret (ie: private key) that can be used to prove ownership of the identity. This enables cryptographically trusted relationships and communication, owned and controlled by the holder.
Decentralized identifiers (DIDs) are similar to usernames in Web3, but with extra features. They are the basis for sharing public keys controlled by the DID holder, creating trusted connections, storing data and many other capabilities.
Here is an example DID using the “Ethereum” DID Method: did:ethr:0x690b9a9e9aa1c9db991c7721a92d351db4fac990
DIDs play a critical role in Web3 ecosystems, which don’t have a centralized authority playing the role of gatekeeper. They enable multiple decentralized identities to establish trusted communication channels, share information and build composable services.
Given a DID, it’s possible to use a software library to lookup an associated DID Document (JSON) that provides lots of extra metadata. This document can define an unlimited number of public keys for different use cases, it supports key rotation and supports listing API’s or service endpoints where you can interact with the identity.
A common use case is for a DID Document to point to a location of an encrypted personal data store where user data is stored; owned and controlled by the user. This is an essential requirement for us to reach the promised land of “owning your own data”.
There is a working group that has established the DID-Core standard under the stewardship of W3C. This allows protocols to define a “DID method” that provides different ways to construct DID identifiers and documents. This allows a software library that can take the identifier and resolve the DID Document. There is a range of working groups supporting discovery related specifications at the DIF.
This DID standard is the leading technology being used by emerging Web3 protocols like the Ceramic Network, Web5, At Protocol by Bluesky and Verida.
Blockchain addresses as DIDs
The emergence of blockchain has pushed forward the technology and broader awareness of public / private key pairs being used as decentralized identifiers. The identifier is a blockchain address and the private key remains a secret kept by the owner.
At first glance, this seems really awesome. Not only do we have a decentralized identity, we also have a key pair allowing us to sign messages or data to create trusted, secure protocols.
Metamask and other crypto wallets have brought this technology to a large user base. (Yes, PGP enabled this a long time ago, but the timing and tooling wasn’t right).
The DID-Core standard provides a very specific way to use a blockchain address as a feature rich decentralized identity with the help of a DID Document. This provides security via key rotation, allows for standardization of data storage and accessing services relating to the user.
However, the vast majority of Web3 projects are simply asking users to sign a message using MetaMask to prove they control a blockchain address rather than using the DID-Core standard.
This gives the perception to a user that they are using a decentralized service, however the user is just logging into a centralized service that stores their data — just like a Web2 application.
This is not a decentralized application!
Sign-in with Ethereum makes things worse!
This concept of signing a message with Metamask to login has been taken even further with the introduction of the “Sign-in with Ethereum” (SIWE) standard.
SIWE requires a user to sign a message with a timestamp and nonce proving they currently control the secret (private key) for an account. This is equivalent to signing in with a username and password to a centralized system.
In fact, that is the underlying purpose of SIWE. To enable a blockchain address to sign into Web2 applications:
Here we hit a major issue.
While this “sign-in” process works well, the architecture is just a front to a centralized system for storing data and interacting with the application. SIWE does not mean your Web3 application data is decentralized. It does not mean you have ownership / control over your data, nor that it is being encrypted using your blockchain keys.
In fact, the design of SIWE makes it impossible to support end-to-end encryption of user data using your blockchain private key.
The application must then store a cookie or a session on a server to maintain information about you as a “logged in” user.
We have the Web3 mullet. It looks like decentralization at the front, but it’s centralized at the back!
SIWE also introduces numerous other issues:
Using a public blockchain address as the identifier is a security and privacy risk.
A user’s public blockchain assets and activity is now linked to their private Web3 application activity.
A user is locked into using a particular blockchain network and private key.
The concept of a DID Document in the DID-Core standard is designed to solve all these issues (and many more).
However… DID-Core implementations also have problems!
The DID-Core standard is not perfect, but it’s a pretty damn good improvement on the current way we handle identities.
The standard introduces the concept of DID Documents that must be publicly discoverable and securely stored somewhere. Developers can define a “DID Method” that outlines different types of identifiers (ie: did:ethr or did:web ) and how the DID Document can be discovered. Each DID method typically has a software library that developers can use to “resolve” the DID Document for a given identifier.
Here’s our first problem. There are lots of DID Methods (see the full list here). No software will support all of those methods, it’s just not feasible. In fact Google and Mozilla objected to the DID-Core specification on this basis, but was overruled by the W3C.
Over time, we will see a necessary consolidation of these DID methods into the ones with the best technical characteristics, flexibility, community and adoption…. but for now it’s a bit of a mess.
Let’s look deeper at the technical requirements that must be considered when implementing a DID Method. It’s critical that DID Documents have the following properties:
Access; Documents must be public to discover and read, but it must be enforced that only the DID controller (user with the secret) can change the document (ie: rotate their keys)
Performant; It must be fast to read and write (seconds), otherwise there will be unacceptable delays when creating a new account or signing into Web3 applications.
Cost; Web3 is competing with Web2. The cost must be very low (ideally free), without the user becoming beholden to a centralized entity paying on their behalf. If the user has to pay, that introduces a huge barrier to entry that makes it infeasible.
Revocable; A user must be able to delete their DID document in accordance with the “right to be deleted”. This is a critical requirement that is missed by the vast majority of DID method implementations.
Full support; The implementation must support the full suite of DID-Core specifications for maximum flexibility and security.
Bluesky’s AT Protocol has a great summary of their criteria around selecting a DID method:
At present, none of the DID methods meet our standards fully.
The current leading DID methods fail on both my high level criteria and that of the AT Protocol on many levels. They are not suitable for widespread mass adoption.
However, let’s take a closer look at the leading contenders to better understand the issues.
DID: Ethereum
TLDR; Expensive, slow, only a partial DID-Core implementation, Non-revocable documents
The ethr-did-registry runs on Ethereum. This makes it very expensive and slow. Blockchains are not designed to store data, so storing a whole DID Document is not feasible at scale.
The current implementation tries its best to be efficient with gas fees, but this results in many compromises. As such, it only supports a subset of the DID-Core standard. This makes it a lot less useful than it appears at first glance.
DID: ION
TLDR; Complex, Requires it’s own layer 2 network, Encourages centralization of infrastructure, Slow to anchor, Non-revocable documents
ION (based on the sidetree specification, supported by Microsoft and favoured by the team behind Web5) stores DID Documents on IPFS nodes and anchors proofs to the Bitcoin blockchain. This seems like a sensible decentralized architecture, but creates a lot of complexity and introduces other interesting issues.
The ION infrastructure requires a network of node operators willing to run infrastructure. At the moment that is voluntary from a small group of organizations with a vested interest in the network continuing to operate, with no economic incentive model.
ION requires node operators to pay Bitcoin transaction fees to anchor DID Document changes:
This places an economic cost on node operators to pay for transactions, rather than empowering an individual to pay for their own. Web3 developers must pay to run their own node or pay others to use their nodes. This creates a delegation of trust which increases centralization and other third party risks across the network.
ION requires locking Bitcoin:
ION is dependent on the slow pace of Bitcoin for it’s anchoring service:
This means proof commits of new DID Document changes take ~20 minutes before they are anchored.
DID: 3ID (Ceramic)
TLDR; Similar to ION without the blockchain, Requires it’s own layer 2 network, Non-revocable documents, Limited DID standard support
3ID DID method is implemented on the Ceramic network which is a stream based mutable storage network that leverages IPFS. As such, it inherits the limitations of IPFS such as the inability to support revocable documents.
The DID method generates a DID document from an object containing multiple public keys. As a result, there is no support for service endpoints or fine grained control over the rest of the DID document, severely limiting its usefulness in a composable Web3 ecosystem.
The DID method is also tightly coupled with the Ceramic network itself, making it challenging for an implementer to use the DID method in projects not using Ceramic.
DID: Cheqd
Cheqd DID method is an honourable mention. Running on top of the Cosmos blockchain and with Hyperledger Indy origins it is a well thought out DID method implementation.
The DID document is stored on chain, however the blockchain key pairs are separated from the identity payloads providing increased privacy and separation between off-chain DIDs and on-chain keypairs.
Cheqd have a well thought through decentralized overnance framework, one of the only on this list.
They also provide infrastructure for other identity related metadata (schemas, assets etc.) and have a privacy preserving payment model for credential verification on their roadmap. Such payment rails will be necessary for creating viable credential business models at scale.
It’s refreshing to see Cheqd have clear pricing available in their documentation, however at current pricing the cost of creating a DID is around $2.00. That being said, Cheqd use cases are more focused on feature rich identity and credentialing where organizations will be creating DIDs more so than individuals, so that price point is not unreasonable.
In a world where there are likely to be multiple DID methods, Cheqd provides a solid option for enterprise use cases.
DID: Web
TLDR; Simple, Cheap, Fast, Fragile.
The Web DID method (currently used by AT Protocol) is simple to implement as it can point to a URL that can be managed by a centralized entity. For example: did:web:acme.com:user:alice is a valid identifier.
On the surface this seems great, however it’s not suitable long term. If the third party website hosting your DID Document goes down, suddenly you have lost your identity! This could be as a result of a temporary outage, the hosting service shutting down or a DNS registrar taking down a domain name. As your DID identifier is hardcoded to that address, there is no way to recover your identity.
The path to true decentralization
There are a variety of other blockchain based DID methods, but they all suffer from some combination of high cost, low speed or limitations to functionality.
For true decentralization of Web3 applications we require three key things:
A DID method that meets the necessary standards for widespread adoption
Applications to start using a suitable DID method instead of “faking” it with blockchain based signatures
Enable applications to be decentralized in the back by leveraging user encrypted data storage and other decentralized services linked to a DID document
It’s hard to blame app developers as they are focused on building products and are currently constrained by the lack of a suitable DID method. This technology is new, so it’s understandable there are trade-offs made on the path to true decentralization.
It’s time to trim the mullet! We must no longer compromise on identity. It’s incredibly difficult to backtrack on identity infrastructure once deployed. Compromises made today will only compound as Web3 adoption grows.
We need a suitable DID method as soon as possible to enable application developers to use fully featured decentralized identity solutions and unlock the ability for fully decentralized end-to-end encrypted Web3 applications.
Value locking is not a requirement for Sidetree. It’s an option to increase your write throughput.