cheqd is now supported in walt.id’s SSI Kit!

Integration of cheqd into SSI Kit provides greater flexibility for adopters of cheqd, opens up a new customer-base for increased utility on the network and helps future-proof cheqd for upcoming EU regulations!

Introduction

We are excited to announce that cheqd is now fully supported in walt.id’s SSI Kit. This integration expands the support for cheqd in a greater array of SDKs, and provides end-customers the flexibility to choose a wider breadth of options for credential exchange protocols.

SSI Kit leverages the cheqd/sdk, slotting neatly alongside other supported SDKs including Veramo, and the soon to be released Aries SDKs, offering a wide range of SDK choices for SSI app developers which they can select dependent on their needs and existing stack.

What is SSI Kit?

SSI Kit is a holistic and standard-compliant open source tool created and maintained by the team at walt.id. It offers everything you need to use Self-Sovereign Identity (SSI) with ease, including the creation, issuance, management and verification of Verifiable Credentials across various ecosystems.

SSI Kit utility for different parties

walt.id docs — SSI Kit | Basics — Learn what the SSI Kit is.

Integrating cheqd with SSI Kit provides an array of benefits for both cheqd and walt.id’s existing end-customers and users:

cheqd customers:

Supporting cheqd within the SSI Kit means that anyone that wants to use cheqd, can now do so through walt.id’s intuitive and easy to use tools — available here. Through this, SSI developers can:

  • Create DID — Create your first did:cheqd
  • Issue VC — Issue your first Verifiable Credential based on a did:cheqd
  • Verify VC — Verify your Credential based on a did:cheqd

This offers cheqd’s customers:

  • Greater flexibility for end-customers: Through expanding support for cheqd into SSI Kit, end-customers can now choose a more specific technical stack that suits their needs best — with Veramo and Aries Framework JavaScript as other enterprise options.
  • Simple APIs for credential operations: walt.id offers a selection of enterprise-ready APIs for creating, updating and revoking credentials. With this new integration, all of the operations can be carried out with cheqd DIDs which makes integrating cheqd DIDs, DID-Linked Resources and Credentials into client applications lightweight and simple!
  • Future proofed for upcoming regulations: SSI Kit uses the OpenID for Verifiable Credentials stack for establishing peer-to-peer connections and for credential exchange. This is notable because it aligns with the proposed European Digital Identity Architecture and Reference Framework, which will accompany upcoming European regulations such as eIDAS v2.
  • Streamlining the bridge from Web2 identity into Web3: Through walt.id’s IDP kit, (Identity Provider Kit) cheqd customers can use cheqd issued Verifiable Credentials with traditional identity infrastructure, such as IAM tools including KeyCloak, gluu and Okta.

IDP Kit — How it works

walt.id customers:

The SSI Kit abstracts complexity for developers by following a “multi-stack approach” that enables developers to use different implementations or “flavours” of SSI. Adding cheqd as the latest “flavour” offers walt’s customers all the benefits cheqd has to offer, including:
  • Support for DID-Linked Resources: cheqd is the first identity network to build and support DID-Linked Resources (now a draft W3C standard) to support various identity data structures such as schemas, trust registries and status lists. Support for cheqd enables walt.id’s existing customer-base to utilise this innovative functionality.
  • Support for upcoming Payment Rails: cheqd’s vision is to become the de-facto payment mechanism for trusted data. By supporting cheqd within the SSI Kit, walt.id’s customers can benefit from already having existing integrations with cheqd, making it far easier and faster to leverage payment rails when released.
  • Offering a higher performance network at a lower cost: cheqd is designed as a highly performant Layer 1 with high throughput. cheqd can process an estimated 7,500 Transactions Per Second (TPS), benchmarking well beyond other leading networks such as Cardono (250 TPS), Ethereum (15–30 TPS), Avalanche (5000 TPS) and Bitcoin (10 TPS). Gas fees on cheqd are a fraction of the cost of other networks, making it far cheaper to transact on the network.

Why is walt.id’s SSI Kit important for cheqd?

When it comes to Self-Sovereign Identity, there are different technical components that need to work together to construct an end-to-end solution. The combination of different protocols together to make-up a tech stack is vital for interoperability between different ecosystems.

The Trust over IP Foundation describe these different components clearly within the ToIP Stack:

Trust over IP (ToIP) Stack

With reference to the image above, cheqd sits at the Layer 1 of the stack; cheqd is a Verifiable Data Registry with a DID method which supports the anchoring of DIDs and associated DID-Linked Resources.

SSI Kit works at Layers 2 and 3 of the stack, supporting a suite of protocols for credential exchange and peer-to-peer connections which hit a different market compared to those cheqd supports in its other SDKs. These include: OAuth, OpenID for Verifiable Credential Issuance (OpenID4VCI), OpenID for Verifiable Presentations (OpenID4VP) and Self-Issued OpenID Provider v2 (SIOP V2).

The image below offers a cheqd specific overview which helps to further illustrate SSI Kit’s place in the stack.

cheqd capability model

By supporting these protocols, it gives end-customers more flexibility in choosing a tech stack that fits on top of their use case, jurisdiction and existing identity management systems. This is especially important as:

  1. The OpenID for Verifiable Credential stack is closely related to OpenID Connect in terms of how the authentication flows work between different parties. This makes it less daunting for companies to transition from something more traditional or federated, such as OpenID Connect, to decentralised identity.
  2. The OpenID for Verifiable Credential protocols are also supported by a range of prominent SSI vendors, such as Microsoft (Entra), Mattr, Yes, Ping and Workday within the VC-JWT Presentation Profile, meaning that cheqd can now support and interoperate with a wider array of large vendors and their clients.
  3. These protocols form part of the European Digital Identity Architecture and Reference Framework, which is a new interoperability profile for companies to exchange trusted data in the European Union. Conforming with the technical stack described here will help future-proof cheqd’s tech stack for the upcoming European regulatory changes, which will give legal effect for credentials as a means of data exchange.

If you are interested in learning more about these regulatory changes, we would recommend that you read Avast’s takeaways from the regulatory changes, or watch Nacho Alamillo’s presentation on the proposed eIDAS 2 Regulation.

A bright future ahead

Interoperability, flexibility, simplicity and cost-efficiency are the key ingredients for adoption of Self-Sovereign Identity. With an eye on all of these, cheqd is positioning itself strategically for any vendor or organisation looking to implement an SSI solution. SSI Kit was the perfect storm for providing another enterprise software product, while also covering a new set of connection credential and exchange protocols.

Oh, and if you made it this far — we also have a lot of exciting developments to come, using this tech stack and the cheqd <> walt.id partnership 🔜👢👢

As always, if this blog resonates with you and you want to learn more about building on cheqd, please get in touch with our product team here and cheq-out our identity documentation here.

Universal Registrar: DID utility off-the-shelf

cheqd-Blog-Universal_Registrar-Off-the-Shelf_cheqd_Utility

cheqd’s new Universal Registrar driver enables easy and efficient integration with cheqd’s DID and DID-Linked Resource utility.

Introduction

We are excited to announce that we have successfully built a cheqd driver into Decentralized Identity Foundation’s (DIF) Universal Registrar to enable out-of-the-box and highly efficient DID and DID-Linked Resource transactions on cheqd. This is a big step in simplifying the developer journey for client applications to use cheqd’s DID and DID-Linked Resource utility in a more light way than integrating with our Software Development Kits (SDKs).

Understanding the value of the Registrar

The Universal Registrar is an open source application created by the Decentralized Identity Foundation (DIF) which aims to make it far easier to create, update and deactivate Decentralized Identifiers (DIDs) across a range of DID Methods without full integration.

EASILY CONSUMABLE DIDS IN A COMMON FORMAT

The aim of the Universal Registrar is similar to the Universal Resolver; to transform method-specific APIs for DID transactions into a common format for client applications to easily call. In more simple terms, remember the kids’ toys with different shapes and different shaped holes? Yep this one!

Imagine each different DID Method driver is a different shape. If you run an application and have to consume all different shapes and sizes, that is a hugeeeee uplift to maintain. What the Universal Registrar does is converts all of these shapes into one common shape which makes it far easier for any application to consume any of the listed DIDs (in technical terms it wraps an API around a number of co-located Docker containers).

DID Operations with minimal integration

Not only does it make it easier for client applications to support DIDs from multiple DID methods, but it also makes it far quicker and easier to create, update and deactivate DIDs — as it calls the method-specific driver with a common API.

If you imagine our SDK as a flatpack #IKEA product for DIDs, where it’s simple to put together, but you have to have instructions & the right tools (and a bit of patience).

Then imagine the Universal Registrar is like buying cheqd DID functionality straight off-the-shelf — it’s simple, efficient and quick! And it allows our partners or customers to use cheqd’s utility within minutes.

Therefore, the barrier for integrating cheqd DIDs into existing client applications has been greatly reduced by the Registrar. Instead of having to integrate with the cheqd SDK, applications can now create a simple workflow to call the relevant APIs for issuing, updating or deactivating cheqd DIDs and creating DID-Linked Resources.

Going beyond other DID Registrar Drivers

cheqd’s DID Registrar driver also supports the creation of DID-Linked Resources which goes beyond any other existing DID Method on the market. This provides the functionality for any developer to easily create the likes of schemas, trust registries and status lists on cheqd.

This week, the W3C has also formally approved the DID-Linked Resource work item which will be developed as a formal standard over the next few months here! 🥳

Getting started with the Registrar

We have created a simple setup guide for using the Registrar with Docker or locally. You can also find us on the Universal Registrar frontend.

Once you have setup the registrar, you can use the cheqd Registrar driver APIs here coupled with the Universal Registrar to build into your workflows!

For more information, we have created an Architecture Decision Record which describes the workflow for building cheqd DIDs and DID-Linked Resources into existing client applications using the Registrar.

Conclusion

We were clear in our Product Vision blog for 2023 that the path to adoption for cheqd goes hand in hand with the simplicity of integrating with its identity functionality. Using a DID Registrar abstracts away a lot of the complexity of fully integrating with cheqd’s SDK, but provides all the same benefits for DIDs and DID-Linked Resources. This is therefore a huge step in gaining wider adoption in a broad array of applications and SDKs, as the uplift for supporting cheqd DIDs is now much simpler. As always, if this blog resonates with you and you want to learn more about building on cheqd, please get in touch with our partnerships team here or you can try out our SDK for issuing and verifying credentials here, and you can setup the DID Registrar here! We set out at the beginning of 2022 to integrate cheqd into the DIF Universal Resolver. The Universal Resolver utilises REST APIs and other interfaces to enable the resolution of any DIDs which have a supported driver. We have successfully made this integration and you can now find did:cheqd on the list of supported drivers. Over 2023, we will improve and refactor our DID Resolver and our integration to make it fully enterprise-ready. The graph below shows our work on the cheqd DID Resolver and how the bulk of the work was carried out towards within the second and third quarter.

Our Product Vision for 2023 at cheqd

Setting the vision for the year ahead for delivering on cheqd network’s unique differentiators in decentralised identity

Co-authored by Ankur Banerjee (CTO/co-founder), Ross Power (Product Manager), and Alex Tweeddale (Product Manager & Governance).

The cheqd team is thrilled to begin 2023 with our first major version released for the cheqd mainnet/testnet to v1.x, which was successfully carried out on 30th January 2023. Throughout this blog post, we want to revisit our product reflections at the end of last year, and lay out a vision for the future.

🚀 Our product roadmap at cheqd for 2023

Our product vision last year (published just two months after the launch) described our objectives using fundamental building blocks that we wanted to deliver. We’re excited to say that our v1.x release delivered on a lot of those fundamentals (more on that later).

product roadmap at cheqd for 2023, at a glance

Therefore, for this year, we’ve outlined five product development goals the cheqd team is working on, in terms of objectives we want to achieve by the end of 2023:

  1. Double-down on building payment rails for digital identity: This is the unique selling point for which most of our partners signed up to the cheqd network — and why many people in the cheqd community are backing us. For reasons we’ll go into more detail in the blog post, we had to spend more time than we anticipated in 2022 laying down the groundwork for this — but now that those foundations have been delivered in our v1.x release, we’ll be laser-focussed on delivering the payment rails everyone has been waiting for.
  2. Continue simplifying developer experience to make building on top of cheqd network faster and cheaper: We’ve spent a lot of time in 2022 simplifying the developer experience for partners and app developers building products on cheqd. We plan to continue on our mission to make building products on cheqd simple in comparison to Web2 as well as Web3 digital identity competitors. We also want to drive more organic adoption of network usage by existing and future partners.
  3. Support compelling products addressing decentralised reputation for Web3 ecosystems: 2023 seems to be a turning point where the wider crypto ecosystem has acknowledged that Web3 requires compelling solutions to decentralised reputation, but so far this effort has been focussed on using NFTs for identity (hello, soul-bound tokens), proof-of-attendance protocols (“POAPs”), and so on. As we laid out in our trends report on decentralised identity, we think there’s a large and unaddressed gap in the market for a more privacy-focussed vision of how online reputation can be solved in decentralised communities. We’ve been working on skunkworks project for the past few months, codenamed “Project Boots”, which is aimed at this space.
  4. Integrate deeper with the Cosmoverse and beyond: We focussed a lot of last year on building out strong partnerships in the self-sovereign identity (SSI) ecosystem. This year, we want to leverage the multichain vision of the Cosmos SDK ecosystem to become one of the go-to solutions for digital identity within the Cosmoverse. We also believe that our network can be of utility for Web3 projects not built on Cosmos SDK, without them needing to switch blockchains. At the same time, we will work on improving the availability of $CHEQ tokens, and first-class support in crypto apps (such as wallets and explorers), all with the aim of making it easier to use and build upon the network.
  5. Drive adoption via industry standards for product innovations made at cheqd: We’ve been working on differentiated product innovations last year at cheqd, such as our approach to DID-Linked Resources. While we’ve written and designed this to be ledger-agnostic, widespread adoption of this idea (and therefore, normalising its usage on the cheqd network) requires us to do the legwork to get them codified as industry standards at W3C, DIF, and ToIP. We think the time is ripe for this, given the Decentralized Identifiers Core (“DID Core”) became an official W3C Recommendation standard last year.

