DID Method Rubric v1.0

Abstract

The communities behind Decentralized Identifiers (DIDs) bring together a diverse group of contributors who have decidedly different notions of exactly what "decentralization" means.

Rather than attempting to resolve this potentially unresolvable question, we propose a rubric — a scoring guide used to evaluate performance, a product, or a project — that teaches how to evaluate a given DID Method according to one's own requirements.

This rubric presents a set of criteria which an Evaluator can apply to any DID Method based on the use cases most relevant to them. We avoid reducing the Evaluation to a single number because the criteria tend to be multidimensional and many of the possible responses are not necessarily good or bad. It is up to the Evaluator to understand how each response in each criteria might illuminate favorable or unfavorable consequences for their needs.

While this rubric allows the evaluation of many aspects of decentralization of a DID Method, it is not exhaustive, and does not cover other factors that may affect selection or adoption of a particular Method, such as privacy, security, reliability, or efficiency.

1. Introduction

This section is non-normative.

1.1 Background

A rubric is a tool used in academia to communicate expectations and evaluate performance. It consists of a set of criteria to be evaluated, possible responses for each criteria, and a scoring guide explaining both how to choose and interpret each response. The act of evaluating a rubric, which we call an Evaluation, provides basis for self-evaluation, procurement decisions, or even marketing points. Written records of an evaluation, which we'll call an Evaluation Report, document how a particular subject is measured against the criteria. For students, a rubric helps to clarify how their work will be evaluated by others. For Evaluators, a rubric provides a consistent framework for investigating and documenting the performance of a subject against a particular set of criteria.

We were inspired to develop a rubric for decentralization when discussions about the requirements for decentralized identifiers, aka DIDs, led to intractable disagreement. It became clear that no single definition of "decentralized" would suffice for all of the motivations that inspired developers of DID Methods to work on a new decentralized approach to identity. Despite this challenge, two facts remained clear:

the people invested in this work shared a common goal of reversing the problems with centralized identity systems and
they also had numerous, distinct reasons for doing so.

Rather than attempt to force a definition of "decentralized" that might work for many but would alienate others, the group set out to capture the measurable factors that could enable Evaluators to judge the decentralization of DID Methods based on their own independent requirements, with minimal embedded bias.

1.2 How to apply this rubric

Pick the most important criteria for your use, ask each question, and select the most appropriate response. Do this for all of the DID Methods under consideration.

Each Evaluation should start with an explicit framing of the use under consideration. Are you evaluating the Method for use in Internet-of-Things (IoT)? For school childrens' extra-curricular activities? For international travel? The use, or set of uses, will directly affect how some of the questions are answered.

Where a given Method offers variability, such as multiple networks for the same Method, then evaluate each variant. For example, did:ethr supports Ethereum mainnet, multiple testnets and permissioned EVM-compliant networks such as Quorum. To apply a criteria to did:ethr, you will evaluate it against all the variations that matter to you. Each variation should get its own Evaluation. This applies to Level 2 Networks that can operate on multiple Level 1 Networks as well as DID Methods that directly offer support for multiple underlying DID registries.

When creating an Evaluation Report, we recommend noting both the Evaluator and the date of the Evaluation. Many of the criteria are subjective and all of them may evolve. Tracking who made the Evaluation and when they made it will help readers better understand any biases or timeliness issues that may affect the applicability of the Evaluation.

Be selective and acknowledge the subjective. Evaluations do not need to be exhaustive. There is no requirement to answer all the questions. Simply answer the ones most relevant to the use contemplated. Similarly, understand that any recorded Evaluation is going to represent the biases of the Evaluator in the context of their target use. Even the same Evaluator, evaluating the same Method for a different use, may come up with slightly different answers—for example, that which is economically accessible for small businesses might not be cost-effective for refugees, and that could affect how well-suited a given Method is for a specific use.

Finally, note that this particular rubric is about decentralization. It doesn't cover all of the other criteria that might be relevant to evaluating a given DID Method. There are security, privacy, and economic concerns that should be considered. We look forward to working with the community to develop additional rubrics for these other areas and encourage Evaluators to use this rubric as a starting point for their own work rather than the final say in the merit of any given Method.

In short, use this rubric to help understand if a given DID Method is decentralized enough for your needs.

1.3 Evaluation reports

To record and report an Evaluation, we recommend two possible formats, either comprehensive or comparative.

A comprehensive Evaluation applies a single set of criteria to just one Method. This set is chosen by the Evaluator; it need not be all possible criteria, but it is all relevant criteria as judged by the Evaluator.

A comparative Evaluation includes multiple Methods in the same table to easily compare and contrast two or more different Methods. This may include any number of criteria. These are the type of reports we use as examples throughout the criteria list.

In addition to the selected criteria, we recommend each report specify

The Method(s) being evaluated
A link to the Method specification
The Evaluator(s)
The date of the Evaluation
A description of the use case(s) for which the Method is being evaluated
The rubric used for the Evaluation, along with reference to the specific version.
Optionally, a URL for retrieving the report.

1.4 Categories of criteria

We have grouped our criteria into several categories:

Rulemaking
Design
Operations
Enforcement
Alternatives
Adoption & Diversity
Security
Privacy

Evaluators should consider criteria from all groups, as best fits your use cases.

Three categories cover how a given Method is governed: Rulemaking, Operations, and Enforcement. Our approach parallels the same separation of authority embodied in the United States Constitution.

Rulemaking addresses who makes the rules and how. (This is the legislative branch in the US.)

Operations addresses how those rules are executed and how everyone knows that they are carried out. (This is the executive branch in the US.)

Enforcement addresses how we find and respond to rule breaking. (This is the judicial branch in the US.)

This mental model is key to understanding the criteria of each section as well as why we included some criteria and not others.

The remaining categories each covers different areas worth considering when evaluating DID Methods.

Design addresses the method as designed. In other words, the output of the rulemaking: what rules apply to this DID method?

Alternatives address the availability and quality of different implementation choices.

Adoption & Diversity covers questions related to how widely a DID Method is used.

Security influences overall trust in the ecosystem. Different DID methods offer different security guarantees, or guarantees of different strengths.

Privacy addresses the ability of a DID method to ensure various privacy mechanisms. When DIDs are used as identifiers for people, it becomes important to consider what tools a DID method offers to operate at different levels of privacy.

1.5 The architecture

When evaluating the governance of DID Methods, three potentially independent layers should be considered: the specification, the network, and the registry.

The specification is the governing document for the Method that outlines how that particular Method implements the required and any optional components of the DID Core specification [DID-CORE].
The network is the underlying communications layer, i.e., how users of the Method communicate with others to invoke the operations of the Method.
The registry is a given instance of recorded state changes, managed according to the specification, using the communications channel.

For Rulemaking, the criteria should be evaluated against all three of the above layers.

For Operations, the criteria should be evaluated against the network and the registry. The specification is taken as a given (it is the core output of Rulemaking).

For Adoption, the criteria should be evaluated for each major software component: wallet, resolver, and registry.

