Frameworks Used

In evaluating threats to the DID ecosystem, we used two different analytic models: STRIDE and Adversaries.

STRIDE is a framework developed by Praerit Garg and Loren Kohnfelder of Microsoft, and described in Adam Shostack's Threat Modeling: Designing for Security (https://shostack.org/books/threat-modeling-book). It also has an excellent Wikipedia article (https://en.wikipedia.org/wiki/STRIDE_model). "STRIDE" is an acronym for six computer security threats: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege.

Adversaries is a framework developed by Christopher Allen, and described in his Smart Custody book discussing strategies for securing legacy wealth in the form of cryptocurrencies. It is available at https://www.smartcustody.com/. The approach identifies 27 adversaries in seven different categories: Loss by Acts of God, Loss by Computer Error, Loss by Crime (Theft), Loss by Crime (Other Attacks), Loss by Government, Loss by Mistakes, and Privacy-related Problems. We include Allen's approach because it deals with several long-term threats that are not caused by active attackers and are essentially missed in STRIDE. For example, passive threats such as Loss by Acts of God and Loss by Computer Error can be significant when considering threats to the DID ecosystem.

Does a threat model need a conformance section?

Components

This table lists each component in the DID ecosystem architecture: identifier, name, and description. Data flows and data objects are described in their respective sections below.

Key Architectural Considerations

The threat boundaries specify areas of concern created because different parties may control different aspects of the system. We break the trust regions into known areas of concern for the DID specification itself, with appreciation for the value of further analysis to address challenges of flows within each trust zone.

This is most relevant in several places:

1. The DID Controller Device is expected to securely store private keys and execute cryptographic operations. The isolation of the DID Controller Application from other applications on the same device is critical for security.
2. The Verifiable Data Registry MUST provide integrity guarantees for stored DID documents. Different DID methods make different trust assumptions about their underlying registries, from fully decentralized blockchains to centralized databases.
3. DID Resolvers act as intermediaries and MUST faithfully retrieve and return DID documents without modification. Verifiers may choose to trust specific resolvers or operate their own resolver infrastructure.
4. Each component is expected to maintain its own local data cache for performance and availability. The data flows for each cache are identified because they create threats related to data freshness, integrity, and confidentiality.
5. Private key material MUST never leave the DID Controller's trusted execution environment except through secure key backup or recovery mechanisms explicitly controlled by the DID Controller.

Threat T1: Private Key Compromise

The private key associated with a DID verification method is stolen, exposed, or otherwise compromised, allowing an attacker to impersonate the DID Controller and make unauthorized updates to the DID document or sign fraudulent proofs.

Response R1. Key Protection and Rotation [Mitigate]

Private keys MUST be stored in secure storage provided by the DID Controller Device, such as hardware security modules, secure enclaves, or encrypted key stores. DID Controllers SHOULD implement key rotation capabilities, allowing compromised keys to be replaced without losing control of the DID. DID documents SHOULD support multiple verification methods to enable key rotation and recovery mechanisms. Controllers SHOULD monitor for unauthorized use of their DIDs and be prepared to rotate keys or deactivate DIDs if compromise is detected.

Affected Components: O4. Private Key, S1. Controller Local Storage, B1. DID Controller Device, P1. DID Controller Application

Analysis Framework: STRIDE (Spoofing, Elevation of Privilege), Adversaries (Loss by Crime - Theft)

Threat T2: DID Document Tampering

An attacker modifies a DID document in transit or in storage to redirect verification methods or service endpoints to malicious resources controlled by the attacker.

Response R2. Cryptographic Integrity [Mitigate]

DID documents SHOULD be protected by the integrity guarantees of the underlying Verifiable Data Registry. For registry types that don't provide inherent integrity protection, DID documents SHOULD be signed by the DID Controller. Resolvers and Verifiers MUST validate the integrity of DID documents against the source registry. Any modification to a properly registered DID document will fail integrity checks and MUST be rejected by verifiers.

Affected Components: P2. Verifiable Data Registry, O3. DID Document, F5. Registry Query

Analysis Framework: STRIDE (Tampering)

Threat T3: Resolver Spoofing

A malicious or compromised DID resolver returns falsified DID documents that don't match what is recorded in the Verifiable Data Registry, potentially redirecting verifiers to attacker-controlled resources.

Response R3. Direct Registry Verification [Mitigate]