We’ll deep-dive into each of the five product development goals below. Alongside this, we are very excited to share an interactive product roadmap for cheqd which we will continue to update and iterate over the course of the year and beyond.

Click here to see interactive product roadmap

1️⃣ Double-down on building payment rails for digital identity

The core vision of cheqd is that while the idea of decentralised identity that is in control of the user is a noble ideal, the lack of business models on why the issuers of this data should give this data back to users is hampering adoption of self-sovereign identity.
Overview of payment rails for digital identity

Payment rails for verifiable credentials will enable each party in a digital identity ecosystem to be rewarded for their participation in the network. Credential issuers may be rewarded for issuing Verifiable Credentials; Holders may be rewarded for sharing their own data in the form of Verifiable Credentials or Presentations; Credential recipients (“Verifiers”) may be rewarded with compliance benefits and lower costs for identity verifications.

At the same time, we acknowledge that one of the fundamental principles of SSI / decentralised identity is giving power to the user. We believe there’s a happy middle-ground that can enable these payment rails and have privacy-preserving characteristics that the SSI ecosystem (and users) value.

REAL-WORLD ANALOGY

  1. You might hold a drivers licence, issued by a trusted authority (e.g., the government driving licence authority)
  2. When you go to buy an age-restricted product, such as alcohol or tobacco, the store might check your age by asking you for your drivers licence. (Note that the “credential” is being used here outside its original intended purpose to prove the right to drive.) This interaction is “free” for the store’s clerk, since they are only interested in checking whether the age in an official-looking document is above a certain number,
  3. However, if you wanted to rent a car, the car rental agency might run a live check against a government database or other 3rd party API to determine whether the licence is currently valid, or whether it has been revoked ahead of its original expiry date. This interaction typically costs the car rental agency something, i.e., a per-check fee paid to the API they do the lookup on.

PUTTING THE ANALOGY IN THE CONTEXT OF SELF-SOVEREIGN IDENTITY

The holder is you (the driving licence holder), the issuer is the driving licence agency, and there are two (separate, unrelated) credential recipients (“verifiers”): the alcohol store and the car rental agency. We believe there’s a large sector of the SSI market where credential recipients will be willing to pay a small fee to check the status of credentials, and it will motivate potential credential issuers to hand out data in portable and secure data credentials.

Responses captured within cheqd blog “Understanding the SSI stack through 5 trends and challenges“

HOW WE’RE APPROACHING BUILDING OUT PAYMENT RAILS THIS YEAR

In order to build such a solution, it is relatively easy to build a centralised, gated API where payment must be made before the API returns a response. Centralised, gated APIs are extremely common in the Web2 world. Such a centralised API would also be privacy-leaking, since the act of looking up details on such APIs itself reveals information about the client application/user accessing the information, the contents of the information being accessed, etc. Both Google and Facebook backdoor tracking data for their ad networks using their “Login with…” buttons, regardless of whether you personally use the Google/Facebook login option or not. Therefore, we’re interested in building a decentralised mechanism or API that is privacy-preserving and minimises leakage of which credential’s revocation status was checked. Logical components include:
  1. A decentralised credential status & trust registry: This answers the question “Is this credential I’ve been shown revoked or not?” and “Is the issuer of the credential trustworthy?”. We’ve already delivered a mechanism to answer these two questions in a decentralised fashion, using DID-Linked Resources (and made it more robust in our v1.x mainnet release).
  2. A token-based payment-gating mechanism: The status & trust registry above should only reveal the answer once the pre-defined payment set by the issuer of the credential has been paid. In other words, this would be a mechanism to charge for read actions on DID-Linked Resources.
  3. A payment-privacy system: The value of a transaction or the sender/recipient itself can leak private information about the parties involved. An ideal payment mechanism for the above would try to minimise information leakage.
Without giving too much of the secret sauce away, our product & engineering team already has a viable approach for a token-based payment-gating mechanism we plan on building out over Q1/Q2 of this year, layer on top of the code we’ve already shipped for credential status & trust registries. We plan on making this functionality available first using a decentralised approach as the first layer of privacy-preservation, and then layer on multiple approaches to increasing payment functionality till the end of the year.

2️⃣ Continue simplifying developer experience to make building on top of cheqd network faster and cheaper

When we started 2022, cheqd had just launched its mainnet in November 2021. While our first mainnet release certainly offered enhanced support for more complex Decentralized Identifier Documents (“DID Documents”), we knew that we were going up against incumbent networks in self-sovereign identity which had been building for much longer than us.

So we set out in address one north star question within the product team last year: “Can an app developer, starting from scratch, build a digital identity use case on cheqd in less than 30 minutes?” Critically, we didn’t distinguish this with any qualifiers such as “…compared to other SSI networks” or “…compared to Web 2.0 identity solutions”. Both Web2 as well as Web3 identity solutions are our competition since they represent the status quo in how our digital identities are handled online.

What the cheqd team has delivered in 2022

Much of what we’ve shipped in terms of products on-ledger and off-ledger was building towards answering this question. Some of this work was driven by the cheqd Product & Engineering team directly to jump-start network usage, such as building a plugin for the widely-used Veramo SDK for W3C-compliant DIDs and Verifiable Credentials.

Other efforts, such as the work done on Hyperledger Aries by Animo to make AnonCreds independent of Hyperledger Indy happened more organically through app developers building on top of the cheqd network. Ultimately, we want more app developers organically building products, so that our team can focus on unique differentiators that no other decentralised identity network offers.

cheqd Product Reflections 2022

STRENGTHENING PRODUCT PARTNERSHIPS ON REAL-WORLD USE CASES

Product partnerships are crucial to cheqd as a network, whether they are mature SSI vendors, or startups that have heard of SSI but haven’t dipped too far into building it into their products so far.

Instead of just looking at integrating cheqd at a technical level, we’re collaborating on more than a dozen specific product use cases with our partners, such as:

  1. Single Sign-On (opening up the opportunity for “Sign-in with cheqd”);
  2. Integrations in enterprise uses cases in Web2;
  3. Integrations into Web3 use cases including community & reputation managements;
  4. Integrations in private network consorta clients
  5. Integrations for Consumer Credit scores to Web3 lending environments
  6. Integrations for recycling and sustainability payments
  7. Payment rails for financial institutions
  8. Opportunities for better management of storage

MAKE IT EASIER TO WRITE TO THE CHEQD NETWORK FOR A WIDER RANGE OF APP DEVELOPERS

At the start of 2022 we surveyed our partners to inform our product strategy for the year. The responses emphasised the importance and potential impact of assigning part of our time to adding cheqd network support in Hyperledger Aries, which is the most widely-used SSI SDK kit.

Aries-based SDKs are dominant, correlating with Indy at Layer 1

(N.B, Respondents could select that they are using multiple SDKs hence the reason for graph illustrating a percentage greater than 100).

Therefore, this year we’re continuing to build on the progress we made to support Aries frameworks on cheqd, working closely with our partners and the wider SSI community to advance standards and interoperability. This includes contributing to and integrating with Hyperledger AnonCreds, a ledger-agnostic and client-agnostic version of the widely used AnonCreds credential format. Working with Animo, we’re enabling our partners to issue Hyperledger AnonCreds using the Aries Framework Javascript SDK, followed by ACA-Py.

However, we also know that not every SSI vendor uses Aries SDK. Having a diverse and vibrant ecosystem of SDKs is important for creating a truly decentralised developer ecosystem, and as such we’re continuing to work closely with the Veramo SDK, supporting both JSON-JWT and JSON-LD credentials.

We also believe that outside of the SSI vendors we’re already partnering with, there’s a larger market of app developers who want to build privacy-enhanced digital identity experiences, but aren’t currently using SSI in their products. This has been evidenced by a large volume of inbound requests we’ve had from such startups and app developers, asking us how they could incorporate a new model for digital identity into their products. Asking these app developers to wholesale switch SDKs is hard.

Therefore, we’re focussed on building cheqd network support into DIF Universal Registrar, making it quick and easy for app developers to integrate cheqd using simple REST APIs. (REST APIs are the most commonly-used API pattern, used in Web 2.0 apps as well as within Cosmos SDK itself, e.g., for Keplr Wallet interacting with Cosmos dApps.) This will increase cheqd’s wider adoption and user / developer experience for SSI vendors, developers and Web3 partners.

PRODUCTION-GRADE SUPPORT IN SSI SDKS AND TOOLS

With a huge amount of work on ledger-agnostic AnonCreds in-flight, we plan to continue funding and accelerating efforts to unlock first-class support for cheqd network in the most widely adopted SSI SDK.

We’re also excited to announce that we will soon be fully supported in walt.id’s SSI Kit, which natively supports JSON and JSON-LD credential types, while using a different credential exchange protocol to our existing Veramo SDK plugin. Walt.id’s SSI Kit uses the Open ID Connect Stack for credential and presentation exchange, affording cheqd even more coverage across the Verifiable Credentials landscape.

3️⃣ Launch compelling products addressing decentralised reputation for Web3 ecosystems

A large gap in the current SSI space is functional governance for SSI ecosystems. There are a few approaches to Trust Registries and Trust Establishment which are currently unstandardised and generally rely on centralised infrastructure. We presented a research paper at the Rebooting Web of Trust conference last year, titled Dynamic & Decentralized Reputation for the Web of Trust: What We Can Learn from the World of Sports, Tinder, and Netflix which laid out some of extremely long-term thinking on where the digital ID industry is heading.

In the more immediate term, with cheqd’s DID-Linked Resources we’ve built a perfect foundation for creating Trusted Issuer Lists, Trust Establishment files, Credential Manifests or Presentation Definitions on-ledger, identifiable with a fully resolvable DID URL. This may even improve the standard paradigm for working with interoperability profiles such as WACI-DIDComm.

Further to this, one of the needs we’ve identified from SSI clients is a web application that is able to manage trusted issuers in a given ecosystem, as well as what levels of governance are required for different purposes.

Using cheqd DID-Linked Resources, we foresee this being far easier to achieve than by building from scratch. This year, we plan to demonstrate these benefits and streamline their existing client facing application and demonstrate DIF Trust Establishment and Trust Registry capabilities on cheqd, alongside one of our partners.

Lastly on this point, we plan on launching our skunkworks project, codenamed “Project Boots”, within Q1/Q2 of this year. While the SSI space often uses the usual suspect use cases, e.g., Know Your Customer (KYC), education degrees, etc, in examples quite often, we fundamentally think these are infrequent use cases, and therefore not something truly painful that real-world users face on a daily basis. What they struggle with is proving their reputation online. Stay tuned for more on how we plan to re-use everything we’ve already launched in a compelling and fun experience for tackling reputation in Web3.

4️⃣ Integrate deeper with the Cosmoverse and beyond

One of the things we understand, in hindsight, is that while we focussed last year a lot on SSI vendor partnerships, we didn’t focus perhaps as much on building equally deep ties within the Cosmoverse. While some of the most notable players in the Cosmos ecosystem validate on our network and we collaborate in terms of contributing back open source code, we could do even better at this.

It’s worth noting that as part of our v1.x release, cheqd is one of the first Cosmos SDK chains to adopt Cosmos SDK v0.46, which brings capabilities such as Interchain Accounts. Besides, Cosmos SDK v0.46 introduces long-term and stable fixes for the “Dragonberry” security vulnerability which could theoretically compromise IBC payments. Incorporating the deep nuts-and-bolts changes needed to make cheqd ledger compatible with changes in upstream Cosmos SDK was one of the reasons why our v1.x release took longer than we expected. While being one of the first chains to adopt this Cosmos SDK release was technically challenging, we take security very seriously at cheqd — especially as we want to build the payment rails for digital identity.

Moreover, the next version of Cosmos SDK (v0.47) has an even bigger growth spurt to make the interchain software foundations more robust and secure. While we won’t need to incorporate these right away, the work we’ve done to transition v1.x will make the process of moving to Cosmos SDK v0.47 smoother when the time comes.

