- Introduction
- Decentralized Identity / Self-Sovereign Identity
- Hyperledger Indy
- Hyperledger Indy Catalyst
- Endnotes
Hyperledger Indy Catalyst is a set of application level software components designed to accelerate the adoption of trustworthy entity to entity1 communications based on Decentralized Identity / Self-Sovereign Identity technology and architecture. Indy Catalyst is builds upon globally available open standards and open source software. At present, Indy Catalyst builds upon Hyperledger Indy, common enterprise open source software, frameworks and patterns such as PostgreSQL, Python, Angular and RESTful APIs. Efforts will be taken to design the software to facilitate the incorporation of evolving open standards and technology. The impetus for Indy Catalyst came from the Verifiable Organizations Network (VON) project. More information about VON can be found at vonx.io
In order to understand the goals and context of Hyperledger Indy Catalyst, it is advisable to become familiar with the model of decentralized identity or self-sovereign identity which enables trustworthy entity to entity communications. The open standards and technologies enabling this new this model are presented below and annotated with references.
Self-Sovereign Identity is a term coined by Christoper Allen in 2016 to describe a new generation of digital identity systems. One which "requires that users be the rulers of their own identity." In order to truly understand the intent of this statement, which at first may sound rather radical, it is important to reflect upon the design of current identity systems and contrast that to the emerging design of decentralized identity systems.
The excellent paper, "Self-sovereign Identity: A position paper on blockchain enabled identity and the road ahead", published in October 2018 by the German Blockchain Association highlights the key differentiators between current digital identity systems and emerging self-sovereign identity systems.
The key differentiator pertains to the means by which current centralized identity systems keep track of individual entities in their databases. Centralized identity systems create and assign an identifer for each individual entity and associate data about that individual entity to that identifier. This is a familiar idea to most of us. In the analog world these identifiers have names such as drivers licence number, credit card number, bank account number, social insurance number, etc. The identity system owner creates and is in control of the identifiers and associated data for individual entities and not the individual entities themselves. Identity system operators have the ability to unilaterally make changes to these identifiers are associated data.
In contrast, the design of a decentralized or "self-sovereign" identity system is to put individual entities in control of the identifiers used to keep track of them as well as the holding and disclosure of the data associated to these new identifiers. These new identifiers, described below, are called "Decentralized Identifiers" (DID). The data associated to these identifiers is encoded into a new format called a Verifiable Credential. These Verifiable Credentials are issued to and held by individual entities.
Using this new approach to identity systems design means a person would be in full control of data issued to them by third parties. People would be in control of disclosing of their personally identifiable data as issued by themselves (e.g. personal preferences, messages, etc) or issued to them by third parties. These third parties may include authoritative issuers such as governments (e.g. identity documents, licences) or they could be issuers such as a local sports club (e.g. membership). Critically, "self-sovereign" is not intended to suggest a "digital self-declaration" of ones identity in opposition to or as a substitute for authoritative and officially issued identity attributes from a government. Rather, that one is both "in control" of the relationship (the decentralized identifier) and the data (verifiable credential) issued to them. Therefore, once one is holding this officially issued data, one can choose when and what one would like to disclose to third parties. The details of how this can be technically achieved are described briefly in the following sections along with appropriate references for further study.
It is important to note that while these emerging standards and technologies are being designed to tackle the very difficult challenges of secure and privacy respecting digital identity for people, they are not limited to the narrow context of personal identity. This new model can be applied to a broader set of use cases beyond those involving personally identifiable information. The model offers a generalized capability enabling highly secure entity to entity communications and it is this generalized capability that has led to the creation of Hyperledger Indy Catalyst. Indy Catalyst components enable enterprises to issue, hold and verify data about entities.
There are two emerging open standards aimed at enabling interoperable secure and privacy respecting entity to entity data exchange.
A DID is a globally unique and resolvable identifier created by a entity. A entity could be any sort of real world actor such as an individual person, a legal entity, a government authority, a thing. DIDs are created and issued by software under the control of a entity. DIDs are bound with the necessary information to allow a entity to demonstrate cryptographic control over the DID and to enable secure communications with that entity. With these basic primitives, secure and privacy respecting entity to entity data exchange becomes possible. DIDs do not require any centralized issuing or resolution authority.
A verifiable credential is data issued to, and held by an entity. Verifiable indicates the credential is rendered tamper-evident and in a manner whereby the issuer can be cryptographically verified.2 Data contained in a verifiable credential is organized into individual claims. Claims within a credential can be about different subjects (e.g entities) and may be verifiable individually.
The DID and Verifiable Credential emerging open standards are being incubated within the W3C Credentials Community Group
Stemming from the work in the Verifiable Credentials is a general model for describing the roles of the main actors in a Decentralized Identity / Self-Sovereign Identity ecosystem.
The roles and information flows are described in the W3C Verifiable Credentials Data Model 1.0. The roles are:
- Issuer
- Holder (also known as the Prover at verification time)
- Verifier
- A Verifiable Data Registry - commonly a decentralized ledger which serves as a system "mediating the creation and verification of issuer identifiers, keys and other relevant data like verifiable credential schemas and revocation registries".
These roles can be fulfilled by a number of "real world" actors including people, legal entities,or things.
The technologies described in this document provide the core functionality required to implement and complement the emerging open standards described above. Together this suite of open standards and technologies create a fundamentally new approach for privacy respecting and secure entity to entity communication.
The high integrity and global availability of a public blockchain combined with the concept of a DID creates a new decentralized root of trust capability. This new capability tackles a long standing problem with centralized identity systems, in particular those based on Public Key Infrastructure (PKI) models. The following sections provide links to in-depth explorations of these new approaches.
As stated in a the Decentralized Key Management Systems research paper for the Department of Homeland Security.
"DKMS inverts a core assumption of conventional PKI (public key infrastructure) architecture, namely that public key certificates will be issued by centralized or federated certificate authorities (CAs)."(DKMS = Decentralized Key Management System)
This paper provides an in-depth on the benefits of DMKS and its design.
A Zero Knowledge Proof protocol is an optional but useful complimentary capability for decentralized identity systems.
Hyperledger Indy does include an implementation of zero knowledge proofs. The implementation is described in this GitHub repository -> indy-anoncreds
Zero Knowledge Proofs allow the holder to prove that some or all of the data in a set of claims is true without revealing any additional information, including the identity of the holder. During these interactions the holder is referred to as a "Prover" as they are offering a proof of knowledge rather than transfering the claim directly to the verifier. This is a powerful capability enabling the holder to selectively disclose (e.g. prove "I am over 25" or "I am holding a valid drivers licence") without revealing to the verifier any other facts about themselves.
Decentralized Identity / Self-Sovereign Identity systems make use of DIDs, Verifiable Credentials, and a Verifiable Data Registry (Decentralized Key Management System). Such an architecture is one where the holder of verifiable credentials (a set of verifiable claims) is in complete control of their identifier, where their verifiable credentials are stored, and how they are used.
{to be completed} Based on indy-node providing the root of trust for Decentralized Identifiers (DID) and other artifacts to enable a decentralized (or self-sovereign) identity network.
Hyperledger Indy is open source software providing:
"tools, libraries, and reusable components for providing digital identities rooted on blockchains or other distributed ledgers so that they are interoperable across administrative domains, applications, and any other silo."
More broadly, Hyperledger Indy based networks create the technical conditions for highly secure entity to entity data exchange without the involvement of a central authority. The techniques made available by Hyperledger Indy mitigate the security and privacy problems stemming from current approaches to data exchange over the Internet. These problems are particularily evident when it comes to the exchange of highly senstive forms of data such as personally identifiable information (e.g. identity attributes).
The technical means by which this is accomplished include a number of new open emerging standards and technologies.
{to be completed}
Indy Catalyst components are designed for several enterprise scenarios:
- join an existing Hyperledger Indy based network as a entity that can engage in entity to entity communication
- establish a credential registry
Networks require a strategy to get them started. This is due to the challenge of creating network effects. There are several excellent resources describing what network effect are, why they are important, and techniques to go about creating them. Several excellent summaries describing techniques for creating network effects can be found in this Andreessen Horowitz articleand in this NfX article. Sometimes this problem is referred to as the "Chicken and Egg Bootstraping problem".
Indy Catalyst components:
- use standard enterprise and Internet technologies;
- implement common integration patterns to minimize effort to adopt; and,
- minimize the learning needed to get started.
TODO
Credential Registry provides a set of RESTful web services you can use to query data from your third-party application, an introduction to use of these API's is available here.
Indy Catalyst provides a web hook facility for interested parties to subscribe to notifications for credential updates.
There are 3 subscription types supported:
- New - notification for any new credential (i.e. newly registered organization) of a specific type
- Stream - any updates for a specific stream - organization (by topic id) and type
- Topic - any updates for a specific organization (Topic)
Interested parties must first register, which creates an ID and password they use to manage their subscriptions. They can then add and remove subscriptions.
They must also provide a REST endpoint for the notifications - they can provide an endpoint with their scubscription and/or an endpoint with each separate subscription.
A test "echo" endpoint using the code at echo-service will be started on localhost:8000 when executing ./manage start. The service can also be run separately in Play With Docker or Play With VON, and used as the endpoint for the web hooks.
More details are available here.
drf-yasg is used to publish a OpenAPI 2.0 spec of the API. Until a 3.x spec generator is available, it is possible to download the up-to-date spec from here and run it through a 2-to-3 converter.
1: A thing with distinct and independent existence such as a person, organization, concept, or device. Source: Verifiable Claims Data Model and Representations 1.0. ↩
2: A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified. Source: W3C Verifiable Credentials Data Model 1.0 ↩