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.

Introduction

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 criterion, 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:

  1. the people invested in this work shared a common goal of reversing the problems with centralized identity systems and
  2. 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.

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

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. This is the type of Evaluation Report we include in .

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

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

An example comprehensive report header can be found in . An example comparative report header can be found in .

Categories of criteria

We have grouped our criteria into five categories:

  1. Rulemaking
  2. Operations
  3. Enforcement
  4. Alternatives
  5. Adoption

Evaluators should consider criteria from all five groups, as best fits your use cases. The first three are about how a given Method is governed: Rulemaking, Operations, and Enforcement. The latter two address issues of lock-in and accessibility: Alternatives and Adoption.

A few notes about governance. Our approach parallels the same breakdown in 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 sections on Alternatives and Adoption were created because we identified decentralization factors that have nothing to do with governance. As an example, a completely open system of formal "decentralized" governance could be de facto centralized because it is the only available option. If there is only one wallet you can use for a given Method, that may be unacceptably centralized for a given use. On the other hand, if that wallet is already ubiquitous in the use cases that matter, this centralizing factor may not be as relevant given its accessibility by intended users. Similarly, some use cases would be dramatically limited if there were only one relying party who is willing to accept DIDs of a given Method. If a theoretical did:facebook Method were only accepted by Facebook (because no other services were willing to use it) that would affect its centralization, even if it were possible by design for any service to do so. The criteria in Alternatives and Adoption sections attempt to evaluate these factors.

The architecture

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

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.

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 A Rubric for Decentralization of DID Methods v0.0.1
Rubric URL TBD

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

The criteria

Rulemaking

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

Open contribution (participation)

Question

How open is participation in governance decisions?

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

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.

Transparency

Question

How visible are rulemaking processes?

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

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.

Breadth of Authority

Question

How many independent parties actively participate in the governance authority?

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

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.

Public v private economies

Question

How privatized is the economic interest of the governing authority?

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

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.

Cost

Question

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

Responses
  1. Free to all
  2. Inexpensive, but accessible
  3. Modest cost for interested parties
  4. Expensive and restricted
  5. Not possible to participate
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.

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.

Operation

Permissioned operation

Question

To use the DID Method, do you need permission?

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

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.

Financial accountability

Question

How transparent and fair are the economics of the Method?

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

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.

Interoperability

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

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

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.

Limited resource resolution

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.

Responses
  1. Minimal. Less than 1MB
  2. Modest. 1MB to 1GB
  3. Substantial. 1GB to 128 GB
  4. Exceptional. Over 128GB in memory
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.

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.

Limited resource registration

Question

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

Responses
  1. Minimal. Less than 1MB
  2. Modest. 1MB to 1GB
  3. Substantial. 1GB to 128 GB
  4. Exceptional. Over 128GB in memory
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.

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.

Scope of usage

Question

How widely can DIDs of this Method be used?

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

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.

Auditability

Question

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

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

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.

Enforcement

The matter of enforcement is a tricky question, one that the authors did not have sufficient time to explore and resolve. Although we are forced to leave this section for future collaboration, we want to share some of our insights.

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.

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.

Active implementations

Question

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

Market share

Question

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

Platform support

Question

Which platforms have implementations?

Language support

Question

Which programming languages have implementations?

Rogue risk

Question

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

Forkability

Question

Is it forkable?

Adoption (and diversity)

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.

Acceptance

Question

How many relying parties accept DIDs of this Method?

Users

Question

How many daily active users use this Method?

International adoption

Question

How many different countries have significant usage?

In which countries?

Question

Which countries have significant usage?

Language support

Question

How many (human) languages are supported?

Security

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

Robust Crypto

Question

What is the lowest security level ("bits of security") provided by the combination of algorithms and key types that the method requires its implementations to support?

Responses
  1. No combination of required features produces a profile with less than 256 bits of security.
  2. Between 128 and 256 bits.
  3. Less than 128 bits
  4. Less than 64 bits
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.

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

Expert Review

Question

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

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

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

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

Future Proofing

Question

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

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

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

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

Self Certification

Question

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

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

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

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

Availability

Question

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

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

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

Evolution

Question

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

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

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

Many Eyes

Question

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

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

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

Diffuse Control

Question

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

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

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

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

Regulatory Compliance

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

Responses
  1. > ?
  2. ?
Relevance

?

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

Privacy

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.

Per-DID constraints on visibility

Question

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

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

Examples
Method Net. Reg. Notes
did:foo A D By design, did:foo is super private.

Cross-DID Leakage

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?

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

Examples
Method Net. Reg. Notes
did:foo A D By design, did:foo is super private.

Incentives for Multicontext DIDs