We’ve heard you loud and clear, though, on the need to increase our presence in the Cosmoverse. Some of our aspirational goals in this space are:

  1. First-class support for cheqd network in more Cosmos SDK wallets and apps: We’ve got first-party integrations into Leap Wallet for our network’s token functionality. We want to work on expanding support for Verifiable Credentials natively in crypto wallets by extending the WalletConnect protocol in 2023. Ideally, we want to extend this to Keplr Wallet and Mintscan, which are the two biggest product requests we get. We’re in continued discussions with both and are looking forward to these product integrations as soon as reasonably possible.
  2. Position cheqd as one of the go-to solutions for digital identity within the Cosmoverse: We’ll leverage the good work we’ve done last year, and continue to do this year, in terms of making utility usage of our network easier to specifically guide Cosmos SDK projects on how to use cheqd for privacy-enhanced digital ID. Our goals defined under simplify developer experience and decentralised reputation (aka “Project Boots”) both feed into this goal.

As always, we’ll continue to support $CHEQ in more CEXs/DEXs as an ongoing goal to make the tokenomics of our network more viable.

5️⃣ Drive adoption via industry standards for product innovations made at cheqd

Technical standards are crucial in ensuring interoperability between different SSI ecosystems. As such, we are currently in the process of getting two different standards created: ledger-agnostic Hyperledger AnonCreds and W3C DID-Linked Resources. This is based on feedback from our SSI vendor-partners that efforts we put into getting these product innovations at cheqd incorporated into standards has a tangible impact on their prioritisation for these features into being used in their products.

Later in the year, we will kick off a technical standard looking at how Verifiable Credentials can be incorporated within WalletConnect at the Chain Agnostic Standards Alliance (CASA). The basic idea here is that there are far more crypto wallets in active use, as opposed to SSI wallets, and native support for Verifiable Credentials in crypto wallets will significantly increase the reach and distribution of SSI. We want to focus on WalletConnect since some of the most widely-adopted crypto wallets support this protocol, and our proposal would be to specify a technical method through which dApps and wallets can signal which kind of Verifiable Credential features they support. Similarly, we’re also exploring collaboration with the Open Wallet foundation, a Linux foundation project with the goal of developing an open-source engine for secure and interoperable multi-purpose wallets.

Finally, we are eager to participate and explore live interoperability testing amongst projects, such as Silicon Valley Innovation Program Plugfest and other large SSI networks such as European Blockchain Services Infrastructure (EBSI) and LACChain. This is important because cheqd does not want to build in a vacuum and aligning with other chains, programmes and identity initiatives will ensure that cheqd’s progress in payments and resources is market-ready and interoperable cross-ecosystem.

⏪ How our v1.x release enables our 2023 product goals

Hopefully, we’ve given a flavour above on our product vision for this year. We’ve been humbled by the response over 2022 from our partners and app developers building on top of the cheqd network. There is clear excitement about the product vision we’ve laid out in terms of economically-sustainable business models for digital identity. But to truly be able to build towards that vision, our strategy was to first offer a decentralised network that was incrementally better than the current state-of-the-art in self-sovereign identity.

Making AnonCreds ledger-independent and the opportunities unlocked by DID-Linked Resources are two tangible examples where we exceeded the capabilities of current SSI networks. But, we also knew that achieving our north star goal of “up-and-running in 30 minutes or less” required additional effort.

To wrap up our product vision, we wanted to recap the key areas that our v1.x release delivers on, and forms the fundamentals of our product roadmap we’ve outlined above for 2023…

Read: cheqd Network Changelog – release 1.x

ENHANCE DID AND DID-LINKED RESOURCES FUNCTIONALITY

The feedback on DID-Linked Resources that we received from the decentralised identity community has been, overall, positive. One of the features that developers appreciated was the robust versioning (and being able to query historical versions) for these digital Resources. While it was technically possible to query historical versions of DID Documents as well, we’ve released the same robust versioning method we built for DID-Linked Resources for actual DID Documents themselves. (It’s worth noting that not all DID methods support versioning.)

We also spent the latter half of 2022 building SDKs and integration software such as support in the DIF Universal Resolver, which we know are important for developer adoption. Using the lessons learnt along the way, we refactored parts of our on-ledger code to make building integrations with SDKs and 3rd party apps easier. This enables our goals for simplifying developer experience, integrating deeper with Cosmoverse, and aligning for industry-standardisation (based on feedback we received for DID-Linked Resources).

MAKING IDENTITY TRANSACTION PRICING MORE ECONOMICALLY-SUSTAINABLE

Prior to the v1.x update, writing a DID to cheqd mainnet only costs gas, approximately 0.004 $CHEQ. In comparison to other networks, this is a far lower price (you’ll find a pricing comparison here, also below).

MAKING IDENTITY TRANSACTION PRICING MORE ECONOMICALLY-SUSTAINABLE

Prior to the v1.x update, writing a DID to cheqd mainnet only costs gas, approximately 0.004 $CHEQ. In comparison to other networks, this is a far lower price (you’ll find a pricing comparison here, also below).
cheqd identity tx pricing comparison with other networks

Additionally, $CHEQ was previously inflationary, meaning the staking rewards are generated from inflation only, and only slashing, tombstoning or no-with-veto slashing provide an inflationary pressure. Therefore, we chose to introduce two key mechanisms to counteract these. The first, identity transaction pricing, means that any transaction on-ledger related to identity has a specific, fixed fee. For example, creating a DID or any form of resource, like an image or schema, has a set fee. The current prices for these can be seen here, and below.

cheqd Identity pricing implemented on-ledger as part of the January 2023

The second, a burn mechanism helps establish equilibrium with the inflation on the network by burning a proportion of the identity transaction charges above. Over time we see this a viable route to return the total supply to the total initial supply of one billion $CHEQ. The current burn % has been set at 50%, however we have tested the right up to 99% and will take the communities lead to decide where this % will remain for a longer term.

In addition to making identity transactions more economically-sustainable, we also see this an important method of providing more stability to app developers building with cheqd, as a means to more accurately forecast and price the build of products for customers.

COMPLEXITIES AND CHALLENGES WITH THE V1.X RELEASE

Preparing for and implementing the v1.x release did however have its fair share of challenges, which transparently slowed down our release cycle.

To accommodate for the ledger enhancements, fundamental changes were required to the underlying code base which the ledger uses. For example identity transaction pricing and the ability to provide an alternative URI for a DID did not exist in the previous version, meaning this feature would not be possible to implement. The effort and time required to implement the changes and test these expanded far greater than we’d anticipated, however ultimately doing so has put us in a far better position which will mean we take back the time in future implementation and releases.

We’ll be providing a deeper-dive into these challenges, plus others, and crucially our lessons learnt which we hope will be useful for other Cosmos SDK-based projects and the general developer community alike.

Tell us what you think!

It’s going to be a very busy and ambitious year here at cheqd and we would love your feedback on our product vision for 2023. We welcome engagement and feedback across a range of different forums, such as our Community Slack and Commonwealth Governance Forum (best for extended, in-depth discussions).

We, at cheqd, help companies leverage SSI. cheqd’s network is built on a blockchain with a dedicated token for payment, which enables new business models for verifiers, holders and issuers. In these business models, verifiable credentials are exchanged in a trusted, reusable, safer, and cheaper way — alongside a customisable fee. Find out more about cheqd’s solutions for self-sovereign identity

cheqd Product Reflections 2022

A retrospective on a year building a Decentralized Identity network on Cosmos. Co-authored by Ankur Banerjee, Ross Power and Alex Tweeddale.

TL;DR

2022 has been a huge year for the cheqd Product & Engineering team. We’ve made three major software upgrade releases to the cheqd network and several minor upgrades, including:

Each upgrade comes at the end of a development cycle (shown by the spikes on the graph below), contributing towards our mission to build a stable, trusted and secure decentralised identity network, known within SSI as a Verifiable Data Registry.

Cadence of our commits on cheqd node over 2022

From these releases, here’s a quick overview of what our overall journey looks like so far:

cheqd Journey to Payment Rails

You can think of everything we have been working on to date as:

  1. Feature parity with all other SSI networks;
  2. Identity functionality that goes beyond existing SSI networks; and
  3. The tooling and scaffolding to lay the foundations for payment rails for Verifiable Credentials.

Bringing this all together into a visual representation, using the Trust Over IP stack as we have done in the past, helps to make sense of what cheqd’s capabilities look like both now and what’s to come…

cheqd Capability Stack

Our top product takeaways

Before diving into how we measured up against our 2022 roadmap, we wanted to lay out five key product takeaways from this year.

1. SDKs are a crucial product driver to adoption

To get cheqd integrated into our partners’ software applications, we must focus on supporting the broadest range of SDKs, across Hyperledger Aries and non-Aries spheres. Until functionality is supported fully in an SDK, the fact that it is supported on the cheqd network is less relevant.

This year, we successfully built out a working Javascript-based SDK, the Veramo SDK for cheqd, which offers end-to-end functionality for developers to build their identity applications. We have also made significant progress with integration into Walt ID’s SSI Kit and our partners Animo Solutions are in the process of building cheqd support into Aries Framework JavaScript.

That said, we also want to be honest with ourselves and you in some areas. We had hoped to make more progress and have a larger suite of SDK support this year. However, the complexity of SDKs and the effort we put into building other first-of-a-kind aspects of our ledger, such as a Resource module has slowed this progress down. Aries SDKs are largely a community challenge. With each SDK so tightly bedded to Hyperledger Indy, it’s taking a mammoth effort from the whole AnonCreds community to rework this into a Ledger-agnostic AnonCredss specification.

2. Payment rails are worth the cost / benefit analysis

Mass adoption for cheqd is predicated on the success of the payment rails. Earlier in the year, we conducted a survey and gathered that payment rails would swing partners to invest the time and resources to fully integrate with cheqd because they would offer a new angle and incentive for clients and customers to bite on SSI technology.

Data showing how payment rails will help cheqd’s partners gain adoption

While admittedly, we didn’t make the progress into payment rails that we set out at the beginning of the year, we have laid the groundwork in terms of identity functionality, partnerships and interoperability for payments to feature centre stage in 2023.

3. Interoperability is a USP

In terms of identity on-ledger, we generally feel a great sense of accomplishment with our progress. Being able to bridge the AnonCreds crowd with the VC-JWT and VC-DI (JSON-LD) proponents using innovative and highly requested standards will help cheqd establish itself as a respected alternative to other leading identity networks such as Sovrin and ION.

We are also leading the charge to broaden Hyperledger Aries SDKs’ dependencies and innate ties to Hyperledger Indy. We joked about the interoperability pitfalls of Aries at the start of the year in our presentation on the Seven Deadly Sins of Commercialising SSI, and now meaningful interop changes are finally coming to fruition.

Meme about Hyperledge Aries interop

4. Never underestimate the difficulty of refactoring to support upstream changes

The Cosmos-wide Dragonberry vulnerability and patch (see 0.6.9) was a big shakeup in the Cosmos SDK ecosystem. As a result of the vulnerability, there have since been widely coordinated sets of changes for securitys reasons across the Cosmos ecosystem.

In just two months there have been six Cosmos SDK bumps addressing security issues. In two of these releases (0.46.5 and 0.46.7) prior versions of Cosmos SDK were retracted for security reasons, meaning that expedited shifts to the latest SDK versions was a priority.

Additionally, software for decentralised identity gets developed very rapidly and requires fast catchup to upstream projects/codebases. For example, our Veramo SDK for cheqd requires changes to be made when there are upstream changes in the Veramo SDK versions.

What that means for us is a lot of developer resources need to be dedicated to keeping up with the quick succession of upstream releases upstream which has inevitably taken away focussed time on cheqd specific product features.

5. Demos speak louder than words (and code…)

Getting a general audience and Web3 audiences to understand the value of decentralized identity can be challenging. Blogs, docs and written information are often difficult to consume for newcomers unfamiliar with our terminology. For this reason it is important that we focus on demonstrating the value of cheqd’s identity technology, rather than simply explaining it.

This year we’ve created two initial demos of how credentials may work in real world scenarios. Firstly, we partnered with Animo Solutions to demo AnonCreds on cheqd being issued and used in various scenarios. This went down very well with identity audiences, but again, newcomers and Web3 companies struggled to understand why AnonCreds were cool!

Secondly, we created a cheqd wallet demo which shows how Verifiable Credentials can be stored and used alongside your crypto. In this demo, we enable a user to get a social media credential for authenticating with Twitter or Discord, then upload a QR code of a ticket for an event, and present a combined presentation of their social media credential and the event credential.

This demonstrates how credentials can be used to prove a level of trust and reputation in someone’s identity and also their validity for entering an event, a topic we’ve since expanded on. Demos like this go a long way to showing people the power of the identity technology we’ve built, and we want to go even further with simple, gamified demonstrations of the tech in 2023.

Looking back on our 2022 Product Vision

We strongly believe that transparency in our product development is integral to the success of cheqd. As such, we want to take a candid look at how we have measured against our initial goals set at the beginning of 2022. We hope that you, our partners and community members, also continually challenge and hold us to account.