For Alternatives, the criteria should be evaluated against the particular DID Method.

For the examples in the rest of this document we refer to a set of Methods that are familiar to the authors and exhibit interesting characteristics for Evaluation. These are listed in the "Comparative Evaluation Report Header" table below.

1.6 Comparative evaluation report header

Comparison Evaluation (used throughout the criteria list)
Evaluators	Joe Andrieu <joe@legreq.com>
Evaluation date	2020-01-03
Use cases	Verifiable software development. The signing of commits by developers and their verification to ensure that source code in a particular git repository is authentic. User authentication. The use of DIDs for authenticating users for access to system services. Long term verifiable credentials. The use of DIDs as subject identifiers for long term (life-long) verifiable credentials such as earned academic degrees.
Report URL	TBD
Rubric	DID Method Rubric v1.0.0
Rubric URL	https://www.w3.org/TR/did-rubric/

Methods considered
Method	Specification	Network	Registry
did:peer	Peer DID Method Spec	n/a (communications can flow over any agreeable channel)	Held by each peer
did:git	DID git Spec	git (an open source version control system)	Any Method-compliant git repository
did:btcr	DID Method BTCR	Bitcoin	Bitcoin
did:sov	Sovrin DID Method Spec	Hyperledger Indy	A particular instance of Hyperledger Indy
did:ethr	ethr DID Method Spec	Ethereum	Specific smart contracts for each network.
did:jolo	Jolocom DID Method Specification	Ethereum	Specific smart contracts for different networks and subnetworks.

Note

Note: The evaluations in this document are made by Joe Andrieu <joe@legreq.com>. Other authors have expressed different evaluations, because of different weighting of the relevant of different characteristics in particular methods. This should be expected in any evaluation: they will always be colored by the particular perspective of the Evaluator.

1.7 Criteria and Criterion

The term "criteria" is often treated as both a singular and a plural noun. In the singular, we say "The most important criteria is the buyer's age". This singular use of criteria has been in use for over half a century https://www.merriam-webster.com/dictionary/criterion#usage-1 In the plural we say "That proposal doesn't meet all of the criteria." Sometimes people use both in the same sentence: "Select one criteria from the list of criteria."

However, for formal use, "criteria" is more broadly accepted as plural while "criterion" is singular. By this style rule, the last sentence in the previous paragraph should be "Select one criterion from the list of criteria."

As editors of a Note published by the World Wide Web Consortium, we are torn. We would prefer to use rigorous grammar and be consistent in doing so. At the same time, we find attempts to enforce the formal rule sometimes leads people to using the inverse, such as "Select a criteria from the list of criterion." This is the exact opposite of our desired outcome.

In our own work with implementers and developers of the DID Core specification, we have found that the singular "criteria" is readily accepted and understood and leads to no confusion when used, even alongside plural usage. Since the DID Method Rubric is, at its core, a set of criteria with ample reason to refer to, for example, "Criteria #23", we find the combined singular and plural use is cleaner (just stick with "criteria"), less confusing, and more aligned with common usage among our audience.

As such, throughout the DID Method Rubric, we use the term "criteria" to refer to both singular instances of criteria and plural sets of criteria.

2. Registration Process

This registry — the DID Method Rubric Registry — provides a public vehicle for publishing updated DID Method Rubric criteria. In order to add or update a criteria, a submitter MUST submit a modification request for this registry, as a pull request on the repository where this registry is hosted, where the modification request adheres to the following policies:

2.1 General Requirements

If there are copyright, trademark, or intellectual property rights concerns, the addition and use MUST be authorized in writing by the intellectual property rights holder under a F/RAND license. For example, criteria that use trademarked brand names, use the titles or excerpts from copyrighted works, or require patented technology to perform the evaluation.
Additions MUST NOT create unreasonable legal, security, moral, or privacy issues that may result in direct or indirect harm to others, including violations of the W3C Code Of Ethics And Professional Conduct https://www.w3.org/Consortium/cepc/ Examples of unacceptable additions include any containing hate speech, unprofessional or unethical attacks, proprietary information, and any personal data or personally identifiable information (excepting identification details of the submitter).
All criteria MUST be uniquely identified and versioned to ensure permanent linkability with version trackability. Those identifiers MUST be present as an href anchor in the HTML for the criteria itself. See the sections below on identifiers and versioning. Subcomponents, such as questions, responses, relevance, and examples, are not separately versioned; any change to a subcomponent triggers an appropriate version change to its primary component.
Use cases, methods, and evaluations cited within a criteria MUST include a local link to a full citation in the relevant citation section: Use Cases Referenced, Methods Evaluated, and Evaluations Cited, respectively.
Rubric criteria and associated metadata in the DID Method Rubric Registry MAY be updated or removed at the editors’ discretion, including the addition or removal of categories of metadata such as Use Cases Referenced or Implementations of Note.

2.2 Component Requirements

The primary components managed by this registry are criteria for evaluating DID Methods, with as many as eight subcomponents: name, id, version, question, responses, relevance, examples, and, optionally, a source. In addition, the DID Method Rubric maintains a list of cited references: DID methods, use cases, and evaluations. The criteria are independently identified and versioned (see those sections for details) while references cited in the criteria themselves link to their full citation in the appropriate list.

2.2.1 Criteria

Updates to criteria MUST follow the following versioning guidelines.
Proposed criteria without at least three independent example evaluations MUST have the word “PROVISIONAL” as the last term in its name. Once at least three independent example evaluations exist, the word “PROVISIONAL” SHOULD be removed.
Accepted (non-provisional) criteria MUST have at least three example evaluations, and generally SHOULD have no more example evaluations than there are possible responses to its question. Each example should distinctly illustrate one possible response to the criteria's question.
To be considered, criteria MUST have the following subcomponents:
1. Name
2. Identifier
3. Version
4. Question
5. Possible Responses
6. Relevance
7. Example Evaluations
Additionally, criteria MAY have the following optional subcomponents:
1. Source

2.2.2 Criteria.Name

Each criteria needs a human-friendly, short, descriptive name that captures the essence of the criteria as concisely as possible.

2.2.3 Criteria.Id

The criteria id must be explicit, unique, and persistent. See the section on Identifiers for details.

2.2.4 Criteria.Version

The criteria version must increment, as appropriate, any time the criteria, or any of its subcomponents, is updated. See the section on Versioning for details.

2.2.5 Criteria.Question

This subcomponent presents the key question for evaluating the criteria. The question MUST be a single inquiry that gets to the heart of the criteria. It should be reasonably clear to a competent professional skilled in the art how to resolve the question into one of the possible responses.

2.2.6 Criteria.Responses

This subcomponent lists the expected responses to the question.

Responses are either labeled or open ended.
Labeled responses MUST include a label and a meaning for that label.
Labels for a response MUST start with “A” in each criteria and progress sequentially through the English alphabet.
Open ended responses specify how an evaluator should fill in the response.

2.2.7 Criteria.Relevance

