Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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:

Image Removed

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?

  1. Compare transactions types and fees (Sovrin example)
  2. 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?

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.

  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:


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?


UtilityBusiness Requirements: Technical RequirementsLegal RequirementsSocial RequirementsGovernance 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