Launching the Veramo SDK for cheqd, enabling our partners to create and manage Decentralised Identifiers, Verifiable Credentials and Verifiable Presentations on cheqd
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.
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).
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.
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.
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:
- 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
- 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
- The SDK should already be used across the SSI ecosystem, with a significant amount of time being invested into its continuous product development
- The SDK should be building in a W3C compliant way, supporting the key exchange protocols and credentials our partners and beyond require
What is the Veramo SDK and why did we select it?
We chose Veramo for a few key reasons.
- 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.
- 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).
- 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.
- 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:
- Identity functionality to be carried out through a native CLI interface; or
- 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):
- Create and manage keys for signing and encryption
- Create and update Decentralized Identifiers (DID) and Decentralized Identifiers Documents (DID Docs) on cheqd (did:cheqd)
- Issue JSON Verifiable Credentials (VCs) with JWT proof format
- Verify JSON Verifiable Credentials (VCs) with JWT proof format
- Issue JSON Verifiable Presentations (VPs) with JWT proof format
- Verify JSON Verifiable Credentials (VPs) with JWT proof format
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 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!
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 (email@example.com).
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.
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.
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 (firstname.lastname@example.org).
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 — email@example.com, or alternatively start a thread in either our Slack channel or Discord.