This subcomponent explains why this criteria is useful. Readers should be able to understand the extent to which this particular criteria is applicable to their situation.

2.2.8 Criteria.Examples

This section lists example evaluations of different DID methods using this criteria, presented as a table for easy correlation between evaluations of different methods using the same criteria.

Each example must have the following entries, each as its own column(s) in the examples table.
1. Method
2. Responses (on column for each element)
3. Notes
Some criteria MAY require an additional "Referent" entry, in its own column in the examples table.
Example Evaluations for a given criteria SHOULD highlight distinct responses. That is, each evaluation should have a different set of responses from the other example evaluations. The point of the examples is to illustrate how different DID methods score differently.
The editors will curate the list of proposed examples to provide a best effort illustration of each criteria, with consideration to highlighting a broad corpus of methods.
Criteria with fewer than 3 example evaluations MUST be marked “PROVISIONAL”
Criteria SHOULD have no more example evaluations than there are possible responses.

2.2.8.1 Criteria.Examples.Method

Example evaluations MUST specify the evaluated method in the first column, using a relative link to the method’s entry in the Methods Evaluated section. The entry in the Methods Evaluated table MUST conform to the requirements in that section.
The title of this column MUST be “Method”.
The Method entry MUST uniquely identify a specific DID Method specification suitable for evaluation, including any specified variant such as testnet, mainnet, etc.

2.2.8.2 Criteria.Examples.Referent

Evaluations MAY refer to open ended responses from other evaluations. If present, this referent MUST be listed as a possible response in another criteria’s evaluation. In this manner, a first criteria can elicit structural elements to be separately evaluated in subsequent criteria. This “structure-variable” pattern allows the Rubric to support criteria that matches the structural complexity of the Method in question.
If present, the Referent MUST be in the second column
The column title MUST be appropriate for the referred structure, e.g., “Layer” or “Governing body”, as understood by the criteria which establishes the structural elements.

2.2.8.3 Criteria.Examples.Responses

Example evaluations MUST include at least one response, and may include multiple columns when appropriate. Each column allows for responses to particular system elements such as “Specification”, “Network”, and “Registry”.
Column names such as "Specification", "Network", and "Registry" may be abbreviated as "Spec.", "Net.", and "Reg."
The number and labels for response columns MUST be proposed by the initial PR and will be finalized when the criteria moves from PROVISIONAL to accepted.
Each column MUST contain an entry that communicates the evaluator’s judgment of the best response to the question for this method for that element (Spec, Reg, Net).
For improved comparability across different methods, responses SHOULD be based on the possible responses listed in the criteria. However, evaluators MAY provide any appropriate response, based on their own judgment
Responses MAY be a variant of the Possible Responses, to capture a nuance beyond those listed. For example, one might append a “+” or a “-”, e.g., A+, or even provide two different responses when different situations merit a distinction, e.g., A/D. The reasoning behind these variants &nbps; SHOULD be explained in the Notes column.
A response of “n/a” (short for Not Applicable) SHOULD be used if the criteria doesn’t apply to the evaluated method.

2.2.8.4 Criteria.Examples.Notes

This entry SHOULD include any details that help explain why that particular response was chosen.It MAY be blank. However, the column MUST be included.
The Notes entry MUST specify a distinct use case listed explicitly in this registry in the Use Cases Referenced section, using the label from that section.
1. The use case label MUST be delimited by square brackets.
2. The label text itself must be a hyperlink to the entry in the Use Cases Referenced section, for example [UC.1] where “UC.1” links to “#useCase-1” in the current document.
The Notes entry MUST identify a published evaluation by reference to an entry in the Evaluations Cited section of the Rubric, using the label from that section.
1. The evaluation label MUST be delimited by square brackets.
2. The label text itself must be a hyperlink to the entry in the Evaluations Cited section, for example [E.1] where “E.1” links to “#eval-1” in the current document.

2.2.9 Criteria.Source

This subcomponent, if present, MUST list the specific external source of the criteria, if any, by referring to its entry in the Rubric’s list of Sources Cited. Source entries should include both the name (or title) of the source as well as a URL. When possible, sources should specify the precise page, section, and/or anchor that points to the specific criteria in the source document. Each source listed in the criteria MUST also be listed in the Sources Cited section.

2.3 Identifiers

Each criteria must be explicitly, uniquely, and persistently identified using incremental numbers. New criteria should use the next available increment based on the highest numbered identifier in the current publication.

Previous numbered identifiers MUST NOT be re-used, even if the criteria so identified are no longer published; this maintains the persistent linkability of previously published versions. Such “retired” criteria MAY be listed in a Prior Criteria section linking directly to the latest published Rubric containing the retired criteria; this Prior Criteria section MUST also contain an anchor with the canonical id.

The registry shall maintain an entry with the “next available” number. Additions should use the “next available” number to construct an identifier for the new criteria, and update the “next available” entry at the same time. Editors will manage any sequencing errors when accepting PRs.

Identifiers must be constructed by appending that numerical value to the string “criteria-” and incorporated in the ID of the heading element for that criteria, which when placed in the Rubric appears as something like (note the version in its own span after the permalink):

Example 1: Example criteria numbering

<h4 id="criteria-1">Open contribution (participation)</h4>
<a href="#criteria-1">https://www.w3.org/TR/did-rubric#criteria-1</a> <span>1.0.0</span>

This allows permanent links to citations based on the publication date of a given Rubric: https://www.w3.org/TR/2021/NOTE-did-rubric-20210826/#criteria-32 as well as version-free links that resolve to the latest version of the criteria, and if retired, to an entry in the Prior Criteria list which itself links to the last valid presentation of the criteria, so that, for example, https://www.w3.org/TR/did-rubric/#criteria-32 points to the current criteria-32 in the latest published document. When that criteria is retired, that same URL points to the entry in the Prior Criteria list, which links to its last versioned publication, e.g., https://www.w3.org/TR/2021/NOTE-did-rubric-20210826/#criteria-32

2.4 Versioning

Criteria versions allow for incremental improvements while retaining long-term referenceability.

Versions contain a Major, Minor, and Patch number, based on SemVer 2.0
Every new criteria has a version of 1.0.0, even if PROVISIONAL.
Updates to criteria must increment the appropriate version number based on the scope of change:
1. Major number MUST increment if, and only if, the criteria is fundamentally changed in a way that invalidates existing evaluations. This could be a material change to any subcomponent of the criteria, including removing or changing Possible Responses.
2. Minor number MUST increment if, and only if, new responses are added, without invalidating existing responses. It’s understood that an evaluator of an existing evaluation may desire to choose the new response if they were evaluating the criteria anew; however, as long as prior evaluations remain valid, a Minor increment SHOULD be applied.
3. Patch number MUST increment if, and only if, the change to the question is “editorial”, defined by clarifying the original intent of the criteria WITHOUT invalidating existing evaluations.
As long as a given criteria is an evolution of essentially the same consideration, it retains the original identifier, even as its version is updated throughout its lifetime.
Criteria that address fundamentally different considerations MUST be assigned a new criteria number rather than iterating an existing version number.

