The “Go Aries!” project focuses on enabling CL signatures and -credentials within the Aries Framework Go to make it compatible with Aries Cloud Agent Python (ACA-Py) agents and the Indy-SDK. Therefore, the benefits of the Aries Framework Go are accessible to ACA-Py and Indy.
Background and Goals
Hyperledger Aries is the dominant protocol to enable SSI applications. The most popular framework is the ACA-Py which enables cloud-based SSI agents based on Python and is closely entangled with Hyperledger Indy, a purpose-built blockchain as trust anchor. The dominant signature scheme are Camenisch-Lysyanskaya (CL) Signatures to sign and verify DIDs and Anoncreds.
The Aries Framework Go (AfGo) comes more from a ledger-independent approach, which is based on Golang and natively supports JSON-LD credentials and standard support for ec cryptography and BBS+ signatures. Due to its language wrappers, it can be deployed directly on machines which gives it a crucial advantage over the ACA-Py and its corresponding mobile frameworks.
To make machine interaction available to ACA-Py Agents, AfGo agents need to support CL signatures. We want to add support of these signatures to make the Aries Framework Go more complete and allow for new use cases in the ACA-Py ecosystem.
There are currently two distinct universes within the Hyperledger Aries Framework. The ACA-Py in connection with Hyperledger Indy is already a quite mature agent and trust anchor framework and is the mostly used framework for SSI projects to date. However, it has its limitations as is aimed to be a cloud agent and does not support mobile or other kind of edge agents. Even though the compatible Aries Framework .NET provides a framework for mobile devices it cannot be implemented on standalone devices like car internal computers. This limits the use of the ACA-Py primarily on cloud agent and mobile devices.
The Aries Framework Go comes from a more independent approach and is not tied to a specific ledger. It can be connected to Hyperledger Indy, but comes with a different form of signature schemes which limits today’s interoperability between these universes.
In order to have strong interfaces between these frameworks, the Aries Framework Go requires support for CL-signatures.
The project will use the Aries Framework Go as the starting point as this approach ensures high compatibility with existing projects based on the Aries Framework Go and it later allows us to easily provide merge requests. We will rewrite existing components and include CL-Signatures that are required for a well performing Aries Framework Go agent. We will also focus on the new modules Aries Askar, that acts as a new wallet to store key material and credentials, Indy CredX for credential handling, and Indy VDR to store public DIDs. Therefore, our new CL-compatible Go agents would be able to create connections by establishing CL-signed communication channels, anchor public DIDs on Indy, issue, store and verify CL-credentials, and creating and reading revocation registries. Furthermore, this makes the ACA-Py also independent from Hyperledger Indy, as it is possible to connect any ledger as a Verifiable Data Registry. This is a major leap towards completing the SSI framework as it unifies the AfGo with ACA-Py and Indy.
The results will be shown in a demonstrator where an Aries Framework Go agent will create and issue Anoncreds and send it to an Aries Cloud Agent. The repository containing the framework solution itself will be open-sourced.