Hyperledger SSI Ecosystem

I assume you already know something about SSI principles. If you don’t, I suggest checking out Introduction to Self-Sovereign Identity. Now, you’re probably interested in what particular SSI technologies are out there. In this article, I’ll describe SSI technology from Hyperledger. There are three projects under the Hyperledger umbrella related to digital identity. Hyperledger Indy, Aries, and Ursa. Indy and Aries also contain more, let’s say, sub-projects. Therefore, it could be hard to get oriented in all of that. I don’t want to dive too deep here, but describe their purpose and how they’re related to each other.

Hyperledger Indy (distributed ledger and wallet)

indy-node contains a source code for the node running as part of the distributed ledger network. It implements PBFT consensus protocol, and it’s not intended to run as a public permissionless network as Bitcoin or Etherum but rather as a permissioned network. There is not one single instance of the Indy network. There are many of them. The most famous and publicly available is Sovrin, which was the first one. You can also use indy-node to run your network or run it locally on your machine via Docker for testing purposes.

indy-sdk works partially as a client for indy-node, but it has much more functionality. The library is written in Rust, and you can find it under the libindy folder. The binary file name is the same. There are also wrappers allowing you to use the library with other languages like Node.js, .NET, Java, Obj-C, and Python. We can divide the functionality into three parts:

• Client for the distributed ledger. It allows to write public DID, register schema, and credential definition or work with revocation registry.
• Manipulation with DIDs and verifiable credentials. There are methods to create and update DIDs, encrypt and decrypt messages, and create credentials or proofs.
• A wallet as secure storage for keys, credentials, and other data. The wallet automatically stores private keys and allows storing other data. All encrypted with a wallet seed. It’s possible to export and import the data back if needed.

All these functions are still relatively low-level, so it would be better to try out some of the Aries frameworks, as I’ll explain later in the Aries chapter.

There are discussions in the community about splitting indy-sdk into more specific standalone libraries. There are already these three projects:

• indy-vdr: client for distributed ledger.
• indy-shared-rs: DIDs and verifiable credentials.
• aries-askar: a wallet as secure storage.

There is another project that wants to evolve from indy-sdk. Evernym company forked the indy-sdk and created vdr-tools.

I think you’re still good to go with indy-sdk for now while being aware of other libraries.

Hyperledger Ursa (cryptography)

In the beginning, there was no Ursa or Aries, just Indy with all functionality together. As time went by, the Hyperledger community realized that there are a lot of useful cryptographic primitives which can be extracted and used by other Hyperledger projects. That’s the reason why Ursa has been created. It’s only one ursa repository containing encryption, signatures, and zero-knowledge algorithms. I’m not a cryptographer, and I’ve been working mainly with Indy and Aries, so I don’t know many details about it. I will leave that investigation up to you if you need to learn more. However, for many SSI use case implementations, you will be good just with knowledge of Indy and Aries.

Hyperledger Aries (protocol and higher-level abstractions)

In the indy-sdk section, I described that it provides functionality to create DIDs, credentials, proofs, etc. Now, you need a way to securely exchange those items in an interoperable and portable way according to SSI principles. That’s the goal of the Aries project. The specification of the protocol is in aries-rfcs, which originated from an older project, indy-hipe (the protocol was part of Indy in the beginning).

There are implementations in more languages like JavaScript, Python, .NET, Go, and Rust. All of them except for Go are using indy-sdk under the hood. Go framework implemented indy-sdk functionality on its own from scratch. That’s the beauty of it. As long as you’re compliant with the protocol, you can build it according to your own needs.

On top of that, as I mentioned earlier, Aries frameworks and libraries add some level of abstraction over indy-sdk to save you some time with repeating tasks. They offer better developer experience, simplicity, and faster development of SSI applications for all issuer, holder, and verifier roles.

Here is a diagram showing how all those components fit together. I took Aries JavaScript Framework for demonstration (I’m a little bit biased here because I started the project, and I’m a fan of it, of course):

Each project would deserve a standalone article. Hopefully, you have at least a good overview of the SSI ecosystem. Maybe we can dive deeper next time.