Page Comparison

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?

...

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.  

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.

1. Business Requirements - The critical activities of an enterprise that must be performed to meet the organizational objective(s) while remaining solution independent.
2. 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.
3. 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.
4. 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.
5. 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:

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?