Looking back to the start of the year, our three focus areas for development laid out in our January Product Vision blog were broken down into:

  1. Identity: Core identity functionality for our partners to build compelling self-sovereign identity use-cases on top of the cheqd network.
  2. Web 3.0 Core: Core Web 3.0 functionality adds deeper integration for our network and token into the Cosmos and other blockchain ecosystems.
  3. Web 3.0 Exploratory: Emerging Web 3.0 use-cases such as decentralised exchanges (DEX) ecosystems; decentralised autonomous organisations (DAOs); identity for non-fungible tokens (NFTs), and in general, DeFi applications.

So, how did we match up against these goals and objectives? We’ll take a look at each Core section and give them a score based on how many goals we successfully achieved.

Identity Retrospective

  • TOTAL SCORE: 5/6

1. Tutorials for developers

STATUS: COMPLETED

Tutorials are critical for having actual utility built on the network, since if users don’t know how to use what we’ve built, there is little value in it. We have been hard at work on expanding our documentation for developers using cheqd’s identity and ledger functionality:

To utilise the Veramo SDK for cheqd, you can follow the setup guide here. You can then follow our tutorials to begin creating DIDs and DID-Linked Resources on cheqd, or create Verifiable Credentials and Presentations.

2. Integrations with industry-standard identity projects

STATUS: COMPLETED

We set out at the beginning of 2022 to integrate cheqd into the DIF Universal Resolver. The Universal Resolver utilises REST APIs and other interfaces to enable the resolution of any DIDs which have a supported driver. We have successfully made this integration and you can now find did:cheqd on the list of supported drivers. Over 2023, we will improve and refactor our DID Resolver and our integration to make it fully enterprise-ready.

The graph below shows our work on the cheqd DID Resolver and how the bulk of the work was carried out towards within the second and third quarter.

Cadence for DID Resolver commits

We have also made significant progress to integrate cheqd into the DIF Universal Registrar. This will enable parties to create, update and deactivate cheqd DIDs through a standard interface. The Universal Registrar can also be leveraged to support cheqd in a wider range of applications and SDKs. You can cheq out our progress in our Open Source repository here.

3. New & Improved Identity Functionality

STATUS: COMPLETED

We have gone above and beyond other identity networks on the market. Firstly, looking at the cheqd DID method, we have incorporated the ability to have multiple DID controllers and to have more complex verification method relationships not present in the did:indy method.

We have also published implementation reports for our DID method, DID resolver and DID URL dereferencer against the DID Core Specification Test Suite to transparently show our DID method capabilities.

Most notably, we have built a ‘resource’ module which supports DID-Linked Resources identifiable with unique, DID Core conformant, DID URLs. This functionality is available to begin using through the Veramo SDK for cheqd. You can learn more about DID-Linked Resources in our guide here.

Using DID-Linked Resources, we have been able to natively support AnonCreds on cheqd, a type of credential format used by Hyperledger Indy and Hyperledger Aries libraries which has increased privacy-preserving qualities compared to VC-JWT and VC-DI (JSON-LD) based credentials.

You can see how cheqd benchmarks against Hyperledger Indy in a side-by-side comparison here.

4. Payment rails for identity

STATUS: IN DESIGN

Payment rails for identity has been cheqd’s flagship offering since the network was launched. In the last year we have laid the groundwork and foundations for payment rails to layer on top.

In our update 1.0.x we are introducing new tokenomics for the network which will tie the CHEQ token to the core identity utility on the network. You can see cheqd’s updated pricing and comparison against Sovrin and Indicio here.

This is the first step towards payment rails, and early in 2023 we hope to release a phased architectural plan for achieving full payment rail functionality.

5. Client SDKs in more programming languages

STATUS: COMPLETED

At the beginning of 2022 we were planning to use Verifiable Data Registry (VDR) Tools SDK, from one of our key partners Evernym (acquired by Avast, now merged into Gen) as the primary enterprise-ready SDK for cheqd. However, towards the beginning of 2022 we conducted a product survey which established that software vendors prefer to use programming languages/frameworks based on JavaScript (81.2%), Python (62.5%), and Go (28.1%), instead of Rust which VDR Tools SDK uses (16%).

Since then, we have built our own SDK (cheqd SDK) and integrated cheqd into a JavaScript based SDK, the Veramo SDK, as a plugin. You can take a look at the modular architecture for our SDK packages here.

In terms of our product development on the cheqd SDK, below you can see the commits over the year for the cheqd SDK and cheqd Veramo plugin.

Cadence for cheqd SDK commits
Cadence for cheqd Veramo plugin commits

We have also successfully demoed cheqd using AnonCreds through Aries Framework JavaScript, and full SDK support is due to be completed following some updates to the AnonCreds spec to decouple dependencies on Hyperledger Indy. Going forward into 2023, we want to continue to integrate cheqd into as wide an array of SDKs as possible, starting with Aries Cloud Agent Python (ACA-Py), followed by Aries Framework Go and Aries Framework .NET.

6. Better interoperability and support for emerging identity standards:

STATUS: COMPLETED

cheqd has made a splash in the identity world with heavy influence into two emerging technical standards. Firstly, a W3C specification for DID-Linked Resources, as an extension to the DID Resolution Specification. Secondly, an updated ledger-agnostic Hyperledger AnonCreds specification that will complement cheqd’s approach to supporting AnonCreds object using its DID-Linked Resources.

Through supporting AnonCreds on cheqd, cheqd is the first network to support all major credential types, with VC-JWT fully supported and VC-DI (JSON-LD) at the final stages of being production ready.

Web 3.0 retrospective

  • TOTAL SCORE: 3/6

1. Wider integration with Cosmos ecosystem

STATUS: IN PROGRESS

We have expanded the number of platforms that cheqd functionality is available on. For example, at the beginning of 2022, staking and governance functionality was only available through with our friends at OmniFlix on our web-based cheqd x OmniFlix dashboard.

Now, we natively support staking and governance in our own cheqd wallet web-app and separately support governance operations at our cheqd x Commonwealth forum.

Notably, cheqd is also fully supported by Leap Wallet on their browser extension and on their mobile app. The beta Leapboard enables you to manage your CHEQ alongside your other Cosmos-based tokens in one place.

Going forward into 2023, we still want to push for full Keplr integration, and importantly, we want to introduce the ability to manage Verifiable Credentials within existing Cosmos-based applications.

2. Bridge to Ethereum networks

STATUS: COMPLETED

In Q1 2022, we successfully set up a bridge to Ethereum for the cheqd network using the Gravity Bridge. A blockchain bridge or ‘cross-chain bridge’ enables users to transfer assets or any form of data seamlessly from one entirely separate protocol or ecosystem to another (i.e. Solana to Ethereum, or in our case Cosmos to Ethereum and vice versa). The ERC20 version of CHEQ, the CHEQ-ERC20 wrapped token can be found here!

Read more about the cheqd x Gravity bridge and our decisions around it here.

3. Improved automation and tooling

STATUS: COMPLETED

We have made significant progress in how we have architected our cheqd node tooling and infrastructure. At the beginning of 2022, for example, it was a manual process to upgrade your cheqd node from scratch. We have since introduced an interactive installer which automates the process of upgrading cheqd nodes, making it significantly easier and less time consuming to run a cheqd node.

In addition, we have introduced several new components to streamline the setup and management of nodes in the form of infrastructure-as-code. We have started using HashiCorp’s Terraform to define consistent and automated workflows. This automation gives prospective network Validators the choice of whether they want to just install a validator node (using our install instructions), or whether they want to set up a sentry-plus-validator architecture for more security.

To complement Terraform, we have also introduced Terragrunt which performs the role of a wrapper to make our infrastructure available in Hetzner and DigitalOcean, as well as making it easier to utilise with AWS or Azure.

And to make cheqd configurations reusable across other Cosmos networks, we have begun using Ansible, which again acts as a wrapper or envelope to take cheqd configurations between separate Cosmos projects for node operators.

For a condensed list of the tooling and automation improvements we have made during the year, take a look through our Open Source-a-thon blog.

4. Native, cross-chain privatives for the Cosmos ecosystem

STATUS: IN PROGRESS

Our demo wallet showcases how cheqd DIDs and DID-Linked Resources can sign and be wrapped into Verifiable Credentials in Cosmos-based identity wallets. Using the demo wallet, you can now obtain credentials for authenticating with a social media profile, as well as for importing event tickets which you can combine into one proof. Within these Credentials, there are schemas and images which are stored as resources on the cheqd network. You can watch a video of the full demo here.

This is a huge step for demonstrating how cheqd’s identity functionality can begin to slot into other Cosmos-based applications. A priority for 2023 will be exploring how cheqd’s identity primitives can be utilised across other Cosmos chains, perhaps through opening up cheqd’s DID and Resource module to the rest of the Cosmos ecosystem via Interchain Accounts.

5. Smart contracts using CosmWasm

STATUS: BACKLOG

Using smart contracts and CosmWasm will likely be a crucial component of creating a privacy-preserving payment flow for credentials on cheqd. We are waiting until the first iteration of payments on cheqd has gone live before looking to integrate smart contracts. This is because CosmWasm will largely increase the computation cost for running a cheqd node. Therefore, we want to make sure the addition of CosmWasm does not get introduced before it is ready to be used.

6. Establish ourselves as a leader in decentralised governance for identity

STATUS: COMPLETED

cheqd’s Governance Framework is poised to become the first fully Trust over IP conformant Layer 1 Governance Framework. This will be enabled through cheqd’s approach to DID-Linked Resources which will identify the Governance Framework with a unique DID URL.

The cheqd governance framework also tightly aligns itself with the latest Governance standards coming out of the ISO/TC 307 technical committees on Governance (ISO/TS 23635:2022) where the concept that cheqd refers to as “Entropy” was a core component of the ISO approach to blockchain governance.

cheqd’s Governance Framework has since been lauded by leaders in the decentralised identity space. Drummond Reed, Director of Trust Services at Gen and co-author of the DID Core Spec stated:

“As SSI matures we’re seeing innovation at every layer of the Trust Over IP stack. cheqd is the only ToIP Layer 1 public utility I’ve seen with a governance framework designed explicitly to evolve from permissioned to permissionless. Add to that cheqd’s commitment to interoperability across all SSI ecosystems and its unique focus on SSI-based value exchange and you have one of the most exciting projects in SSI today.”

We’ll also be continuing to engage with working groups, consortium and organisations in the SSI space, such as Decentralized Identity Foundation (DIF), Trust over IP (ToIP), World Wide Web Consortium Credentials Community Group (CCG), European Blockchain Services Infrastructure (EBSI), and LACCHAIN to align on best practices and standards for governance and identity technology.

Conclusion

