DID Method Rubric v1.0

2.1.1.1 Question

How open is participation in governance decisions?

2.1.1.2 Responses

1. Anyone can participate in an open, fair process where all participants have equal opportunity to be heard and influence decisions.
2. Anyone can comment and contribute to open debate, but decisions are ultimately made by a closed group.
3. Debate is restricted to a selected but known group.
4. Debate is conducted in secret by an unknown group.

2.1.1.3 Relevance

Governance determines how the rules of the underlying network are set and maintained. The more parties that are able to contribute to governance debates, the more decentralized the governance.

2.1.1.4 Examples

2.1.2.1 Question

How visible are rulemaking processes?

2.1.2.2 Responses

1. Agendas and participation details for all meetings are publicly announced, the meetings are broadcast in real-time to any listeners, and all minutes and recordings are captured in realtime and publicly reviewable in perpetuity.
2. Minutes of meetings are reviewable by the public, including all votes and who cast them, but real-time observation may be limited.
3. All current rules are publicly available.
4. Rules may be changed without public notice.

2.1.2.3 Relevance

While participation measures active contribution, transparency measures the visibility of discussions affecting rule making. If such discussions are only visible to a limited group, it centralizes decision making in ways that Evaluators and users cannot easily see.

2.1.2.4 Examples

2.1.3.1 Question

How many independent parties actively participate in the governance authority?

2.1.3.2 Responses

1. Rules are decided by an open set of multiple parties.
2. Rules are decided by a closed set of multiple parties.
3. Rules are decided by a single known entity.
4. Rules are decided by an unknown party.

2.1.3.3 Relevance

Is the governing authority for the DID Method innately centralized? Is the Method governed by a single entity, who could make arbitrary changes to the governance? Or is it governed by a closed set of parties, without fully open access? Or is there a legitimate effort to open the decision making process to multiple, competing and cooperating parties?

2.1.3.4 Examples

2.1.4.1 Question

How privatized is the economic interest of the governing authority?

2.1.4.2 Responses

1. The governing authority is established for the public good without rents or remuneration.
2. The governing authority is established for the common good of a limited set of parties.
3. The governing authority is established to enhance profits for a limited set of parties.
4. The governing authority is established to extract rents.

2.1.4.3 Relevance

The underlying financial goals of DID Method creators may affect the centralization of their Method. If the goal of a Method is to enhance or support a certain group, then there may be centralization focused on that group and their interests. In the most centralized extreme, a Method may be created explicitly to establish a monopoly market that it can extract rent from. The opposite extreme is a Method created explicitly for the public good.

2.1.4.4 Examples

2.1.5.1 Question

How expensive is it to participate in governance (in time, money, or effort)?

2.1.5.2 Responses

1. Free to all
2. Inexpensive, but accessible
3. Modest cost for interested parties
4. Expensive and restricted
5. Not possible to participate

2.1.5.3 Relevance

Governance takes resources, which can limit the ability of interested parties to influence rulemaking. Generally, the more expensive it is to participate, the more governance centralizes to those parties most able to make the investment.

2.1.5.4 Examples

2.2.1.1 Question

To use the DID Method, do you need permission?

2.2.1.2 Responses

1. Anyone can participate fully (full read/write and participation in consensus).
2. Anyone can read/write, but consensus mechanism is permissioned.
3. Anyone can read, but writing and consensus is permissioned.
4. All participation is permissioned.

2.2.1.3 Relevance

Permissioned operation impacts the availability of the network to various participants, which can affect inclusivity with regard to underserved or vulnerable populations. Permissioned networks also expose the permission giver to legal or other attacks.

2.2.1.4 Examples

2.2.2.1 Question

Does the DID Method restrict access or functionality to particular wallet implementations per the specification? (Whether or not any given wallet works with the resolver or registry is covered elsewhere.)

2.2.2.2 Responses

1. Any wallet can work with any resolver on any registry,
2. Any wallet can work with multiple resolvers and multiple registries,
3. Some implementations of some wallets can work with some resolvers,
4. There is a single combined suite of resolver, registry, and wallet.

2.2.2.3 Relevance

The ability to communicate with different (ideally all) resolvers and registries significantly increases the applicability of a decentralized identity layer / usability of a given wallet. Vice versa, limited capability to work with other Methods and registries restrict usage.

2.2.2.4 Examples

2.2.3.1 Question

How widely can DIDs of this Method be used?

2.2.3.2 Responses

1. Universal: DIDs can only be created and used universally, between any number of parties.
2. Contextual: DIDs can be created and used contextually, between any set of collaborating parties.
3. Paired: DID can be created and used pairwise, between any two parties.
4. Central: DIDs can only be created and used with a single, centralized party.

2.2.3.3 Relevance

