Hyperledger Aries ACA-Py Agents Setup and Running Tutorials— Part I — Hyperledger Indy Project Overview
Recently, I started to touch Hyperledger Indy (referred to Indy hereafter) known as a leading Distributed Ledger Technology (DLT) project that empowers companies to develop Self Sovereign Identity (SSI) systems. When digging into more details on Indy, I’ve become more fascinated by its potential to enable SSI for the future.
Overview
In Part I, I’ve introduced the general benefits of using SSI and why Hyperledger Indy and Aries can fit in the big picture. In Part II, a scenario overview and tools were described. Part III shows details on how to set up a Dev environment to run an ACA-Py agent V0.6.0. In Part IV, it focused on the one-time agent level connection channel establishment. Part V described how to create a credential schema as well as its relevant credential definition. Part VI showed how a holder can request a new credential from an issuer, who will then issue a new credential to the holder as per holder’s request, so the holder can receive the newly issued credential from the issuer. Part VII will present how a proof (aka claim) of a credential is requested from a verifier. The holder will then reveal a proof for the verifier to achieve the proof verification.
Game Starts
Nowadays, what happens in reality is for each of us as an individual user when using websites such as Facebook, we have no option but have to give a username and password plus all other personal information that will be stored in the websites’ systems. Giving our personal identity information to those websites is based on an assumption that we will have to trust them not going to reveal our identity information in any cases. In practice, we have very limited visibility on how our personal data would/could be used by them. What’s even worse could be if a disaster happened to those websites, there could a possibility all our personal data would be gone, and it’s beyond our ability to protect our personal data to be destroyed.
All these limitations of current use of our personal identity information could be resolved by using SSI. Actually, the most cool bit in the SSI concept is that it gives back the power to us so we will have the full control of holding our own personal identity information in our hands. We can also decide whether we want to reveal one or multiple digital credentials (it is a digital version of a paper-based credential such as a passport, a driving licence or a Uni degree) to others. These digital credentials are stored in a digital wallet which can be a simple mobile app for an individual user or a sophisticated server-side app for corporate users.
Sound very cool, right! However, the complexity of the Indy, started as 1 project and later on split into 3 projects (Indy, Aries and Ursa) makes newcomers like me a bit hard to figure out how we use them to make SSI come true. Some of the challenges are there are a number of online documentations available, whilst some of them are up to date, the others are out of date. In addition, some concepts in the documentations are amazing, but in reality it’s really hard to implement them in the current Indy-related projects. Therefore, to have a hands-on experiences on them becomes the right approach for me to figure out what are doable and not pragmatically.
Indy as a DLT platform is very different from other DLT platforms such as Hyperledger Fabric, R3 Corda, Consensus Quorum I used to play with. For those DLTs, any types of common data can be stored on the DLT as long as these shared data can be beneficial to parties in the DLT eco-system. However, Indy’s DLT ledger only deals with certain types of data. Apart from it, it actually includes a unique component called agent.
Linux Foundation introduces the below Trust Over IP (ToIP) Stack to clearly state four layers should be considered in a typical Indy-based SSI system.
Corresponding to this ToIP stack, the three projects mentioned earlier are clearly stated in the below diagram.
Basically, the mapping between the four layers and 3 projects are:
Layer 4 — Aries Controller, Ursa
Layer 3 — Aries, Ursa
Layer 2 — Aries, Ursa
Layer 1 — Indy, Ursa
As a right entry point for understanding on how Indy, Aries and Ursa work, readers are recommended to try the two official Edx courses as shown below. They are currently free for limited time periods when this series of tutorials is being written, and I’ve found them very useful.
https://www.edx.org/course/identity-in-hyperledger-aries-indy-and-ursa
https://www.edx.org/course/becoming-a-hyperledger-aries-developer
This series of blogs aim to give more hands-on tutorials on running ACA-py as one of the most popular Aries agents with its latest version V0.6.0 only as a complement to the current official docs, as I’ve found it’s a bit hard to even make a simple process happen for new comers (from agents communication to credential schema/definition creation, to credential issuance, verification and credential revocation). I will share all my experiences on how to make each step work and what traps a new comer could meet potentially.
See you in the first hands-on tutorials in Part II soon.
