Building decentralised Identity applications on cheqd with Veramo

cheqd - Veramo Software Development Kit (SDK) for cheqd

Launching the Veramo SDK for cheqd, enabling our partners to create and manage Decentralised Identifiers, Verifiable Credentials and Verifiable Presentations on cheqd

Co-authored by Ross Power (Product Manager), Tasos Derisiotis (Senior Blockchain Engineer), Ankur Banerjee (CTO/co-founder) and Alex Tweeddale (Governance & Compliance Lead)

We’re thrilled to launch the Veramo Software Development Kit (SDK) for cheqd. A Software Development Kit is a collection of libraries containing crucial building blocks of SSI which act as a bridge between cheqd and the identity apps provided by our partners. This is a big step forward in the overall adoption of the cheqd network as it makes it possible for our partners to start building their Decentralised Identity applications using cheqd.

Introduction

One of the primary objectives for Q2 at cheqd was to make it easier for our SSI partners to create and manage DIDs, schemas, CredDefs (for AnonCred users) and Verifiable Credentials. We also wanted to begin work on supporting credential presentation and verification (you can see what we set out to achieve below).

Source: Q2 and beyond product roadmap for cheqd from Q1 round-up from cheqd

To achieve this objective, it was important to build cheqd support into software that was compatible with languages and applications that our partners already used.

As part of our Product Research earlier this year, we conducted a survey to gauge the current stack our SSI partners are currently working with and plan to leverage in the future.

Within this, we identified that most companies use JavaScript/TypeScript or related frameworks as their primary language for development, as seen in the graphic below:

However, despite this dominance, the choice of SDK’s (Software Development Kit) didn’t correlate to this, with non-Javascript based SDKs holding the largest proportion, 35.1%, of respondents using Aries Cloud Agent Python (ACA-Py); and secondly, 27.0% of the respondents using Evernym’s VDR Tools SDK (tied to Hyperledger Indy):

=

What do we mean by an SDK?

The widely used, yet often not well described, term ‘SDK’ refers to Software Development Kits.

To get to grips with this, it’s first important to understand one of the key building blocks that make up SDKs — ‘libraries’.

A library is a packaged, reusable chunk of code that performs a certain function or set of closely related functions. You can insert a library into your application and call it when you need to implement that function without having to write the code from scratch.

So, suppose that instead of an application, you are building a house. One of the things you will need for that house is a stove, but it will not be very practical for you to build it from scratch when you could just buy one off the shelf. A library is to an application what the stove is to that house.

Building on this, an SDK is therefore a collection of libraries, APIs, documentation, utilities, and/or sample code that help you implement certain features without having to do the work from scratch. SDKs vary in scope and function from implementing a feature or set of features, like an analytics SDK for instance, to building whole applications for a specific platform.

Going back to our house analogy, if a library is a stove, then an SDK is a whole kitchen. While you can go and buy all your kitchen appliances, cabinets, and counters separately, it will be a lot easier to buy a full kitchen set, complete with built-in appliances and instructions on how to assemble it. SDKs can be limited in scope such as in the case with one room, but they can also have a bigger scope of a collection of rooms or even the whole house.

Where do SDKs fit in the overall SSI technology stack?

Taking a look at the Trust over IP technology stack helps to illustrate where SDKs fit in. As a reminder, this Trust over IP stack demonstrates the different elements of what is required in the Self Sovereign Identity ecosystem.

At the top level, Layer 4, you’ll notice application ecosystems. These are what the regular user interacts with; a mobile app you download from the app store to hold an airline ticket or vaccine credential for example. At the opposite end of the stack, Layer 1, you have the underlying plumbing. This is the distributed ledger layer where Decentralised Identifiers (DIDs), used to sign Verifiable Credentials (VCs), live.

Between the two you have a vast array of technologies which are used for the sending and receiving of Verifiable Credentials (VCs) and Verifiable Presentations (VPs) in a secure, privacy-preserving fashion. The combination of these two layers is what are more commonly known as SDKs, which contain various libraries that are made up of the technologies required for sending and receiving VCs and VPs.

