Flavours
Top 5 DID Methods
Below are some of the most commonly used DID methods, including their advantages and potential drawbacks. It's important to note that the applicability of a DID method depends largely on the specific requirements of a use case. While did:web and did:ion are highlighted as the best, it doesn't mean the other methods are inherently bad—they may simply be more suited for different types of applications.
1. did:web
Best for organisations and web-native applications
did:web is a DID method that allows domain name owners to express DIDs and DID Documents in a way that is compatible with the existing web architecture. DIDs are derived directly from domain names and can be resolved using standard HTTP protocols.
Advantages
- Web-native: did:web is easy to use and understand for developers already familiar with the web.
- Interoperable: It works seamlessly with existing web technologies and infrastructure.
- Non-blockchain: It does not require a blockchain, avoiding potential scalability issues and transaction costs.
Risks
Centralisation:
The reliance on domain names brings some degree of centralization, as domain names are managed by centralized entities.
2. did:ion
Best for applications requiring high level of decentralization
did:ion is a public, permissionless, Decentralized Identifier network that uses the Sidetree protocol on top of the Bitcoin blockchain.
Advantages:
- Decentralized: did:ion leverages the security and decentralization of the Bitcoin network.
- Scalable: It uses the Sidetree protocol, which allows for high scalability and low cost operations.
- **Anchoring is Optional: ** Anchoring is optional, which means that applications can choose to anchor DID Documents on the Bitcoin blockchain or not.
Drawbacks:
Complexity: The Sidetree protocol is complex and may be more difficult for developers to understand and implement.
3. did:sov
Good for permissioned, privacy-focused applications
did:sov is a DID method used on the Sovrin network, a public permissioned blockchain built specifically for identity.
Advantages:
- Privacy-focused: did:sov was designed with privacy as a top priority, with features like selective disclosure built in.
- Purpose-built: Sovrin is specifically built for identity-related use cases.
Risks
- Permissioned: The Sovrin network is permissioned, which may not align with the needs of some applications seeking a fully decentralized solution.
- Lesser-known: The Sovrin network is not as widely used or recognized as other blockchains.
4. did:key
Best for simple, static applications
did:key is a DID method that allows for a simple, file-based method for creating DIDs. It's basically a way to derive DIDs directly from a public cryptographic key.
Advantages:
- Simplicity: did:key is straightforward to implement and use, making it ideal for testing and simple applications.
- No Blockchain Needed: It does not require any interaction with a blockchain or other external system, which can make it faster and more cost-effective.
- Self-contained: The DID Document is directly derived from the DID itself, so it's completely static and self-contained.
Risks
- Lack of Dynamic Updates: Because did:key DIDs are directly derived from the public key, they can't be updated. If the key is compromised, a new did:key needs to be created.
- Limited Use Cases: Due to its static nature, did:key is not suitable for complex applications that require updates or interaction with a blockchain or other external system
5. did:peer
Best for peer-to-peer applications
did:peer is a DID method that allows for the creation of DIDs using a peer-to-peer network.
Advantages:
- Peer-to-peer: did:peer is a peer-to-peer network, which means it does not rely on a centralized authority.
- No Blockchain Needed: It does not require any interaction with a blockchain or other external system, which can make it faster and more cost-effective.
- Self-contained: The DID Document is directly derived from the DID itself, so it's completely static and self-contained.
Risks
- Lack of Dynamic Updates: Because did:peer DIDs are directly derived from the public key, they can't be updated. If the key is compromised, a new did:peer needs to be created.