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 Method | Blockchain | Key Features | Use Cases | Pros | Cons |
---|---|---|---|---|---|
did:ethr | Ethereum | Uses Ethereum's public key infrastructure Support key rotation & delegation | General-purpose decentralized identity dApps and Web3 services | Large ecosystem Flexible & extensible | Gas fees for operations Scalability concerns. |
did:sov | Sovrin | Built on Hyperledger Indy Governance framework for trust | Enterprise identity solutions Regulated industries | Strong privacy features Designed for compliance | Less flexible than some alternatives Centralized governance. |
did:web | Web domains | Uses existing web infrastructure No blockchain required | Organizational identity Easy transition from centralized systems | Simple to implement Leverage existing DNS | Relies on domain ownership Less decentralized than blockchain solutions. |
did:key | None (self-contained) | Fully self-contained Stateless and portable | Offline or air-gapped systems Temporary or disposable identities | Simple and lightweight No external dependencies | Limited functionality No built-in key rotation. |
did:ion | Bitcoin(anchoring only) | No built-in key rotation High throughput | Scalable decentralized identity Scalable decentralized identity | Scalable and cost-effective Leverages Bitcoin's security | More complex than some alternatives Relatively new compared to others |
DID methods like
did:ion
(Bitcoin) anddid:ethr
(Ethereum) offer strong decentralization due to their use of public blockchains, though they come with trade-offs like higher complexity and costs. Methods likedid:sov
provide decentralized identity within a permissioned network, offering specialized identity features but limiting decentralization.Methods like
did:web
, anddid: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.
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:
- Security requirements
- Scalability needs
- Cost constraints
- Performance requirements
- Decentralization priorities
- Integration complexity
- Maintenance capability
- Regulatory compliance
Selection Guidelines
- Start with simplest method that meets requirements
- Consider future scaling needs
- Evaluate operational costs
- Assess technical expertise required
- Review regulatory implications
- Test in representative environments
- Plan for key management
- 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
- Applications needing quick identity lookup
- Systems requiring decentralized control
- Projects with limited blockchain budget
- 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
- Simple verification needs
- Offline scenarios
- Testing environments
- 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
Top comments (0)