Decentralised Identity & Verifiable Credentials

Key Control Areas

• DID Method Selection and Resolution Security (IA-08, SC-12): Choose DID methods appropriate to the trust model. did:web anchors trust to DNS/TLS — suitable for enterprise issuers with established PKI but vulnerable to DNS hijacking. did:key is ephemeral and self-certifying — suitable for ephemeral agent identities but offers no revocation path. did:ion and did:ethr provide cryptographic anchoring to public ledgers (Bitcoin Sidetree, Ethereum) with stronger non-repudiation. Universal resolver deployment must validate DID document integrity and reject stale or unsigned documents.
• Key Management for DIDs (SC-12, IA-05, SC-28): Each DID document references one or more public keys for authentication, assertion, key agreement, and capability invocation. The corresponding private keys must be protected in hardware security modules (HSMs) or secure enclaves for high-assurance issuers, or in secure element/Trusted Execution Environment (TEE) for mobile wallets. Key rotation must be reflected in the DID document without breaking existing credential validity — implementors must track key version at time of issuance (verificationMethod reference in credential proof).
• Verifiable Credential Issuance Pipeline (IA-05, SA-11, CM-03): The issuance API must authenticate the credential subject using LoA-appropriate identity proofing before binding claims. OID4VCI (OpenID for Verifiable Credential Issuance) is the emerging standard issuance protocol. Credentials must be signed with the Issuer's DID key, include an expiry (exp claim), and reference a revocation mechanism. Credential schema validation must enforce type constraints before signing to prevent malformed credentials propagating through the ecosystem.
• Holder Wallet Security (IA-05, SC-28, AC-19): The wallet is the most attack-targeted component — it holds private keys and all credentials. Architectural requirements: device binding (key generated in secure element, non-exportable), backup/recovery mechanism that does not expose key material (BIP-39 social recovery or custodial backup with threshold encryption), biometric unlock with OS-level secure storage, and credential compartmentalisation (separate key pairs per issuer relationship to prevent holder correlation). EUDIW wallets must be certified against EN 17926 (EUDIW certification scheme).
• Selective Disclosure and Zero-Knowledge Proofs (SC-13, PT-01, PT-03): Implement selective disclosure to enforce data minimisation at the protocol level. SD-JWT: the issuer produces salted hashes of each claim; the holder discloses only the salt+value pairs for requested claims. BBS+: the issuer signs all claims in a single group-signature; the holder derives a fresh unlinkable proof over a subset of claims. For age verification without date-of-birth disclosure, implement range proofs (e.g., Bulletproofs, Groth16 circuits). Each presentation must use a fresh nonce from the verifier to prevent replay attacks.
• Trust Registry and Issuer Accreditation (PM-07, SA-09, RA-03): Verifiers must have a reliable mechanism to determine which issuers are authorised to make particular claims. Trust registries (EBSI Trusted Issuer Registry, X.509 PKI hierarchies, Gaia-X notarisation) provide this anchoring. Implement a layered trust model: Root Trust Anchors (government CAs, EBSI notaries) accredit Intermediate Trust Anchors (sector bodies, professional associations) which accredit Leaf Issuers (individual institutions). Trust registry entries must themselves be verifiable credentials signed by the accrediting authority.
• Revocation Architecture (IA-05, SI-07, AU-02): StatusList2021 (W3C Bitstring Status List) embeds a compact bit-array at a published URL; verifiers check the bit at the credential's statusListIndex without revealing which credential they are checking (privacy-preserving). Accumulator-based revocation (RSA accumulators, Merkle tree accumulators) allows zero-knowledge non-revocation proofs but requires accumulator updates to be distributed to all holders. Short-lived credentials (15-minute TTL for access tokens, 24-hour TTL for session credentials) can replace revocation for lower-sensitivity use cases. Revocation check freshness must be bounded — accept cached status only within a defined window (default: 1 hour for high-assurance, 24 hours for standard).
• Privacy Architecture and GDPR Compliance (PT-01, PT-02, PT-03, PT-05): DIDs and VCs create novel GDPR tensions: the DID itself may constitute personal data if it is persistent and linkable to a natural person; on-ledger DID registration makes erasure requests technically complex; verifiable presentations create audit logs at the verifier. Mitigations: use pairwise DIDs (different DID per relationship) to prevent correlation; minimise on-ledger data (hash commitments only, no PII); implement right-to-erasure via credential revocation (the credential becomes worthless without valid status) and DID document deletion; ensure holder consent is captured for each credential issuance.
• eIDAS 2.0 EUDIW Compliance (IA-08, IA-12, SA-09, PM-07): Implementing a Qualified Trust Service Provider (QTSP) or wallet-relying party under eIDAS 2.0 requires: EUDIW wallet certification (EN 17926), QEAA issuance requires qualified HSMs (CC EAL 4+ or FIPS 140-2 Level 3), LoA assessment at the instance level (Low — self-assertion, Substantial — remote identity proofing, High — in-person proofing with government document verification), and cross-border recognition of QEAAs from other EU member states via the EUDIW trust framework. The ARF mandates SD-JWT as the primary credential format.
• Cross-Protocol Interoperability (SC-08, CM-06, SA-04): The DID/VC ecosystem intersects with existing identity protocols. OID4VP (OpenID for Verifiable Presentations) enables credential presentation within existing OAuth 2.0/OIDC infrastructure — verifiers act as OAuth Resource Servers with DIF Presentation Exchange as the presentation request format. SIOPv2 (Self-Issued OpenID Provider v2) allows holders to act as their own OpenID Providers. Implementors must manage version compatibility across W3C VC Data Model 1.1 and 2.0, JSON-LD context resolution failures, and DID method sunset risk.
• Audit and Non-Repudiation (AU-02, AU-06, AU-10): Issuer signing logs must record: DID of subject, credential type, claims bound, signing timestamp, and key reference — without logging PII claim values. Verifier audit logs must record: credential type presented, issuer DID, verification result, and verifier purpose — not the claims themselves. Implement audit log integrity via append-only log with periodic hash chaining (similar to Certificate Transparency). Non-repudiation at the verifier: the signed VP (Verifiable Presentation) with verifier-provided nonce constitutes cryptographic proof of presentation.

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.