Decentralised Identity & Verifiable Credentials
Click any control badge to view its details. Download SVG
Key Control Areas
DID Method Selection and Resolution Security
Key Management for DIDs
Verifiable Credential Issuance Pipeline
Holder Wallet Security
Selective Disclosure and Zero-Knowledge Proofs
Trust Registry and Issuer Accreditation
Revocation Architecture
Privacy Architecture and GDPR Compliance
eIDAS 2.0 EUDIW Compliance
Cross-Protocol Interoperability
Audit and Non-Repudiation
When to Use
Use this pattern when: building a digital identity wallet for citizens or employees; implementing cross-organisational credential exchange without a shared IdP; implementing KYC portability (verify once, reuse across institutions); deploying age verification with privacy preservation; participating in EUDIW as an issuer, wallet provider, or relying party; implementing professional licence verification or academic credential attestation; replacing username/password with hardware-bound cryptographic credentials.
When NOT to Use
Do not use DID/SSI as the primary enterprise identity layer if you need real-time provisioning/de-provisioning (SCIM + OIDC is simpler and more mature). DIDs add complexity without benefit for internal single-organisation identity where a standard OIDC IdP is sufficient. BBS+ and ZK proof systems should not be used in production without a formal review of the cryptographic library — the mathematics are sound but implementations are immature and supply chain risk is high. If your threat model does not require privacy-preserving selective disclosure, SD-JWT over OIDC is sufficient and much simpler to implement and audit.
Typical Challenges
DID method lock-in is the most significant architectural risk — choosing a method that loses community support or suffers a critical vulnerability can invalidate your entire credential ecosystem. Key recovery without exposing key material to a custodian is an unsolved UX problem for consumer wallets; enterprise wallets typically resolve this with M-of-N Shamir Secret Sharing held by the employer, introducing custodial trust. JSON-LD context resolution failures cause silent verification failures in production — context documents must be pinned locally or served from content-addressed storage. Revocation check performance degrades at scale with StatusList2021 if the status list URL is not CDN-distributed. GDPR compliance and on-ledger DID registration are in direct tension for did:ethr and did:ion methods — legal analysis is required before registering DIDs on public blockchains in EU contexts.
Threat Resistance
This pattern addresses: credential replay and theft (through holder binding and nonce-based presentations), issuer impersonation (through DID-anchored public key verification and trust registries), wallet compromise and key extraction (through hardware-backed key storage and device binding), correlation attacks (through pairwise DIDs and unlinkable ZK proofs), governance bypass (through layered trust registries with cryptographic accreditation chains), and key recovery attacks (through threshold key recovery with audit logging). It reduces reliance on centralised identity providers as single points of failure, and prevents mass identity disclosure events by eliminating centralised credential databases.
Assumptions
This pattern assumes the organization is operating as one or more roles in the trust triangle: Issuer (creating and signing credentials), Holder (receiving credentials into a wallet and presenting them), or Verifier (receiving and validating presentations). It assumes familiarity with public key cryptography (elliptic curve signatures, key pairs) and awareness of the W3C standards stack. For eIDAS 2.0 compliance sections, this pattern assumes an EU-regulated context or an organization seeking mutual recognition. The pattern assumes TLS 1.3 for all API transport and that DID resolution is performed over authenticated channels.
Developing Areas
- Post-quantum cryptography poses an existential challenge to the DID/VC ecosystem because the signature algorithms underpinning both DIDs and Verifiable Credentials — ECDSA (secp256k1, P-256) and EdDSA (Ed25519) — are vulnerable to Shor's algorithm on a cryptographically relevant quantum computer. Unlike short-lived TLS sessions, VCs may have multi-year validity periods: a professional licence credential issued today with an EdDSA signature could be forged by a quantum-capable adversary within the credential's lifetime, and retrospective forgery of any credential whose presentation was recorded becomes possible. NIST PQC standards (ML-DSA in FIPS 204 for general signatures, SLH-DSA in FIPS 205 for stateless hash-based signatures) are finalised but not yet integrated into any W3C DID method or VC proof suite. The BBS+ signature scheme enabling unlinkable selective disclosure has no post-quantum equivalent — research into lattice-based anonymous credentials (e.g., IBM's lattice-based DAA) is active but years from standardisation. Organisations should implement crypto-agility in their DID document structures: abstract the verificationMethod to support hybrid proof suites (classical + PQC) during transition, and plan for mass credential re-issuance when post-quantum VC proof suites are standardised. See SP-040 Post-Quantum Cryptography Migration for algorithm selection and transition planning.
- AI-generated identity fraud is fundamentally altering the threat landscape for identity proofing, the critical step that precedes credential issuance. Deepfake technology can now generate photorealistic synthetic faces, forged identity documents, and real-time video impersonation sufficient to defeat remote identity proofing at LoA Substantial — the 2024 Hong Kong deepfake video call fraud ($25.6M) demonstrated that even human-in-the-loop verification is vulnerable. For VC ecosystems, this means the integrity of every credential in circulation is only as strong as the identity proofing performed at issuance: a synthetically generated identity that passes KYC and receives a legitimate VC from a legitimate issuer is indistinguishable from a genuine credential at verification time. Biometric liveness detection (ISO/IEC 30107-3 Presentation Attack Detection) is engaged in an arms race with generative adversarial networks; injection attacks that bypass the camera entirely by feeding synthetic video directly into the verification SDK are particularly difficult to counter. The emerging defence is layered: device attestation (proving the biometric was captured on a genuine device), injection attack detection (verifying the video pipeline has not been intercepted), document authenticity verification (NFC chip reading for ePassports), and cross-referencing against known synthetic identity databases. Organisations issuing high-assurance VCs should require LoA High identity proofing with in-person or supervised remote verification for credentials that confer significant entitlements.
- Cross-ecosystem interoperability is the most significant barrier to decentralised identity achieving network effects beyond siloed deployments. The identity credential landscape is fragmenting across at least four incompatible ecosystems: W3C DID/VC (SD-JWT and JSON-LD serialisations), ISO 18013-5 mDL (mobile driving licence with CBOR/COSE encoding and device engagement protocols), ICAO Digital Travel Credentials (DTC for passport-grade credentials with sovereign PKI), and proprietary wallet platforms (Apple Identity in Wallet, Google Wallet credentials) with closed verification APIs. OID4VP is emerging as a bridge protocol — it can transport both SD-JWT VCs and ISO 18013-5 mDL credentials within a single presentation request — but adoption is uneven and the credential format Balkanisation means a verifier must implement multiple verification paths. The EU's eIDAS 2.0 ARF mandates SD-JWT for EUDIW but must accommodate mDL for driving licences and existing national eID schemes with diverse technical stacks. Without convergence on a common presentation layer, holders will need multiple wallet apps for different credential types, recreating the fragmented card-wallet experience that decentralised identity was supposed to eliminate.
- Machine identity and IoT DIDs represent a significant expansion of the DID/VC model beyond human holders to devices, autonomous agents, and software services. Supply chain provenance use cases — where a sensor device attests its calibration status, firmware version, and manufacturer identity via a device-bound VC — are being piloted by the W3C Verifiable Credentials for Supply Chain working group and industry consortia like MOBI (Mobility Open Blockchain Initiative) for vehicle identity. Extending DIDs to billions of IoT devices creates resolution scalability challenges that current DID methods were not designed for: did:web requires DNS infrastructure per device manufacturer, did:key has no update mechanism for device key rotation, and ledger-anchored methods face transaction throughput limits. The emerging approach is hierarchical delegation: a manufacturer DID issues device VCs binding each device's secure element public key to its identity, without registering individual device DIDs on any ledger — the manufacturer DID serves as the trust anchor and the device VC serves as the identity assertion. Autonomous AI agent identity adds another dimension: as agents act on behalf of humans or organisations (see SP-047 AI Agent Security), they need verifiable delegation credentials proving their authority scope, creating a DID-based capability delegation chain from principal to agent. NIST SP 800-183 (Networks of Things) and IEEE 802.1AR (Secure Device Identity) provide foundational standards, but integration with the W3C DID/VC stack remains at the proof-of-concept stage.
- Regulatory divergence on digital identity frameworks threatens to prevent the cross-border credential interoperability that is the core value proposition of decentralised identity. The EU's eIDAS 2.0 mandates government-issued EUDIW wallets with qualified trust service providers, creating a regulated top-down ecosystem; the United States has no federal digital identity framework, with a patchwork of state-level mobile driver's licence (mDL) deployments and private-sector identity solutions competing without mutual recognition. India's Aadhaar/DigiLocker ecosystem serves 1.4 billion people but uses a centralised biometric identity model fundamentally incompatible with SSI principles, while China's CTID (Cyber Trust Identity) operates within a state-controlled identity infrastructure with no interoperability mechanism for foreign credentials. Mutual recognition agreements — the legal instruments that would allow a German EUDIW credential to be accepted by a US relying party — do not exist for decentralised identity and face fundamental barriers: differing identity proofing standards, incompatible privacy regimes (GDPR vs. US sectoral privacy laws vs. China's PIPL), and divergent trust anchor models (government PKI vs. blockchain-anchored vs. centralised). The risk is that decentralised identity reproduces the jurisdictional fragmentation of traditional identity systems rather than transcending it, with organisations operating across borders forced to maintain parallel credential ecosystems for each regulatory regime.
Related Patterns
Patterns that operate within or alongside this one. Click any to view.