Why the DID Core Specification's Extensibility is Its Greatest Weakness

The spec's optional parameters create a combinatorial explosion of non-standard DID methods. Wallets and verifiers must implement bespoke logic for each variant, making universal resolvers a myth.

• Result: A user's did:example:123 is unreadable by a verifier built for did:key:456.
• Evidence: Over 100+ registered DID methods with wildly different governance and technical stacks.

Extensible proof formats (JWT, LD-Proofs) and key types force verifiers to support an ever-growing attack surface. Security audits become impossible against a moving target.

• Result: Relying Parties either reject valid credentials or accept insecure ones.
• Vector: A verifier supporting Ed25519 signatures may blindly trust a malicious did:web credential using an unsupported, broken algorithm.

User-centric design fails when credentials and keys are locked to a specific method's ecosystem. Moving from did:ethr to did:sol requires re-issuance of all attestations, a multi-party coordination nightmare.

• Result: Users are siloed, and DID providers achieve de facto lock-in.
• Metric: Zero major projects have successfully executed a cross-method user migration at scale.

No central authority to deprecate broken or malicious DID methods. The W3C registry is a list, not a gatekeeper. This allows low-security methods to persist, tarnishing the entire ecosystem's reputation.

• Result: Scam did:phishing methods exist alongside legitimate ones, with no clear signal for users.
• Consequence: Enterprise adoption stalls due to unacceptable liability and lack of a trusted root.

Generic DID resolvers must handle everything from on-chain lookups to HTTP requests. The lack of a mandated, optimized primitive forces worst-case latency for every resolution.

• Result: A simple did:key resolution is burdened by infrastructure built to handle slow did:web or did:btcr calls.
• Latency: Resolution times vary from ~50ms to 10+ seconds, destroying UX.

Ironically, decentralized identifiers often rely on centralized, method-specific infrastructure (did:web on a single server, did:ethr on a specific RPC). Extensibility discourages the hard work of building robust, decentralized resolution layers.

• Result: The system replaces centralized databases with centralized protocol gatekeepers.
• Example: A did:ion identity is only as available as Microsoft's Ion node cluster.

DID methods define their own proof formats, making credentials from one ecosystem unverifiable in another. This defeats the core purpose of portable, user-owned identity.

• W3C VC-DATA-MODEL is a standard, but its JWT vs JSON-LD implementation split creates parallel universes.
• Issuers like EBSI and Spruce ID use incompatible signature suites and verification methods.
• Result: A credential from a KYC provider is useless for accessing a DeFi protocol on a different stack.

Every DID method requires a custom resolver, forcing applications to integrate and trust dozens of endpoints. This creates centralization, latency, and security risks.

• Universal Resolvers become single points of failure and censorship.
• Performance degrades with ~100-500ms added latency per cross-method lookup.
• Projects like ION (Bitcoin) and did:key have zero incentive to ensure mutual resolvability.

Custom DID methods enable privacy features (e.g., did:indy pairwise identifiers), but the lack of a universal privacy baseline means most implementations leak data by default.

• did:web exposes personal server endpoints, creating correlation vectors.
• Without standardized ZKP frameworks or privacy-preserving presentations, users revert to opaque centralized logins.
• The result is a lowest-common-denominator privacy model dominated by OAuth and Web2 paradigms.

Corporates and governments need deterministic, auditable systems. DID Core's optionality forces them to create restrictive, non-interoperable profiles, recreating walled gardens.

• Microsoft Entra Verified ID and IBM Verify Credentials implement different subsets of the spec.
• Compliance teams reject open-ended specs, leading to bespoke, permissioned ledgers like Corda or Hyperledger Indy.
• This stifles the network effects a universal decentralized identity layer requires.

Wallet developers face exponential complexity supporting multiple DID methods, verification suites, and presentation formats. This cost is passed to users as bloat and delayed features.

• Wallets like MetaMask or Spruce's Sign-In with Ethereum sidestep DIDs entirely, using simpler signatures.
• Supporting did:ethr, did:polygonid, and did:jwk requires 3x the engineering effort for marginal user benefit.
• The economic incentive is to ignore the spec and build proprietary identity stacks.

The fix isn't more specs, but a settlement layer for identity states. Analogous to blockchain L2s, a minimal consensus layer for DIDs could enable interoperability without restricting innovation.

• Ceramic Network acts as a composable data layer, but lacks a canonical DID resolution standard.
• Ethereum's ERC-725/735 provides a smart contract-based identity primitive, creating a shared state root.
• The goal: DID Core as a namespace, with a consensus-backed root for universal resolvability and proof verification.

Every issuer defines its own proof format and verification method. A verifier must support a combinatoric explosion of methods, not just one standard.

• Result: Verification libraries become bloated, insecure monoliths.
• Cost: Integration time balloons from days to months per new issuer type.
• Risk: Security audits are impossible; you're trusting each custom implementation.

Mandate a single, battle-tested cryptographic suite (e.g., EdDSA/Ed25519) and a canonical JSON-LD context for the core properties.

• Benefit: Verifiers write one integration. Issuers get instant, universal compatibility.
• Trade-off: Limits cryptographic agility, but agility is overrated for core identity.
• Precedent: See W3C Verifiable Credentials Data Model for a stricter, more usable approach.

A DID document can link to any resolution endpoint with any authentication scheme. This turns DID resolution into a security liability.

• Attack Vector: Malicious or compromised resolution endpoints can spoof any identity.
• Performance: Latency is unbounded, killing UX for real-time checks.
• Reality: Projects like ION (Bitcoin) and Ethereum ENS succeed by rejecting this, using deterministic, on-chain resolution.

Bind DID methods to specific, verifiable trust layers (L1s, IPFS, secure federations). Resolution becomes a deterministic lookup, not a network call to an unknown server.

• Benefit: Resolution is cryptographically verifiable and fast.
• Implementation: Use CCIP-read patterns (like ENS) or direct state proofs.
• Outcome: Eliminates entire classes of phishing and spoofing attacks.

Extensibility creates syntactic interoperability (DIDs parse) but not semantic interoperability. Two "verified" credentials from different systems convey zero guaranteed, machine-readable meaning.

• Consequence: You cannot build logic atop DIDs alone. You need a separate, heavy layer like W3C VCs or OpenAttestation.
• Fragmentation: The ecosystem splits into Sovrin, Veramo, Microsoft ION silos that don't actually talk.

Adopt and enforce a presentation protocol (like W3C Presentation Exchange or DIF's Credential Manifest) as a core dependency, not an optional extension.

• Benefit: Creates a predictable request/response flow for credential exchange.
• Clarity: Separates the DID (identifier) from the credential (claim) layer cleanly.
• Action: Build your stack assuming this layer exists; reject DIDs that don't support it.