by Martin Schäffner | 18 July 2022 | Blockchain, Featured, SSI
As one of the selected parties in the current eSSIF program, Datarella aims to bring Anoncreds based on CL-Signatures to the Aries Framework Go. In this blogpost, we provide a progress report on the Aries Bridge from the project we are working on in the eSSIF-Lab and where we are heading next.
There are currently two major types of Verifiable Credentials used in the SSI world that implement different cryptography schemes and have different capabilities. However, both are perfectly fine to implement working SSI use cases.
The first type is based on the “Camenisch-Lysyanskaya ZKP” signature scheme, or short CL-Signatures, to issue so-called Anoncreds. It is used in SSI projects that implement Hyperledger Indy, a DLT with an SDK that was created specifically for SSI use cases and with support of the Aries Protocol. The popular Aries Cloud Agent Python is implementing these kinds of Verifiable Credentials and therefore a lot of existing SSI use cases are using Anoncreds.
The second type are JSON-LD credentials which is recommended as a standard by the W3C. It comes from an ledger independent approach and relies more on semantics which allow for a broader ecosystem interoperability. This approach is preferred among the Aries Framework Go ecosystem.
If you want to learn more about different credential types, take a look at the article “Categorizing Verifiable Credentials” from Evernym and the paper from Kalyia Young called “Verifiable Credentials Flavors Explained”.
One major problem is that these two types of Verifiable Credentials are not compatible with each other as they are using different cryptography determined by the ecosystem they are residing in. Therefore, Datarella aims to make Anoncreds available to the Aries Framework Go to get the best of both worlds. This allows for deploying agents on non-mobile edge devices while being compatible with solutions built on the Aries Cloud Agent Python or Hyperledger Indy, respectively.
We decided to write a wrapper of the indy-credx library in Go. This allows us to call the indy-credx functions for credential management from a Go environment, such as a vehicle or a mobile device. Our pull request was successfully merged in the shared rust libraries and is now openly accessible by others. However, this was just the first step. In the next step, we will integrate the wrapper with the Aries Framework Go to simplify the integration from that side.
Stay tuned for when we are giving a progress report on the Aries Bridge again in our News section; e.g. leveraging it for the mobility space in our moveID Gaia-X project.
This project has received funding from the European Union’s Horizon 2020 research and innovation programme within the framework of the eSSIF-Lab Project funded under grant agreement No 871932.
by Martin Schäffner | 6 April 2020 | Ask Datarella, Blockchain, SSI
Self-Sovereign Identity (SSI) is increasingly mentioned in connection with innovations and digital identities. Even in the context of the coronavirus crisis, SSI finds possible applications, such as the possible use of a tracking app for infected people or as a digital staff “passport” in hospitals that respects each user’s privacy. To support others in classifying SSI correctly, we are now publishing a series of blog posts that explain components of SSI. The first part of the introduction to Self-Sovereign Identity focuses on the three essential components – DIDs, DID Documents and Verifiable Credentials.
As already described in detail in the first blog post, Self-Sovereign Identity offers the user the possibility to manage their own digital identities completely autonomously. There is no platform or provider, such as an email address provider or a social network that controls identity. This is achieved using an underlying blockchain or a DLT on which key pairs can easily be generated that serve as identity representation.
Decentralized Identifiers
Now we come to the first component – the Decentralized Identifiers (DIDs). Their purpose is to act as a unique identifier of the person or object. These are derived from the public keys and can be identified over various blockchains. An example DID is shown below.
DIDs follow a general syntax: the schema (did:), the method (sov:) and the method-specific identifier (WRfXPg8dantKVubE3HX8pw). While the scheme is always the same, the method that describes how a DID is derived from a blockchain (here: Sovrin) and the method-specific identifier bo depend on the underlying blockchain. However, DIDs alone don’t bring any value.
DID Document
What fills a DID with life is the DID Document. This piece of data describes the DID object and its properties. By default, it contains the associated public key to a DID. However, it is also possible to add more public keys to the DID document that are authorized to perform actions in the name of a DID. Moreover, a DID can contain different types of attributes and service endpoints that allow the actual interaction with a DID. Changes to a DID Document can only be made by authorized public keys defined in the DID Document. An example DID Document with authorized public keys.
Verifiable Credentials
Now, that it is possible to identify an entity and to interact with it, is possible to attach information to the digital identity. This can be done with Verifiable Credentials (VCs) that act as an attestation or a digital representation of a credential such as an ID, a driver’s license or a club membership card. A VC consists of three main values:
-
- The issuer’s DID and signature
- The entity’s DID
- The information that is attached
Based on these three fragments, third-party verifiers can immediately determine the authenticity of the object by looking up the issuer’s DID. Verifiable Credentials are in possession of the DID owner that it was issued to and can be stored in a wallet. However, the issuer can always revoke the VC and adding it to the revocation registry that should be publicly visible.
These three components serve as the basis for a decentralized, trustless identity ecosystem that doesn’t rely on centralized authorities. DIDs identify an identity over, the DID Document describes the DID and a Verifiable Credential attaches verifiable information to a DID. Users are in sole control of their identity and can decide how information is shared and with whom.
However, this was only a small part of the entire SSI infrastructure. Part 2 of the Introduction to Self-Sovereign Identity components is about DID resolution, the process of resolving a DID Document from the DID, and DID authentication.
If you have any questions about SSI or want to leave feedback, feel free to contact me.