In 2022 we have made huge amounts of progress in terms of product development across the board, completing 8/12 objectives we set at the beginning of the year. Our development cadence and quantity of work is also illustrated by the sheer volume of commits (5,365), pull requests (262) and frequency of PRs (1.3 per day) that we’ve achieved this year, shown in the overview below (this is just based off of 2 of our repositories (cheqd/cheqd-node and cheqd/sdk).

Overview of cheqd’s development metrics

Putting this into perspective, cheqd ranks at the top of all the Cosmos-based chains for total commits for the month of December (as of 22/12/2022) with 874, and this wasn’t even our month with the highest number of commits (we reached 1,175 in November).

Graphic showing monthly commits of Cosmos chains

This is a huge testament to the dev and dev ops teams who have worked around the clock to bring our product visions to life, and we’d be nowhere without them!

In summary, 2022 was the year of building solid foundations, and this can often go under the radar. 2023 will be the year of functional applications, utility and deployments on cheqd.

In fact, we intend to start the year with a bang (hint hint you may have heard of a project with the codename Boots.)

cheqing out,

Ankur, Ross and Alex

cheqd’s tokenomics for SSI explained: part 4

cheqd-Tokenomics-4

Identity network transaction pricing

Tokenomics are typically documented and distributed via a dedicated whitepaper. However, since our tokenomics will be a constant iteration, we have been using blogs to explain these in an easier-to-digest format, with a summary available in the Governance Framework.

Part 1 of cheqd’s tokenomics covered the context/background, utility through parameters such as initial supply and inflation, and governance tokenomics. It’s now time to complete the picture with distribution/allocations.

Part 2 of cheqd’s tokenomics covered the initial distribution of the token.

Part 3 of cheqd’s tokenomics covered the planned architecture of the payment rails.

TL;DR

Tokenomics part four outlines measures to improve the tokenomic sustainability of the cheqd network. This is achieved through an increase in the network’s identity transaction pricing for DIDs and Resources (from gas price to more concrete dollar values) and the introduction of deflationary mechanisms in the form of burns. Essentially, the fee used for identity transactions will be split: a portion will go back to Validators and Delegators as block rewards, a portion will be burnt (destroyed) to reduce supply, and a portion will be designated to the Community Pool. The exact weighing of this split is for you, the community, to decide.

We are proposing to introduce two new mechanisms to the cheqd tokenomics:

  1. Identity transaction pricing: Identity transactions such as DIDs, credential schema, etc. writes will have a cost greater than gas which will increase rewards from the network as identity utility increases.
    – This is similar to Osmosis’ external incentive charges funding the community pool and rewards on Kujira stakers scaling with network utility use.
    – This has been achieved using genesis parameters which will be updated periodically to maintain stable pricing for users until we migrate to using oracles such as those provided by Umee.
  2. Burns: A proportion of the identity transaction charges will be burnt to establish equilibrium with the inflation on the network and target total supply returning to a total initial supply of one billion $CHEQ.
    – A Commonwealth discussion has been created to open up discussion on the proportion of any charges which should be burnt.
  3. Community pool parameter increase: The $CHEQ community pool recently funded work by Animo to reward them for their work on their Anoncreds demo on cheqd and continue their work on Anoncreds ledger independence. We believe the percentage of network rewards should be increased to encourage work such as this.
    – A Commonwealth discussion has been created to open up discussion on the proportion of network rewards which should be allocated to the community pool.

Identity transaction pricing and burns will augment the work we are doing on payments for self-sovereign identity/decentralised identity.

TLDR CHEQ Tokenomics update

We believe this is a big improvement to our original tokenomics.

What do you think? Join the discussion on commonwealth or in our community groups.

Introduction

It’s almost a year to the day since we successfully launched the cheqd mainnet. In that time, we have learnt a huge amount, especially regarding tokenomics which we are now proposing to update.

Currently (prior to the proposed update), writing a DID to cheqd mainnet only costs gas, which is approximately 0.004 $CHEQ. This is extremely cheap when compared to networks such as Sovrin, where writing a DID costs $10, especially taking into account the value we are bringing as a network, protocol and team.

Alongside this, $CHEQ is currently inflationary (where staking rewards come from), with only slashing, tombstoning or no-with-veto slashing providing any deflationary pressure.

We are proposing to update and improve both of these.

The best and easiest place to start is pricing.

Network Pricing

Per the introduction, current identity transactions on cheqd are too cheap for the value they create. We intend to move to the following pricing structure, which is still extremely competitive whilst matching the value created much closer.
cheqd benchmarked against Sovrin pricing

Note: Currently, schemas, credential definitions and revocation registry transactions are all priced the same since on-ledger they are all categorised as “resources”. Over time, these will likely become opinionated and differentiated according to the value they create and the burden they place on the ledger.

The keen-eyed of you will notice that the pricing above is in dollars, and obviously, cheqd mainnet runs in $CHEQ. In short, we are setting parameters to convert from US dollars to $CHEQ using baselined $CHEQ pricing at network update. For more details, please see the Implementation: Dollar to $CHEQ section below.

At current price levels ($0.03-$0.04), writing a DID will equate to 66.6–50 $CHEQ, which leads us to where these tokens will be distributed upon writes. This mechanism is similar to the mechanism Osmosis uses to fund the community pool through network charges for anyone creating external pool incentives. It also brings us towards the mechanisms built by the Kujira team for rewards to increase as the use of the network utility increases.

Distribution, rewards & burn

The tokens being charged by the network can either be distributed across stakers or burnt (or both according to a defined split):

  • Burn: Provides a deflationary mechanism to counter inflation on the network.
  • Distribution: Augments inflation-based rewards so APY will rise as network use does.

DISTRIBUTION AND REWARDS

If we assume that 50% of the tokens spent will be burnt, we have 50% being distributed to delegators, validators and the community pool.

Using the example in the diagram below, any block with a DID written within it is worth approximately ~four times a standard block where the block reward is ~12 $CHEQ. This means rewards on the network will begin to rise with adoption.

Current versus future staking rewards

It is also worth noting that whilst resource transactions (which include revocation writes and updates) are substantially cheaper than DID transactions, we are expecting them to be orders of magnitude more frequent. Sovrin mainnet has a ratio of approximately fifty revocation registry updates to every DID, which we believe will be on the extreme low-side as adoption scales.

Repeating a table we included in Tokenomics part 3 below, issuing credentials and hence interacting with revocation registries is significantly higher than DID transactions.

Identity transaction volume examples

Tokens which have been charged by the network for identity transactions but not burnt will be distributed according to stake on the network so, distributed across delegators, validators and the community pool.

BURN

As mentioned above, the network is currently inflationary only aside from slashing, tombstoning and no-with-veto having deflationary effects. Implementing a burn mechanism will bring the system into equilibrium.
Inflationary to equilibrium

The volume of tokens burnt will increase in the same way as distributions will, with the aim of bringing total supply back to one billion.

ALL TOGETHER

Bringing distribution, rewards and burn all together means the system will be dynamic and as the network use increases, both rewards and burns will increase, increasing APY whilst also bringing the total supply back towards one billion. As rewards increase, the $CHEQ community can prioritise APY or accelerating burns to drive total supply down to the original initial supply.
Current versus future $CHEQ supply

Implementation

DOLLAR TO $CHEQ

In the first version of identity transaction pricing, we are achieving dollar pricing through periodically adjusting on-ledger parameters , using baselined $CHEQ prices, via governance votes. Over time, we intend to migrate to oracles such as those provided by Umee to maintain constant dollar pricing for our partners. Until we have implemented oracles, we propose to update the parameters quarterly to keep pricing stable. Please see the Community and Governance section for more details.
Genesis parameters

BURN PERCENTAGE

As can be seen in the image above showing the genesis parameters which define the costs in $CHEQ, there is also a “burn_factor” variable which sets the percentage of the tokens charged for identity transactions which will be directly burnt. This can be adjusted through on-ledger governance votes according to the cheqd community preferences.

Community and Governance

Implementation of these mechanisms (pricing, distribution, and burn) will require on-ledger votes both to implement but also to periodically maintain these, especially before we implement pricing oracles to programmatically maintain stable dollar pricing for our partners.

We would welcome the community’s feedback on the burn_factor, specifically on whether they would prioritise burning more or increasing rewards on the network.

Our view is that a high burn_factor in the immediate term would be preferable since this minimises the amount of burning required in the future to return to the total initial supply (one billion) whilst maintaining rewards where they currently are but would welcome the community’s views and opinions. We’re looking forward to engaging here. To that end, we have begun a Commonwealth discussion here.

FREQUENCY

Until we build support for oracles so that dollar pricing can be maintained programmatically, we will need to periodically update the genesis parameters covered in Implementation: Dollar to $CHEQ. Currently, we believe this should be quarterly so that we do not need to hold governance votes every month which would put too much burden on both delegators and validators. However we would welcome feedback from the community.

COMMUNITY POOL

This also feels an opportune time to open a discussion on the percentage of network rewards allocated to the community pool, specifically to increase the percentage allocated and hence empower and reward more work like Animo’s work on demonstrating AnonCreds on the cheqd network via the community pool. We have therefore opened up another Commonwealth discussion here.

NEXT STEPS

We believe all of these changes will improve the sustainability and success of the cheqd ecosystem but, as always, want to hear the community’s feedback. As per the introduction, we are constantly learning here at cheqd and want to make sure we build on those learnings to achieve maximum success.

We want to open these changes up for discussion, specifically, the burn_factor which will define the proportion of network charges which will be burnt and how much will be distributed to delegators, validators and the community pool. We also want to open up a discussion to increase the proportion of rewards allocated to the community pool to further incentivise work like that being delivered by Animo.

As we launch these implementations onto the network, we are able to focus on building support for cheqd into more SDKs to allow our partners to access the network utility more easily as well as focusing on our USP: payments, which is what we’re most excited about.

Please head to the following Commonwealth discussions for each debate or our Telegram and Discord for more informal conversations:

We look forward to hearing from you.

Thanks,
The cheqd team

Disclaimers

The values and statements made above are indicative only and should not be construed as an offer or guarantee.

About this Document

This document sets out the aims and intentions of the core cheqd team for the payment models, based on the current state of its ecosystem in November 2022. These evaluations are subject to change for technical, legal, business and other reasons. We will make our best efforts to keep the entire cheqd community informed and updated with changes to this distribution strategy.

cheqd Governance

Integral to cheqd is the concept of decentralised Governance, explained in full detail in our Governance Framework. This is important because the content of the cheqd tokenomics and this distribution document are subject to change if the governance mechanism opts to make Major Network Changes. Such governance decisions are outside of the direct control of the core team. As such, changes may affect (among other things) the token ($CHEQ) price , the specifics of token distribution and the network parameters.

Legal Uncertainty as a Risk Factor

There is underlying legal uncertainty in the nature of blockchain projects due to how quickly the industry is evolving and how legal regulations and frameworks need to adapt to keep up. For this reason, it is reasonably foreseeable that there will be further guidance and regulations on digital assets, cryptocurrency, Decentralised Autonomous Organisations (DAOs) and digital identity going forward. cheqd’s core team has made the best efforts to build cheqd in a generative way to develop alongside updates in the law. This notwithstanding, there is still a surface area of risk, where future or existing legal regulations could have a negative effect on the proper functioning of the project and on the value of $CHEQ.

No regulatory authority in Singapore, including the Monetary Authority of Singapore, has reviewed or approved the $CHEQ tokens or any of cheqd’s documentation, including blog posts, website material, webinars, events, videos or other graphics (the “Information Material”). The acquisition of tokens is subject to a potential acquirer’s compliance with the laws and regulations in the jurisdiction they reside in.

Acquisition as a Risk Factor

The acquisition of $CHEQ tokens carries with it significant risks. Prospective acquirers should carefully assess and take into account such risks prior to acquiring $CHEQ tokens. cheqd’s initial core team and all of their collective past, present or future officers, directors, managers, employees, agents, advisors or consultants, or any other person (collectively, “cheqd”), expressly disclaims any and all responsibility for any direct or consequential loss or damage of any kind whatsoever arising directly or indirectly from: (a) reliance on any information contained in the Information Material; (b) any error, omission or inaccuracy in any such information; and © any action resulting therefrom. cheqd does not guarantee the accuracy of the statements made or conclusions reached in the Information Material and does not make, and expressly disclaims, all representations and warranties (whether express or implied by statute or otherwise). Past is not a reliable indicator of the future. The Information Material does not constitute advice, nor any recommendations or an offer, by cheqd or any of its affiliates and all of their collective past, present or future officers, directors, managers, employees, agents, advisors or consultants, or any other person, to any recipient of the Information Material. cheqd strongly encourages you to seek appropriate advice in respect of $CHEQ tokens and taking into account your personal circumstances, including but not limited to financial, legal, tax advice.

The Use Case as a Risk Factor

The $CHEQ token is worthless in itself and gains potential value within the cheqd ecosystem only through the protocol, its use and through continual use of Verifiable Credentials utilising cheqd payment functionality. Therefore, the success of the coin’s utility depends on multiple factors, including but not limited to, the health of the overall cryptocurrency market, the resilience of the cheqd protocol, and the success of Self-Sovereign Identity vendors in implementing real-world use cases.

$CHEQ must also be held within a wallet that can, ideally, consume Verifiable Credentials as well as $CHEQ tokens. This relies on the work of third parties to facilitate a functioning and healthy ecosystem.

In order to offer access to acquiring the $CHEQ tokens, it is essential that cheqd engages centralised or decentralised exchanges to list and facilitate the trade of tokens. The dependence on exchanges to recognise and list $CHEQ is a large risk vector. The likelihood of (specifically centralised) exchanges listing cheqd is directly correlatable to the size and activity of the cheqd community and the functional capabilities of the protocol and its governance model.

Security of Technology as a Risk Factor

Blockchains are not infallible to risk; nor is the storage of private keys for the purposes of owning $CHEQ and Verifiable Credentials. The wallet and the tokens it contains can only be accessed using the corresponding private keys. The owner of the tokens is solely responsible for keeping their private keys safe and protecting the safekeeping and protection of the private keys for the wallet against unauthorised access. While there will be safeguards put in place to help prevent such loss, the issue cannot be ruled out.

51% Proof of Stake attacks as well as rogue, malicious Governance proposals could be damaging to the proper functioning of cheqd as a protocol and as a community. It can also not be ruled out that blockchains generally, the cheqd Network, or other decentralised protocols become the target of attacks by hackers — alongside the further development of new technologies such as quantum computing.

cheqd update 1 year since network launch — next stop: payment rails

The foundations are set for cheqd’s first-of-a-kind decentralised identity payment rails

Co-authored by Ross Power (Product Manager), Alex Tweeddale (Product Manager & Governance Lead) and Ankur Banerjee (CTO/co-founder).

Making cheqd the most flexible, usable and interoperable network is integral for achieving wider adoption, as we pave the way for the first-of-its-kind decentralised identity payment rails. Recently we wrapped up the third quarter of 2022 and nearing just 1 year since network launch, we’re thrilled to have built the foundation for our partners to truly get to work on building their decentralised identity applications on the cheqd network, and we can’t wait to see what they create. Now, as partners begin to integrate their applications with cheqd, we’re heads down on building what we’re here for… cheqd’s Payment Rails for self-sovereign identity (SSI).

Introduction

Since we launched cheqd in 2021, we’ve been on a mission to build a stable, trusted and secure decentralised identity network (known within SSI as a Verifiable Data Registry). This is the cornerstone of SSI, acting as the ultimate trust machine required for the verifications of identity data.

Ultimately, it is the fundamental infrastructure needed for being able to offer our first-of-a-kind payment rails which we believe is the missing piece in the widespread adoption of Self Sovereign Identity.

Here’s a quick reminder of what the journey so far looks like…

cheqd — journey to credential payment rails

In a sense, you can think of everything we have been working on to date as:

  1. Feature parity with all other SSI networks;
  2. Identity functionality that goes beyond existing SSI networks; and
  3. The tooling and scaffolding to lay the foundations for payment rails for Verifiable Credentials.

Bringing this all together into a visual representation, using the Trust Over IP stack as we have done in the past, helps to make sense of what cheqd’s capabilities look like both now and what’s to come…

cheqd Capability Matrix

For more information on any of the above including tutorials for creating DIDs and Issuing Verifiable Credentials, head to our identity docs, or reach out to [email protected].

Going beyond the current SSI paradigm

With all the above in place, we now match many of the leading networks in the space, and go well beyond.

Not bad going for a company just over a year old — check out the image below as an example of how cheqd now stacks up against Hyperledger Indy:

cheqd vs Indy comparison — October 2022

To learn more about cheqd pricing and features comparison to Indy based networks, please email: [email protected].

Breaking this down into a quick summary, we can safely say that:

  1. Performance: We are much faster and more scalable for production environments, boasting a far greater transaction per second speed and number of transactions per block.
  2. Decentralisation: Owing to the number of nodes which can run on cheqd there is far greater decentralisation. This means that the network is more resilient to attack or malicious actors.
  3. Incentives: We include rewards for maintaining and using the network functionality using our native token: CHEQ. This is even prior to our payment rails being enabled.
  4. Extensibility: We have improved on the way Indy handles DIDs, keeping directly in line with DID Core. This enables cheqd to support the full remit of DID Core, since it does not need to convert anything like a ‘nym’ into a DIDDoc. It works using DIDs from the start.
  5. Innovation: We include far more flexible on-ledger resources, which we’ve built to be directly retrievable using standardised DID URLs. This enables a far greater range of resources to be anchored and easily referenced on cheqd
  6. Interoperability: We support a greater range of Verifiable Credentials and SDKs (JSON based JWT, AnonCreds and soon JSON-LD). Indy is closely tied to Hyperledger Aries libraries and struggles to work with other libraries owing to its specific transaction types.
 

From today, this means our existing partners will be able to begin using cheqd to its full potential, with feature parity with other networks and additional benefits.

Here’s a quick reminder of who are existing partners are:

cheqd partners — October 2022

Looking ahead to the future

As a network we have built fast and are now at a poignant moment for ourselves and partners as we witness products start to fully integrate with cheqd. Soon we’ll be seeing real applications using cheqd as their underlying network. Our demo with Animo shows a first in SSI with AnonCreds being issued on a non-Indy chain (check this out here).

It also means we can now move our attention to our primary objective and what we believe is the missing piece in the widespread adoption of Self Sovereign Identity — a commercial model that works for all parties.

Therefore, over the next 6 months, our roadmap is largely broken down into two streams:

  1. Integrating with SSI networks and onboarding them onto cheqd for existing clients and identity use cases
  2. Completing the research, development and implementation of payment functionality for revocation statuses and eventually for Verifiable Credentials.
cheqd partners — October 2022

Like always, we’d love to hear your thoughts on our writing and how resources on-ledger could improve your product offering. Feel free to contact the product team directly — [email protected], or alternatively start a thread in either our Slack channel or Discord.

AnonCreds Indy-Pendence: Part Two

Part 2: Bringing cheqd AnonCreds to life with Animo Solutions in Aries Framework JavaScript

Co-authored by Alex Tweeddale (Product Manager at cheqd), Ross Power (Product Manager at cheqd), Timo Glastra (CTO, co-founder at Animo), Berend Sliedrecht (Software Engineer at Animo).

Read part 1 here.

Introduction

In our previous blog we explained how we’re using cheqd’s on-ledger resources module to decouple AnonCreds from Hyperledger Indy and natively support AnonCreds and AnonCreds Objects on cheqd.

This work has laid the foundation for the next piece of the puzzle, bringing cheqd AnonCreds to life with easily accessible and usable Software Development Kits (SDKs).

Over the past few months we have been collaborating with Animo Solutions to support AnonCreds on cheqd within Aries Framework JavaScript. We are thrilled to announce that we have achieved this goal. Via this integration, users will be able to issue, verify and present AnonCreds with cheqd DIDs, and with AnonCreds Objects written as cheqd Resources, identifiable via DID URLs.

Showcasing AnonCreds on cheqd

During the demo we co-hosted with Animo at their office in Utrecht as a pre-event for Rebooting the Web of Trust (RWoT) on the 19th September 2022, we were able to show a full end-to-end journey of Ankur, our CTO, using AnonCreds. You can also watch a demo of this, here.

As you’ll see in the video, using a custom version of Animo’s self-sovereign identity demo we were able to showcase:

  1. AnonCreds issuance: Ankur gets his Animo identity for his name, date of birth and address as a fully functional AnonCred on cheqd.
Accepting Animo Identity AnonCred Credential into identity wallet

2. AnonCreds presentation and verification: Ankur signs up to attend the RWoT conference using his Animo identity AnonCred which is verified against the cheqd network.

Signing up for RWoT using Credentials
Connecting to RWoT to sign up for conference
A Credential request from RWoT for Ankur’s Credentials

3. AnonCreds issuance: Ankur receives a RWoT AnonCred for his entry to the conference.

Accepting the RWoT Credential sent to Ankur

4. AnonCreds presentation and verification: Ankur presents his RWoT AnonCred to gain access to the conference.

Presenting the RWoT as an AnonCred to attend the conference

Under the hood, you can check out the schema and credential definitions used for this AnonCred, which are identifiable using a DID URL, and stored as cheqd resources, via our DID Resolver.

Animo Identity schema:

Animo Identity credDef:

RWoT schema:

RWoT Credential Definition:

Integration into Aries Framework JavaScript

Aries Framework JavaScript (AFJ) is a framework that enables users to quickly and easily issue, hold and verify Verifiable Credentials. The main goals of AFJ are:

  • Interoperability between all the Aries implementations,
  • Usability for non-SSI developers and to remain agnostic of the credential format or DID method that is used and to lead the way in terms of interop.

In the recent months AFJ has heavily been expanding into a more modular and “less specific” framework. The integration with cheqd is a prime example of this, being the first true showcase of anchoring AnonCreds on non-Indy ledgers. Supporting more credential formats, ledgers and DID methods is crucial and essential to the continual development of AFJ.

How Animo leveraged the cheqd SDK to accelerate the integration into AFJ

One of the catalysts for Animo to support AnonCreds on cheqd was the release of cheqd/SDK in August, which was integrated into the Veramo SDK for cheqd. The Veramo SDK for cheqd was built in a modular fashion, which made it a very useful frame of reference for integrating cheqd into AFJ, and making it easier to leveraging the architectural design that the cheqd team put together.

Looking ahead

To continue the work to decouple AnonCreds from Hyperledger Indy, Animo is currently raising funds to fully implement Ledger Agnostic AnonCreds in AFJ and ACA-Py with cheqd. cheqd and Animo are also working closely with Esatus to support the development of Aries Framework .NET. This means, over the coming months users will be able to interact with cheqd and build their identity applications in any of the key SDKs they already use, whether this is AFJ, ACA-Py, Veramo or .NET. The image below provides a visual aid to where things are currently at:
The cheqd “stack” and tooling at different technical layers

Animo and cheqd continue to collaborate in this effort. The cheqd team are continuing to offer support for widening the SDKs available, for example working on a Universal Registrar Driver which will speed up the ACA-Py development. cheqd are also seeing the community get behind these efforts, with an new initiative to utilise the Community Pool funds to help financially support the progress.

AnonCreds Indy-Pendence: Part One

PART 1: DECOUPLING THE RELIANCE ON HYPERLEDGER INDY AND CREATING MORE EXTENSIBLE ANONCREDS OBJECTS WITH CHEQD.

Co-authored by Alex Tweeddale (Product Manager & Governance Lead), Ross Power (Product Manager), and Ankur Banerjee (CTO/Co-founder).

Read part 2 here.

Introduction

🚀 We are very excited to announce that the on-ledger resources feature released on cheqd mainnet allows for developers to support AnonCreds natively on the cheqd network.

Supporting AnonCreds on cheqd is a landmark achievement, since they have previously been tightly coupled with Hyperledger Indy chains. We are the first network to successfully decouple this dependency.

cheqd now provides support for AnonCreds, and in doing so, it remains compliant with W3C DID Core Spec, enabling Schemas, CredDefs, Revocation Registry Definitions and Revocation Registry Entries to be created using on-ledger resources, identifiable via DID URLs. This work is seminal in creating a broader ecosystem-agnostic ledger-layer, which supports greater interoperability for self-sovereign identity (SSI).

What are “AnonCreds”?

AnonCreds are a type or “flavour” of Verifiable Credentials that are utilised predominantly by Hyperledger Indy for ledger code and interactions, Hyperledger Ursa for cryptographic libraries, and the Hyperledger Aries codebase for agent, wallet, and credentialing code.

AnonCreds are now widely adopted, through organisations, such as the Government of British Columbia, IDunion and the IATA Travel Pass.

We carried out a survey earlier in 2022, finding that AnonCreds constituted the highest adopted (or roadmapped) Credential type amongst our respondents in 2022:

  • 45.9% AnonCreds;
  • 40.5% JSON based JWT;
  • 40.5% JSON-lD with BBS+ signatures; and
  • 32.5% JSON-LD.

(The percentages represent the percentage of respondents who selected the Credential type to support in 2022).

The respondents here were largely partners of cheqd. Therefore, to fully support all our partners and their existing clients within our network, we needed to build a way to support AnonCreds.

Why are AnonCreds a contentious issue?

For anyone in the self-sovereign identity (SSI) community, there is no avoiding the fact that AnonCreds divide the opinion of the community.

AnonCreds were originally designed to provide additional privacy benefits, compared with JSON and JSON-LD based Verifiable Credentials. To achieve these privacy benefits, AnonCreds utilise a series of bespoke technical components, including:

  1. Camenisch-Lysyanskaya (CL-Signatures) to encode individual claims for the purpose of enabling selective disclosure.
  2. Link secrets written into Credential Definitions, used when issuing AnonCreds to: (a) bind the issued Credentials to a particular holder; and (b) enable the holder to present a Zero-Knowledge Proof to a verifier without using a correlatable identifier.
  3. Hyperledger-Indy specific transaction syntax for on-ledger schemas, credential definitions, revocation registry definitions and revocation registry entries.
  4. Cryptographic accumulator deltas on-ledger, compiled into off-ledger ‘tails files’, for the purpose of asserting proofs of non-revocation, while maintaining privacy for AnonCreds holders.

These bespoke technical components afford AnonCreds a degree of ingenuity; but it comes at the cost of interoperability.

Vendor Lock-in

A bit like how Apple products only really work with other Apple products; AnonCreds only really work with Hyperledger Indy, and are largely tied to Hyperledger Aries libraries to be issued and consumed.

Image comparing AnonCreds and Apple compatibility. Source.

Historically, AnonCreds cannot be written to other Layer 1 Utilities, since Credential Definitions and CL-Schemas are custom Indy-specific transactions which are not conformant with W3C DID Core. This shoehorns adopters into a particular tech stack, which although open source, is largely reliant on the Indy/Aries community for updates, since there is no formalised Standard approved by a reputable international body like IETF or W3C. It is worth noting, however, that AnonCreds v1 is being proposed as a Standard and is in the process of being taken to the Internet Engineering Task Force (IETF).

Scalability

The use of ZKP-CL signatures provides AnonCreds benefits from a privacy perspective, yet, it also requires the computation of very large files which can lead to inefficiencies when used at scale in production environments.

Kaliya Young’s recent blog on Being “Real” about Hyperledger Indy & Aries / Anoncreds highlights many of the scalability issues around CL-Signatures well.

Similarly, the “tails files” used in Indy revocation suffer from similar inefficiencies. Each “tails file” can contain up to 20,000 revocation entries; and in a highly utilised ecosystem, there may be large amounts of these tails files, of 20,000 entries archived. On making a request of non-revocation and querying a tails file of this size, it may take a much longer time than usual to return a proof, creating a slower user experience than standard centralised models.

Owing to the benefits, as well as the tradeoffs, we previously concluded that AnonCreds in their current format have led to a degree of short-termism and long-termism within the community. Vendors with clients knocking on their door and asking for a product tomorrow are swaying towards short-term solutions which work now (such as AnonCreds which contains privacy-preserving revocation and the capability for predicate proofs).

Whereas, enthusiasts and SSI visionaries are looking at a longer-term vision of harmonisation and wide-barrelled interoperability (such as JSON-LD with BBS+ signatures or even AnonCreds V2 with BBS+ signatures). This is because BBS+ signatures provide a lot of the same benefits as AnonCreds (CL signatures), but with much smaller file sizes. Nonetheless, at cheqd we have acknowledged that there is a value in supporting both types of Verifiable Credentials.

Supporting AnonCreds on cheqd

Our first port of call in supporting AnonCreds was differentiating what makes AnonCreds distinct from other types of Credentials in terms of what goes on the ledger, and looking at ways that we could accommodate for those differences using cheqd functionality.

Decoupling AnonCreds from Indy

The key features of what makes an AnonCred exist at two distinct levels:

  1. Ledger level: What must be written to a verifiable data registry for AnonCreds to be created and functional in practice?
  2. Credential and SDK level: What cryptographic techniques must be employed within an SDK to give AnonCreds their privacy-preserving features?

For the existing AnonCreds stack, on Hyperledger Indy, these two levels can be represented by Figure 1 below:

Figure 1: How Indy and Aries interact for AnonCreds support

Here, Hyperledger Indy is important for supporting AnonCreds since it has to-date been the only identity-blockchain which can natively support DIDs, Schemas, Credential Definitions (and optional Revocation Registry) transactions written to the ledger.

Our hypothesis in supporting AnonCreds was that if we were able to replicate the functionality of the Ledger layer, the SDK and credential layer would be able to fit on top, without any wholesale changes in client applications that currently use AnonCreds. This would decouple the dependency on Hyperledger Indy, creating a much broader and widely interoperable ecosystem for AnonCreds.

Figure 2: How cheqd and Aries theoretically can interact for AnonCreds support

However, we did not want to build a carbon copy of Hyperledger Indy. As previously discussed, Hyperledger Indy is contentious for multiple reasons, scalability, and interoperability.

For this reason, we wanted to explore the option of supporting Credential Definitions and Schemas on-ledger, but in a way which directly conformed with W3C DID Core and with greater scalability.

Composition of AnonCreds Object identifiers

To reach a composition of Schemas, CredDefs, RevRegDefs and RevRegEntries on-ledger which is W3C DID Core compliant, it is important to understand exactly how these bespoke transactions are composed on Hyperledger Indy, and why this did not achieve conformance with the standard.

What goes into a Legacy AnonCreds ID?

Historically, AnonCreds Identifiers for scheamas, CredDefs and Revocation writes have been composite strings, recognised only by Hyperledger Aries and Indy applications.

For example, AnonCreds on-ledger schema_id, contain the following information:

  • Publisher DID: is a string. The DID of the Schema Publisher.
  • Object type: An integer denoting the type of object. 2 is used for Schemas.
  • Name: is a string, the name of the schema
  • Version: is a string, the version of the schema in semver format. The three part, period (“.”) separated format MAY be enforced.

The schema_id therefore was formatted in the following way:

<publisherDid>:<objectType>:<name>:<version>

For example, a Legacy AnonCreds schema_id could be:

7BPMqYgYLQni258J8JPS8K:2:degreeSchema:1.5.7

The problem with this approach is that it:

  1. Ties AnonCreds to Hyperledger Indy, since Indy is the only possible chain which can provide all the required content for schemas, CredDefs and Revocation writes;
  2. Limits client applications to expect a very specific identifier format for AnonCreds Objects.

Therefore, to decouple AnonCreds from Hyperledger Indy it has been important to move away from this identifier format and to create a more extensible approach to providing client applications the required information.

AnonCreds Specification expansion

Recently, the AnonCreds specification has evolved to allow different ‘AnonCreds Object Methods’ which do not necessarily need to conform to the same representation as the legacy identifiers.

This approach gives different Object Methods the flexibility to define their own AnonCreds Object Identifier formats. This is a welcome change which provides greater flexibility in how AnonCreds Objects may be represented on different chains. Using this extension of the AnonCreds specification, cheqd has been able to create its own AnonCreds Object Method.

cheqd AnonCreds Object Method

In an earlier blog, we discussed our approach to resources on cheqd at length and highlighted the benefits of using on-ledger schemas, compared to other existing solutions such as schema.org.

cheqd AnonCreds Objects build directly on this approach, in that we wanted to create an identifiable path to each specific AnonCreds Object using DID URLs.

Example of cheqd DID URL for schema resource

We have now created an extensive body of documentation to explain how we can support AnonCreds on cheqd, including how we represent each of the AnonCreds Objects using DID Core conformant DID URLs. See here for: Central to this approach has been removing all dependencies on Hyperledger Indy from the core “data” contents of an AnonCreds Object, and moving anything specific to a particular network to “AnonCreds Object Metadata”. This mimics how DID Document representation is able to support multiple different approaches, where anything network specific should be represented within the “DID Document metadata” section, rather than in the core body of what is returned.

Conclusion and next steps

Through the use of the resource module, cheqd is able to support all AnonCreds specific Objects within the parameters of DID Core, by identifying each Object and future Object versions with DID URLs.

This creates an elegant platform for AnonCreds to be issued on-top, which will allow cheqd to support any SSI vendor in the marketplace at a technical level. We have started with integration into Aries Framework Javascript (AFJ) and are looking to expand into Aries Cloud Agent Python (ACA-Py) as well as Aries Framework .NET. Read more about our plans in Part 2!

We look forward to working with our partners and the broader SSI community to see how we can innovate together using this new functionality, and decouple AnonCreds dependencies further.

As always, we’d love to hear your thoughts on our work and how resources on-ledger, or AnonCreds on cheqd could improve your product offering. Feel free to contact the product team directly — [email protected], or alternatively start a thread in either our Slack channel or Discord.

AnonCreds Indy-Pendence was originally published in cheqd on Medium, where people are continuing the conversation by highlighting and responding to this story.

Building decentralised Identity applications on cheqd with Veramo

cheqd-Blog-Veramo_SDK_for_cheqd-2022

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 ([email protected]).

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 ([email protected]).

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 protected], or alternatively start a thread in either our Slack channel or Discord.

