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.
This rubric is a collection of criteria for creating Evaluation Reports that assist people in choosing a DID Method. While this rubric assists in the evaluation of many aspects of a DID Method, it is not exhaustive.
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:
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.
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.
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
We have grouped our criteria into several categories:
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.
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. See the tables below.
The following sources provided example evaluations for this rubric. These are not presented as objective fact, but rather as attempts by contributors to illustrate noteworthy differences using their subjective judgement. Additional contributions that flow into the registry should include a section that documents their source with an additional row in the table.
|eval-1||DID Method Rubric||Evaluations written by Joe Andrieu, for this rubric. Not explicitly funded.|
|eval-2||DID Method Rubric||Evaluations written by Daniel Hardman, to illustrate this rubric. Not explicitly funded.|
|eval-3||"A Rubric for Decentralization of DID Methods". Joe Andrieu, Shannon Appelcline, Amy Guy, Joachim Lohkamp, Drummond Reed, Markus Sabadello, Oliver Terbu. Rebooting the Web of Trust. Published 2020-07-20. https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/decentralization-rubric.pdf.||The original DID Rubric paper from Rebooting the Web of Trust. Not explicitly funded.|
|eval-4||VeresOne Rubric Evaluation||Funded by Digital Bazaar under DHS SVIP contract 70RSAT20T00000029.|
|usecase-1||Long term verifiable credentials||The use of DIDs as subject identifiers for long term (life-long) verifiable credentials such as earned academic degrees.|
|usecase-2||User authentication||The use of DIDs for authenticating users for access to system services.|
|usecase-3||Verifiable software development||The signing of commits by developers and their verification to ensure that source code in a particular git repository is authentic.|
|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.|
|did:ipid||IPID DID Method||@johnnycrunch||DIDs persisted to IPFS.|
|did:web||did:web Method Specification||CCG work item||DIDs associated with control of a domain name (DNS).|
|did:indy||did:indy Method Spec||Hyperledger Indy community||Supersedes did:sov to service all Indy-based ledgers.|
|did:iota||IOTA DID Method Spec||IOTA Foundation||DIDs persisted to the IOTA tangle.|
|did:keri||The did:keri Method 0.1||Sam Smith, et al.||DIDs that can migrate from one blockchain to another, or use no blockchain at all.|
|did:hedera||Hedera Hashgraph DID Method Specification||Hashgraph, Inc||DIDs written to a ledger that uses Hashgraph consensus as an alternative to traditional blockchain.|
|did:key||The did:key Method v0.7||CCG work item||Use a keypair as a DID.|
|did:twit||Twit DID method specification||Gabe Cohen||Publish a DID via Twitter feed.|
|did:pkh||did:pkh Method Specification||Spruce ID||Wrap an identifier (e.g., payment address) from one of many existing blockchains in did format.|
|did:trustbloc||TrustBloc DID Method Specification 0.1||Trustbloc||Persist DIDs via Sidetree wrapper around a permissioned ledger.|
|did:jlinc||JLINC DID Method Specification||JLincLabs||Register DIDs over the JLinc protocol for sharing data with terms and conditions.|
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.
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.
Each criteria needs a human-friendly, short, descriptive name that captures the essence of the criteria as concisely as possible.
The criteria id must be explicit, unique, and persistent. See the section on Identifiers for details.
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.
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.
This subcomponent lists the expected responses to the question.
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.
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.
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.
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):
<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
Criteria versions allow for incremental improvements while retaining long-term referenceability.
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:
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.
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:
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.
Rulemaking addresses who makes the rules and how. Output of rulemaking are the rules.
How open is participation in governance decisions?
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.
|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. [eval-1]|
|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". [eval-1]|
|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. [eval-1]|
|did:sov||B||B||B||The Sovrin Foundation has an open community governance model but has not yet had open elections of trustees. [eval-1]|
|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. [eval-1]|
|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. [eval-1]|
How visible are rulemaking processes?
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.
|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. [eval-1]|
|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. [eval-1]|
|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. [eval-1]|
|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. [eval-1]|
|did:ethr||C||C||D||The governance is controlled by a smart contract, which is immutable. [eval-1]|
|did:jolo||C||C||D||Jolocom does not expose the internal and/or customer conversations that drive rulemaking. [eval-1]|
How many independent parties actively participate in the governance authority?
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?
|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). [eval-1]|
|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. [eval-1]|
|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. [eval-1]|
|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. [eval-1]|
|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. [eval-1]|
|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. [eval-1]|
How privatized is the economic interest of the governing authority?
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.
|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. [eval-1]|
|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. [eval-1]|
|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. [eval-1]|
|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. [eval-1]|
|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. [eval-1]|
|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. [eval-1]|
How expensive is it to participate in governance (in time, money, or effort)?
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.
|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. [eval-1]|
|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. [eval-1]|
|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. [eval-1]|
|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. [eval-1]|
|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. [eval-1]|
|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. [eval-1]|
Design criteria addresses the method as designed. In other words, the output of the rulemaking: what rules apply to this DID method?
To use the DID Method, do you need permission?
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.
|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. [eval-1]|
|did:git||A||D||Git software is available to anyone. Participation and access is controlled by the repo maintainers. [eval-1]|
|did:btcr||A||A||The bitcoin network is open to anyone. [eval-1]|
|did:sov||C||C||Sovrin foundation limits access to writing and consensus, but the network is open to all for reading. [eval-1]|
|did:ethr||A||A||Ethereum is open to anyone. The registry is accessible to anyone. [eval-1]|
|did:jolo||A||A||Ethereum is open to anyone. The registry is accessible to anyone, although some subregistries/subnetworks may have alternate rules. [eval-1]|
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.)
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.
|did:peer||A||A||did:peer is agnostic regarding the software that implements it. [eval-1]|
|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. [eval-1]|
|did:btcr||A||A||Bitcoin has no restrictions on the software used to access the network. [eval-1]|
|did:sov||A||A||did:sov: has no restrictions on any software that implements it. [eval-1]|
|did:ethr||A||A||Neither Ethereum nor the smart contract has any restrictions on the software used to access them. [eval-1]|
|did:jolo||A||A||Neither Ethereum nor the smart contract has any restrictions on the software used to access them. [eval-1]|
How widely can DIDs of this Method be used?
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.
|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. [eval-1]|
|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. [eval-1]|
|did:btcr||A||A||Open, permissionless, and globally resolvable. [eval-1]|
|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. [eval-1]|
|did:ethr||A||A||Open, permissionless, and globally resolvable. [eval-1]|
|did:jolo||A||A||Open, permissionless, and globally resolvable. [eval-1]|
How transparent and fair are the economics of the Method?
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.
|did:peer||D||D||The financials of both parties have no visibility. [eval-1]|
|did:git||A||D||The financials of both parties have no visibility. However, the underlying git software is free and open source. [eval-1]|
|did:btcr||A-||A-||Bitcoin is transparent, although operations are somewhat obscured by pseudonymous transaction addresses. [eval-1]|
|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. [eval-1]|
|did:ethr||A-||A-||Ethereum is transparent, although operations are somewhat obscured by pseudonymous transaction addresses. [eval-1]|
|did:jolo||A-||A-||Ethereum is transparent, although operations are somewhat obscured by pseudonymous transaction addresses. [eval-1]|
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.
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.
|did:peer||A||A||Resolution typically requires looking up a file in the file system, which uses minimal RAM. [eval-2]|
|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. [eval-1]|
|did:btcr||D||D||To definitively resolve, one must operate a full node. [eval-1]|
|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. [eval-1]|
|did:ethr||B||B||A full ethereum node takes >100GB, but a light ethereum node can support this method with less than 256kb. [eval-1]|
|did:jolo||B||B||A full ethereum node takes >100GB, but a light ethereum node can support this method with less than 256kb. [eval-1]|
What are the minimum resources required to create a trusted DID without relying on intermediaries?
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.
|did:peer||A||A||Registration may require a few KB of RAM as a DID doc is written to disk. [eval-2]|
|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. [eval-1]|
|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. [eval-1]|
|did:sov||A||A||Registration of a DID is a single transaction that can be performed by a thin client. [eval-1]|
|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. [eval-1]|
|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. [eval-1]|
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.
Who can retrieve cryptographic proof of the history of changes to a given DID Document?
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.
|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). [eval-1]|
|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. [eval-1]|
|did:btcr||A||Anyone can see everything. [eval-1]|
|did:sov||A||Anyone can see everything—the Sovrin ledger is completely public. [eval-1]|
|did:ethr||A||Anyone can see updates and deletes. Creation is private. [eval-1]|
|did:jolo||A||Anyone can see updates and deletes. Creation is private. [eval-1]|
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.
How many (active) substitutable, interoperable implementations support this Method?
How large is the share of use by each of the top three implementations?
Which platforms have implementations?
Which programming languages have implementations?
If there is one dominant implementation, how many programmers would need to be compromised to get a back-door into distribution?
Is it forkable?
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.
How many relying parties accept DIDs of this Method?
How many daily active users use this Method?
How many different countries have significant usage?
Which countries have significant usage?
How many (human) languages are supported?
Security has a strong influence on overall trust in the ecosystem. Different DID methods offer different security guarantees, or guarantees of different strengths.
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?
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.
|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. [eval-2]|
|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. [eval-2]|
|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. [eval-2]|
Does the system use cryptographic and security primitives that are well vetted by technical experts, and battle hardened in the school of experience?
Exotic crypto and other security mechanisms without expert review and a production track record is likely to contain hidden risks.
|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. [eval-2]|
|did:git||C||Git uses SHA-1 hashes to identify commits. This hash has known collision attacks. [eval-2]|
How friendly is the system to adopting post-quantum crypto, larger hashes, or other measures that upgrade its security?
A DID method that is hard to upgrade with respect to crypto creates incentives to remain with deprecated algorithms beyond their useful lifespan.
|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). [eval-2]|
|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. [eval-2]|
To what extent is the entropy used to create an identifier demonstrably connected to the party that created its inception key?
An identifier that has a predictable or manipulable value, or that has inception keys that anyone could have created, is an attack vector.
|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. [eval-2]|
The value of a DID in did:hedera is always directly derived from the
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
How robust are protections against attempts to suppress information flow, whether legal (cease and desist) or technical (denial of service)?
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.
|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. [eval-2]|
|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. [eval-2]|
Is the current state of a DID document provably correct from a history that's visible to anyone who can resolve the DID?
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.
|did:foo||A||D||By design, did:foo supports 123.5 bits of security.|
Is the code of the method published, does it have many contributors, and does it have a published vulnerability reporting (responsible disclosure) mechanism?
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.
|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. [eval-2]|
|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. [eval-2]|
To what extent does the system support mechanisms where DID control is distributed across multiple parties (m-of-n control, threshold signatures, etc.)?
Diffuse trust makes hacking harder and recovery more robust (but maybe more complex).
|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. [eval-2]|
|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. [eval-2]|
Does the system use cryptographic mechanisms that satisfy legal requirements in relevant jurisdictions (e.g., FIPS-certified algorithms, requirements for encryption back doors, etc.).
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.
|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. [eval-2]|
|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. [eval-2]|
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.
What provisions are made for restricting visibility of DIDs to audiences other than the general public?
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.
|did:twit||C||A did:tweet is created and updated by posting to a public twitter feed; it is always completely public. [eval-2]|
|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. [eval-2]|
|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. [eval-2]|
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?
Inferring relationships between Bitcoin addresses allowed law enforcement to track down the operators of Silk Road, even though those operators believed they had privacy.
|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. [eval-2]|
|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. [eval-2]|
To what extent does the method incentivize (due to cost, hassle, etc.) a DID to be reused in multiple contexts?
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.
|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. [eval-2]|
|did:sov||C||The Sovrin ledger deliberately charges for ledger writes to discourage its use for privacy-oriented identifiers. [eval-2]|
|did:peer||A||Creating a peer DIDs is free and nearly instantaneous. There are no incentives for reuse. [eval-2]|
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.)
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.
|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. [eval-2]|
|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. [eval-2]|
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 .
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.
This DID Method Rubric one framework for evaluating DID Methods. 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.
This Note is a derivative work of [[[DID-DEC-RUBRIC]]], a collaborative paper written at Rebooting the Web of Trust IX by Joe Andrieu, Shannon Appelcline, Amy Guy, Joachim Lohkamp, Drummond Reed, Markus Sabadello, and Oliver Terbu.