Verifiers with high security requirements SHOULD operate their own DID resolvers or directly query the Verifiable Data Registry to avoid dependency on third-party resolvers. When using third-party resolvers, verifiers SHOULD implement resolver redundancy by querying multiple independent resolvers and comparing results. DID documents resolved through untrusted resolvers SHOULD be validated against the source registry when possible. Resolvers SHOULD provide cryptographic proof of the DID document's origin from the registry.

Affected Components: P3. DID Resolver, F4. DID Resolution Request, F5. Registry Query, F6. DID Document Response

Analysis Framework: STRIDE (Spoofing, Tampering, Information Disclosure)

Threat T4: Verifiable Data Registry Compromise

The underlying registry (blockchain, distributed ledger, database) is compromised through 51% attack, consensus manipulation, database breach, or other means, affecting the integrity and availability of all DIDs recorded in that registry.

Response R4. Registry Selection and Redundancy [Accept and Mitigate]

This threat is largely outside the scope of the DID specification and depends on the security properties of the chosen Verifiable Data Registry. DID Controllers SHOULD select DID methods backed by registries with appropriate security guarantees for their use case. For high-value identifiers, controllers MAY register the same DID or equivalent DIDs across multiple registries to provide redundancy. Critical applications SHOULD monitor registry health and have contingency plans for registry compromise, including migration paths to alternative registries. The DID specification accepts that registry-level compromise is possible and relies on the registry's own security mechanisms for protection.

Affected Components: P2. Verifiable Data Registry, B3. Verifiable Data Registry System, S2. Registry Storage

Analysis Framework: STRIDE (Tampering, Denial of Service), Adversaries (Loss by Crime - Other Attacks)

Threat T5: DID Recovery Process Exploitation

Adversaries exploit DID recovery mechanisms (social recovery, key recovery services, backup systems) to seize control of DIDs from legitimate controllers. Recovery processes designed to help users regain access become attack vectors when improperly secured or when recovery credentials are compromised.

Response R5. Secure Recovery Mechanisms [Mitigate]

DID recovery mechanisms MUST implement strong authentication requirements that are distinct from primary authentication methods. Social recovery systems SHOULD require multiple independent parties to prevent single points of failure. Recovery processes SHOULD include time delays and notification mechanisms to alert controllers of recovery attempts. Recovery credentials SHOULD be stored separately from primary keys and protected with equivalent or stronger security measures. Controllers SHOULD regularly audit and update recovery configurations. DID method specifications SHOULD define secure recovery procedures specific to their architecture.

Affected Components: P1. DID Controller Application, S1. Controller Local Storage, O4. Private Key, F3. DID Update

Analysis Framework: STRIDE (Spoofing, Elevation of Privilege), Adversaries (Loss by Crime - Theft)

Threat T6: Cache Poisoning and Freshness Attacks

Attackers poison DID document caches to serve stale or malicious documents, especially after key rotation or deactivation events. Cached documents may contain compromised keys or outdated service endpoints, allowing attackers to impersonate controllers or redirect traffic even after legitimate updates.

Response R6. Cache Validation and Freshness Controls [Mitigate]

Caches MUST implement time-to-live (TTL) mechanisms appropriate to the security requirements of the application. Resolvers and verifiers SHOULD validate cached documents against the authoritative registry for high-security operations. Caches SHOULD implement cache invalidation mechanisms that respond to update notifications. When key rotation or deactivation is detected, applications MUST flush relevant cache entries immediately. Verifiers SHOULD compare cache timestamps against known update events. DID documents SHOULD include metadata indicating last modification time to facilitate freshness validation.

Affected Components: S3. Resolver Cache, S4. Verifier Local Storage, F10. Resolver Cache Management, F11. Verifier Cache Management

Analysis Framework: STRIDE (Tampering, Information Disclosure), Adversaries (Loss by Computer Error)

Threat T7: Unauthorized DID Document Change Detection Failure

The lack of standardized notification mechanisms means controllers may not learn when their DID documents are modified, enabling undetected unauthorized modifications. Attackers who compromise a controller's keys can make changes that go unnoticed for extended periods.

Response R7. Change Monitoring and Notification [Mitigate]

Controllers SHOULD implement automated monitoring of their DID documents for unexpected changes. Applications SHOULD provide notification services that alert controllers when document modifications occur. Controllers SHOULD maintain local copies of their DID document state and regularly compare against the registry. DID method specifications SHOULD define event notification mechanisms for document updates. For high-security applications, controllers SHOULD subscribe to blockchain monitoring services or implement webhook notifications. Multi-party monitoring services MAY be used to provide independent verification of document state.

