Skip to main content

How did:scid Addresses the Limitations of Legacy DID Methods

mhrsntrk

mhrsntrk / September 16, 2025

While established DID methods like did:ion, did:ethr, did:key, and did:web have pioneered the decentralized identity landscape, they each carry inherent limitations that become apparent at scale. Enter did:scid—a new DID method specifically designed to maximize the benefits of Self-Certifying Identifiers (SCIDs) while addressing the core challenges that have constrained earlier implementations.

Understanding Self-Certifying Identifiers

At its core, did:scid revolves around Self-Certifying Identifiers—cryptographically verifiable identifiers that are bound directly to the cryptographic keys from which they were generated. This fundamental design eliminates the need for third-party verification, as the binding can be verified using only the verification metadata (DID documents and key event history).

Unlike traditional DIDs that may depend on specific infrastructure or third-party services for verification, SCIDs enable truly autonomous identity verification—a critical advancement for achieving genuine self-sovereignty.

Three Pillars of Innovation

1. True Portability and Location Independence

The most significant limitation of existing methods is their binding to specific locations or infrastructure. did:web ties identities to domain names, did:ethr requires Ethereum network access, and did:ion depends on IPFS and Bitcoin infrastructure.

did:scid breaks these chains by separating the identifier from its verification metadata location. The DID itself is a pure SCID that never needs to change, while location information is conveyed through a standard query parameter in did:scid URLs. This means:

  • Multi-anchoring capability: Store verification metadata across web servers, blockchains, trust registries, databases, or file systems simultaneously
  • Infrastructure agnostic: Move between different storage solutions without changing the DID
  • Permanent immutable account identifiers: The DID remains constant regardless of where verification metadata is stored

2. Enhanced Privacy and Security

did:scid implements several security improvements over legacy methods:

  • Cryptographic event logs: Each new version of verification metadata includes a hash of the previous version, creating a tamper-evident hashchain or microledger
  • Secure generation: The cryptographic binding can be generated entirely within digital wallets, secure elements, or HSMs
  • Pairwise pseudonyms: Lightweight enough to support automatic pairwise private DID connections for individuals
  • Encrypted private channels: Enables DID applications to automatically use encrypted communications

3. Format Flexibility and Ecosystem Integration

Rather than creating another isolated standard, did:scid is designed as a "metamethod" that can support multiple SCID-based formats. This enables:

  • Backward compatibility: Support for existing formats like did:peer, did:webs and did:webvh
  • Developer choice: Teams can choose the SCID format that works best for their use case
  • Future-proofing: Extensible to support new SCID-based formats as they emerge
  • Cryptographic agility: Version identifiers support evolution as newer cryptographic algorithms are developed

Addressing Real-World Requirements

The did:scid specification directly addresses practical requirements that have emerged from real-world implementations, particularly those identified by Bluesky for supporting millions of accounts:

  • Low marginal costs: No expensive blockchain transactions for basic operations
  • Rapid creation and updates: Sub-second identifier operations
  • Reliable performance: Predictable latency for both updates and resolution
  • Long-term durability: Identifiers function after periods of inactivity
  • Context-free resolution: New resolvers can independently resolve old identifiers

Multi-Anchoring: The Game Changer

One of did:scid's most innovative features is multi-anchoring—the ability to store verification metadata in multiple locations simultaneously. This addresses several critical challenges:

Resilience: If one storage location becomes unavailable, others remain accessible Performance: Different locations can serve different geographic regions or use cases Trust: Multiple independent storage locations increase tamper resistance Compliance: Meet different regulatory or organizational requirements simultaneously

For example, a did:scid identifier could simultaneously store its verification metadata on a web server for fast access, a blockchain for immutability, and a peer-to-peer network for censorship resistance—all while maintaining a single, unchanging DID.

Practical Implementation Examples

The specification demonstrates this flexibility through concrete examples:

# Pure SCID for peer-to-peer usage
did:scid:vh:1:QmfGEUAcMpzo25kF2Rhn8L5FAXysfGnkzjwdKoNPi615XQ

# Same DID with web server source
did:scid:vh:1:QmfGEUAcMpzo25kF2Rhn8L5FAXysfGnkzjwdKoNPi615XQ?src=example.com/allan

# Same DID with blockchain source  
did:scid:vh:1:QmfGEUAcMpzo25kF2Rhn8L5FAXysfGnkzjwdKoNPi615XQ?src=did:cheqd:testnet

Looking Forward

did:scid represents a maturation of decentralized identity concepts, learning from the limitations and successes of earlier methods. By focusing on the fundamental properties that make identifiers truly self-sovereign —cryptographic self-certification, location independence, and infrastructure agnosticity— it provides a foundation for the next generation of decentralized identity applications.

For developers building identity systems today, did:scid offers a path to create more resilient, portable, and future-proof solutions. Rather than being locked into specific infrastructure choices, applications can evolve their storage and verification strategies while maintaining consistent user identities.

The decentralized identity space continues to evolve rapidly, but did:scid suggests a direction toward greater flexibility, security, and true user sovereignty—principles that will likely define the next chapter of digital identity.