Overview
Decentralized Identifiers (DIDs) are globally unique identifiers that enable verifiable, self-sovereign digital identities. Unlike traditional identifiers managed by central authorities (email addresses, usernames, government IDs), DIDs are created and controlled by the identity owner through cryptographic keys. DIDs serve as the foundational addressing layer for decentralized identity, enabling independent verification of digital signatures and encrypted communications without relying on a central authority. They're integral to Verifiable Credentials (VCs), where the issuer's DID Document provides the public key needed to validate credential signatures. While DIDs can leverage blockchain technology, many DID methods (did:web, did:key) work without distributed ledgers. Good looks like user-controlled identity that works across systems, cryptographically verifiable without contacting issuers, and privacy-preserving through selective disclosure.
Architecture & Reference Patterns
Pattern 1: DID Resolution Architecture
DIDs are resolved to DID Documents through method-specific resolvers:
DID String → DID Resolver → DID Method Handler → DID Document
↓ ↓ ↓ ↓
did:web:example.com Universal HTTPS Fetch Public Keys
did:key:z6Mk... Resolver Key Derivation Auth Methods
did:ion:0xe4... Blockchain Query Service Endpoints
The DID Document contains:
- Verification Methods: Public keys for signature verification
- Authentication Methods: Methods to prove control of the DID
- Service Endpoints: URLs for messaging, credential repositories
- Metadata: Management information (created, updated, deactivated)
Pattern 2: DID-Based Authentication
Replace password authentication with DID-based cryptographic proof:
Service presents challenge → User signs with DID private key →
Service resolves DID → Retrieves public key → Verifies signature →
Authentication complete (no password, no central IdP)
Pattern 3: Organizational DID Hierarchy
Enterprises can use DIDs for organizational identity:
- Root organizational DID (verified through
did:web:company.com) - Departmental DIDs derived or linked to organizational DID
- Employee DIDs with organizational attestation
- System/service DIDs for workload identity
Key Decisions
| Decision | Options | Recommendation | Notes / Gotchas |
|---|---|---|---|
| DID method selection | did:web, did:key, did:ion, did:ethr, did:peer | did:web for orgs, did:key for ephemeral | Match method to use case; consider decentralization needs |
| Key management | Software wallet, Hardware security key, HSM | HSM for organizational, hardware key for individuals | Key loss = identity loss; recovery planning critical |
| Resolver deployment | Universal resolver (hosted), Self-hosted, Embedded | Universal resolver for dev, self-hosted for production | Control resolution infrastructure for critical use cases |
| Blockchain vs. non-blockchain | Blockchain-based (did:ion), Web-based (did:web), Key-based (did:key) | Non-blockchain for most enterprise use cases | Blockchain adds complexity; evaluate if decentralization needed |
| DID rotation strategy | Single long-lived DID, Periodic rotation, Per-relationship DIDs | Per-relationship DIDs for privacy | Multiple DIDs prevent correlation across contexts |
| Recovery mechanism | Social recovery, Multi-sig, Backup keys | Multi-sig + backup for organizations | Single key = single point of failure |
Implementation Approach
Phase 0: Discovery
Inputs: Use case requirements, existing identity infrastructure, regulatory constraints, technical capabilities Outputs: DID use case analysis, method evaluation, integration requirements, proof-of-concept scope
Phase 1: Design
Inputs: Use case analysis, selected DID methods, integration requirements Outputs: DID architecture design, key management strategy, resolver deployment plan, credential format alignment (with VCs), recovery procedures
Phase 2: Build & Integrate
Inputs: Architecture design, selected tools/libraries, integration specifications Outputs: DID infrastructure deployed, resolver operational, key management implemented, credential issuance/verification integrated, developer documentation
Phase 3: Rollout
Inputs: Built infrastructure, pilot plan, user onboarding materials Outputs: Pilot deployment with selected use cases, user wallet provisioning, operational procedures validated, feedback collection
Phase 4: Operate
Inputs: Production infrastructure, operational procedures Outputs: Ongoing operations, key rotation management, resolver monitoring, adoption metrics tracking, ecosystem participation
Deliverables
- DID architecture design and method selection rationale
- Key management strategy and procedures
- Resolver deployment and operations guide
- Integration specifications for applications
- Credential issuance workflow documentation
- Recovery and rotation procedures
- Developer documentation and SDKs
- User wallet/agent guidance
Risks & Failure Modes
| Risk | Likelihood | Impact | Early Signals | Mitigation |
|---|---|---|---|---|
| Key loss results in identity loss | M | H | User lockouts, recovery requests | Multi-sig, social recovery, backup procedures |
| DID method becomes obsolete | L | H | Reduced community support, interoperability issues | Method-agnostic design, migration planning |
| Resolver unavailability blocks verification | M | M | Verification failures, service outages | Redundant resolvers, caching, fallback methods |
| User adoption challenges (wallet complexity) | H | M | Low enrollment, support tickets | UX investment, familiar analogies, progressive onboarding |
| Regulatory uncertainty | M | M | Compliance questions, legal guidance delays | Legal review, regulatory monitoring, flexible design |
KPIs / Outcomes
- DID adoption rate (percentage of target users with DIDs)
- Credential verification success rate (target: greater than 99%)
- Resolver availability (target: greater than 99.9%)
- Key recovery incidents (track volume and resolution time)
- Verification latency (target: less than 500ms)
- Cross-system authentication success (measure interoperability)