2.5 Metadata Tables

The registry maintains several tables of metadata, which aggregate references cited in Criteria. Each table presents an internally referencable label, anchor tag, and the necessary details for the contents of each.

2.5.1 Evaluations Cited

Every example evaluation cited in the Notes entry in an evaluation MUST link to a proper citation in this section.

This is not a comprehensive listing of DID Method Rubric evaluations. It is expected that such evaluations are developed and published elsewhere, in support of various methods and use cases. Only those evaluations cited as Example Evaluations in current criteria will be listed.

Entries in this section MUST include:

Evaluators The name and contact information for the parties accepting responsibility for that evaluation. It MAY include each evaluator’s affiliation at the time of the evaluation.
Evaluation Date The performance date of the evaluation.
Funding The source, if any, of funds explicitly paid to perform the evaluation.
Use Cases One or more use cases listed Use Cases Referenced section of this registry, using the label from that section.
1. The use case label MUST be delimited by square brackets.
2. The label text itself must be a hyperlink to the entry in the Use Cases Referenced section, for example [UC.1] where “UC.1” links to “#useCase-1” in the current document.
Report URL A permalink where readers can read or download the published evaluation

2.5.2 Use Cases Referenced

Every use case cited in the Notes entry in an evaluation MUST link to an entry in this section.

A collection of the use cases referenced by different evaluations. This is not a comprehensive list (see the DID Use Cases and Requirements document for a more detailed discussion). Rather, it is an aggregation of all the use cases cited by example evaluations in current criteria.

This section MUST list all use cases cited by any example evaluation for current criteria.
Use cases must specify a label for use by citations within the registry.
The label must be of the form UC.x where “x” is a unique, incremental number within the Use Cases Referenced section.
Each use case must have an unique name and an illustrative description of a value-creating use of DIDs.
Use cases SHOULD identify unique contexts or situations not covered by other use cases in the registry.

2.5.3 Methods Evaluated

Every DID method cited in the Example Evaluations MUST link to a proper citation in this section.

This is not a comprehensive list (see the DID Specification Registries for a current list of registered Methods). Rather, this section aggregates the methods used in example evaluations of current criteria for easy reference.

Each entry in the table SHOULD contain the following:

A label for the DID method within the registry
An anchor tag so that the entry in the table can be linked by fragment from example evaluations.
Columns for the Specification, the Network, and the Registry (SNR) evaluated with this label.
In the case that all three SNR entries would be identical for different rows in the same table, subsequent entries MAY refer to the prior entry by Method (with link), along with a description of the difference, in a single column spanning all three SNR columns.
Each SNR entry should uniquely describe the component evaluated.
1. Specification identifies the DID Method specification under evaluation, with a hyperlink to the specification (at the time of the evaluation).
2. Network identifies the communications mechanism through which DID operations (create, read, update, and deactivate) are communicated.
3. Registry should unambiguously identify the state management substrate of the method’s Verifiable Data Registry.
Each SNR entry SHOULD include a hyperlinked URL when additional details are available.

2.6 Editorial Acceptance & Publication

The Editors of the DID Method Rubric Registry MUST consider all of the policies above when reviewing additions to the registry and MUST reject registry entries if they violate any of the policies in this section. Entities registering additions can challenge rejections first with the W3C DID Working Group and then, if they are not satisfied with the outcome, with the W3C Staff. W3C Staff need not be consulted on changes to the DID Method Rubric Registry, but do have the final authority on registry contents. This is to ensure that W3C can adequately respond to time sensitive legal, privacy, security, moral, or other pressing concerns without putting an undue operational burden on W3C Staff.

Submissions to the registry that meet all the criteria listed above will be considered for inclusion, however the editors retain the responsibility of curating the content to ensure the broadest applicability of the DID Method Rubric with the goal of enabling effective evaluations of any DID Method for any legitimate use case.

3. The criteria

3.1 Rulemaking

Rulemaking addresses who makes the rules and how. Output of rulemaking are the rules.

3.1.1 Open contribution (participation)

https://www.w3.org/TR/did-rubric#criteria-1 v1.0.0

3.1.1.1 Question

How open is participation in governance decisions?

3.1.1.2 Responses

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

3.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.

3.1.1.4 Examples

Method	Spec.	Net.	Reg.	Notes
did:peer	B	C	C	did:peer has no intrinsic network. It can use any communications channel between parties. Only those two parties are privy to the decisions made about communications and recordation. The spec is openly developed on github by a listed set of contributors and issues may be raised by anyone.
did:git	B	C	D	The git network is the git source code, which is controlled (currently) by 16 people. They do not have a public issues process. The spec is openly developed on github by a listed set of contributors and issues may be raised by anyone. Each registry is controlled by potentially unknown parties as negotiated in "meatspace".
did:btcr	B	D	D	Changes to the bitcoin protocol are chaotic and uncertain. They use BIPs, but the path to adoption is uncertain and the relative power of developers, miners, and users is open to debate. The spec is openly developed on github by a listed set of contributors and issues may be raised by anyone.
did:sov	B	B	B	The Sovrin Foundation has an open community governance model but has not yet had open elections of trustees.
did:ethr	C	B	n/a	The network is Ethereum, which evolves through EIPs proposed by anyone, discussed by "the community" and ultimately adopted by Ethereum core devs. The spec is published on GitHub with issues open to the public. The smart contract for the registry is immutable.
did:jolo	D	B	D	Jolocom's network is Ethereum. Decisions over Jolocom's smart contracts are made by an unknown group within Jolocom. The specification (as listed in the DID Method Registry [DID-SPEC-REGISTRIES]) is currently archived and not open to public comment.

3.1.2 Transparency

https://www.w3.org/TR/did-rubric#criteria-2

3.1.2.1 Question

How visible are rulemaking processes?

3.1.2.2 Responses

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.
Minutes of meetings are reviewable by the public, including all votes and who cast them, but real-time observation may be limited.
All current rules are publicly available.
Rules may be changed without public notice.

3.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.

3.1.2.4 Examples

Method	Spec.	Net.	Reg.	Notes
did:peer	C	n/a	B	Rules for accepting changes to the business rules are bilaterally negotiated between the peers, subject to conformance with the specification.
did:git	C	n/a	D	The controllers of the git repo are a limited set, but their decisions are "meatspace protocol" and hence not explicitly transparent.
did:btcr	C	C	C	The spec is maintained by volunteers, operating in an open fashion but without formal processes for announcements and meeting notes. The network and registry are bitcoin, which has a fairly public but messy innovation process, without formal meetings or votes.
did:sov	B	B	B	The Sovrin Governance Framework actually requires all minutes of Sovrin governance discussions are public with a handful of exceptions for legal reasons (e.g., HR actions, legal actions). See Section 9 of Sovrin Governing Body Policies.
did:ethr	C	C	D	The governance is controlled by a smart contract, which is immutable.
did:jolo	C	C	D	Jolocom does not expose the internal and/or customer conversations that drive rulemaking.

