Guidelines for Choosing a DID Method

As explained in the video, there are several key factors that influence the choice of a DID method. The most relevant aspects are highlighted below:

Subject of the DID

The choice of a DID method significantly depends on whether the DID represents a person, an organization, or a thing (such as an IoT object). Each of these subjects faces different legal and functional considerations:

  • Persons: For individuals, data protection regulations, like the GDPR in Europe, impose strict requirements, including the right to be forgotten. This means that any system using DIDs to identify individuals must allow for the deletion of personal data to comply with these regulations. Therefore, DID methods that utilize immutable technologies, such as certain blockchains, might not be suitable if they do not allow for compliance with these rules.
  • Organizations: Organizations may need DIDs with advanced functionalities, such as the management of multiple authorized signatories with different levels of authorization. The complexity and power structure within an organization may require a more sophisticated DID method that supports these complex features.
  • Things: DIDs representing objects may have less stringent requirements in terms of privacy regulations but might need to support a high volume of transactions or secure interactions with other devices.

Legal and Regulatory Framework

The legal and regulatory environment is crucial when selecting a DID method, especially concerning personal identities. Privacy and data protection laws vary significantly across jurisdictions and can dictate not only the choice of the DID method but also the underlying infrastructure used to store and manage DIDs.

Required Functionality vs. Technical Complexity

Choosing a DID method also involves weighing the required functionality against the technical complexity and infrastructure requirements. Some methods offer advanced functionalities, such as key rotation and the designation of authorized signers, but may require a more complex infrastructure and be more costly to maintain. On the other hand, simpler methods might offer fewer functionalities but be easier and cheaper to implement and manage.

Regulation Compliance

Specifically, for individuals, it is crucial to choose a DID method that allows for compliance with data protection regulations. This may involve the ability to efficiently modify or delete personal information from the system to honor the right to be forgotten and other privacy protections.

Balance between Functionality and Regulatory Compliance

Finally, finding the right balance between the functionality offered by the DID method and compliance with data protection regulations is a challenge. In some cases, like the European Union’s last-minute adjustments to comply with the GDPR, this balance may compromise functionality to ensure legal compliance.


In summary, choosing a DID method is a complex decision that should be based on a detailed understanding of the subject to be identified, the applicable legal and regulatory requirements, and the specific needs of functionality versus technical complexity and implementation costs. However, to simplify the complexity of this subject somewhat, this table may serve as a useful tool:

DID MethodGeneral SpecificationsGuidelines for Use
DID WebUtilizes standard URLs as identifiers that are resolvable via HTTP/S.Suitable for use cases where web interoperability and ease of resolution are critical.
DID KeyGenerates DIDs from a pair of cryptographic keys, ideal for straightforward verification.Appropriate for scenarios requiring quick and direct setup without the need for additional infrastructure.
DID IONBased on the Bitcoin network, offers a scalable and secure decentralized identity solution.Recommended for applications that need high security and can benefit from the robustness of the Bitcoin network.
DID QuarkidA decentralized, public, permissionless, open, extensible, multi-chain, and interoperable SSI protocol​“【oaicite:1】“​​“【oaicite:0】“​.Ideal for implementations in Latin America and situations that require interoperability and flexibility in digital identity management.