Question

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

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

Examples
Method Net. Reg. Notes
did:foo A D By design, did:foo is super private.

Deletion

Question

How are mistakes corrected, and how is the right to be forgotten addressed? (Note how this creates a tension with immutability, which may be valuable in 2.7.1 and elsewhere.)

Responses
  1. Provable deletion of data is fully supported. Once something is deleted, nothing internal to the system allows it to be recovered.
  2. True, provable deletion is not supported, but deleted data can be suppressed in jurisdictions where this is required.
  3. The VDR is a permanent, immutable record with no support for deletion of any kind.
Relevance

?

Examples
Method Net. Reg. Notes
did:foo A D By design, did:foo is super private.

Help With Best Practice

Question

Does the method acknowledge privacy risks in service endpoints and other forms of DID document data, and provide technical, policy, or explanatory safeguards?

Responses
  1. ?
  2. ?
  3. ?
Relevance

?

Examples
Method Net. Reg. Notes
did:foo A D By design, did:foo is super private.

Not decentralization criteria

We reviewed a lot of proposed criteria for inclusion in this rubric. Not all of them turned out to be a good fit, often because they were simply not related to decentralization. They were useful criteria for evaluating a DID Method, but we specifically limited ourselves to ONLY consider those criteria that specifically capture some notion of decentralization or its related benefits.

We've included a list of additional considered criteria in .

Maturity was one of those categories of criteria that we liked, but just wasn't related to how decentralized a Method is. We considered the maturity of the specification, such as how long it has been published. We considered the organizational maturity of the lead proponents of the Method: is this Method backed by a major player that has been around a while or is its only advocate a small startup? We even considered the operational maturity of the Method: how long had the Method been live, in production?

These are all excellent questions to ask when considering supporting, adopting, or contributing to a particular DID Method, but they do not capture anything about how decentralized a Method is. A system simply doesn't become more or less centralized just because it is around a long time.

What can happen over time is that a given Method might improve in its adoption or diversity, as more institutions, users, and platforms add support in various ways, and these aspects of a Method can shift how decentralized a Method might be, but maturity itself does NOT affect centralization.

The authors had similar discussions considering security, privacy, and reliability criteria. All of these are important, but not directly related to the question of decentralization. While decentralization can improve reliability, it can also undermine it if done poorly. Similarly, security and privacy don't necessarily impact decentrality and vice-versa.

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

Conclusion

This Rubric for Decentralization of DID Methods provides one framework for evaluating how "decentralized" a given DID Method is. It offers a set of criteria which can be used selectively by Evaluators to better understand and document their considerations when deciding to support or adopt a given DID Method.

We look forward to feedback and improvements on this document and will be proposing it as the foundation for further development in the Decentralized Identifier Working Group (DID WG) of the World Wide Web Consortium. Today, comments are welcome in the Rebooting Web of Trust repository in which this document is published. Our intention is to move this conversation to the DID WG, should the group accept this contribution as a starting point for future work.

Terminology

Evaluator
The individual or organization applying this rubric to evaluate a DID Method.
Evaluation
The process of and analysis from answering the question in each selected criteria for a given DID Method. Evaluation could refer to deciding the answer to a single criteria or to a "complete" set, where completeness is in the judgment of the Evaluator.
Evaluation Report
The output of an Evaluation. The written documentation of the result of evaluating one or more DID Methods against this rubric. In practice, this is a completed report template, with answers for all of the criteria selected by the Evaluator.
Network
the channel that enables communication of DID Method operations, .e.g, for BTCR, any of the main bitcoin networks can be used (mainnet, testnet, etc.). For did:ethr, the network is any EVM-compliant network (each DID specifies one and only one such network).
Registry
the instantiated storage and integrated business logic that record the effect of DID Method operations. In did:ethr, the registry is a smart contract. In did:btcr, the registry is the specific bitcoin network (the network and the registry are the same).
you
Throughout this document we use the second-person pronoun "you" to refer to Evaluators of a DID Method applying this Rubric.

Possible additional criteria

Maturity

  1. ​How long has the specification been published?
    1. Just a concept sketch
    2. A complete draft...
    3. ...
    4. Published as a fixed, recommended specification
    5. [Published for X years]
  2. ​How mature is the entity who controls the specification?
  3. ​How long has the specification been in live usage?

