Digital Identity Using Hyperledger Blockchain : Indy, Aries & Ursa
Digital identity is an use case that can be implemented using blockchain. Firstly, we have a look at verifiable credentials. In essence, verifiable credentials are digital, cryptographically-protected data that you can use to prove you are you!
Verifiable credentials:
- An authority decides you are eligible to receive a credential and issues you one.
- You hold your credential in your (digital) wallet
- At some point, you are asked to prove the claims from the credential.
- You provide a verifiable presentation to the verifier, proving the same things as with a paper credential.
- You can prove that the issued credential has not been revoked.
Your verifiable credentials are issued to you, stored in your digital wallet, and you decide when and where you want to use them. That improves your privacy — you are in control of when and with whom you share your information. Verifiable presentation data is proven without needing to call back to the issuer.
Next, we look at SSI. Self sovereign identity (SSI) is the idea that you control your own data. With SSI, there is no central authority holding your data.
SSI: “Lifetime portable identity for any person, organization, or thing that does not depend on any centralized authority and can never be taken away.”
While verifiable credentials are an important component of SSI, a thing called a decentralized identifier (DID) is a key enabler for verifiable credentials. The verifiable credential model requires a decentralized ecosystem in order to work. Such an ecosystem is brought about with DIDs and agents. DIDs are a special kind of identifier that are created by their owner, independent of any central authority.
DIDs can be resolved. When we pass a valid DID to a piece of software called a DID Resolver, it works like a browser given a URL, resolving the DID and returning a document. However, instead of returning a web page, a DID Resolver returns a DID Document (DIDDoc), a JSON document. Notably, a DIDDoc contains (usually) public keys whose private keys are held by the entity that controls the DID, and (usually) service endpoints that enable communication with that entity.
A public DID is one that is intended to be widely available — visible to anyone that is presented with the DID. Public DIDs are put on blockchain so that they can be globally resolved. Private DIDs enable a small group to connect with one another, the data in private DIDs is not loaded on blockchain.
Thirdly, another key component of SSI, along with verifiable credentials and DIDs, is the software that you use to process verifiable credentials and DIDs. It is called digital wallet. Indy, Aries and Ursa use the term agent to mean the software that interacts with other entities (via DIDs). For example, a person might have a mobile agent app on their smart device, while an organization might have an enterprise agent running on an enterprise server, perhaps in the cloud.
Together, Indy, Aries and Ursa make the Hyperledger Identity “Stack.”
The vast majority of those working with the Hyperledger identity stack will build on top of Aries and have relatively little interaction with Indy, and almost none with Ursa.
Hyperledger Ursa contains the cryptographic library.
Hyperledger Indy provides code that implements the public distributed ledger technology (DLT) and the code to build applications that interface with the ledger.
- indy-sdk: a software development kit that enables Indy clients (called “agents”) to be built that interact with the Indy blockchain
- indy-node: the blockchain/DLT component of Indy
Hyperledger Aries agent is a piece of software that enables an entity (a person, organization) to assume one or more of the roles within the verifiable credential model — an issuer, holder or verifier — and allows that entity to interact with others that also have verifiable credential roles. Agents use private, pairwise DIDs to secure their peer-to-peer communications. With a different pairwise DID for every relationship, each with keys and end points that you control, communication between agents is end-to-end encrypted, and secure.
To build an Aries agent application, that requires building an agent controller application that integrates with Aries agent functionality. To date, there are two approaches for integrating a controller with agent capabilities, the agent framework model and the cloud agent model.
In Aries framework model, you build your controller as an application with the Aries agent embedded in your controller as a library.
In Aries cloud agent model, as embodied by aries-cloudagent-python, separates the controller and agent into processes communicating using an HTTP API.
As developer, we will be building agent application on Hyperledger Aries.