Affected Components: O3. DID Document, P2. Verifiable Data Registry, F3. DID Update, P1. DID Controller Application

Analysis Framework: STRIDE (Tampering, Repudiation), Adversaries (Loss by Crime - Other Attacks)

Threat T8: Verification Method Controller Delegation Attack

Controllers can set verification methods controlled by other parties without granting document update rights. This creates scenarios where unauthorized parties can authenticate on behalf of an identifier while remaining unable to modify the authoritative document, enabling selective impersonation attacks.

Response R8. Verification Method Binding Validation [Mitigate]

Verifiers SHOULD distinguish between document controllers and verification method controllers when evaluating proofs. Applications SHOULD validate that verification methods are appropriately bound to the DID subject. Controllers SHOULD clearly document the purpose and scope of each verification method. Verification methods controlled by external parties SHOULD be explicitly marked and their authorization scope limited. Verifiers MAY require verification methods to be controlled by the same entity as the document for high-security operations. DID documents SHOULD use the controller property to make delegation relationships explicit.

Affected Components: O1. Verification Method, O3. DID Document, O6. Cryptographic Proof, P4. Verifier Application

Analysis Framework: STRIDE (Spoofing, Elevation of Privilege)

Threat T9: Expired/Revoked Key Verification Bypass

Systems may fail to check expiration dates or revocation status of verification methods, allowing expired or revoked keys to remain functional. This undermines the security model by permitting authentication with compromised or outdated cryptographic material.

Response R9. Mandatory Validity Checking [Mitigate]

Verifiers MUST check expiration timestamps on verification methods before accepting cryptographic proofs. Systems MUST NOT verify any proofs associated with expired or revoked verification methods. DID documents SHOULD include explicit expiration dates for all verification methods. Revocation mechanisms MUST be checked before trusting verification methods. Applications SHOULD reject proofs if they cannot verify the validity status of the associated verification method. DID method specifications SHOULD define how expiration and revocation information is expressed and validated.

Affected Components: O1. Verification Method, O6. Cryptographic Proof, P4. Verifier Application, F4. DID Resolution Request

Analysis Framework: STRIDE (Spoofing, Elevation of Privilege)

Threat T10: DID Method Manipulation

An attacker exploits vulnerabilities in a specific DID method implementation to create fraudulent DIDs, corrupt the resolution process, or gain unauthorized control over existing DIDs.

Response R10. Method-Specific Security Requirements [Mitigate and Transfer]

Each DID method specification MUST define security considerations specific to that method's architecture. Implementers MUST follow the security requirements defined in the DID method specification they choose to implement. Verifiers SHOULD maintain a list of trusted DID methods and MAY reject DIDs using methods that don't meet their security requirements. This specification establishes baseline security requirements, but method-specific threats are the responsibility of individual DID method specifications.

Affected Components: P2. Verifiable Data Registry, O5. DID, F2. DID Registration

Analysis Framework: STRIDE (Spoofing, Tampering, Elevation of Privilege)

Threat T11: DID Deactivation/Deletion

An unauthorized party deactivates or deletes a DID, causing denial of service for legitimate users who need to resolve the DID or verify proofs associated with it.

Response R11. Authorization and Audit Trail [Mitigate]

DID deactivation operations MUST require cryptographic proof of authorization from the DID Controller. The Verifiable Data Registry SHOULD maintain an audit trail of all DID lifecycle operations including deactivation. DID method specifications SHOULD define whether deactivated DIDs remain resolvable (returning a deactivated status) or become completely unresolvable. For critical DIDs, implementers MAY use multi-signature or threshold authorization requirements for deactivation to prevent unauthorized deactivation even if a single key is compromised.

Affected Components: F7. DID Deactivation, P2. Verifiable Data Registry, O4. Private Key

Analysis Framework: STRIDE (Denial of Service, Elevation of Privilege)

Threat T12: Time-of-Check to Time-of-Use Race Conditions

Between resolving a DID document and using its verification methods, the document could be updated maliciously. This creates race conditions where stale keys or service endpoints are used for verification, potentially allowing attackers to exploit the timing window.

Response R12. Atomic Resolution and Validation [Mitigate]

