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.
...
- What is the cost of writing to the ledger?
- What is the cost of running a node?
- Do I have to run a node?
- Is there financial incentive for me to run a node?
- Is the business model of the utility platform viable?
...
- What is the minimum count of nodes of my utility needed to be considered as decentralized and censorship resistant?
- Do I want the utility I use to have permissioned of public write access?
- Do I want my Utility to have public read access?
- Do I want permissioned or public nodes?
- Does my utility need to be an open source project?
- Who has influence on the product roadmap?
- Who can make changes to the product?
...
- Do I have a particular legal entity structure needed around my utility?
- Is there a need for my utility to meet localized privacy regulations?
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
6 things you should know about blockchain utilities when pursuing a decentralized identity strategy
As part of it's mission to architect what is needed for Internet-scale digital trust, the Trust over IP (ToIP) Foundation has published a duel-architecture design that places emphasis on governance, but also the need for publicly available utilities to store pertinent information relating to the Issuers of Verified Credentials and the structures of these credentials. To achieve portable digital identities and equip people and organizations with trusted and secured credentials, it's important to consider the base layer of the stack. See below:
Within the ToIP's Utility Foundry working group, we've been working alongside the community of utility project conveners to document their missions and requirements when forming their respective utility layers. Based on the initial research, here are 6 things you should know about utilities when pursuing a decentralize identity strategy for your business and respective ecosystems.
1. How much am I willing to pay to use a utility?
- Compare transactions types and fees (Sovrin example)
- Depending on ecosystem use case, you may need lots of transactions
2. Should I consider convening in the creation of my own utility?
- What are complexities (managing consortium, legal entity formation)
- Costs
- Why private networks aren't better than databases
3. Do I need to run a node to use a utility?
- Benefits of running a node
- Example of Sovrin stewards
- Costs of running a node
4. How can I evaluate existing utility options?
- Side revenue-generating services
- Interoperability - Avoiding ledger-lock
- We documented utilities list: https://github.com/trustoverip/utility-foundry-wg/blob/master/UTILITY_LIST.md
5. Do I need to consider data privacy laws (e.g., GDPR) in my decisioning?
- Write about IDunion here and the rise of localized networks such as CanaCred.
6. Can I test a utility before committing to one?
...
Broad differentiators, standards and questions
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? |
Public Utility Grading Criteria
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.
- Business Requirements - The critical activities of an enterprise that must be performed to meet the organizational objective(s) while remaining solution independent.
- Legal Requirements - Any compliance requirements placed on an ecosystem or participants within the ecosystem that pertain to a range of laws such as financial regulations, tax obligations, and privacy regulation.
- Technical Requirements - The range of technical issues that must be addressed to successfully complete a PUI project. These include but are not limited to performance, reliability, and availability.
- Social Requirements - It’s important for the ecosystem to create value for the society and also generate income (if not wealth). Our solutions must be innovative, unique, people and environment friendly. Examples of social requirements can include transparency, inclusivity, diversity, and accessibility. Beyond helping curb those global challenges, sustainability can drive business success. Several investors today use Environmental, Social, and Governance (ESG) metrics to analyze an organization’s ethical impact and sustainability practices. Investors look at factors such as a company’s carbon footprint, water usage, community development efforts, and board diversity.
- Governance Requirements - The collection of governing processes required by the Utility to be successful and sustainable.
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.
Scoring system for simple graphic representation
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.
Business Requirements
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:
- Provide client software (or a Software Development Kit) to issue and consume Verifiable Credentials, with DIDs anchored on the Utility, for the purpose of developing SSI use cases?
- 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?
- Remunerate Node Operators in any financial capacity?
- 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?
Notes and more subjective considerations:
- What contracts does the Utility have with technology providers? Do they have long term contracts or short term contracts?
Technical Requirements
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:
- Support Public DIDs, as defined in the W3C DID core specification, anchored to the Utility for the purpose of Self-Sovereign Identity (SSI) use cases?
- 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, Capacity Invocation 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?
Notes and more subjective considerations:
Legal Requirements
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:
- Support GDPR by design (i.e. no personal data or personally identifiable information is written to the Utility?
- Have a public crisis and contingency policy, in case the Utility enters a period of downtime or failure?
- 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)?
Notes and more subjective considerations:
- Is there a level of compliance offered with respect to data privacy laws when joining a utility? Does my organization need to be structured in a certain way to comply with legal requirements for joining the Utility?
Social Requirements
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:
- 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 on a weekly basis?
- Support and/or partner with more than 10 SSI vendors?
- Engage in initiatives to offset carbon and/or reduce its environmental footprint?
Notes and more subjective considerations:
- Has there been negative press announcements regarding the operation of the utility?
- What impact does the Utility have on the local community?
- How is the Utility dealing with self-sovereignty and human rights principles?
Governance Requirements
Finally, this section will help you understand why governance is important and where traditional and decentralized governance differentiate.
Does the Utility:
- 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?
Notes and more subjective considerations:
- Has the utility defined an adequate number of members to sustain operations?
- How is the actual network governed regarding such things like updating the network, running consensus on transactions, and adding parties to the network?
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 |