{"data":{"id":"SP-052","slug":"decentralised-identity-verifiable-credentials","title":"Decentralised Identity & Verifiable Credentials","description":"Security architecture for decentralised identity (DID/SSI) systems covering W3C DID method selection and resolution, Verifiable Credential (VC) issuance and verification, holder wallet architecture, EU Digital Identity Wallet (EUDIW) eIDAS 2.0 compliance, zero-knowledge selective disclosure (ZK proofs, BBS+ signatures, SD-JWT), trust registry governance, revocation mechanisms (StatusList2021, accumulator-based), and GDPR-compliant privacy architecture. Addresses the transition from federated identity (SAML, OIDC) to holder-controlled, cryptographically verifiable credentials. Maps 35 NIST 800-53 controls across IA, AC, SC, AU, PM, PT, SA, CM, IR, and RA families. Applicable to government digital identity schemes, financial services KYC/AML, healthcare patient identity, and cross-border credential recognition under eIDAS 2.0.","url":"https://www.opensecurityarchitecture.org/patterns/sp-052","metadata":{"release":"26.03","classification":"Identity & Access Management","status":"draft","type":"pattern","datePublished":"2026-03-10","dateModified":"2026-03-10","authors":["Spinoza","Vitruvius"],"reviewers":[],"provenance":"Developed in response to the accelerating adoption of W3C Decentralised Identifiers (DID) and Verifiable Credentials (VC) standards by governments, financial services firms, and enterprises seeking to move beyond federated identity. Informed by the eIDAS 2.0 Architecture Reference Framework (ARF v1.4, 2024), the EU Digital Identity Wallet (EUDIW) specification, W3C DID Core 1.0, W3C VC Data Model 2.0, OpenID for Verifiable Credential Issuance (OID4VCI), and OpenID for Verifiable Presentations (OID4VP) standards. The EU mandate requiring member states to offer EUDIW-compatible wallets by 2026 and the growing adoption of EBSI for cross-border credential recognition have made DID/SSI architecture a practical enterprise concern rather than a research curiosity."},"diagram":{"svg":"/images/sp-052-decentralised-identity-verifiable-credentials.svg"},"legend":"Architecture zones represent the DID/VC trust triangle: Issuer (credential creation and signing), Holder (wallet custody and selective disclosure), and Verifier (credential verification and trust policy enforcement). Colour coding: Navy (#003459) — cryptographic infrastructure (DID registries, key management); OSA Blue (#007EA7) — trust governance (trust registries, accreditation authorities); Sky (#00A8E8) — protocol flows (issuance, presentation, verification); Midnight (#00171F) — governance and regulatory overlays (eIDAS 2.0, GDPR). Critical controls (IA-05, SC-12, SC-13, IA-08) govern the cryptographic binding between DIDs and credential claims. NIST control badges link to detailed control descriptions.","content":{"description":"Decentralised identity replaces the traditional identity provider (IdP) hub-and-spoke model with a cryptographic trust triangle: Issuers publish signed Verifiable Credentials into Holder wallets; Holders present selective disclosures to Verifiers; Verifiers resolve Issuer DIDs to retrieve public keys and validate signatures — without contacting the Issuer or any central authority at verification time. This pattern covers the security architecture decisions required to implement this model safely at enterprise scale.\n\nThe W3C DID Core 1.0 specification defines a globally resolvable identifier format (did:method:identifier) backed by a DID document containing public keys, service endpoints, and capability delegations. Method selection (did:web for enterprise, did:key for ephemeral, did:ion for anchored, did:ethr for Ethereum-based) determines the trust and availability model. The W3C VC Data Model 2.0 defines the structure of signed claims, with JSON-LD and JWT as primary serialisations.\n\nThe EU Digital Identity Wallet (EUDIW) under eIDAS 2.0 mandates a Level of Assurance (LoA) framework aligned to ISO/IEC 29115 (Low/Substantial/High), with Qualified Electronic Attestations of Attributes (QEAAs) issued by accredited Trust Service Providers (TSPs). This creates a regulated trust anchor distinct from the permissionless DID ecosystem. EBSI (European Blockchain Services Infrastructure) provides a public permissioned ledger for DID registration and trusted issuer registries.\n\nZero-knowledge selective disclosure addresses the privacy gap in basic VC presentations: a holder can prove age over 18 without revealing date of birth, or prove membership of a licensed professional body without revealing their name. BBS+ signatures (IETF draft) enable multi-message signing where any subset of claims can be disclosed with a derived proof. SD-JWT (IETF RFC 9901) provides a simpler selective disclosure mechanism using salted hash commitments, adopted by eIDAS 2.0 ARF as the primary format for EUDIW. Both approaches must be implemented without correlation risk — each presentation must use a fresh proof to prevent verifiers from linking presentations to the same holder.","keyControlAreas":["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."],"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.","typicalChallenges":"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.","indications":"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.","contraIndications":"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.","threatResistance":"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."},"examples":{"DID Method Selection":["Enterprise issuer (financial institution) deploying a KYC credential: use did:web anchored to the institution's regulated domain (e.g., did:web:kyc.acmecorp.com). The DID document is served over HTTPS with the institution's EV certificate — TLS/DNS provides the trust anchor. Key material held in FIPS 140-2 Level 3 HSM. DID document cached at verifiers with a max-age of 1 hour; stale documents trigger re-resolution before accepting high-value presentations.","Government national ID wallet (EUDIW): use EBSI DID method (did:ebsi:...) anchored to the European Blockchain Services Infrastructure permissioned ledger. EBSI nodes are operated by EU member state governments, providing sovereign trust anchoring without dependency on commercial blockchains. The DID document is registered once at wallet provisioning; key rotation is performed via DID document update signed by the current authentication key.","Ephemeral device credential for IoT provisioning: use did:key (Ed25519) — a self-describing DID that encodes the public key directly in the DID string, requiring no registry resolution. Suitable for short-lived device credentials (24-hour TTL) where revocation is handled by expiry, not revocation list. No on-ledger registration, no resolution infrastructure dependency, but no update or revocation path beyond natural expiry.","Healthcare professional licence verification: dual-DID architecture — the professional holds a long-lived did:web DID controlled by the professional regulator (GMC, NMC) as the subject; each presentation uses a fresh pairwise did:key to prevent hospital systems from correlating the professional's activity across institutions. The regulator-issued did:web serves as the public identity anchor for licence verification; the ephemeral did:key provides presentation unlinkability."],"Verifiable Credential Issuance":["OID4VCI pre-authorised code flow for batch employee credential issuance: HR system triggers issuance after identity proofing completion; issues a pre-authorised code to the employee's wallet app via deep link; wallet redeems code at the credential endpoint (/credential) with proof-of-possession JWT signed by the wallet's binding key; issuer validates proof, constructs SD-JWT credential with claims {given_name, family_name, employee_id, department, clearance_level}, signs with issuer DID key, returns credential. Each claim is individually salted and hashed, enabling selective disclosure at presentation.","Qualified Electronic Attestation of Attributes (QEAA) issuance for EUDIW: identity proofing at LoA High (in-person at bank branch with passport NFC read + facial biometric comparison); binding to EUDIW wallet via wallet attestation (proof that wallet is certified); credential issued as SD-JWT signed with qualified HSM key; StatusList2021 revocation endpoint registered at issuance; credential validity period 12 months with quarterly revalidation check recommended to relying parties.","Age verification credential with ZK disclosure: issuer issues a BBS+ signed credential containing {date_of_birth, nationality, document_number}; wallet derives a presentation proof proving date_of_birth is more than 18 years before today without revealing the actual date — implemented as a Pedersen commitment over the birthdate with a range proof; verifier receives only the proof and a boolean (over_18: true) with a fresh unlinkable BBS+ derived proof; no correlation possible between presentations."],"Trust Registry Integration":["Verifier policy engine: on receiving a VP (Verifiable Presentation), the verifier extracts the Issuer DID from each VC, resolves the DID document to obtain the signing public key, validates the credential signature, checks the credential status (StatusList2021 HTTP GET), and then queries the trust registry API to confirm the issuer is authorised to make the claimed credential type. Trust registry response is itself a signed VC (Trusted Issuer Record) issued by the sector authority. If any step fails, the entire presentation is rejected.","Multi-tier trust framework for professional credentials: Root Trust Anchor = Professional Standards Authority (signed self-issued VC pinned in code); Intermediate Trust Anchors = individual regulatory bodies (GMC, SRA, ICAEW) each holding a VC signed by PSA certifying their scope of authority; Leaf Issuers = individual employers or training providers, each holding a VC signed by their regulatory body. A verifier accepting a pharmacist credential chain-validates: Pharmacist VC → signed by GPhC DID → GPhC Trusted Issuer VC → signed by PSA DID → PSA DID pinned in verifier trust store. Revocation at any level propagates downward.","EBSI trust registry for cross-border EU credential recognition: member state issues mDL (mobile driving licence) as a EUDIW credential using EBSI-registered issuer DID. Another member state's verifier (e.g., car rental company in France receiving a German licence) resolves the German issuer DID via EBSI, finds it listed in the EBSI Trusted Issuer Registry as authorised to issue driving licences in Germany, validates the BBS+ credential signature, and accepts the presentation. No bilateral agreement between Germany and France required — EBSI provides the common trust anchor."],"Revocation Architecture":["StatusList2021 implementation: maintain a bitstring of 131,072 bits (16KB) per status list credential, each bit representing one issued credential. The status list credential is a VC signed by the issuer, published at a stable URL (https://issuer.example.com/credentials/status/1), and cached by verifiers. To revoke credential N, set bit N in the bitstring and re-sign the status list. Verifiers fetch the status list at most once per hour; within that window, revocation propagation latency is acceptable for most use cases. For high-assurance use cases (payment authorisation), use a 5-minute cache TTL.","Short-lived credential strategy for session access: instead of long-lived VCs with revocation infrastructure, issue access credentials with a 15-minute expiry. The holder's wallet automatically requests a fresh credential from the issuer endpoint at each session (silent re-issuance via OID4VCI refresh token). If the holder's status changes (employment termination, suspension), the issuer simply stops issuing renewal credentials. No revocation infrastructure required; maximum exposure window equals the credential TTL.","Accumulator-based non-revocation for privacy-critical use cases: RSA accumulator maintained by the issuer; on issuance, the credential index is added to the accumulator; the current accumulator value and a membership witness (specific to each credential) are provided to the holder. At presentation, the holder proves their witness is valid against the current accumulator value without revealing their index. Revocation removes the index from the accumulator (requires updating witnesses for all remaining holders — operationally expensive, suitable only for small, high-value credential sets such as judicial warrants or security clearances)."],"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."]},"references":[{"title":"W3C Decentralised Identifiers (DIDs) v1.0","url":"https://www.w3.org/TR/did-core/","note":"Core specification defining the DID syntax, data model, and conformance requirements"},{"title":"W3C Verifiable Credentials Data Model v2.0","url":"https://www.w3.org/TR/vc-data-model-2.0/","note":"Defines the structure and security model for Verifiable Credentials and Verifiable Presentations"},{"title":"EU Digital Identity Wallet Architecture and Reference Framework (ARF) v1.4","url":"https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework","note":"Authoritative technical specification for eIDAS 2.0 EUDIW implementation"},{"title":"OpenID for Verifiable Credential Issuance (OID4VCI)","url":"https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html","note":"Protocol specification for credential issuance over OAuth 2.0 infrastructure"},{"title":"OpenID for Verifiable Presentations (OID4VP)","url":"https://openid.net/specs/openid-4-verifiable-presentations-1_0.html","note":"Protocol specification for credential presentation within OIDC/OAuth 2.0 flows"},{"title":"IETF SD-JWT: Selective Disclosure for JWTs (RFC 9901)","url":"https://www.rfc-editor.org/rfc/rfc9901","note":"Selective disclosure mechanism adopted by eIDAS 2.0 ARF as primary EUDIW credential format"},{"title":"BBS Signature Scheme (IETF Draft)","url":"https://identity.foundation/bbs-signature/draft-irtf-cfrg-bbs-signatures.html","note":"Multi-message signature scheme enabling unlinkable selective disclosure proofs"},{"title":"W3C Bitstring Status List (formerly StatusList2021)","url":"https://www.w3.org/TR/vc-bitstring-status-list/","note":"Privacy-preserving revocation mechanism for Verifiable Credentials"},{"title":"EBSI Technical Documentation — Trusted Issuers Registry","url":"https://hub.ebsi.eu/vc-framework/trust-model","note":"European Blockchain Services Infrastructure trust model and issuer registry specification"},{"title":"DIF Presentation Exchange v2.0","url":"https://identity.foundation/presentation-exchange/","note":"Standard format for verifiers to request specific credential types and selective disclosures"},{"title":"NIST SP 800-63-4 Digital Identity Guidelines","url":"https://pages.nist.gov/800-63-4/","note":"Updated identity assurance framework with coverage of decentralised identity approaches"},{"title":"ENISA Digital Identity: Leveraging the SSI Concept to Build Trust","url":"https://www.enisa.europa.eu/publications/digital-identity-leveraging-the-ssi-concept-to-build-trust","note":"EU cybersecurity agency report (January 2022) on self-sovereign identity under eIDAS. Covers architectural elements, governance mechanisms, and the security risks and opportunities of decentralised electronic identity."}],"relatedPatterns":["SP-029","SP-033","SP-040","SP-044","SP-051"],"relatedPatternNames":["Zero Trust Architecture","Passkey Authentication","Post-Quantum Cryptography and Quantum Readiness","SaaS Identity Lifecycle Management","Tokenised Asset Security Architecture"],"controls":[{"id":"IA-01","name":"Policy and Procedures","family":"IA","emphasis":"important"},{"id":"IA-02","name":"Identification and Authentication (Organizational Users)","family":"IA","emphasis":"important"},{"id":"IA-04","name":"Identifier Management","family":"IA","emphasis":"critical"},{"id":"IA-05","name":"Authenticator Management","family":"IA","emphasis":"critical"},{"id":"IA-08","name":"Identification and Authentication (Non-organizational Users)","family":"IA","emphasis":"critical"},{"id":"IA-12","name":"Identity Proofing","family":"IA","emphasis":"critical"},{"id":"IA-13","name":"Identity Providers and Authorization Servers","family":"IA","emphasis":"important"},{"id":"AC-01","name":"Policy and Procedures","family":"AC","emphasis":"standard"},{"id":"AC-03","name":"Access Enforcement","family":"AC","emphasis":"important"},{"id":"AC-04","name":"Information Flow Enforcement","family":"AC","emphasis":"important"},{"id":"AC-16","name":"Security and Privacy Attributes","family":"AC","emphasis":"important"},{"id":"AC-19","name":"Access Control for Mobile Devices","family":"AC","emphasis":"important"},{"id":"SC-08","name":"Transmission Confidentiality and Integrity","family":"SC","emphasis":"important"},{"id":"SC-12","name":"Cryptographic Key Establishment and Management","family":"SC","emphasis":"critical"},{"id":"SC-13","name":"Cryptographic Protection","family":"SC","emphasis":"critical"},{"id":"SC-17","name":"Public Key Infrastructure Certificates","family":"SC","emphasis":"important"},{"id":"SC-28","name":"Protection of Information at Rest","family":"SC","emphasis":"important"},{"id":"AU-02","name":"Event Logging","family":"AU","emphasis":"important"},{"id":"AU-06","name":"Audit Record Review, Analysis, and Reporting","family":"AU","emphasis":"standard"},{"id":"AU-10","name":"Non-repudiation","family":"AU","emphasis":"critical"},{"id":"PM-07","name":"Enterprise Architecture","family":"PM","emphasis":"important"},{"id":"PM-18","name":"Privacy Program Plan","family":"PM","emphasis":"important"},{"id":"PT-01","name":"Policy and Procedures","family":"PT","emphasis":"critical"},{"id":"PT-02","name":"Authority to Process Personally Identifiable Information","family":"PT","emphasis":"critical"},{"id":"PT-03","name":"Personally Identifiable Information Processing Purposes","family":"PT","emphasis":"critical"},{"id":"PT-05","name":"Privacy Notice","family":"PT","emphasis":"important"},{"id":"SA-04","name":"Acquisition Process","family":"SA","emphasis":"standard"},{"id":"SA-09","name":"External System Services","family":"SA","emphasis":"important"},{"id":"SA-11","name":"Developer Testing and Evaluation","family":"SA","emphasis":"important"},{"id":"CM-03","name":"Configuration Change Control","family":"CM","emphasis":"important"},{"id":"CM-06","name":"Configuration Settings","family":"CM","emphasis":"standard"},{"id":"IR-04","name":"Incident Handling","family":"IR","emphasis":"important"},{"id":"IR-09","name":"Information Spillage Response","family":"IR","emphasis":"standard"},{"id":"RA-03","name":"Risk Assessment","family":"RA","emphasis":"important"},{"id":"SI-07","name":"Software, Firmware, and Information Integrity","family":"SI","emphasis":"important"}],"controlFamilySummary":{"IA":7,"AC":5,"SC":5,"AU":3,"PM":2,"PT":4,"SA":3,"CM":2,"IR":2,"RA":1,"SI":1},"threats":[{"id":"T-DID-001","title":"Credential Replay and Presentation Theft","description":"Attacker intercepts a Verifiable Presentation in transit or at the verifier and replays it to impersonate the holder at another relying party. Without holder binding and nonce enforcement, any party who captures a signed VP can reuse it. Particularly relevant in offline/proximity presentation scenarios (NFC, QR code) where the channel is not authenticated.","mitigatedBy":["IA-05","AU-10","SC-08","SC-13"]},{"id":"T-DID-002","title":"Issuer DID Impersonation and Forgery","description":"Attacker registers a DID that appears visually similar to a legitimate issuer DID (homoglyph attack in did:web domain names, or registration of a look-alike did:ethr address), then issues fraudulent credentials under the rogue DID. Verifiers without a trust registry check accept the forged credentials because the cryptographic signature is valid — just not from the expected issuer.","mitigatedBy":["IA-08","SA-09","PM-07","RA-03"]},{"id":"T-DID-003","title":"Holder Wallet Key Extraction","description":"Attacker compromises the holder device (malware, physical access, rogue wallet app) and extracts private key material from the wallet's software keystore. With the holder's private key, the attacker can present any credential held in that wallet indefinitely until the key is rotated. Software-only keystores on rooted/jailbroken devices are most vulnerable; attacks on secure enclaves require hardware-level exploits.","mitigatedBy":["IA-05","SC-12","SC-28","AC-19","IR-04"]},{"id":"T-DID-004","title":"Credential Correlation and Holder Tracking","description":"Verifiers collude or are compromised to correlate holder activity across presentations. Even without revealing the holder's identity, a stable holder DID or non-rotating key identifier allows verifiers to build a profile of where, when, and what the holder presents credentials for. Metadata (IP address, timing, credential types) enables re-identification even when selective disclosure is in use.","mitigatedBy":["PT-01","PT-02","PT-03","SC-13","AC-04"]},{"id":"T-DID-005","title":"Trust Registry Poisoning","description":"Attacker compromises the trust registry (EBSI node, sector authority credential signing key) and inserts a malicious issuer entry, causing verifiers to accept credentials from an unauthorised issuer. This is a single point of failure in the entire ecosystem trust model — all relying parties that depend on that registry are simultaneously compromised. EBSI's permissioned consensus model reduces but does not eliminate this risk.","mitigatedBy":["SA-09","PM-07","CM-03","AU-10","RA-03"]},{"id":"T-DID-006","title":"DID Document Hijack via DNS/PKI Compromise","description":"For did:web method, the DID document is served via HTTPS at a well-known path on the issuer domain. An attacker who compromises DNS (BGP hijack, DNS cache poisoning) or the issuer's TLS certificate (misissuance via compromised CA) can serve a fraudulent DID document with the attacker's public key, enabling them to sign credentials that appear to come from the legitimate issuer.","mitigatedBy":["SC-17","SC-08","SC-12","SI-07","AU-02"]},{"id":"T-DID-007","title":"Revocation Infrastructure Denial of Service","description":"Attacker performs a DDoS attack against the revocation status endpoint (StatusList2021 URL), causing verifiers to be unable to check credential status. Verifiers that fail-open (accept credentials when revocation status is unavailable) will continue accepting revoked credentials; those that fail-closed will reject all credentials, causing service outage. Both failure modes are unacceptable for high-assurance relying parties.","mitigatedBy":["IR-04","AU-02","CM-06","SC-08"]},{"id":"T-DID-008","title":"Issuer Key Compromise Leading to Mass Credential Forgery","description":"Attacker obtains the issuer's DID signing private key (via HSM compromise, insider threat, key export vulnerability, or supply chain attack on the issuance software stack) and uses it to mint arbitrary credentials. Unlike X.509 CA compromise, there is no browser-trust-store mechanism to instantly revoke issuer trust — verifiers must be individually notified to stop trusting the compromised DID. Mass forgery of government ID, health credentials, or financial attestations is possible before detection.","mitigatedBy":["SC-12","IA-05","AU-10","IR-04","SA-11"]},{"id":"T-DID-009","title":"Key Recovery Attack via Social Engineering","description":"Attacker uses social engineering against the holder or the holder's designated key recovery contacts (Shamir Secret Sharing share holders, recovery service custodian) to reconstruct the holder's private key. Recovery flows are designed for usability and often lack the authentication rigour of the primary credential flow — a recovery phone number or email account with weak security becomes the effective authentication factor for the entire wallet.","mitigatedBy":["IA-05","IA-12","SC-12","IR-04","PT-01"]},{"id":"T-DID-010","title":"Governance Bypass via Namespace Collision","description":"Attacker exploits ambiguity in how verifiers resolve DID method namespaces or credential type URIs to cause a credential of type A to be accepted as type B. For example, a credential with type URI http://example.org/credentials/DriversLicense might be accepted by a verifier expecting https://gov.example/credentials/DriversLicense if the verifier does not perform strict URI matching. JSON-LD context resolution failures can result in undefined type interpretations, enabling semantic confusion attacks.","mitigatedBy":["CM-06","SA-04","AC-03","SI-07"]}],"context":{"dataTypes":[{"ref":"TDCE-PII-01","state":["at-rest","in-transit","in-use"],"volume":"medium"},{"ref":"TDCE-AUTH-01","state":["at-rest","in-transit"],"volume":"medium"}],"protocols":[{"ref":"TPE-WEB-01","boundary":"external","direction":"bidirectional"},{"ref":"TPE-API-01","boundary":"external","direction":"bidirectional"}],"assetTypes":["identity-wallet","credential-issuer","trust-registry","did-resolver","key-management-service","revocation-service"],"adversaryProfile":{"minTier":"TACM-T2","relevantActorTypes":["cybercriminal","nation-state","insider-malicious","competitor"]},"regulatoryScope":["GDPR","eIDAS-2.0","NIS2","DORA"],"humanFactors":["THFM-COG-01","THFM-SOC-02"]}}}