Applications SHOULD minimize the time window between DID document resolution and verification method use. Verifiers SHOULD include document resolution timestamps in verification decisions. For high-security operations, verifiers SHOULD re-resolve DIDs immediately before critical operations. Applications SHOULD validate that DID documents have not been updated between resolution and use. Verification methods SHOULD include nonces or timestamps that bind them to specific document states. DID method specifications SHOULD provide mechanisms to detect concurrent modifications during verification flows.

Affected Components: P3. DID Resolver, P4. Verifier Application, F4. DID Resolution Request, F6. DID Document Response

Analysis Framework: STRIDE (Tampering, Elevation of Privilege)

Threat T13: Key Rotation Failure

Improper key rotation procedures leave old compromised keys valid or break the continuity of the DID, causing either security vulnerabilities or loss of access to the identifier.

Response R13. Structured Key Management [Mitigate]

DID documents SHOULD support multiple concurrent verification methods to enable smooth key rotation without service interruption. When rotating keys, controllers SHOULD follow a process of: (1) adding the new verification method to the DID document, (2) updating all systems to use the new key, (3) monitoring for continued use of the old key, and (4) removing the old verification method only after confirming all systems have migrated. DID method specifications SHOULD define best practices for key rotation specific to their registry architecture. Controllers SHOULD maintain secure backups of all key material and recovery mechanisms to prevent permanent loss of DID control during rotation failures.

Affected Components: F8. Key Rotation, O1. Verification Method, O4. Private Key, O3. DID Document

Analysis Framework: STRIDE (Denial of Service), Adversaries (Loss by Mistakes)

Threat T14: Equivalence/Canonical ID Confusion Attack

Multiple equivalent identifiers (alsoKnownAs, canonical IDs) for the same subject can be exploited to bypass security checks or create confusion attacks where different equivalent forms are treated inconsistently across systems.

Response R14. Equivalence Validation and Normalization [Mitigate]

Verifiers SHOULD normalize DIDs to canonical form before making security decisions. Applications SHOULD validate equivalence relationships cryptographically before accepting them. Systems SHOULD maintain consistent treatment of equivalent identifiers across all security boundaries. When processing alsoKnownAs properties, verifiers SHOULD verify that the controller of each equivalent identifier approves the equivalence relationship. Security policies SHOULD be applied uniformly to all equivalent forms of an identifier. DID method specifications SHOULD define canonical identifier forms and equivalence validation procedures.

Affected Components: O5. DID, O3. DID Document, P4. Verifier Application

Analysis Framework: STRIDE (Spoofing, Elevation of Privilege)

Threat T15: Service Endpoint Exploitation

Malicious or compromised service endpoints listed in DID documents are used for phishing, data exfiltration, malware distribution, or other attacks against parties who trust and interact with those endpoints.

Response R15. Endpoint Validation and Least Privilege [Mitigate]

Verifiers SHOULD NOT automatically trust service endpoints listed in DID documents. Applications interacting with service endpoints SHOULD validate TLS certificates, implement timeout and rate limiting, and treat responses as potentially malicious input requiring validation. Service endpoints SHOULD be used with the principle of least privilege, only accessing the minimum necessary functionality. DID Controllers SHOULD regularly audit service endpoints in their DID documents and remove any that are no longer needed or trusted. When possible, service endpoint URLs SHOULD use the DID URL syntax to tie the endpoint cryptographically to the DID itself. Verifiers MAY implement allowlists or denylists of service endpoint domains based on reputation systems.

Affected Components: O2. Service Endpoint, O3. DID Document, P4. Verifier Application

Analysis Framework: STRIDE (Spoofing, Information Disclosure, Elevation of Privilege), Adversaries (Loss by Crime - Other Attacks)

Threat T16: Amplification/Resource Exhaustion Attacks

Crafted DID resolution requests with small, valid inputs result in exponentially costly processing, exhausting resolver or registry resources through denial-of-service attacks. Malicious DIDs could reference complex resolution chains or trigger expensive cryptographic operations.

Response R16. Resource Limiting and Rate Controls [Mitigate]

Resolvers SHOULD implement resource limits on resolution operations, including maximum resolution chain depth, timeout limits, and computational budgets. Systems SHOULD implement rate limiting on resolution requests per client. DID method specifications SHOULD define maximum complexity bounds for resolution operations. Resolvers SHOULD detect and reject resolution loops or excessively deep delegation chains. Applications SHOULD monitor resource consumption during resolution and abort expensive operations. Registries SHOULD validate DID documents for complexity before accepting registration.

Affected Components: P3. DID Resolver, P2. Verifiable Data Registry, F4. DID Resolution Request, F5. Registry Query

