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.
| Categories | Question |
|---|---|
| 1. Business Model / Sustainability |
|
| 2. Product Governance |
|
| 3. Legal Governance |
|
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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?
- Most established utilities have test networks that are free to use for testing and use case proofing
- Write about Indicio and Sovrin here.
| 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? | 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 | ||||||||||||||||||||||||||||||||||||||