Our Approach to Resources on-ledger

USING THE CAPABILITIES OF THE DID CORE SPECIFICATION FOR STANDARDS-COMPLIANT RESOURCE LOOKUP

This blog post has been co-written by Alex Tweeddale, Ankur Banerjee and Ross Power.

Introduction

Since the beginning of Q2 2022, cheqd has been assembling the building blocks for anchoring “resources” to the cheqd network.

The concept of resources in self-sovereign identity (SSI) ecosystems is not new, however, as we will discuss throughout this blog post, existing approaches to resources in SSI oblige adopters to make compromises between security, availability and interoperability. We first noticed this when we were looking at how we could securely reference credential schemas, something we will expand on throughout this post.

Our objective in building resources on cheqd is to improve the way resources are stored, referenced and retrieved for our partners and the broader SSI community, in line with the existing W3C DID Core standard.

Within this blog, we will answer three simple questions:

  1. What are resources?
  2. What are the problems with the way resources are stored?
  3. How have we implemented resources on cheqd?

By answering these questions, we aim to provide a conceptual understanding of why we have chosen this approach, how it improves on existing approaches, and the timelines for this being implemented on cheqd in practice.

In self-sovereign identity (SSI) ecosystems, “resources” are often required in tandem with W3C Verifiable Credentials, to provide supporting information or additional context to verifiers receiving Verifiable Presentations.