Analysis Framework: STRIDE (Denial of Service), Adversaries (Loss by Crime - Other Attacks)

Threat T17: Multi-Controller Authorization Confusion

With multiple controllers for a single identifier, authorization decisions become ambiguous. Any controller can modify the document, potentially creating conflicting or malicious changes without consensus mechanisms, leading to authorization confusion and security policy bypass.

Response R17. Multi-Controller Governance [Mitigate]

DID documents with multiple controllers SHOULD clearly specify governance rules for updates. Implementations SHOULD consider requiring multi-signature or threshold authorization for critical operations when multiple controllers exist. Controllers SHOULD establish off-chain agreements about update authorization before deploying multi-controller DIDs. Verifiers SHOULD be aware that any listed controller can modify the document. Applications SHOULD monitor for conflicting updates from different controllers. DID method specifications SHOULD define how multi-controller authorization is handled and validated.

Affected Components: O3. DID Document, F3. DID Update, P2. Verifiable Data Registry, E1. DID Controller

Analysis Framework: STRIDE (Tampering, Elevation of Privilege, Repudiation)

Threat T18: Immutable Data Exposure

DID documents on immutable registries (blockchains) cannot be corrected or removed if they contain errors or sensitive information. This creates permanent exposure risks, privacy violations, and regulatory compliance issues (GDPR right to erasure).

Response R18. Privacy-Preserving Design [Accept and Mitigate]

Controllers SHOULD carefully review DID documents before publishing to immutable registries. DID documents SHOULD NOT contain personally identifiable information or sensitive data. Applications SHOULD use content-addressed references rather than embedding content directly. Controllers SHOULD use deactivation rather than deletion for immutable registries. For privacy-sensitive applications, controllers SHOULD select DID methods that support document modification or deletion. Implementers SHOULD educate users about the permanence of data on immutable registries. This threat is partially accepted as inherent to certain registry types.

Affected Components: O3. DID Document, P2. Verifiable Data Registry, S2. Registry Storage

Analysis Framework: STRIDE (Information Disclosure), Adversaries (Privacy-related Problems, Loss by Mistakes)

Threat T19: DID URL Fragment Exploitation

DID URLs with fragments reference specific resources within documents. Malicious fragments could redirect to attacker-controlled verification methods or service endpoints within otherwise legitimate documents, or exploit parsing vulnerabilities in fragment handling.

Response R19. Fragment Validation and Sanitization [Mitigate]

Applications SHOULD validate that DID URL fragments reference legitimate resources within the resolved document. Verifiers SHOULD sanitize fragment identifiers to prevent injection attacks. Applications SHOULD validate that referenced resources match expected types (e.g., a verification method fragment should reference a verification method). Systems SHOULD implement strict parsing of DID URL syntax. Verifiers SHOULD reject malformed or suspicious fragments. Applications SHOULD apply security policies to fragment-referenced resources as strictly as to the full document.

Affected Components: O5. DID, O3. DID Document, P4. Verifier Application, F4. DID Resolution Request

Analysis Framework: STRIDE (Spoofing, Tampering)

Threat T20: Correlation Attack

Multiple uses of the same DID across different contexts allow tracking and profiling of the DID subject, compromising privacy even when the DID document doesn't contain directly identifying information.

Response R20. Pairwise and Limited-Use DIDs [Mitigate]

DID Controllers SHOULD create unique pairwise DIDs for each relationship or context to prevent correlation across different verifiers. For high-privacy scenarios, controllers SHOULD use single-use DIDs that are deactivated after a single interaction. DID method specifications SHOULD support efficient creation of multiple DIDs to enable these privacy practices. Applications SHOULD educate users about the privacy implications of DID reuse and provide easy mechanisms for creating context-specific DIDs.

Affected Components: O5. DID, E1. DID Controller, E2. Verifier

Analysis Framework: STRIDE (Information Disclosure), Adversaries (Privacy-related Problems)

Threat T21: Personal Data and Service Endpoint Correlation

Service endpoints and personal data (email addresses, social media accounts, websites) publicly advertised in DID documents enable tracking and profiling across contexts. Even with pairwise DIDs, service endpoints can reveal identity and enable correlation.

Response R21. Minimal Service Endpoint Disclosure [Mitigate]

