Sarah stared at her phone in disbelief. Another data breach. Another company apologizes for losing her personal information. Another round of password resets and identity verification hoops to jump through.
"There has to be a better way," she muttered.
That's when her tech-savvy neighbor, Marcus, introduced her to the "Digital Identity Squad"(DID methods) – Different approaches to taking control of her digital life. Each with its own superpower, each perfect for different moments in her digital day.

In Web5, a user's Decentralized Identifier(DID) links their identity to their data via Decentralized Web Nodes (DWNs). This removes users off from centralized data storage, granting them full control over their data.
DIDs are unique identifiers that users can create and control without relying on third parties. DIDs use cryptoanalysis techniques to demonstrate ownership.

Different DID methods implement unique mechanisms for creating, updating, and resolving DIDs. Here's a comparison of several prominent DID methods:

did:ion

DID ION is built on the Sidetree protocol, which operates without needing its blockchain. Instead, it uses Bitcoin's immutable timestamping mechanism to anchor DID operations. ION aggregates multiple operations into batches, reducing the load on the blockchain.

• High scalability, as it batches multiple operations in a single Bitcoin transaction.
• It is very decentralized due to its reliance on Bitcoin.

did:ethr

DID Ethr is built on the Ethereum blockchain. It uses smart contracts to manage DIDs, storing and updating DID documents as transactions on the Ethereum blockchain. It can be resolved using an Ethr-DID registry contract.

• Its scalability depends on Ethereum solutions like layer 2 or Ethereum 2.0
• It has high decentralized nature.

did:sov

DID Sov is built on Hyperledger Indy, which is a permissioned distributed ledger specifically designed for decentralized identity. It uses a global public ledger to store DID documents and supports privacy-preserving features.

• Good for its specific use case but may not scale to massive public use cases like Bitcoin or Ethereum.
• Its decentralization is limited to the permissioned network of Hyperledger Indy

did:key

DID Key is a self-contained method where DIDs are derived from a cryptographic key pair (e.g., a public key). The DID document is generated directly from the key material without needing external storage or resolution.

• Highly scalable since it does not rely on external infrastructure.
• Decentralized is high, as it doesn't rely on any central authority or ledger.

did:web

DID Web relies on the Domain Name System (DNS) and HTTP(S) protocols. DID documents are stored on a web server under a domain name, with DIDs structured as URLs (e.g., did:web:example.com).

• Highly scalable as it leverages the existing web infrastructure.
• Decentralization is limited as it depends on centralized DNS and web servers.

• DID methods like did:ion (Bitcoin) and did:ethr (Ethereum) offer strong decentralization due to their use of public blockchains, though they come with trade-offs like higher complexity and costs. Methods like did:sov provide decentralized identity within a permissioned network, offering specialized identity features but limiting decentralization.

• Methods like did:web, and did:key offer simplicity and scalability, leveraging existing web or cryptographic infrastructure. However, they may lack the strong security guarantees of blockchain-based methods.

Choosing the right DID method depends on the balance between decentralization, scalability, simplicity, and the specific needs of the identity system being developed.

Learn more on DID methods

Security Considerations

Key Management

• did:sov: Robust but complex
• did:ethr: Smart contract-based recovery
• did:ion: Multiple key support
• did:web: Traditional web security
• did🔑 Basic key pair only

Integration Complexity

Development Effort

• did:key (Minimal)
• did:web (Low)
• did:ethr (Medium)
• did:ion (High)
• did:sov (Highest)

Best Practices for Selection

Factors to Consider:

1. Security requirements
2. Scalability needs
3. Cost constraints
4. Performance requirements
5. Decentralization priorities
6. Integration complexity
7. Maintenance capability
8. Regulatory compliance

Selection Guidelines

1. Start with simplest method that meets requirements
2. Consider future scaling needs
3. Evaluate operational costs
4. Assess technical expertise required
5. Review regulatory implications
6. Test in representative environments
7. Plan for key management
8. Consider ecosystem compatibility

Some other DID methods in web5 are did:dht and did:jwk but not limited to these DID methods I have mentioned in this post

did:dht

(Distributed Hash Table): Think of did:dht as a digital phone book that's owned by everyone and no one at the same time. Instead of storing information in one place, it spreads it across a network of computers, like how torrent files work.

For instance;
Imagine a neighborhood bulletin board system where:

• Everyone can post notices
• No single person controls the board
• Information is copied across multiple boards
• Anyone can verify who posted what

Perfect For

1. Applications needing quick identity lookup
2. Systems requiring decentralized control
3. Projects with limited blockchain budget
4. Peer-to-peer networks.

// Example DID Document using did:dht
{
  "id": "did:dht:example123",
  "controller": ["did:dht:example123"],
  "authentication": [{
    "id": "did:dht:example123#keys-1",
    "type": "Ed25519VerificationKey2020",
    "publicKeyMultibase": "z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
  }]
}

did:jwk

(JSON Web Key): did:jwk is like a self-contained digital ID card. Everything needed to verify your identity is packed into one compact format, using well-established JSON Web Key standards.

It's like a holographic ID card that:

• Contains its own verification system
• Doesn't need external databases
• Can be instantly verified
• Is tamper-evident

Perfect For

1. Simple verification needs
2. Offline scenarios
3. Testing environments
4. Quick prototypes

// Example DID using did:jwk
{
  "id": "did:jwk:eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2Iiwie...",
  "verificationMethod": [{
    "id": "#0",
    "type": "JsonWebKey2020",
    "controller": "did:jwk:eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2Iiwi...",
    "publicKeyJwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "example-x-value",
      "y": "example-y-value"
    }
  }]
}

Making the Choice

Choose did:dht when you need:

• Decentralized storage
• Network resilience
• Community-driven control
• Scalable identity system

Choose did:jwk when you need:

• Simplicity
• Self-contained verification
• Offline capabilities
• Quick implementation

Do you want to know more about web5 and decentralization? Join the tbd community today.

This is my GitHub