Different Methods enable different scopes in which a DID might be considered usable or valid. For example, peer DIDs are only usable between the two peers who share unique DIDs with each other; other parties are unable to resolve the DID, find the DID Document, or use its information to establish secure interactions. In contrast, BTCR records all DIDs on a public ledger, meaning that all DIDs are fundamentally accessible to any party who might receive the DID. Contextual DIDs are a middle ground that allow a set of parties to use DIDs, while those outside that group cannot meaningfully do so. Finally, central DIDs use the DID syntax and DID Documents to establish secure communications, but authority to use these DIDs resides with the central party, who may revoke that ability at their discretion.

2.2.3.4 Examples

2.3.1.1 Question

How transparent and fair are the economics of the Method?

2.3.1.2 Responses

1. All operational finances are transparent and accounted for. ​
2. Compensation for primary operators is transparent. ​
3. Some financial flows are visible. ​
4. Operation is privatized with no visibility.

2.3.1.3 Relevance

Similar to Governance, financial accountability reflects the integrity and sustainability of the DID registry. The more open, transparent, and accountable the system, the greater the confidence a DID controller may have that it will remain stable and operational, and therefore continue to provide service.

2.3.1.4 Examples

2.3.2.1 Question

How much memory is required for DID resolution, without relying on authoritative intermediaries (e.g. blockchain explorer APIs)? We consider the amount of memory required to fully resolve a DID of the method, whether that memory is stored locally or processed ephemerally via communications.

2.3.2.2 Responses

1. Minimal. Less than 1MB
2. Modest. 1MB to 1GB
3. Substantial. 1GB to 128 GB
4. Exceptional. Over 128GB in memory

2.3.2.3 Relevance

Whether or not one can resolve a DID directly on a resource-constrained device affects the granularity at which smaller devices can be part of the ecosystem. If small edge devices, such as a smart watch, smart speaker, or even a mobile phone, are incapable of directly resolving a DID of the DID Method, then the method will lead to cloud-based services like blockchain explorer APIs, which themselves become a point of centralization. Many find this option an acceptable engineering trade-off. Others would prefer solutions that allow even the smallest devices to be fully capable of resolving DIDs in an authoritative manner.

2.3.2.4 Examples

2.3.3.1 Question

What are the minimum resources required to create a trusted DID without relying on intermediaries?

2.3.3.2 Responses

1. Minimal. Less than 1MB
2. Modest. 1MB to 1GB
3. Substantial. 1GB to 128 GB
4. Exceptional. Over 128GB in memory

2.3.3.3 Relevance

Being able to create a DID in constrained situations enables certain types of decentralized applications that otherwise are not possible. On the edge, many devices rely on gateways to manage compute-, memory-, and bandwidth- intensive tasks. For example, while a smart lightbulb might use ZigBee or 6LowPAN, it will typically use a hub to connect to the Internet, even for access from devices within the local IP network. The more resources it takes for small devices to participate in registration, the greater the percentage of those that will need to rely on centralizing factors like hubs and gateways.

2.3.3.4 Examples

2.4.1.1 Question

Who can retrieve cryptographic proof of the history of changes to a given DID Document?

2.4.1.2 Responses

1. Anyone
2. Only a select group, including parties not involved in a given DID transaction
3. Only parties to the transaction
4. Not available

2.4.1.3 Relevance

