Hyperledger Aries ACA-Py Agents Setup and Running Tutorials — Part II — Scenario Overview and Dev Environment Prerequisites


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 this Part II, I will give an overview of a general and simplistic scenario that are normally used in the context of SSI. From this Part II until the end, it is assumed readers have already gone through the two Edx courses recommended in Part I and have already understood all the key concepts. I’ll give some basic explanations on some of them if I think it’s critical for more clarifications, but definitely can’t and won’t cover all of them.

Scenario Overview

In a typical SSI scenario, there are three types of actors.

(1) credential issuer (referred to as issuer hereafter): this actor is an authority that can issue digital credentials.

(2) credential requester/holder/prover (referred to as requester/holder/prover hereafter): this actor has different names in different stages. a) Before getting a digital credential (referred to as credential hereafter) from a credential issuer, this actor needs to request a credential from the issuer. This process makes it become a requester. b) Upon obtaining the credentials from the issuer, this actor becomes a holder as it has the credentials in its digital wallet. c) When this actor needs to reveal the credentials as claims, this actor becomes a prover.

(3) credential verifier: this actor asks for proofs from a holder/prover and will verify the authenticity of the proofs revealed by the holder/prover.

The relationship between the 3 actors is: the requester requests credentials to be issued by an issuer. Once the issuer issues credentials, then it sends them to the requester/holder. The verifier asks the holder to reveal proofs for some purposes, and the holder/prover reveals the proofs to the verifier. The verifier then verifies the proofs with a final decision on whether the proofs pass the verification or not.

In practice, each actor can have its own ACA-Py agent. In this blog, we will create two ACA-Py agents, one runs as an issuer/verifier and the other runs as a requester/holder/verifier. Of course, the verifier can run in its own individual agent if you want.

A general process of using ACA-Py v0.6.0 as the latest version that will be covered in this series of blogs includes:

  1. One-time agent-level connection channel establishment (associated with Layer 2 in the ToIP).
  2. Credential schema/definition creation (associated with Layer 1 in the Tech Stack of the ToIP).
  3. Credential request, issuance and reception (associated with Layers 2 and 3 in the Tech Stack of the ToIP)
  4. Proof request, reveal and verification (associated with Layers 1, 2 and 3 in the Tech Stack of the ToIP).
  5. Credential Revocation and proof verification failure (associated with Layers 1, 2 and 3 in the Tech Stack of the ToIP).

One might notice that Layer 4 (controller) is currently not covered in this series of blogs, but there is a plan to include it in the future.

Dev Environment Prerequisites

Starting from here, we are now at the beginning of the real hands-on experiences, excited! This is also the stage when I as a newcomer came to Indy and Aries and wondered what tools I needed to make things happen. Please note, this series of blogs only shows how to set up and run ACA-Py in v0.6.0 agents in a Dev environment, so we only need what we need for simplicity. Also the main purpose of these blogs is to lower the entrance threshold for new comers to the world of Indy and ACA-Py, and quickly run these ACA-Py agents to see how a basic SSI process/flow would work from theory to practice, so making sure each step works in an end-to-end journey shown in this blog is the core here.

  1. An Indy Dev Networkvon network. Von network is a dev Indy network developed as part of the Verifiable Organizations Network (VON). It includes a ledger browser we will use later.
  2. A von tails server. This server is used for credential revocation. If you want to know more details of how it works, please read this doc.
  3. Two VMs + underlying networks setup. As mentioned above, we will have two VMs, each for one ACA-Py agent. This is actually the first bit that blocked me when I tried to run the ACA-Py agent in my local laptop. It didn’t work quite well, as it would require extra manual config to make it work, and I still haven’t figured it out properly. No surprise here, like you, I’ve been still in the learning process on Indy and Aries. Nevertheless, the motivation I’ve got was to test whether two ACA-Py agents if running on two separate VMs would be able to connect and transfer messages to make all the following communication process happen as stated in Layers 2 and 3 in the ToIP. From all my pervious experiences, simulating how things can successfully communicate on 1 machine sometimes won’t work for having them in multi machines. So to run ACA-Py agents on two VMs to figure out what extra configs are needed for them to talk can better simulate multi agents communication in a future production environment.
  4. Azure Cloud: In my case, I have used Azure as the main cloud service and set up the two VMs + the underlying network on it. If you want to use AWS as the cloud service, there are extra steps you have to configure for the von network to run (see this link).
  5. ACA-py agents: no surprise, this is the core tool.


This Part II mainly focuses on introducing typical types of actors involved in the the world of SSI and gives you a general idea on what tools we will need for a Dev environment. In the Part III, I will go deep for details on the real Dev Environment setup. See you there.

Dr. Yunxi Zhang currently works as a Tech Arch and Blockchain capability lead at Liquid Studio London. His interests cover DLT, Cloud Services and DevOps.