Controllers SHOULD NOT include personal data or identifying information in service endpoints unless necessary. Applications SHOULD discourage revealing social media accounts, personal websites, or email addresses in DID documents. For high-privacy scenarios, service endpoints SHOULD use anonymous or context-specific addresses. Controllers SHOULD use different service endpoints for different contexts to prevent correlation. Applications SHOULD warn users when adding potentially correlatable service endpoints. Privacy-preserving communication protocols SHOULD be preferred over direct endpoint disclosure.

Affected Components: O2. Service Endpoint, O3. DID Document, E1. DID Controller

Analysis Framework: STRIDE (Information Disclosure), Adversaries (Privacy-related Problems)

Threat T22: Group Privacy and Herd Privacy Leakage

DID method choice, registry selection, transaction patterns, and usage behaviors can reveal group membership or organizational affiliation. Even with pairwise DIDs, metadata about DID creation and usage can compromise privacy by revealing associations.

Response R22. Anonymity Set Preservation [Mitigate]

Controllers SHOULD select DID methods with large user populations to maximize anonymity sets. Applications SHOULD avoid creating unique transaction patterns that distinguish users. DID creation and update operations SHOULD be timed to avoid correlation with other activities. Controllers SHOULD use common registration patterns rather than distinctive configurations. Privacy-focused DID methods SHOULD implement transaction mixing or anonymity-enhancing technologies. Applications SHOULD educate users about metadata privacy risks.

Affected Components: O5. DID, P2. Verifiable Data Registry, F2. DID Registration, E1. DID Controller

Analysis Framework: STRIDE (Information Disclosure), Adversaries (Privacy-related Problems)

Threat T23: Unsupported DID Methods

A verifier encounters a DID using a method they don't support or recognize, creating interoperability failures that prevent the verifier from resolving the DID or validating associated proofs.

Response R23. Method Discovery and Graceful Degradation [Accept and Mitigate]

Verifiers SHOULD clearly document which DID methods they support. Universal resolvers SHOULD support a broad range of DID methods to maximize interoperability. When encountering an unsupported DID method, applications SHOULD provide clear error messages and, where possible, offer alternative verification mechanisms. The DID specification accepts that not all verifiers will support all methods. Controllers SHOULD consider the method support landscape when selecting a DID method, choosing methods with broad adoption when interoperability is important.

Affected Components: O5. DID, P3. DID Resolver, P4. Verifier Application

Analysis Framework: STRIDE (Denial of Service), Adversaries (Loss by Computer Error - Bitrot)

Threat T24: Encrypted Data Key Management Failure

Storing encrypted data in DID documents creates permanent data loss if encryption keys are lost, or permanent exposure if keys are compromised. No lifecycle management exists for encrypted content, creating long-term key management challenges.

Response R24. Encrypted Data Lifecycle Management [Mitigate]

Controllers SHOULD avoid storing encrypted data directly in DID documents. Applications SHOULD use content-addressed references to encrypted data stored elsewhere. When encryption is necessary, controllers MUST implement robust key backup and recovery procedures. Encrypted content SHOULD include key rotation mechanisms. Applications SHOULD document key management responsibilities clearly. For high-value encrypted data, controllers SHOULD implement key escrow or multi-party key management. DID method specifications SHOULD provide guidance on encrypted data handling.

Affected Components: O3. DID Document, O4. Private Key, S1. Controller Local Storage

Analysis Framework: STRIDE (Information Disclosure, Denial of Service), Adversaries (Loss by Mistakes)

Threat T25: Quantum Computing Cryptographic Break

Future quantum computers could break current cryptographic algorithms used in DIDs, compromising all historical encrypted data and signatures. Harvest-now, decrypt-later attacks could compromise data retroactively when quantum computers become available.

Response R25. Post-Quantum Preparedness [Accept and Mitigate]

This is a long-term threat that is partially accepted given current technology limitations. DID method specifications SHOULD support cryptographic agility to enable future algorithm upgrades. Applications SHOULD monitor post-quantum cryptography standardization efforts. Controllers SHOULD plan for eventual migration to post-quantum algorithms. For highly sensitive long-term data, controllers MAY implement hybrid cryptographic schemes combining classical and post-quantum algorithms. The ecosystem SHOULD establish migration paths for transitioning to quantum-resistant cryptography. This threat requires ongoing monitoring of cryptographic research and standardization.

Affected Components: O1. Verification Method, O4. Private Key, O6. Cryptographic Proof

Analysis Framework: STRIDE (Spoofing, Information Disclosure), Adversaries (Loss by Computer Error - Technical Obsolescence)