For example, common types of resources that might be required to issue and validate Verifiable Credentials are:

Schemas

Describe the fields and content types in a credential in a machine-readable format. Prominent examples of this include schema.org, Hyperledger Indy schema objects, etc. You can think of them as a template for what is included in a Verifiable Credential.

Below is an example of a schema.org residential address with full URLs:

{
 "@type": "http://schema.org/Person",
 "http://schema.org/address": {
   "@type": "http://schema.org/PostalAddress",
   "http://schema.org/streetAddress": "123 Main St.",
   "http://schema.org/addressLocality": "Blacksburg",
   "http://schema.org/addressRegion": "VA",
   "http://schema.org/postalCode": "24060",
   "http://schema.org/addressCountry": "US"
 }
}

This might also take the form of evidence schemes, which describe additional information about the processes used to validate the information presented in a Verifiable Credential in common, machine-readable format.

Revocation status lists

Allow recipients of a Verifiable Credential exchange to check the revocation status of a credential for validity. Prominent examples of this include the W3C Status List 2021 specification, W3C Revocation List 2020, Hyperledger Indy revocation registries, etc.

Visual representations for Verifiable Credentials

Source: Overlays Capture Architecture Specification Version 1.0.0

Although Verifiable Credentials can be exchanged digitally, in practice most identity wallets want to present “human-friendly” representations. A resource, using something like Overlay Capture Architecture (OCA) may enable a credential representation to be shown according to the brand guidelines of the issuer, internationalisation (“i18n”) translations, etc. Such visual representations can also be used to quickly communicate information visually during identity exchanges, such as airline mobile boarding passes.

Source: British Airways MediaCentre— Multiple Boarding Passes Land on BA APP

In the example above from British Airways, the pass at the front is for a “Gold” loyalty status member, whereas the pass at the back is for a “standard” loyalty status member. This information can be represented in a Verifiable Credential, of course, but the example here uses the Apple Wallet / Google Wallet formats to overlay a richer display.

While it’s useful to have digital credentials that can be verified cryptographically, the reality is that there are often occasions when a quick “visual check” is done instead. For example, when at an airport, an airline staff member might visually check a mobile boarding pass to direct people to the correct queue they need to join. The mobile boarding pass does get scanned at points like check-in, security, boarding etc., to digitally read the information, other scenarios where this is not done are equally valid. However, most Verifiable Credential formats do not explicitly provide such “human-friendly” forms of showing the data held in a credential.

Documents

More broadly, there are other types of resources that might be relevant for companies beyond SSI vendors, that want a way to represent information about themselves in an immutable and trustworthy way.

Many companies require documentation such as Privacy Policies, Data Protection Policies or Terms of Use to be made publicly available. Moreover, Trust over IP (ToIP) recommends making Governance Frameworks available through DID URLs, which would typically be a text file, a Markdown file, PDF etc.

Logos

Companies may want to provide authorised image logos to display across different websites, exchanges or block explorers. Examples of this include key-publishing sites like Keybase.io (which is used by Cosmos SDK block explorers such as our own to show logos for validators) and “favicons” (commonly used to set the logo for websites in browser tabs).

The current uses for resources are therefore very broad across the SSI ecosystem, and in addition, for other companies that may want to use DIDs to reference relevant information on ledger. For this reason, it is essential that the SSI community strengthens the way that resources are stored, referenced and retrieved in SSI ecosystems.

What are the problems with the way resources are stored?