Source: Introduction-to-ToIP-V2.0–2021–11–17.pdf

Find out more about the ToIP stack and learn through the interactive model available on the ToIP website

Selecting the most suitable SDK to leverage for cheqd

Based on the findings detailed above, deciding on which SDKs wasn’t immediately obvious, although we had a few key requirements:

  1. The SDK should be JavaScript based — this is both due to the overall stack out partners were using, and also the dominance of Javascript and Typescript in the Web 3.0 and Cosmos ecosystem
  2. The SDK should be written in languages that are used in web-based applications, such as Keplr, so we can demonstrate DeFi activities (e.g, governance, staking and delegating) in the same wallet as holding a credential
  3. The SDK should be highly modularised so that those not directly using it can easily leverage the cheqd plug-ins built to work with it into their own SDK
  4. The SDK should already be used across the SSI ecosystem, with a significant amount of time being invested into its continuous product development
  5. The SDK should be building in a W3C compliant way, supporting the key exchange protocols and credentials our partners and beyond require

After some research, including exploring Aries Framework JavaScript, Aries Framework Go (transpiled to Wasm), Trinsic Okapi and MATTR, we settled on the Veramo SDK.

Source: Github — uport-project/veramo

What is the Veramo SDK and why did we select it?

Available at: uport-project/veramo

Veramo is a JavaScript Framework for Verifiable Data. The Veramo SDK is an agent designed to handle multiple networks and DID methods. Current implementations of the Veramo SDK include did:ethr, did:web, did:key and more.

We chose Veramo for a few key reasons.

  1. Design Principles — The Veramo SDK was designed to be highly flexible and modular making it highly scalable and fit for a lot of complex workflows. As a result, we felt it offered a route to minimise how much needs to be built from scratch. Through its flexible plug-in system, it’s easy to pick and choose which plug-ins are most beneficial, plus it’s possible to add in our custom packages where required which we knew would be necessary from Cosmos-based transactions.
  2. Developer Experience — The Veramo SDK has been designed in a way that offers a fast end-to-end process. Ultimately, at cheqd, we want to reduce the amount of time our team spends on SDKs and so we can maintain our focus on building ledger functionality (i.e. building our implementation of the revocation registry and the credentials payment rails).
  3. Attractive & Simple CLI — The Veramo core API is exposed by its CLI which makes it easy to create DIDs and VCs directly from a terminal or local cloud agent.
  4. Platform Agnostic — The Veramo packages run on Node, Browsers and React & React Native right out of the box.

What does the Veramo SDK for cheqd allow you to do on the cheqd network?

Veramo provides an excellent foundation for clients that want to build verifiable data applications. This is because Veramo Core, the Veramo CLI and any specific plugins are available as NPM packages, enabling:

  1. Identity functionality to be carried out through a native CLI interface; or
  2. Identity functionality to be integrated directly into client applications through NPM packages.

More importantly, Veramo is useful for both DIDs as well as Verifiable Credentials and Verifiable Presentations. It’s not just for one side of the credential usage process.

When combining the existing packages provided by the Veramo SDK with some native packages that we’ve built at cheqd the following functionality is available on the cheqd network (hyperlinks go to the tutorial/information for each):

With the additional Resource module recently applied to the cheqd ledger, AnonCreds will also be possible through the cheqd/sdk which the Veramo SDK for cheqd uses. This is not yet available but is part of the immediate cheqd product roadmap.

Thank you to the Veramo team for all their support throughout. We’re thrilled to strengthen this partnership and appreciate these kind words shared with us by the Veramo team:

The cheqd team quickly and effectively understood all the effort that the Veramo team has been putting into making life easier for developers when building better layers of trust in their applications. We also thank the cheqd team for being participative and collaborative in the Veramo community by supporting the development and discussions.

– Italo Borssato 