Trustlessness is a prerequisite of a decentralized system. If you have to trust the source of a DID Document (i.e., if you can't verify cryptographically a DID Document that is returned from resolution), then you are at the mercy of a potentially centralized authority. If, instead you have a cryptographic audit trail, then the current state of a DID cannot be compromised by an intermediary or central party.

2.4.1.4 Examples

2.5.1.1 Question

How many (active) substitutable, interoperable implementations support this Method?

2.5.2.1 Question

How large is the share of use by each of the top three implementations?

2.5.3.1 Question

Which platforms have implementations?

2.5.4.1 Question

Which programming languages have implementations?

2.5.5.1 Question

If there is one dominant implementation, how many programmers would need to be compromised to get a back-door into distribution?

2.5.6.1 Question

Is it forkable?

2.6.1.1 Question

How many relying parties accept DIDs of this Method?

2.6.2.1 Question

How many daily active users use this Method?

2.6.3.1 Question

How many different countries have significant usage?

2.6.4.1 Question

Which countries have significant usage?

2.6.5.1 Question

How many (human) languages are supported?

2.7.1.1 Question

What is the lowest security level ("bits of security", not to be confused with bit size of a key or hash) provided by the combination of algorithms and key types that the method requires its implementations to support?

2.7.1.2 Responses

1. No combination of required features produces a profile with less than 256 bits of security.
2. Between 128 and 256 bits. (Conventional wisdom — NIST recommendation — says that this level of security is adequate until the next revolutionary breakthrough.)
3. Less than 128 bits. (NIST recommends replacing this security by 2030.)
4. Less than 112 bits. (Security is obsolete today.)

2.7.1.3 Relevance

A DID method that requires implementations to support something weak (e.g., 1024-bit RSA) is guaranteeing that its users will cooperate by default with encryption that's relatively easy to crack, with hashing that's not adequately collision-resistant, etc. See NIST 800-57 Part 1, section 5.6.1.

2.7.1.4 Examples

2.7.2.1 Question

Does the system use cryptographic and security primitives that are well vetted by technical experts, and battle hardened in the school of experience?

2.7.2.2 Responses

1. Experts generally consider the system very secure, and this opinion is reinforced by a track record of secure production use.
2. The theoretical security of the system looks excellent, and no known attacks or substantive criticisms are unaddressed. However, limited review or limited experience informs the opinion.
3. Credible reports of vulnerabilities or design shortcomings have not been addressed.
4. The system actively uses mechanisms that are officially deprecated.

2.7.2.3 Relevance

Exotic crypto and other security mechanisms without expert review and a production track record is likely to contain hidden risks.

2.7.2.4 Examples

2.7.3.1 Question

How friendly is the system to adopting post-quantum crypto, larger hashes, or other measures that upgrade its security?

2.7.3.2 Responses

1. Any user of the system can easily upgrade their crypto at any time.
2. No code changes are needed, but the whole system needs to be reconfigured to allow new crypto.
3. Code changes must be implemented before new crypto is possible.
4. Code changes must be implemented, and migration of all existing data must be performed, before new crypto is possible.

2.7.3.3 Relevance

A DID method that is hard to upgrade with respect to crypto creates incentives to remain with deprecated algorithms beyond their useful lifespan.

2.7.3.4 Examples

2.7.4.1 Question

To what extent is the entropy used to create an identifier demonstrably connected to the party that created its inception key?

2.7.4.2 Responses

1. Identifier entropy is directly derived from inception keys. Initial pre-rotation preserves this quality.
2. Identifiers are assigned by a VDR rather than chosen by users. The VDR uses a cryptographically robust RNG. This creates a chain of custody that's as strong as the VDR's integrity.
3. Identifiers are related to inception keys with some caveats, or they are assigned by a VDR using an algorithm that has vulnerabilities.
4. Identifiers are arbitrary. They have no chain of custody before they are registered on a VDR. DID squatting is possible.

2.7.4.3 Relevance

An identifier that has a predictable or manipulable value, or that has inception keys that anyone could have created, is an attack vector.

2.7.4.4 Examples

2.7.5.1 Question

How robust are protections against attempts to suppress information flow, whether legal (cease and desist) or technical (denial of service)?

2.7.5.2 Responses

1. The VDR is practically immune from this risk.
2. The VDR has reasonable protections in place. However, motivated and well resourced attackers could temporarily disrupt access in a targeted context.
3. Attackers could permanently disrupt access in a targeted context.

2.7.5.3 Relevance

Control over an identifier is far less valuable if the propagation of that control can be limited by someone else. Availability is the "A" in the security evaluation acronym CIA.

2.7.5.4 Examples

2.7.6.1 Question

Is the current state of a DID document provably correct from a history that's visible to anyone who can resolve the DID?

2.7.6.2 Responses

1. Every evolution of state is recorded, accessible, and linked appropriately to its predecessor. Arbitrary versions can be queried and proved correct, and they have a reasonably useful timestamp.
2. Adequate evidence of proper evolution exists, and a forensic analysis could prove correctness. However, it's not exposed for consumption of ordinary resolvers, it lacks supporting metadata, or it's exposed in a very suboptimal way.
3. Limited evidence of proper evolution exists.
4. No evidence of proper evolution exists; the users have to trust the system's assertion that current state resulted from something appropriate.

2.7.6.3 Relevance

It's possible to tamper with systems that don't actively prove the correctness of their current state. Such tampering is not easy to discover.

2.7.6.4 Examples

2.7.7.1 Question

Is the code of the method published, does it have many contributors, and does it have a published vulnerability reporting (responsible disclosure) mechanism?

2.7.7.2 Responses

1. The code is public. It has hundreds of contributors. CVEs or similar reports have been published and handled appropriately.
2. The code is public, but the list of contributors is small. No vulnerability reporting mechanism has been announced, or it's been announced but has no demonstrable track record.
3. The code is partly private.
4. The code is entirely private.

2.7.7.3 Relevance

Security vulnerabilities tend to be found and fixed best in code that has many active contributions and a strong history of correctly handled responsible disclosure.

2.7.7.4 Examples

2.7.8.1 Question

To what extent does the system support mechanisms where DID control is distributed across multiple parties (m-of-n control, threshold signatures, etc.)?

2.7.8.2 Responses

1. Rich diffuse control mechanisms are a first-class feature, and anyone who resolves a DID can see whether they are in use so confidence is increased. This may include device revocation (where keys must be exercised on a particular device to be valid).
2. Some diffuse control is possible but has important deficits in documentation, maturity, or visibility.
3. Multiple parties can exercise control independently. Diffuse control is possible outside the system (e.g., using Shamir secret sharing to reconstitute a single key before updating a DID document). It's not possible to know whether such mechanisms are in use.
4. Only a single party can exercise control at a time.

2.7.8.3 Relevance

Diffuse trust makes hacking harder and recovery more robust (but maybe more complex).

2.7.8.4 Examples

2.7.9.1 Question

Does the system use cryptographic mechanisms that satisfy legal requirements in relevant jurisdictions (e.g., FIPS-certified algorithms, requirements for encryption back doors, etc.).

2.7.9.2 Responses

1. The method uses only algorithms that are officially endorsed by whatever regulatory bodies are important to the reviewer. For example, a reviewer in the USA might assign this score if cryptography is FIPS-approved.
2. The method uses algorithms that are ignored rather than endorsed by the relevant authority -- or uses a combination of algorithms with the practical outcome that interop is unlikely using only approved settings.
3. The method uses cryptography that is not aligned with requirements of the relevant authority.

2.7.9.3 Relevance

Some governments and enterprises may require DID methods that are officially endorsed by the EU, by their own security bureau, etc. Note that being out of harmony with government requirements may be considered a positive property by some reviewers; see this story for an example.

2.7.9.4 Examples

2.8.1.1 Question

What provisions are made for restricting visibility of DIDs to audiences other than the general public?

2.8.1.2 Responses

1. Fully private is possible.
2. VDR is visible to "all", but "all" is a restricted audience with enforced terms of service or other disincentives to abuse.
3. VDR is fully public with no constraints.

2.8.1.3 Relevance

Restricting the audience for a DID is a way to discourage crawling and secondary, possibly abusive publication. However, no mechanism can completely prevent this; creating disincentives, accountability, and/or costs that encourage the DID owner's wishes to be respected is the best we can hope for.

2.8.1.4 Examples

2.8.2.1 Question

How possible is it to control multiple DIDs, without having an observer of one DID be able to deduce that another DID has the same controller?

2.8.2.2 Responses

1. Each DID is entirely isolated; there is no practical way to infer relationships of common control between them.
2. It may be possible to infer relationships of common control based on timing and the IP address of clients, but not based on data persisted in the VDR itself. Inference is expensive or impractical.
3. It is possible to infer relationships based on data persisted in the VDR itself, and the inference is easy.

2.8.2.3 Relevance

Inferring relationships between Bitcoin addresses allowed law enforcement to track down the operators of Silk Road, even though those operators believed they had privacy.

2.8.2.4 Examples

2.8.3.1 Question

To what extent does the method incentivize (due to cost, hassle, etc.) a DID to be reused in multiple contexts?

2.8.3.2 Responses

1. The natural and default behavior is to create a new DID in each new context, and there is no meaningful incentive to do otherwise.
2. It is possible to create and manage numerous DIDs, but the latency, complexity, or monetary expense of doing so results in modest pressure to reuse a DID.
3. Each DID is expensive in at least one important dimension. Incentives to reuse are strong.

2.8.3.3 Relevance

People will often trade away privacy for a low price or ease of use. Methods that encourage this tradeoff are less optimal from a privacy perspective, even if their privacy features are theoretically reasonable.

2.8.3.4 Examples

2.8.4.1 Question

How does one revoke consent for the storage of a DID? (Note how this creates a tension with immutability, which may be valuable in 2.7.1 and elsewhere.)

2.8.4.2 Responses

1. The VDR fully supports removal of data that no longer has consent. Once something is removed, nothing internal to the system allows it to be recovered, and the system no longer qualifies as a data controller.
2. The DID method only supports a current view, and the state of an identifier in its VDR can be updated to a deleted or removed state. Thus, the identifier ceases to resolve. However, a permanent record of the previous state of the identifier remains, and could be used to reconstruct historical data. The VDR thus remains a data controller for deleted identifiers, at least in concept.
3. The DID method supports both current and previous views of an identifier. While deletes are possible, the old state of an identifier is a fully supported feature, so adding the identifier to the VDR is irrevocable.

2.8.4.3 Relevance

Some legal authorities may require that individuals have redress when they are not satisfied with the actions of a data controller. This might include but go beyond the so-called "right to be forgotten," encompassing geographical or jurisdictional limitations, limits on processing, and so forth. See this legal analysis for one view, but note that this is not a well settled legal question.

2.8.4.4 Examples