There are multiple approaches to decentralised identity which rely on centralised infrastructure across different technical layers. Decentralised Identifiers (DIDs): are often stored on ledgers (e.g., cheqd, Hyperledger Indy, distributed storage (e.g., IPFS in Sidetree), or non-ledger distributed systems (e.g., KERI). Yet, DIDs can be stored on traditional centralised-storage endpoints (e.g., did:web, did:git).

Predominantly, however, the issue of centralisation affects resources providing extra context and information to support Verifiable Credentials. These resources, such as schemas and revocation lists, are often stored and referenced using centralised hosting providers.

Using centralised hosting providers to store resources may have a significant difference in the longevity and authenticity of Verifiable Credentials. For example, a passport (which typically has a 5–10 year validity) issued as a Verifiable Credential anchored to a DID (regardless of whether the DID was on-ledger or not) might stop working if the credential schema, visual presentation format, or other necessary resources were stored off-ledger on traditional centralised storage.

This section will therefore explain the pain points that should be addressed to improve the way resources are stored, managed and retrieved in SSI ecosystems.

SINGLE POINTS OF FAILURE

Even for highly-trusted and sophisticated hosting providers who may not present a risk of infrastructure being compromised, a service outage at the hosting provider can make a resource anchored on their systems inaccessible.

The high centralisation of cloud providers and history of noteworthy outages clearly demonstrates why we should not host resources on centralised cloud storage in production environments. In Q1 of 2022, the three largest players in the cloud (AWS, Google Cloud, Microsoft Azure) dominated with 65 per cent in nearly all regions (outside of China).

Source: CoinTelegraph “The future of the internet: Inside the race for Web3’s infrastructure’

Furthermore, beyond cloud providers, there are other events that exemplify the issuers relying on larger players. The Facebook outage of 2021 (shown in the graph below) took down apps that used “Login with Facebook” functionality. This highlights the risks of “contagion impact” (e.g., a different Facebook outage took down Spotify, TikTok, Pinterest) of centralised digital systems — even ones run by extremely-capable tech providers.

Source: Why Facebook, Instagram, and WhatsApp All Went Down Today

Ed Skoudis, president of the SANS Technology Institute amusingly commented on this issue:

“In the IT field, we sometimes joke about how we spend 15 years centralizing computing, followed by 15 years decentralizing, followed by another 15 years centralizing again,” he said. “Well, we have spent the past 10 years centralizing again, this time on [the] cloud.”

Likewise, with decentralised identity, there has been excellent work to decentralise, with standards that remove the need for centralised intermediaries — notably around Verifiable Credentials and the decentralised trust provided by DID Authentication. Yet, all of this excellent work may be eroded in practice, unless every component of an SSI ecosystem is able to maintain an equivalent level of decentralised trust. Resources are currently an area that has been centralised for the sake of convenience.

LINK ROT

“Link rot” happens when URLs become inaccessible over time, either because the endpoint where the content was stored is no longer active, or the URL format itself changes. The graph below from an analysis by The New York Times shows the degradation over time of URLs.

Source: What the ephemerality of the Web means for your hyperlinks

For this reason, keeping an up-to-date version of the links themselves is crucial. Furthermore, a study of link rot found at least 66.5% of links to sites in the last 9 years are dead. This can have an adverse impact on the digital longevity of Verifiable Credentials if there’s “link rot” in the resources necessary to process the credential. For this reason, projects such as The Internet Archive’s Wayback Machine exist to snapshot digital ephemera before they are lost forever.

Source: Ahrefs Study on Link Rot

This illustrates that link rot can affect a significant proportion of links in a relatively small amount of time, and once again, looking at how resources are currently stored in SSI ecosystems, if the resource locations are moved and the links are broken, the Verifiable Credentials relying on these resources become unusable. Therefore, resources, once defined, should be architected to be used and referenced indefinitely, without being changed.

TAMPER-EVIDENT CHANGES AND CENSORSHIP RESISTANCE

Finally, the centralised way that resources are currently stored and managed is not immutable, and as a result, it is liable to tampering. For example, if a hosting provider is compromised, or if malicious actors are working for the company, resources may be changed and previous resource versions may be purged from the central database.

As we move towards a new web infrastructure with Web 3 (and beyond…), and as more projects leverage blockchain and distributed ledgers, it’s important not to port the previous issues of the web, and instead find novel ways to better manage information, with longevity in mind. This is why at cheqd, we have decided to redesign the way resources are captured on the ledger.

How have we implemented resources on cheqd?

cheqd’s on-ledger resources can be defined as data files, stored in an organised collection and common format on a distributed ledger. As such, these resources will be highly available, resilient to attack and with immutable archives showing expired, revoked or deprecated resources.

Resources, using the same method of referencing may also be stored off-ledger.

When working towards this objective, we laid out a set of requirements we benchmarked our implementation against:

  1. Resources must be referenceable via immutable and uniquely identifiable using Decentralised Identifiers (DIDs).
  2. Resources can be stored on-ledger if they are sufficiently small enough. (If a resource is too large to be stored on-ledger, e.g., an image or video file, they should still be referenceable via their DIDs.)
  3. Resources must be versioned, with each version easily accessible in the future.
  4. Resources can be indexed, to promote reuse of resources.
  5. Existing DID resolvers should be able to either resolve resource URLs or get references to them without significant modification to how they currently function and behave.
  6. There should be an ability to mark resources as deprecated or superseded by new versions.;
  7. On-ledger resources must fit within the existing W3C standards for decentralised identity;
  8. Resources should be assigned a media type, to allow client applications to apply logic to what resources they expect and want to consume.

Is this similar to Hyperledger Indy’s approach to Schemas and CredDefs on-ledger?

We heavily considered the schema implementation used by AnonCreds on Hyperledger Indy in our design phase, since it tackles many of the problems highlighted above. However, the issue we have with schemas and Credential Definitions for AnonCreds is that they are very tightly coupled with Indy-based ledgers. Both schemas and Credential Definitions, require Indy-specific transactions, limiting the interoperability of these Credentials outside of Indy ecosystems.

Our implementation will enable resources on the ledger to be far more interoperable, beyond cheqd, since the architecture does not tie resources to a specific ledger, and builds within the parameters of the W3C DID Core Spec. This means that partners using AnonCreds and proponents of JSON or JSON-LD Verifiable Credentials can benefit from this approach. We have tried to design our architecture as flexible as possible to allow new resource types to be created, without any vendor lock-in.

We will be writing a specific blog post on how cheqd supports AnonCreds and Credential Definitions using its resource architecture.

On-ledger resources on cheqd

To explain the details of how we have structured this, we will start by breaking down the high-level overview diagram shown in figure 1.

Figure 1: High-level architecture flow for resources on-ledger

The diagram above shows multiple layers to this architecture:

ISSUER DID DOCUMENT

This Issuer DID Document is created as per usual. It may be updated to reference a Collection DID Document within the service section, and also may specifically link to a Resource using a service endpoint.

This allows an Issuer to explicitly cite which resources it uses when issuing Verifiable Credentials.

COLLECTION DID DOCUMENT

This Collection DID Document references an on-ledger Collection, using the unique identifier of its DID URL, which is the same as the Collection ID. It also acts as the keys and gating mechanism for controlling, updating and managing on-ledger resources within that Collection.

The same verification methods listed in this DID Document are used to authenticate with and manage the resources within the collection it refers to.

RESOURCE COLLECTION

Resource Collections are a way of organising resources into different versions or media types. This enables new resources to be added to a collection, and old resources to be indexed and still be retrievable through querying a collection by version time.

The Collection ID is the same as the unique identifier of the Collection DID Document’s DID URL and ‘id’.

RESOURCE

The resource contains the actual data of the resource itself, including its name and media type. A resource is directly retrievable through the service endpoints of both the Collection DID Document, and optionally within an Issuer DID Document.

The full architecture including specific layer-by-layer details about how each component references and links to the other can be found in the Resources section of our Identity Documentation.

REFERENCING RESOURCES WITH DIDS

We decided to identify and reference each ‘resource’ with its own unique identifier, within a ‘collection’ tied to a DID. This enables us to reference a resource in the following way:

Figure 2: resource configuration via DIDs

Each Collection and Resource is identified with its own Universally Unique Identifier (UUID). However, the Resource Collection ID is also the same as the unique identifier of the DID that controls the collection.

UTILISING THE ‘SERVICE’ SECTION

We decided to reference ‘resources’ by using the ‘service’ section, rather than creating a new section in a DIDDoc for multiple reasons:

  1. While the DID Core spec technically allows creating new sections, most client apps expect the specific default/minimum list, and would not know how to handle the contents within a new section.
  2. Service Types are already designed to be extended. It is a well-trodden and well-recognised part of DID Documents. For example, the DID Spec Registries currently list two service types: LinkedDomains and DIDCommMessaging

We used the LinkedDomains service type in our first DID to directly reference an image hosted on IPFS using a DID.

{
"id": "did:cheqd:mainnet:zF7rhDBfUt9d1gJPjx7s1JXfUY7oVWkY#non-fungible-image",
"type": "LinkedDomains"
"serviceEndpoint": "https://gateway.ipfs.io/ipfs/bafybeihetj2ng3d74k7t754atv2s5dk76pcqtvxls6dntef3xa6rax25xe",
}

If you look up the IPFS link above through any valid IPFS gateway, you’ll find our Data Wars poster.

Likewise, we are using the ‘service’ section of DID Documents to reference specific resources:

{
“id”: "did:cheqd:mainnet:46e2af9a-2ea0–4815–999d-730a6778227c#DegreeLaw"
"type": "CL-Schema",
"serviceEndpoint": "https://resolver.cheqd.net/1.0/identifiers/did:cheqd:mainnet:46e2af9a-2ea0-4815-999d-730a6778227c/resources/688e0e6f-74dd-43cc-9078-09e4fa05cacb"
}

Through linking to the resource this way it is highly accessible and easily consumable for client applications, DID resolvers and developers. Furthermore, if a client app doesn’t understand a service section, most of them skip and ignore it rather than throwing an error and causing the system to fail, potentially catastrophically.

Creating and retrieving a resource

In order to create a resource on the ledger, the following steps laid out in figure 2 should be followed:

Figure 3: Creating and retrieving a resource on cheqd

Writing resources to the ledger

CREATE COLLECTION DID DOCUMENT

Anchor Collection DID and associated Collection DID Document to the ledger through a create DID operation

CREATE RESOURCE

Anchor Resource to the ledger and specify Collection ID as the same identifier as the unique identifier from the Collection DID Document. Sign createResource transaction with the same private key as the verification method listed in the DID Document

UPDATE COLLECTION DID DOCUMENT

Update Collection DID Document and reference the Resource within the ‘service’ section

This Collection DID Document and Resource may also be referenced within an Issuer DID Document, as shown in figure 1.

Retrieving resources from cheqd ledger

QUERY LEDGER FOR RESOURCE

Through referencing resources using DIDs, as explained above, it makes it far easier to query historic or deprecated resources using DID resolvers and DID URL dereferencing,

For example, the following request could be made to a resolver to fetch a resource from a specific point in time:

https://resolver.cheqd.net/1.0/identifiers/did:cheqd:mainnet:46e2af9a-2ea0-4815-999d-730a6778227c#degreeLaw?versionTime=2022-06-20T02:41:00Z

This may be incredibly powerful where a resource, such as a schema, has evolved over time, but you want to prove that it was issued using the correct schema at the point of issuance.

RETURN RESOURCE

Full Resource is returned including any data files attached.

Tutorials for creating a resource on-ledger can be found here on our identity documentation site. Further technical detail about creating resources can be found in our Architecture Decision Record 008.

How this improves the way resources are stored and retrieved

Through storing resources on ledger, referencing them through resolvable DID URLs, and authenticating them using DID Documents, the resources on-ledger will be:

HIGHLY AVAILABLE AND EASILY RETRIEVABLE

Resources are identified by a DID URL which allows them to be retrieved easily from a distributed ledger using existing DID Resolvers.

Using a distributed ledger like cheqd to store and index resources removes the problem identified by centralised systems creating single points of failure, such as schema.org.

Schemas, for example, would therefore become on-ledger resources, represented in the format of the following example:

Resource1
{
 "header": {
   "collectionId": "46e2af9a-2ea0–4815–999d-730a6778227c",
   "id": "688e0e6f-74dd-43cc-9078–09e4fa05cacb",
   "name": "DegreeLaw",
   "resourceType": "CL-Schema",
   "created": "2015–02–20T14:12:57Z",
   "checksum": "a7c369ee9da8b25a2d6e93973fa8ca939b75abb6c39799d879a929ebea1adc0a",
   "previousVersionId": null,
   "nextVersionId": "0f964a80–5d18–4867–83e3-b47f5a756f02",
   }
 "data": "<CLSchema.json containing ‘{\"attrNames\":[\"last_name\",\"first_name\"\"degree_type\"\"graduation_year\"\"degree_percentage\"]}>”
}

This schema could be resolved through a DID Resolver, with an input such as the following:

did:cheqd:mainnet:46e2af9a-2ea0–4815–999d-730a6778227c#degreeLaw?versionTime=2015–09–08T02:41:00Z

You can dive into further detail on the syntax of resources and how they can be retrieved within the Resources section of our Identity Documentation.

Controllable and self-attestable

Resources can be tied to DID Documents and control over resources can be exerted via the same verification method keys as those written into an associated DID Document.

This allows persons to authenticate with a DID Document to update or prove control of a Resource, which addresses the problem of tamper-proofing identified around centralised cloud providers.

Built to be consumed by client applications

Resources must specify a name, and resource type and compile into a media type, which provides specific information to any client application about what data format and syntax the data are expected to be retrieved in.

This allows client applications to apply business rules to what types of resources are expected, and which should be accepted, making resources far easier to be consumed by third-party software. This differs from existing Hyperledger Indy resources, which require the client applications to be familiar with Indy in order to process and consume Indy resources.

Conversely, our method gracefully allows “dumb” applications, that do not understand specific DID protocols, to still fetch and access a resource over HTTP/REST APIs. In addition, “smart” applications, that do understand these protocols, can process, query, and get their own resources from DID resolution and dereferencing.

Indexable

Resources are versioned with unique identifiers (UUIDs), allowing previous versions to be archived within a collection, and retrieved through querying a unique ID or a version time.

This mitigates the problem identified of link rot when using centralised storage systems since each version is archived immutably.

For more information, please refer to the section on Versioning and Archiving Resources in our identity documentation.

Conclusion

In building resources on-ledger, we want to avoid the risks associated with relying on centralised infrastructure for storing resources, while importantly, remaining conformant with W3C standards and avoiding ledger lock-in. We believe that we have achieved this compromise by enabling the management of resources through the use of DID Documents, identifying resources using DID URLs and retrieving resources using existing DID Resolvers. Not only does this work solve existing problems, but it opens the door for far more innovation using DIDs, including:
  • Fully identifiable and resolvable governance documentation and schemes on ledger, tied to DIDs and DID Documents
  • Full AnonCreds support on non-Indy ledgers (to be explained further in a future blog)
  • On-ledger revocation lists, where each tails file can be uniquely versioned and retrieved efficiently (this is our next priority roadmap item)
  • Logos and company information easily accessible on-ledger, referenced within that company’s DID
We look forward to working with our partners and the broader SSI community to see how we can innovate together using this new functionality, and properly securing SSI architecture in a decentralised end-to-end flow. As always, we’d love to hear your thoughts on our writing and how resources on-ledger could improve your product offering. Feel free to contact the product team directly — [email protected], or alternatively start a thread in either our Slack channel or Discord.

Our Approach to Resources on-ledger was originally published in cheqd on Medium, where people are continuing the conversation by highlighting and responding to this story.