3.1.3 Breadth of Authority

https://www.w3.org/TR/did-rubric#criteria-3

3.1.3.1 Question

How many independent parties actively participate in the governance authority?

3.1.3.2 Responses

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

3.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?

3.1.3.4 Examples

Method	Spec.	Net.	Reg.	Notes
did:peer	B	B	B	There is only one editor to the did:peer specification, but the repository itself lists 14 contributors with actual commits. The network and registry rules are ultimately decided by the parties participating in each did:peer context (a closed set of peers).
did:git	B	B	D	There is only one editor to the did:git specification, with a total of three contributors with actual commits (although more are listed). The network is git (controlled by an unknown population) and the registry is a particular repo under the control of potentially unknown parties.
did:btcr	B	A	A	The spec lists 4 editors and the repo lists 4 committers. The network and registry is bitcoin, which relies on an informal process of any number of parties.
did:sov	C+	C+	C+	All three layers are ultimately under the control of the Sovrin Foundation, which itself has a governance framework to coordinate input from multiple parties.
did:ethr	B	B	n/a	The specification is now under DIF control and the registry is immutable. The network is Ethereum, which is controlled by Ethereum core devs.
did:jolo	C	B	C+	The specification and registry are controlled by Jolocom, sometimes in coordination with customers. The network is Ethereum, which is controlled by Ethereum core devs.

3.1.4 Public v private economies

https://www.w3.org/TR/did-rubric#criteria-4

3.1.4.1 Question

How privatized is the economic interest of the governing authority?

3.1.4.2 Responses

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

3.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.

3.1.4.4 Examples

Method	Spec.	Net.	Reg.	Notes
did:peer	A	B	B	The specification was developed to demonstrate a way that anyone can use DIDs without a distributed ledger. Each network and registry is established solely for the benefit of each peer.
did:git	A	A	B	The specification was developed to demonstrate how you might use DIDs to enhance git-based software development. Git itself (the network) was developed so anyone could have better software development practices. Any given registry (each repo is a registry) is assumed to be established for the common good of its controllers.
did:btcr	A	A	A	The specification was developed to demonstrate how you could use Bitcoin for DIDs. The network and registry were created as a public benefit proof of concept for decentralized digital cash.
did:sov	B	B	B	All three elements are developed and maintained for the common good. As a 501(c)4 the Sovrin foundation is a social welfare organization that must operate primarily to further the common good and general welfare of the people of its community.
did:ethr	C	C	C	The specification and registry were created by a private company (uPort) to support their business. The smart contract is a common good and free to use. However, the network, Ethereum, was created to create wealth for its creators.
did:jolo	C	C	C	The specification and registry were created by a private company (Jolocom) to support their business, but are now available for anyone to use. Similarly, the network, Ethereum, was created to create wealth for its creators.

3.1.5 Cost

https://www.w3.org/TR/did-rubric#criteria-5

3.1.5.1 Question

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

3.1.5.2 Responses

Free to all
Inexpensive, but accessible
Modest cost for interested parties
Expensive and restricted
Not possible to participate

3.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.

3.1.5.4 Examples

Method	Spec.	Net.	Reg.	Notes
did:peer	B	n/a	n/a	The specification is available for engagement via Github, but participating in decision making takes time and requires expertise. The network and registry are negotiated on a case-by-case basis, so participation could be anywhere on the spectrum.
did:git	B	D+	D	The specification is available for engagement via Github, but participating in decision making takes time and requires expertise. Git itself (the network) is partially influenceable through online issues, but real change requires deep expertise and is controlled by a handful of developers. Any given registry's governance is, by design, a question of "meatspace" negotiations, which is expensive and limited to the parties who control the repo.
did:btcr	B	D	D	The specification is available for engagement via Github, but participating in decision making takes time and requires expertise. The network and registry (bitcoin) are theoretically open to any participants, but influencing the direction of bitcoin is notoriously expensive and unpredictable.
did:sov	B	B	B	The did:sov: method together with 100% of the Sovrin ledger and Sovrin infrastructure are governed by an open public non-profit organization that is open to anyone to participate. The Sovrin Governance Framework Working Group is an all-volunteer community-driven effort in which over 50 volunteers have participated for over three years to develop a fully public governance framework on which anyone can comment and suggest improvements. The Sovrin ledger operates on the Hyperledger Indy open source code base to which anyone can contribute.
did:ethr	C	D	E	The specification is available for engagement via Github, and managed by DIF. The network itself, Ethereum, is expensive and difficult to influence: not impossible for an outsider, but expensive. Governance of the registry is not accessible except with uPort's permission.
did:jolo	D	D	E	While the did:jolo specification is available online, it is archived and not open to further engagement. Jolocom has sole control over who can participate in developing specifications based on did:jolo, and they work with customers to customize the Method. The network itself, Ethereum, is expensive and difficult to influence: not impossible for an outsider, but expensive. The registry is immutable and therefore not open to participation.

3.2 Design

Design criteria addresses the method as designed. In other words, the output of the rulemaking: what rules apply to this DID method?

3.2.1 Permissioned operation

https://www.w3.org/TR/did-rubric#criteria-6

3.2.1.1 Question

To use the DID Method, do you need permission?

3.2.1.2 Responses

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

3.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.

3.2.1.4 Examples

Method	Net.	Reg.	Notes
did:peer	A	D	By design, did:peer can use any communications channel and only the participation of the participants is required. Unfortunately, for those outside the peer context, the registry is inaccessible.
did:git	A	D	Git software is available to anyone. Participation and access is controlled by the repo maintainers.
did:btcr	A	A	The bitcoin network is open to anyone.
did:sov	C	C	Sovrin foundation limits access to writing and consensus, but the network is open to all for reading.
did:ethr	A	A	Ethereum is open to anyone. The registry is accessible to anyone.
did:jolo	A	A	Ethereum is open to anyone. The registry is accessible to anyone, although some subregistries/subnetworks may have alternate rules.

3.2.2 Interoperability

https://www.w3.org/TR/did-rubric#criteria-7

3.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.)

3.2.2.2 Responses

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

3.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.

3.2.2.4 Examples

Method	Net.	Reg.	Notes
did:peer	A	A	did:peer is agnostic regarding the software that implements it.
did:git	A-	A-	did:git is predicated on using git software. However, git itself uses a protocol that any software could implement. Although we know of no other implementation in widespread use, we know of no limitations in the protocol itself.
did:btcr	A	A	Bitcoin has no restrictions on the software used to access the network.
did:sov	A	A	did:sov: has no restrictions on any software that implements it.
did:ethr	A	A	Neither Ethereum nor the smart contract has any restrictions on the software used to access them.
did:jolo	A	A	Neither Ethereum nor the smart contract has any restrictions on the software used to access them.

3.2.3 Scope of usage

https://www.w3.org/TR/did-rubric#criteria-8

3.2.3.1 Question

How widely can DIDs of this Method be used?