Cryptography

  1. Can the individual use their own cryptographic material for key generation without sharing secrets? ​
  2. Can DID Controllers specify their own cryptographic suite for key generation / signing / hashing / etc.? ​
  3. Can DID Controllers specify ANY cryptographic suite for key generation / signing / hashing / etc.? ​
  4. Do DID Controllers have cryptographically provable control over DID Documents? ​
  5. Are all registry transactions publicly inspectable and cryptographically verifiable?Does the Method support specific cryptographic capabilities?
    1. Multi-sig
    2. Shamir secret sharing
    3. HD Keys
    4. Object capabilities
  6. Does the Method provide a cryptographic DID, or does it try to provide a human-readable name? ​
  7. Do DIDs with a few random substitutions result in different valid DIDs, or is there cryptographic error correction to identify transmission errors and typosquatting? ​
  8. Can the Method-specific-id be generated without the use of a per-Method centralized registry service (as required in the DID specification [[DID-CORE]])?

Fiduciary commitments

  1. Do operators of resolvers accept fiduciary responsibility to users? Do any? ​
  2. Do operators of registry nodes accept fiduciary responsibility to users? Do any? ​
  3. Do the parties in charge of governance accept fiduciary responsibility to users? Do any? ​
  4. Do wallet creators & maintainers accept fiduciary responsibility to users? Do any?

Reliable recovery

  1. Are there mechanisms to recover from key loss? ​
  2. Are there non-administrative mechanisms to recover from key loss ​
  3. Are there cryptographically robust mechanisms for key recovery that allow individuals to select specific advocates or stewards?

Substitutability

  1. Are the DIDs portable to other Methods? ​
  2. Are the DIDs portable to multiple registries? ​
  3. Does the Method allow DID Controllers to specify where the DID Document resides? ​
  4. Does the Method allow DID Controllers to specify wherever they want the DID Document to reside?

Revocation / deactivation / deletion

  1. Is it possible to provably remove a DID from the system (and all nodes)? ​
  2. Is it possible to provably remove a DID Document from the system (and all nodes)? ​
  3. Are revocations and deactivations provably documented? ​
  4. Do revocations and deactivations allow for publicly visible explanations? ​
  5. Can cryptographic material be selectively revoked or rotated? ​
  6. Resolution ​
  7. Are all DIDs globally resolvable to a definitive, provably current DID Document? ​
  8. Are private DIDs (which are NOT globally resolvable) supported? ​
  9. Can access to DID Documents be limited to authorized parties? ​
  10. Can you get older versions by version number and by timestamp? ​
  11. Can you get cryptographic proof of the history of changes to a given DID Document?

Costs

  1. How much does DID creation and key rotation cost a DID Controller? ​
  2. Must individual DIDs be written to the registry? ​
  3. How much do changes to a DID Document cost the DID Controller? ​
  4. Do changes to DID Documents require updating the registry? ​
  5. What is the total cost of ownership for a typical DID and DID Document? ​
  6. Are there free versions of wallets? ​
  7. Are there free versions of registry software? ​
  8. Are the free versions of resolvers?

Censorship resistance

  1. Is there a single legal or natural entity, or set of known entities, who can be targeted with intent to manipulate the operation or governance of the Method? ​
  2. Is participation in operation of the Method dependent on identification using traditional legal credentials, such as a birth certificate, driver's license, or passport? ​
  3. Are activities on the registry traceable to real world individuals? ​
  4. Can DIDs be disabled or revoked by an administrator? ​
  5. Can DID Documents be edited or removed by an administrator?

Uncategorized

  1. Is the Method name definitive? (there are no known alternative forks or namespace collisions)
  2. Is the Method resilient against registry forks? ​
  3. Permissioned: governed/operation vs. use/creation ​
  4. Open source: multiple independent implementations ​
  5. Open standard ​
  6. Does the individual create and control? ​
  7. Can the individual choose how keys are managed? ​
  8. Does the issuer/controller have a fiduciary responsibility to DID Controller? ​
  9. Does it support social recovery? ​
  10. What does a single DID cost? TCO ​
  11. Is resolution observable? ​
  12. Are stealth DIDs supported? ​
  13. Is deactivation publicly documented? ​
  14. After control is lost can other people deactivate? ​
  15. Possible confusion between implementations and DID Methods ​
  16. Does it support HD Keys? ​
  17. Are transactions publicly cryptographically verifiable? ​
  18. Are DIDs permanent (unremovable--still able to be deactivated but all traces can never vanish)? ​
  19. Can you get the latest version and older versions? Provable order of versions? ​
  20. Is the Method published? ​
  21. Is that Method independently implementable? ​
  22. did:web and the .onion TLD (truly decentralized) RFC 6761 and 7686 ​
  23. Is there a centralized database? ​
  24. Is its blockchain byzantine fault tolerant? ​
  25. Does a single party control a majority of the source of truth? (Under what conditions can the DID controller lose capability?) ​
  26. If you give control away, can you get it back?

Acknowledgements

Many thanks to contributions from Kai Wagner.