The purpose of this list is to help ToIP Ecosystem Solution Providers prioritize questions to ask themselves within their decisioning process of selecting a Utility.
Public Utilities for decentralized identity are not all built in the same way technically and may differentiate in various broad ways, in terms of their design and standards.
This section will lay out some of the more general points of differentiation to look our for, whereas, the following section will go into more specific detail on use-case-specific requirements. Since this section is looking more at the standard differentiators, the answers will be text based and will not employ the scoring model in the section below.
Differentiator | Explanation |
Utility name | What is the public name of the Public Utility, blockchain or ledger? |
DID Method | What DID method is used? Point to where it is registered on the DID Registry |
Convenor | Which organization, person or DAO is responsible for the Utility? |
Base Protocol | What is the base protocol that the Utility is built upon (e.g. Hyperledger Indy) |
Permissioned or Permissionless | Does the Utility have a permissioned or permissionless model? |
Number of nodes | How many nodes, validators or stewards (analogous) are there running on the network? |
Schema storage | Where does the Utility store its Verifiable Credential schemas |
Credential Definitions | Does the Utility support Credential Definitions? |
DID Document storage | Where does the Utility store its DID Documents? |
Revocation registry supported | What type of Revocation method or registry is supported? |
Credential type supported | What Credential flavors or types are supported by the Utility |
Utility Software Development Kit (SDK) | What specific SDKs does the Utility support for utilizing its functionality |
Types of DID resolver supported | What implementations of a DID resolver does the Utility support |
Cross-ledger DID support | Does the Utility support or make any efforts to enable DIDs to be cross-utility compatible? |
Payments for DIDs supported | Does the Utility charge for Decentralized Identifier (DID) writes? If so, how much does it charge? |
Payments for VCs supported | Does the Utility have any functionality to support payments for Verifiable Credentials natively? |
Governance type | Does the Utility support a traditional or a decentralized governance model? |
In creating business cases around technology, people often use a simple framework of Business, Legal, and Technology to support the business decision processes. A common mistake innovators should try to avoid is to start with technology requirements, before considering the business and legal requirements. With decentralized architecture such as the ToIP Framework, it’s critical to also take Social and Governance elements into consideration.
These may not be the only elements you want to use to evaluate your own project requirements, but we will focus on each of these elements below.
Unlike the W3C DID Rubric v1.0, which goes into detailed specifics of each section of a Public Utility and DID method, using a A, B, C, D scoring system; the intention of this document is to create a more easily accessible, visual representation and template of how to compare Layer 1 Utilities.
For this reason the scoring system will be a more basic model:
Fully supported by the Utility | Partially supported by the Utility or on roadmap | Not supported by the Utility |
A template and visual representation will be provided at the bottom of this document.
This section is important to determine whether the utility aligns with the commercial model of your company, whether it would be sustainable, and whether it provides easy and accessible software and documentation.
Does the Utility:
This section will help you understand the technical specifics of each Utility, such as technical standards and capabilities, and considerations that you should make when approaching different Utilities you want to build on.
Does the Utility:
This section should help assess whether each utility has done enough to stay compliant within the jurisdiction you want to build your SSI use case within.
Does the Utility:
This section addresses social requirements, such as whether the Utility is environmentally sustainable, whether it is accessible and easy to understand and whether it has a proactive and engaging community.
Does the Utility:
Finally, this section will help you understand why governance is important and where traditional and decentralized governance differentiate.
Does the Utility:
Utility | Business Requirements: | Technical Requirements | Legal Requirements | Social Requirements | Governance Requirements | ||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Does the Utility: | Provide client software (or a Software Development Kit) to issue and consume Verifiable Credentials? | Utilize an Open Source license for its core network functionality and/or SDK? | Have a transparent commercial costs model for DIDs anchored to the Utility? | Support native payment flows for Verifiable Credentials? | Have a financial or economic model for the sustainability of the Utility? | Have examples of its use within a Proof of Concept (PoC)? | Have examples of its use within a production environment? | Provide a testnet or testing environment? | Support Public DIDs, as defined in the W3C DID core specification? | Support W3C Verifiable Credentials, as defined in the Verifiable Credentials Data Model? | Support AnonCreds V1? | Support the storage of credential schemas on ledger? | Support the storage of DID Documents on ledger? | Support Verifiable Credential revocation? | Provide privacy preserving Verifiable Credential revocation? | Have a publicly accessible DID Core compliant DID method? | Support multiple DID controllers in its DID method? | Support Verification Method Relationships such as Authentication and Assertion in its DID method? | Support the retrieval of historic DID states, such as old/rotated Verification Methods? | Have the capability to support multiple wallets and implementations on top of its core functionality? | Provide clear technical documentation for setting up a node on its core Network? | Support GDPR by design (i.e. no personally identifiable information is written to the Utility? | Have a public crisis and contingency policy, in case the Utility enters a period of downtime? | Have a defined legal organization, responsible for the actions of the network? | Utilize a Decentralized Autonomous Organization (DAO) to underpin its corporate structure? | Intend on acting as a trusted network for the European Blockchain Services Infrastructure (EBSI)? | Publicize educational content on how to create/resolve DIDs on the Utility? | Formally support Trust over IP, as a registered Utility? | Have a core team which actively engages in the SSI community? | Support and/or partner with more than 10 SSI vendors? | Engage in initiatives to offset carbon and/or reduce its environmental footprint? | Support open, public participation in governance decisions? | Have a public, transparent governance framework? | Allow the community to influence the product roadmap? | Have an active strategy to achieve a state of sufficient decentralization or censorship resistance? | Have an enforcement policy for counteracting bad behavior on the Network? | Have a forum for Utility-specific discussion for the users and participants? | A governance voting structure, either based on an elected Board or through a more distributed/decentralized voting structure? | Support the use of democratic voting using a governance token? |
Sovrin | |||||||||||||||||||||||||||||||||||||||
Bedrock | |||||||||||||||||||||||||||||||||||||||
Indicio | |||||||||||||||||||||||||||||||||||||||
KochiOrgBook | |||||||||||||||||||||||||||||||||||||||
IDunion | |||||||||||||||||||||||||||||||||||||||
cheqd | |||||||||||||||||||||||||||||||||||||||
Kilt | |||||||||||||||||||||||||||||||||||||||
EBSI | |||||||||||||||||||||||||||||||||||||||
Sidetree | |||||||||||||||||||||||||||||||||||||||
Nym | |||||||||||||||||||||||||||||||||||||||
Dock | |||||||||||||||||||||||||||||||||||||||
Velocity |