3.2.3.2 Responses

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

3.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.

3.2.3.4 Examples

Method	Net.	Reg.	Notes
did:peer	A+	C	Did:peer is communication-layer independent, so it can be used on any network, including direct physical links. However, only those parties to the creation of the DID can actually use it. The DIDs have no use outside that direct peer-to-peer relationship.
did:git	A	B	Anyone can set up a git-based repo and use did:git. However, to interact with a given repo, one must be aware of the repo, including which instance of it is authoritative.
did:btcr	A	A	Open, permissionless, and globally resolvable.
did:sov	A	B	Transactions on the Sovrin ledger are publicly readable by anyone. Transactions may be written by any Transaction Author however for GDPR reasons personal data may not currently be written to the Sovrin ledger. See Sovrin Data Protection.
did:ethr	A	A	Open, permissionless, and globally resolvable.
did:jolo	A	A	Open, permissionless, and globally resolvable.

3.3 Operation

3.3.1 Financial accountability

https://www.w3.org/TR/did-rubric#criteria-9

3.3.1.1 Question

How transparent and fair are the economics of the Method?

3.3.1.2 Responses

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

3.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.

3.3.1.4 Examples

Method	Net.	Reg.	Notes
did:peer	D	D	The financials of both parties have no visibility.
did:git	A	D	The financials of both parties have no visibility. However, the underlying git software is free and open source.
did:btcr	A-	A-	Bitcoin is transparent, although operations are somewhat obscured by pseudonymous transaction addresses.
did:sov	B	B	The Sovrin Foundation publishes an annual report with details about overall finances for their operation, and the books are required to be openly available for inspection by anyone.
did:ethr	A-	A-	Ethereum is transparent, although operations are somewhat obscured by pseudonymous transaction addresses.
did:jolo	A-	A-	Ethereum is transparent, although operations are somewhat obscured by pseudonymous transaction addresses.

3.3.2 Limited resource resolution

https://www.w3.org/TR/did-rubric#criteria-10

3.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.

3.3.2.2 Responses

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

3.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.

3.3.2.4 Examples

Method	Net.	Reg.	Notes
did:peer	A	A
did:git	B	varies	Git for Windows is just shy of 50 MB (please update if there are smaller versions available). However, one must still download the entire repo containing the registry material.
did:btcr	D	D	To definitively resolve, one must operate a full node.
did:sov	A	A	The Sovrin ledger is based on Hyperledger Indy which supports highly efficient state proofs for cryptographic verification of resolution responses. A full node is not required.
did:ethr	B	B	A full ethereum node takes >100GB, but a light ethereum node can support this method with less than 256kb.
did:jolo	B	B	A full ethereum node takes >100GB, but a light ethereum node can support this method with less than 256kb.

3.3.3 Limited resource registration

https://www.w3.org/TR/did-rubric#criteria-11

3.3.3.1 Question

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

3.3.3.2 Responses

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

3.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.

3.3.3.4 Examples

Method	Net.	Reg.	Notes
did:peer	A	A
did:git	B	varies	Git for Windows is just shy of 50 MB (please update if there are smaller versions available). However, one must still download the entire repo containing the registry material.
did:btcr	A-	A-	To register a DID, one must simply get a transaction on the ledger, unless you choose to host a continuation DID Document elsewhere, which would require its own resources.
did:sov	A	A	Registration of a DID is a single transaction that can be performed by a thin client.
did:ethr	A+	A+	The smart contract used for did:ethr recognizes any valid public key as a DID, without requiring registration. This means DIDs can even be created offline with full usability. Only rotation and the registration of service endpoints require network access.
did:jolo	A+	A+	The smart contract used for did:ethr recognizes any valid public key as a DID, without requiring registration. Only rotation and the registration of service endpoints require network access.

3.4 Enforcement

The matter of enforcement may be interpreted at many levels. Enforcement criteria addresses how the system enforces its own rules as well as how jurisdictional governance applies.

In state-level governance, enforcement is an operational matter for the police and a judgmental matter for the courts. In other words, the police and the courts constitute the enforcement powers of governance.

For distributed systems, especially those like Bitcoin and Ethereum, enforcement is a function of both social and technical functions.

Technical enforcement could include such notions as which cryptography is used to ensure proper authentication of transactions or the details of a consensus mechanism such as proof of work (POW) or proof of stake (POS). Should a given cryptographic technique prove to be compromised, that would affect the ability of the system to enforce its own rules, making the specific cryptography used by a given Method a significant factor in evaluating the suitability of a given Method. Further, understanding the decentralized nature of a given POW or POS mechanism requires an Evaluation of both the means for executing the mechanism as well as a profile of those parties who could potentially influence or even undermine that mechanism.

Social enforcement mechanisms rely on community or institutions. For Methods that have explicit governing bodies, like did:sov, presumably enforcement is a matter under their jurisdiction. Nodes on the network that operate outside the guidelines of the governing bodies can presumably have permission revoked as a means of enforcement. Methods that do not have formal governing bodies may, nevertheless, have a strong enough community to correct violations, as Ethereum did in response to the DAO hack.

Finally, all Methods operate in (and across) one or more geographic jurisdictions, each with potentially distinct laws and mechanisms of enforcement. Identifying the potential enforcement mechanisms that could apply to the Method, to those using a Method, or to the operators of a Method, is almost certainly going to be relevant to certain Evaluators. We have already seen GDPR and various US laws being applied based on where different servers are physically located, with lawsuits brought against server operators. It is inevitable that similar actions will eventually be brought against DID Method operators at various levels.

In short, understanding the process for identifying violations and enforcing the rules as set by the rulemakers is vital to a complete Evaluation of the decentralization of a DID Method. We regret that we were not able to sufficiently explore these issues for this rubric and we look forward to working with subsequent collaborators to flesh out criteria that can provide suitable guidance for enforcement criteria.

3.4.1 Auditability

https://www.w3.org/TR/did-rubric#criteria-12

3.4.1.1 Question

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

3.4.1.2 Responses

Anyone
Only a select group, including parties not involved in a given DID transaction
Only parties to the transaction
Not available

3.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.

3.4.1.4 Examples

Method	Reg.	Notes
did:peer	C-	DID:peer maintains a cryptographic journal, but it is only available to the peers and, technically, can be refused (each peer may suspend interactions at any time).
did:git	B-	If you have access to the authoritative git repo, you can see the cryptographic journal. However, within the method specification, there is no way to know if the repo you are inspecting is, in fact, definitive.
did:btcr	A	Anyone can see everything.
did:sov	A	Anyone can see everything—the Sovrin ledger is completely public.
did:ethr	A	Anyone can see updates and deletes. Creation is private.
did:jolo	A	Anyone can see updates and deletes. Creation is private.

3.5 Alternatives

For each major software component (Wallet, Resolver, and Registry), ask each of the following questions. In this section, because DIDs are so early in the development lifecycle, most DID methods in production have only one implementation and some have none. Therefore, we have not standardized the responses nor provided examples. Consider these open-ended essay questions for consideration. As the market matures, this subset of questions will improve.