I was pleasantly surprised to hear that the folks from cheqd were able to extend and adapt Veramo to their own use-case while leveraging existing integration, which then allowed them to focus on their core business. This kind of permissionless innovation and integration is what we were hoping for when designing the Veramo framework. I’m very happy to see the cheqd team not only using Veramo but also contributing back.

– Mircea Nistor

Our implementation of the Veramo SDK for cheqd

Veramo’s modular architecture meant we were able to leverage much of the existing work which offers the core functionality required for credential and presentation issuance and verification.

Adding the ability to create and update DIDs took more work, including contributing to Veramo upstream to improve the overall ecosystem beyond our own implementation. For example, we wanted to support full DIDDoc create and update operations which were not previously available within Veramo’s codebase.

Below you’ll find the basic architecture for the Veramo SDK for cheqd. The Veramo packages offer key Layer 2 and Layer 3 functionality, as described above, including exchange protocols and proof formats.

The key cheqd package is did-provider-cheqd.

The purpose of this @cheqd/did-provider-cheqd NPM package is to enable developers to interact with the cheqd ledger using Veramo SDK.

It includes Veramo SDK Agent methods for use with the Veramo CLI NPM package. It can also be consumed as an NPM package outside Veramo CLI for building your own applications with NPM.

The package’s core functionality is borrowed from Veramo Core NPM package and extends this to include cheqd ledger functionality, such as creating and managing DIDs.

Head over to our tutorials site to find everything you need to install this package and start using cheqd for your identity products today!

Figure 1: Veramo SDK for cheqd architecture

A reference implementation of the Veramo SDK for cheqd, built for the cheqd web demo

If you’re interested in how cheqd has worked with the Veramo packages, but aren’t sure what this would look like in practice, perhaps our implementation we built for an IIW demo would be useful for you.

For a full walkthrough of our choices here check out Ankur’s Tweetstorm on this and if you’re interested in doing something similar feel free to reach out to the product team at cheqd (product@cheqd.io).

Figure 2: A reference implementation of the Veramo SDK for cheqd, built for the cheqd demo

FAQs on Veramo & our implementation

Q: Is it possible to use cheqd libraries to build a mobile wallet? (do the cheqd libraries take React Native support into account)

A: Veramo runs on React Native right out of the box. More information on this is available here.

Q: Do the cheqd libraries introduce any new dependencies that won’t work in React Native? (e.g. the cosmjs libraries or other crypto-related libraries)

A: React Native can work with any browser-based JS library, since cosmjs works in browser environments and most other libraries we use at cheqd.

Q: Where are keys stored?

A: The Veramo SDK uses a PrivateKeyStore for hosting the key data. The @veramo/data-store package provides an implementation that uses a database for storing these keys encrypted by a SecretBox.

The modular architecture of the framework makes it possible to use multiple types of key stores and key management systems for different purposes. These include implementations using CloudHSM, mnemonic-based key derivation, or even web3 wallets.

Conclusion

We’re thrilled to have hit this exciting milestone at cheqd.

We knew our partners were eager for us to answer their question “when will I be able to use the cheqd ledger for identity? and now we’re happy to be able to say “go have a play now!”.

So what’s next for cheqd in terms of SDKs?

Ultimately, we know that there are more focused and dedicated teams who are building SSI SDKs, and our Veramo SDK is just the start. Over the coming months and weeks, we’re in the process of forming ’cheqd SDK Alliances’ within our partner network who can collaborate on required SDKs, leveraging this implementation.

These alliances include those looking to build for; Aries Framework Javascript, .NET, Aca-PY and further building on Veramo.

Where we believe we can add the greatest value is by building out our approach to Revocation Registry and the credential payment rails, which we believe will be a real game-changer for SSI’s adoption.

If you’re interested in joining one of the alliances, reach out to the cheqd product team (product@cheqd.io).

As always, we’d love to hear your thoughts on our writing and what this means for your company. Feel free to contact the product team directly — product@cheqd.io, or alternatively start a thread in either our Slack channel or Discord.