HYPERLEDGER INDY FOR THE ENTERPRISE
SO WHAT IS HYPERLEDGER INDY ALL ABOUT?
More than ever, organizations are being challenged with how to securely manage their client's personal information while maintaining the public's expectation of data privacy, integrity, and availability. Organizations are increasingly collaborating and looking for solutions to manage their online identity and do business electronically. These needs have pushed organizations to consider new and innovative platforms in their search to build more robust applications.
Hyperledger Indy (or Indy for short) is one of the lesser-known projects within the Linux Hyperledger Foundation that is focused on Identity, Privacy and Self Sovereign Identity. Indy provides a solution to both the problem of managing personal information privacy, as well as supporting enterprise applications that need to connect and communicate in a trusted manner.
Based on Blockchain technology, Indy includes innovations that solve typical Blockchain problems such as scalability and managing personal information. However, if you have any preconceived notions about Blockchain, throw those out.
Indy is uniquely distinct because it doesn't store data on a shared Ledger. Individuals and organizations can use Indy to manage their own data, on their own terms, and present verifiable, cryptographically signed credentials rather than relying on paperwork or issuing organizations, or by putting their data on a shared Ledger.
Let's see how does this can work in practice.
INDY IN ACTION
Let's say Alice wants to apply for a job at Acme Inc. (This is an example that is described in detail in the Indy documentation.)
Acme's job description states that they are looking for a college graduate with a GPA over 3, which means Alice needs to provide this proof before she can submit an application. Fortunately, Alice attended Faber College (with a GPA of 4) and Acme, Alice and Faber are all running Indy-enabled software.
To start, Alice requests a transcript from Faber, which is delivered to her as an electronic document and held in an application on her smartphone. She then proves her identity to Faber using an electronic ID, e.g. a drivers license, issued to her in the same way from her local jurisdiction.
Alice presents the transcript from Faber to Acme as evidence of her academic credentials (and in fact she can do this without revealing her actual GPA). Acme verifies this information by looking up Faber's identity on the Indy Ledger, along with some cryptographic materials that they can use to verify that Faber is the one who issued the transcript.
Once employed at Acme, they issue Alice an electronic employment credential (containing her employment status and salary) in the same manner, which she uses to open an account and apply for a loan at Thrift Bank.
Alice holds all her electronic credentials in an application on her smartphone - they are not shared anywhere on a publicly accessible Ledger or Blockchain. However Acme and other organizations can verify the information on these credentials, and verify who issued and certified this information, based on data that is publicly accessible. This protects Alice's privacy, as she is the custodian of her information and how it is used. When Alice presents a credential, for example using her Faber transcript to apply for a job, the issuer is not involved in or even aware of this transaction.
Let's take a look at some of the core Indy functionality in a bit more detail.
THE INDY LEDGER, AND VERIFIABLE CREDENTIALS
The shared information on the Indy Ledger includes Decentralized Identifiers (DIDs), Schemas and Credential Definitions. This is used to support Verifiable Credentials and Proofs, which are not shared on the Ledger. (DIDs and Verifiable Credentials are in development as W3C standards.)
A Decentralized Identifier (DID) is a globally unique identifier that can be used to identify an individual or organization, and is shared on a distributed Ledger, such as Indy. The DID contains a reference to the owner, as well as to cryptographic material that can be used to verify information issued by this owner.
A Schema provides a general data definition or a document that will be issued, and a Credential Definition links a Schema to a DID (and therefore to an issuing organization). For example a Schema might be defined to describe a standard Drivers License, and each organization issuing Drivers Licenses according to this Schema would create a Credential Definition, linking the Schema to their public DID. The Schema and Credential Definition are also written to the shared Indy Ledger.
This information is used to create Verifiable Credentials (VCs) - which are directly to an individual or organization's private Wallet (which is just an application that can securely manage these credentials). The data within a VC is defined by the underlying Credential Definition and Schema, and can be verified based on the DID of the issuing organization. Individual attributes within a VC are referred to as Claims.
Claims can be shared using Proofs (a.k.a. Credential Presentations). When a Proof is created, the data owner can decide which Claims to include; Claims from multiple Credentials can be included on the same Proof. This can also include a Zero Knowledge Proof (or ZKP), which provides "evidence" of a Claim without revealing the value of the claim itself. (For example Alice can prove that her GPA is higher than 3 without revealing her actual value.)
Indy is, essentially, a distributed, shared, decentralized public key management platform. The shared Ledger stores the identifiers (DIDs) that can be used to verify the identity of the participants, as well as the Credentials they issue. Verifiable Credentials and Proofs are exchanged between participants, but are not stored on the Ledger, and neither is the evidence of how this information is used and shared. This ensures the security of the information and the privacy of the participants.
This structure provides the foundation for a platform that enables Self Sovereign Identity. Indy is an alternative to shared social media platforms (where a large amount of information is stored centrally under the control of a private organization) or centralized information hubs (where the hub mediates the identity and activity of the participants). Users are in control of their data and how it is used.
CONNECTING WITH INDY AGENTS
Indy provides the platform to support exchange of Verifiable Credentials and Proofs, but for widespread adoption software applications need to understand how to interact with the Indy Ledger and with each other, and this is where Indy Agents come into play.
Indy Agents (now moving into a new project, Hyperledger Aries) provide the ability for applications to establish Connections, to exchange Credentials and Proofs, and to build custom business processes on top of the Hyperledger Indy foundation.
Acting as independent software applications, Indy Agents manage Credentials on behalf of a person or organizational (in a data store known as a Wallet), or they can manage multiple Wallets on behalf of a number of participants.
Before Indy Agents can exchange information and collaborate they must first establish a Connection - this is done by exchanging information through an Invitation and Connection Protocol. The Invitation can be sent from one agent to another via a text message or email, a link on a web site, or many other means including a scanned QR code. The Connection Protocol includes information for the Agents to understand how to communicate with each other (including an endpoint, supported protocols, routing information, etc.).
Each Agent will create and exchange a private DID specifically used for this Connection. ( These are known as Pairwise DIDs.) This allows the Agents to encrypt and sign information that they are exchanging, and to uniquely identify the remote party on the Connection.
The Connection Protocol does not "identify" the remote party, in that the exchange doesn't include specific identifiers or "Proofs" that the parties are who they claim to be. The Pairwise DIDs confirm that the remote party is the party who originally joined the Connection, but the actual identification comes after the exchange of Proofs and Credentials.
Once Agents connect, then they exchange information by exchanging Messages. A Conversation is defined by the specific Messages that must be exchanged, and this protocol is referred to as a Message Family. Two core Message Families are Credential Exchange and Proof Exchange, and all Agents are expected to support these protocols (in addition to the Connection protocol and a few other basic Message Families). These protocols define the set of messages that must be exchanged in order to deliver a Credential or a Proof.
As Agents interact and exchange Proofs, they build up a profile of the participant at the remote end of the Connection. This profile is based on what the participant chooses to share, and will be specific to the purpose of each Connection. The profile will be specific to the Connection, and applications can require and share the amount of information they require in order to build trust in the remote party.
This mirrors how relationships happen in the real world, where a connection is made, identity is learned through exchange of information, and trust is established over time. There is no central "Identity Hub" or "Identity Provider" - participants establish their identity by presenting Credentials from well-known and trusted Issuers, and this all takes place as a true peer-to-peer relationship.
BUILDING ON THE SOVRIN LEDGER
Blockchains are shared Ledgers, and to be useful the Ledger must be generally and publicly available.
The Indy Ledger is referred to as "Public Permissioned" which means although the Ledger is Public (meaning that anyone can read it), writing to the Ledger requires a role with specific Permissions to be granted. Indy requires specific roles to write to the Ledger, but also provides public access to read Ledger data.
Sovrin is an example of a public Ledger that is based on the Indy platform. The Sovrin Foundation maintains the governance structure of the network, and signs up the trusted organizations who maintain and operate the nodes on the network - these trusted organizations are referred to as Stewards. The Sovrin Foundation ensures that the Stewards abide by the rules of the network, and that the set of Stewards has a broad geographic and industry representation.
Stewards are responsible for writing DIDs to the network, and provide the assurance that these DIDs contain a valid reference to the organization or individual they represent. When a DID is written to the network, it is associated with a Role that may have permissions to write Schemas and Credential Definitions to the Ledger. If an organization is going to issue Verified Credentials, then it requires a public DID and has to publish the associated Credential Definitions on the Ledger.
Participants who are using the Indy Ledger only need to access to the Ledger to read the Credential Definition and related information to validate the Claims contained in the Credentials and Proofs.
Indy network users will take on the role of Issuer, Holder/Prover and/or Verifier:
AN ENTERPRISE EXAMPLE
Organizations can use the Indy platform to move to an electronic business model. For example business licenses and other credentials (such as government certifications) can be issued as Verifiable Credentials, and stored in an organization's Enterprise Wallet. The organization can then present this information electronically as Proofs when conducting business online.
OrgBookBC is an example of an Indy-based business application that is in production use today. Developed by the Province of British Columbia, OrgBook BC is a public registry of credentials for businesses and organizations operating in BC. These credentials are published as Verifiable Credentials on a publicly searchable registry, however for businesses which adopt Indy technology and develop the capability of managing their own credentials, these VC's can be issued directly to the business. Any organization who issues business credentials or licenses can issue to OrgBook BC (and in the future to the businesses themselves). You can read about OrgBook BC and the Verifiable Organizations Network (or VON) here.
These Credentials can enable businesses to operate in a true B2B manner.
For example, a public sector organization may have a list of Qualified Vendors who are allowed to bid. These qualifications could be issued as Verifiable Credentials. When bidding on a procurement, the organization could provide evidence of their Qualified status via a Proof. If they were also required to provide evidence of their financial strength (or references from previously completed projects), these could also potentially be collected and held as Verifiable Credentials, and then presented as Proofs as part of their Bid in a procurement cycle.
Indy provides a foundation for all this activity to take place on-line, in a true peer-to-peer manner, without the need for any intermediary organizations.
So what is required to build a Hyperledger Indy-based application?
WHERE TO GO NEXT?
Indy supports a Layered Architecture - you don't need to know Blockchain fundamentals, or even the nuts and bolts of hooking up an Indy Agent, in order to build Indy-enabled applications. Indy Agents can be used to easily "Indy-enable" an existing application to allow it to issue Credentials and to receive and understand Proofs.
If you are interested in learning more about the underlying technology, or if you are interested in developing a Proof of Concept for your business, you can read our article and explore our training materials about Indy Architecture and Application Frameworks.
If you are interested in a deeper discussion on the background of Self Sovereign Identity and a "big picture" view of how Hyperledger Indy fits into the Identity space, there are some excellent Hyperledger Indy Training Materials available.
Copyright 2019 Anon Solutions Inc. All rights reserved.