3.5.1 Active implementations

https://www.w3.org/TR/did-rubric#criteria-13

3.5.1.1 Question

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

3.5.3 Platform support

https://www.w3.org/TR/did-rubric#criteria-15

3.5.3.1 Question

Which platforms have implementations?

3.5.4 Language support

https://www.w3.org/TR/did-rubric#criteria-16

3.5.4.1 Question

Which programming languages have implementations?

3.5.5 Rogue risk

https://www.w3.org/TR/did-rubric#criteria-17

3.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?

3.5.6 Forkability

https://www.w3.org/TR/did-rubric#criteria-18

3.5.6.1 Question

Is it forkable?

3.6 Adoption (and diversity)

Adoption covers questions related to how widely a DID Method is used. Similar to the alternatives section, this section is limited because DID methods are just beginning to reach production, and so we have minimal knowledge of current adoption. As the market matures, we anticipate this section improving.

3.6.1 Acceptance

https://www.w3.org/TR/did-rubric#criteria-19

3.6.1.1 Question

How many relying parties accept DIDs of this Method?

3.6.2 Users

https://www.w3.org/TR/did-rubric#criteria-20

3.6.2.1 Question

How many daily active users use this Method?

3.6.3 International adoption

https://www.w3.org/TR/did-rubric#criteria-21

3.6.3.1 Question

How many different countries have significant usage?

3.6.4 In which countries?

https://www.w3.org/TR/did-rubric#criteria-22

3.6.4.1 Question

Which countries have significant usage?

3.6.5 Language support

https://www.w3.org/TR/did-rubric#criteria-23

3.6.5.1 Question

How many (human) languages are supported?

3.7 Security

Security has a strong influence on overall trust in the ecosystem. Different DID methods offer different security guarantees, or guarantees of different strengths.

3.7.1 Robust Crypto

https://www.w3.org/TR/did-rubric#criteria-24

3.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?

3.7.1.2 Responses

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

3.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.

3.7.1.4 Examples

Method	Score	Notes
did:ipid	C	The DID method specific identifier for the IPID DID method is a hash of the public key of an IPFS node. Typically this is a SHA-256 value (256 bits of security), but other hashing algorithms can be plugged in. Ed25519 and RSA are the supported keytypes. Edwards keys are 256-bit but offer 128 bits of security; typical 2048-bit RSA offers 112 bits of security. Access to IPFS via a web service API such as ipfs.io/api uses TLS; spot-checking shows 2048-bit RSA certs.
did:web	C	Although the DNS subsystem that supports did:web does not provide strong security, control of a DID is proved by accessing /.well-known over TLS. Thus, the security is tied to certificate config. Most web server certificates use 2048- bit RSA, which gives 112 bits of security.
did:indy	B	Hashes are SHA2-256. Keys are Ed25519/Curve25519 (128 bits of security). Reads and writes to the Indy ledger use CurveZMQ rather than TLS. This gives 128 bits of security in the aggregate.

3.7.2 Expert Review

https://www.w3.org/TR/did-rubric#criteria-25

3.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?

3.7.2.2 Responses

Experts generally consider the system very secure, and this opinion is reinforced by a track record of secure production use.
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.
Credible reports of vulnerabilities or design shortcomings have not been addressed.
The system actively uses mechanisms that are officially deprecated.

3.7.2.3 Relevance

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

3.7.2.4 Examples

Method	Score	Notes
did:iota	A	The IOTA ecosystem has published security audits by at least three independent experts. Its code is open source. It uses cryptographic primitives that are well known (e.g., the Blake256-2b hash). It has been running in production for years with no reported CVEs.
did:git	C	Git uses SHA-1 hashes to identify commits. This hash has known collision attacks.

3.7.3 Future Proofing

https://www.w3.org/TR/did-rubric#criteria-26

3.7.3.1 Question

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

3.7.3.2 Responses

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

3.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.

3.7.3.4 Examples

Method	Score	Notes
did:ipid	B	The IPFS ecosystem allows a user to use a different hash algorithm as a configuration choice. Since this algorithm is the basis of the CID, which is in turn the basis of the DID value, did:ipid can easily upgrade its DID values if a hash algorithm needs updating. (Score = A) However, did:ipid supports only the Ed25519 and RSA keytypes; upgrading these would require a revised spec and re-implementation. (Score = C).
did:peer	A	The fundamentals of peer DIDs are described without reference to any particular hash or key type. Representations of hashes use multihash, allowing arbitrary upgrade without disruption. Any implementation can begin using new key types at any time.

3.7.4 Self Certification

https://www.w3.org/TR/did-rubric#criteria-27

3.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?

3.7.4.2 Responses

Identifier entropy is directly derived from inception keys. Initial pre-rotation preserves this quality.
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.
Identifiers are related to inception keys with some caveats, or they are assigned by a VDR using an algorithm that has vulnerabilities.
Identifiers are arbitrary. They have no chain of custody before they are registered on a VDR. DID squatting is possible.

3.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.

3.7.4.4 Examples

Method	Score	Notes
did:keri	A	The value of a DID in did:keri is always directly derived from its inception key. This guarantees a chain of custody even before it is registered on a public VDR. The chain of custody cannot be broken without invalidating the DID.
did:hedera	B	The value of a DID in did:hedera is always directly derived from the `#did-root-key` value. This guarantees a chain of custody for that key. However, the DID doc may contain other keys at inception, which means that they do not have the same chain of custody. This may or may not matter.
did:web	D	No chain of custody is guaranteed; the current owner of a did:web may not be the same as the owner of that domain in the past or the future. Within the lifespan of ownership of a domain, the DNS record and `.well-known` data are not guaranteed to provide a stable chain of custody for a DID, either.

3.7.5 Availability

https://www.w3.org/TR/did-rubric#criteria-28

3.7.5.1 Question

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

3.7.5.2 Responses

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

3.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.

3.7.5.4 Examples

Method	Score	Notes
did:sov	B	A Hyperledger Indy blockchain such as Sovrin MainNet returns state proofs that allow a reliable answer even if only a single node responds. It also separates network traffic related to clients from traffic related to inter-node consensus, with consensus occurring on a NIC that blacklists all IP addresses except other nodes. This significantly mitigates denial of service or service interruptions for reading. Writes are submitted to 1/3 of the nodes in parallel, so attacks on individual nodes are unlikely to produce downtime. This behavior is validated with careful testing and has been demonstrated through four years of production usage with greater than 99% uptime. Sovrin adds to Indy's guarantees by publishing a node and network health dashboard, by maintaining statistics about the historic behavior of nodes, by having a publicly vetted node selection algorithm that forces nodes in different geographies and legal jurisdictions, and by having a written crisis management plan that has been exercised and reviewed by security professionals. However, a determined adversary might be able to reduce network write speed by submitting many transactions in parallel, for a sustained period of time.
did:btcr	A	The global bitcoin network has a strong track record of uptime, stretching back for well over a decade, even in the face of motivated attack.

