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.