Self-Sovereign Identities And Hyperledger Projects

Self-sovereign identity (SSI) is, simply put, a decentralized digital identity, but before we dive in, let’s look at what identity and digital identity actually mean.

Digital Identity

Identity is not only about a physical identity card issued by the government. An identity is a group of various attributes and relationships describing the existence of each individual.

The first model is the Siloed or centralized identity that all of us are familiar with. You have an account at an organization where you log in using your username and password.

You “prove” that you are the owner of the account by entering your username and password. The website will check in its own database if these credentials are correct. This wasn’t always a safe solution. Credentials would be sent in plain text over the web, allowing anybody in between you and the website to read your credentials. Standards like https://, SSL, and TLS got introduced to encrypt communication, making it harder to steal them. However, if a website got hacked and account data got leaked to the web, the same credentials would be used to try to access other websites.

Two-factor authentication got introduced to secure accounts better. Instead of needing just a password, you would need to have access to the device of the victim as well. A one-time password is required which can be sent as a text message to a phone or generated using an authenticator app.

The second model is the third-party or federated identity provider. We know them as the buttons that allow you to login with your Google, Facebook, Twitter, or LinkedIn account. In this case, the website where you log in does not store your password, instead, they rely on the identity provider to verify that you are you.

Over the years a number of standards have been created to make integration with identity providers easier. These standards are SAML, OAuth2, and OpenID Connect. With these standards, it is also possible for websites to request information from your account from the identity providers. As far as I know, this information is usually limited to your name and email address.

Self-Sovereign Identity (SSI)

The third model is the newest one in the family and is called Self-Sovereign Identity (SSI) and it is completely different from the other two. Instead of having to rely on a website to issue, verify and protect your credentials, it is managed by a decentralized system made on four open standards.

With SSI, you create your own credentials and a reference to these credentials is stored in a blockchain or a distributed network. These credentials will be used to create a connection with every other peer you connect with. A peer can be anything, a company, a person, an application, a device. This connection will be secured by your credentials which consist of public-private key pairs. You will store your keys in a digital wallet.

These keys are your credentials. Credentials can be issued by yourself or can be issued by any other peer. There are three basic roles in SSI. Issuer, verifier, and holder. You can create a credential that can be verified with a public key. This public key is stored in the ledger.

The first standard for storing the public key in the ledger is DID(Decentralized Identifier).

The second standard is called DKMS (Decentralized Key Management System). This standard will make sure your keys or wallet are not locked into a specific vendor. You can have different wallets on different devices that can all interoperate.

The third standard is called DID Auth. This standard covers how you can actually authenticate over a connection.

The fourth standard is Verifiable Credentials. This standard covers how you can have interoperable credentials over different wallets.

Hyperledger SSI Ecosystem

There are three projects under the Hyperledger umbrella related to digital identity. Hyperledger Indy, Aries, and Ursa. It all started as one project called Indy. 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 the PBFT consensus protocol, and it’s not intended to run as a public permissionless network as Bitcoin or Ethereum 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 a secure storage for keys, credentials, and other data. The wallet automatically stores private keys and allows for storing other data. All are 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.