3.7.6 Evolution

https://www.w3.org/TR/did-rubric#criteria-29

3.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?

3.7.6.2 Responses

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.
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.
Limited evidence of proper evolution exists.
No evidence of proper evolution exists; the users have to trust the system's assertion that current state resulted from something appropriate.

3.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.

3.7.6.4 Examples

Method	Net.	Reg.	Notes
did:foo	A	D	By design, did:foo supports 123.5 bits of security.

3.7.7 Many Eyes

https://www.w3.org/TR/did-rubric#criteria-30

3.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?

3.7.7.2 Responses

The code is public. It has hundreds of contributors. CVEs or similar reports have been published and handled appropriately.
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.
The code is partly private.
The code is entirely private.

3.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.

3.7.7.4 Examples

Method	Score	Notes
did:sov	A	The most prominent codebases that implement this method, github.com/hyperledger/indy-* have over 1000 forks, about 200 unique contributors from over a dozen organizations, spanning 5 years and about 25000 commits as of 2021. Sovrin's Technical Governance Board, which vets some aspects of the design, is composed of numerous independent experts, and meets regularly. Both Hyperledger and Sovrin Foundation have responsible disclosure mechanisms for vulnerabilities, and both have successfully handled vulnerabilities from initial report to patch and public disclosure.
did:peer	B	The spec and implementations of code are entirely public, with incubation through DIF's identifiers WG. However, contributors are limited to a dozen developers, activity is light, and there is no announced vulnerability mechanism.

3.7.8 Diffuse Control

https://www.w3.org/TR/did-rubric#criteria-31

3.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.)?

3.7.8.2 Responses

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).
Some diffuse control is possible but has important deficits in documentation, maturity, or visibility.
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.
Only a single party can exercise control at a time.

3.7.8.3 Relevance

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

3.7.8.4 Examples

Method	Score	Notes
did:key	C	did:key is controlled by a single key. If aggregate control is desired, these keys can be sharded, but that is outside the method's feature set.
did:peer	A	Dynamic peer DIDs explicitly define an m-of-n scheme that can be used to authorize any evolution of state, or any verification method supported by the DID.

3.7.9 Regulatory Compliance

https://www.w3.org/TR/did-rubric#criteria-32

3.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.).

3.7.9.2 Responses

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.
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.
The method uses cryptography that is not aligned with requirements of the relevant authority.

3.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.

3.7.9.4 Examples

Method	Score	Notes
did:twit	A (for a reviewer suspicious of NIST-approved curves); C (for a reviewer requiring compliance with standards of the Australian government)	The did:twit method supports only Ed25519 keys, which are not on the FIPS 186-4 approved curve list required by the Australian government.
did:pkh	C (for a reviewer requiring compliance with the Chinese government's SM2 cryptosystem); B (for a reviewer wanting to use the system in Canadian government contexts).	The `did:phk` method subsumes multiple blockchain ecosystems. Most use the secp256r1 curve, but supporting the method broadly means tolerating a variety of crypto algorithms that are not all equally approved by Canada. None use the SM2 crypto system.

3.8 Privacy

Addresses the ability of a DID method to ensure various privacy mechanisms. When DIDs are used as identifiers for people, it becomes important to consider what tools a DID method offers to operate at different levels of privacy. Use cases that focus on IoT or institutions may not feel that this dimension is especially important (though institutional privacy may sometimes be desirable).

Privacy tends to surface some interesting tradeoffs. For example, DID methods that score very high in the "transparency" dimension may score low in privacy, and vice versa.

3.8.1 Per-DID constraints on visibility

https://www.w3.org/TR/did-rubric#criteria-33

3.8.1.1 Question

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

3.8.1.2 Responses

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

3.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.

3.8.1.4 Examples

Method	Score	Notes
did:twit	C	A did:tweet is created and updated by posting to a public twitter feed; it is always completely public.
did:key	A	Nothing about the did:key method requires it to be published anywhere. It is as private or as public as the mechanism used to share it.
did:trustbloc	B	A did:trustbloc is public to all users of the Hyperledger Fabric instance where it is published -- but that blockchain may be permissioned and restricted to a private audience.

3.8.2 Cross-DID Leakage

https://www.w3.org/TR/did-rubric#criteria-34

3.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?

3.8.2.2 Responses

Each DID is entirely isolated; there is no practical way to infer relationships of common control between them.
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.
It is possible to infer relationships based on data persisted in the VDR itself, and the inference is easy.

3.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.

3.8.2.4 Examples

Method	Score	Notes
did:pkh	B or C	Some of the blockchains used by did:pkh have Bitcoin-like traceability. Others have Ethereum-like features, which include mixers or zkSNARKS/zkSTARKS. However, none of them render a user completely anonymous.
did:keri	B	If a did:keri uses a blockchain as a witness, it may acquire some privacy characteristics from that blockchain. However, did:keri in and of itself is not easy to correlate.

3.8.3 Incentives for Multicontext DIDs

https://www.w3.org/TR/did-rubric#criteria-35

3.8.3.1 Question

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

3.8.3.2 Responses

The natural and default behavior is to create a new DID in each new context, and there is no meaningful incentive to do otherwise.
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.
Each DID is expensive in at least one important dimension. Incentives to reuse are strong.

3.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.

3.8.3.4 Examples

Method	Score	Notes
did:btcr	C	At times when Bitcoin value has spiked, creating a DID on Bitcoin has required an expensive transaction. Finality also takes a significant amount of time. This creates incentives to reuse a DID in multiple contexts.
did:sov	C	The Sovrin ledger deliberately charges for ledger writes to discourage its use for privacy-oriented identifiers.
did:peer	A	Creating a peer DIDs is free and nearly instantaneous. There are no incentives for reuse.

3.8.4 Revocation of Consent

https://www.w3.org/TR/did-rubric#criteria-36

3.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.)

3.8.4.2 Responses

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.
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.
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.

3.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.

3.8.4.4 Examples

Method	Score	Notes
did:peer	A	A peer DID is designed to be shared only with the party that has direct need to process it. That party is a single legal entity that can be held responsible for their behavior. The peer DID protocol includes a way to tell that party that the DID must be deleted. Once deletion has occurred, nothing in the peer DID mechanism preserves inappropriate data.
did:jlinc	B	The `did:jlinc` method supports deletion, and refuses to resolve DIDs that have been deleted. It is also predicated on sophisticated data-sharing agreements that can provide substantial protection for individuals. However, it persists data to an immutable blockchain, meaning that a deleted DID can be reconstructed outside the method, using data that the method created.

3.9 Other criteria

We reviewed a lot of proposed criteria for inclusion in this rubric. Not all of them turned out to be a good fit. We've included a list of additional considered criteria in § B. Possible additional criteria.

We encourage everyone using this rubric to consider it as one tool for evaluating DID Methods. Other Evaluations will also be necessary to make a fully informed decision about adopting, supporting, or contributing to any given Method.