The role of cheqd in Trusted Data markets

The role of cheqd in trusted data markets

A technical approach to building Trusted Data Markets, reducing the time-to-reliance and compliance costs in digital interactions.

Introduction

The “Trust Gap”

As discussed in “The Anatomy of a Trusted Data Market, the composition of “trust” is a complex and interpersonal relationship between two parties. It is predicated on more than the mere reliance on a particular party; namely, it involves an “extra factor”, including the perception of good faith and the willingness to act in a credible way.

However, when considering “trust” in a digital context, it becomes increasingly challenging. As opposed to an “interpersonal” relationship, digital trust is often a “pseudonymous” relationship. Here we approach what is widely regarded by academics as the “trust gap”; the de facto lack of the capacity to make an informed judgement on the “extra factor” to build “trust” beyond “mere reliance”.

Therefore, to build a functional Trusted Data Market with cheqd, we need to augment the requirement for this “extra factor” using a combination of trust-building technologies and techniques.

See: Camila Mont'Alverne, Sumitra Badrinathan, Amy Ross Arguedas, Benjamin Toff, Richard Fletcher, and Rasmus Kleis Nielsen. The Trust Gap: How and Why News on Digital Platforms is viewed more Sceptically versus News in General. 2022. University of Oxford. Reuters Institute.

Available at: https://reutersinstitute.politics.ox.ac.uk/

The Technical Components of a Trusted Data Market

  1. Decentralized Identifiers (DIDs)
  2. Verifiable Credentials (VCs)
  3. Trust Management Infrastructure (TMI) such as Trust Registries (TRs) or Status Registries (SRs).
  • Legitimacy established by DIDs
  • Integrity established by VCs
  • Reputability established by TMI
Technical Composition of Trusted Data
Technical Composition of Trusted Data

Legitimacy through Decentralized Identifiers

Decentralized Identifiers (DIDs) are a relatively new technical standard, ratified by the W3C as a formal recommendation in 2022, for uniquely identifying a particular entity in a digital domain. Each DID can be “resolved” to fetch a data file called a DID Document, which helps prove legitimacy in three ways:

Verification

DID Documents must contain signing keys, known as Verification Methods, which can be used to cryptographically sign other data files (such as Verifiable Credentials). If a DID and associated Verification Method is found referenced in another data file, that DID and it’s key can be challenged, and authenticated against, to prove that DID is in fact:

  1. Legitimate;
  2. Associated with a particular DID Document (discussed in point 2);
  3. Associated with any other DID-Linked Resource (discussed in point 3).

If a DID is proved to be legitimate, it is possible to infer that the data file signed by the DID has a higher level of trustworthiness.

Resolution

Resources

Integrity through Verifiable Credentials

Verifiable Credentials (VCs) are another type of data file, again formalised by the W3C as a standard, designed to ensure absolute integrity of the “claims” listed in the data file. A “claim” in this sense is an assertion about a particular entity; for example, this could be attesting to someone’s name, address, date of birth etc.

VCs are able to carry out this function because the “claims” contained in the credential are intrinsically verifiable through cryptographic “proofs”.

VCs dovetail well together with DIDs, since the “proof” embedded in the VC is able to be signed by DIDs and their associated Verification Method keys. This allows the VC “proof” to be challenged and authenticated against using the Public Key Infrastructure from the DID and associated DID Document.

Once the proof is embedded in the VC, the VC may also be serialised as a JSON Web Token (JWT) or use a Data Integrity proof (VC-DI), to create a representation of the Credential that is tamper-evident. This means that if any modification is made to the serialisation, the embedded “proof” will become unverifiable.

Commonly therefore, VCs are issued to a “holder”, who holds this in a data wallet, and these VCs are cryptographically signed by a DID of the issuing entity “issuer”. This enables the “holder” to prove to a third party that the Verifiable Credential has both:

  1. Legitimacy — since it is signed by a particular entities DID; and
  2. Integrity — since the cryptographic proof is tamper-evident.

Different cryptographic signature schemes can also be layered on top of VCs to provide additional benefits, such as:

  1. Selective disclosure: where only a selected subset of VC claims, or selected claims from multiple VCs, are presented in one tamper-evident format (e.g. SD-JWT).
  2. Zero-Knowledge Proofs (ZKPs): where a VC can use its legitimacy and integrity to prove a particular fact, in a yes/no challenge/response mechanism, without revealing the actual “claims” written into the VC (e.g. AnonCreds).

VCs are highly flexible in their design, with certain flavours being useful for specific use cases. However, each type maintains the same underlying focus on data integrity. This data integrity coupled with the legitimacy of DID authentication, is in many cases, enough for a verifier to build a level of “trust” in a digital interaction, reducing the time-to-reliance significantly.

Reputability through Trust Management Infrastructure

Trust Management Infrastructure (TMI) can be used to move the needle from “low/medium” trust digital interactions to “high” trust digital interactions. As such, this infrastructure may not always be required in a trusted data market — but may be relied upon when necessary.

DID-Linked Resources (DLRs) may be used to establish TMI in a decentralized way. Examples of common TMI for Trusted Data Markets are Trust Registries (TRs) which may ascertain whether a DID belongs to a trusted set; or Status Registries (SRs), which may be used to check if the VC status has been revoked or not. However, for the purposes of this paper, we will use TRs as the canonical TMI to explain the concept of reputability.

A TR is a data object where one entity publicly attests to the legitimacy of other entities. For example, a Health Regulator such as the Medicines and Healthcare products Regulatory Agency (MHRA) in the UK may create multiple trust registries of pharmaceutical manufacturers or wholesalers that are legally regulated to provide certain types of medicines, drugs or pharmaceutical products in the UK.

In the context of decentralised identity technology, TRs contain lists of DIDs pertaining to specific entities for a particular purpose. In the example above, MHRA could create a TR including the DIDs of each pharmaceutical manufacturer or wholesaler regulated to carry out a particular action.

Through resolving-to and parsing a TR, a verifier can traverse the DIDs and metadata that is listed to establish a root-of-trust and establish that the data they are receiving hits requisite levels of assurance for a specific governance framework.

TRs provides relying parties with additional assurance through this way of linking to a root-of-trust, resulting in:

  1. Reputability, since the “verifier” will be able to check that the “issuer” DID signing the “holder” VC is attested to by one or multiple other entities through a public TR; this layers on top of:
  2. Legitimacy (as previously discussed)
  3. Integrity (as previously discussed)

To conclude this section, the diagram below helps explain how the three technological components described in this section work in conjunction with one another — to build a comprehensive web of trust.

Interplay between DIDs, VCs and TRs

This diagram illustrates the following flows:

  1. A DID cryptographically signs a VC, which establishes Legitimacy and Integrity in the data the VC contains
  2. A VC references a TR (or other TMI), which establishes Legitimacy and Integrity that a TR is intended to be used by the verifier
  3. The TR provides additional information about the reputability of the DID, which establishes Legitimacy, Integrity and Reputability in the DID and signed VC which can be used to meet governance and compliance requirements.

Bridging the Trust Gap

  1. Legitimate, since it is attested to by a particular “issuer” (I)
  2. Cryptographically untampered because the VC data model enables proof serialisation and data integrity
  3. Reputable, since one or multiple TRs can be referenced to where the issuer’s DID is attested to by third parties
  1. Other parties they are interacting with meet compliance requirements for their industry or use case, creating trusted markets;
  2. They themselves meet compliance requirements, as they can demonstrably assure third-party regulators that the data they receive from other parties has absolute legitimacy, integrity and sufficient reputability for a particular governance framework.

Making the Market

  • Legitimacy, via the authentication of a DID = Free
  • Integrity, via the verification of a VC = Free
  • Reputability, via the verification of a TR (or other TMI) = Paid
  1. A cost saving opportunity for entities to achieve a high-level of trust, compared to existing KYC and KYB mechanisms
  2. A time-efficiency bonus for achieving a high-level of trust, with trusted data being instantaneously verifiable — reducing the burden of regualtory compliance
  3. A never-before seen revenue opportunity for “issuers” of trusted data

Payment Gating Reputation

The way that cheqd supports the above objective is through payment gating the reputational arm of Trusted Data, Trust Management Infrastructure (TMI)Trust Registries (TR) or in an alternative use case, Status Registries (SR).

Payment gating a Trust Registry (TR)
Payment gating a Trust Registry (TR)
Payment gating a Status Registry (SR)
Payment gating a Status Registry (SR)
  1. “Issuers” (and in some cases “Regulators”) are able to set the market price of unlocking a TR or SR
  2. “Verifiers” are able to choose whether they want to pay to unlock the result of a TR or SR to achieve
  3. Payments will be made back to the “issuers” of the VC that is being presented to the “verifier”
  1. If a TR for a particular DID, or SR for a particular VC, has a high Level of Assurance (LoA), such as being created by a reputable entity, it is reasonably foreseeable that the price for that check may be higher than average.
  2. If the price of a TR or SR check is too high, the verifier will either: (a) Choose not to make the extra payment; or (b) Choose another TR to make the check against (if available)
  3. Once organisations and industries see the revenue opportunities from creating TRs, it is hypothesised that a competitive market will emerge — with a range of TRs with differing LoAs and associated range of prices.

We will explore how these use-cases present a clear product market fit for cheqd, cheqd’s partners and also the wider SSI ecosystem, projected to capture 550 billion dollars worth of value by 2030.

Introducing Zero Knowledge Credentials (ZKCreds), the latest addition to cheqd

cheqd - Introducing ZKCreds

cheqd becomes one of the first Decentralised Identity networks to enable Zero Knowledge Credentials, ‘ZKCreds’, also known as AnonCreds. Leveraging the renowned and widely used AnonCreds Verifiable Credential format, cheqd, alongside Animo, has built ZKCreds into our tech stack, opening the door to a more privacy-preserving online experience for users.

Introduction

Zero Knowledge has fast become one of the hottest topics in Web3, with projects across protocols boasting bold and powerful new tooling to enable more private and autonomous online experiences for users.

Zero Knowledge or a zero-knowledge-proof (ZKP) is “a method by which one party (the prover) can prove to another party (the verifier) that a given statement is true while the prover avoids conveying any additional information apart from the fact that the statement is indeed true” (ExpressVPNP).

Put simply, a user is able to share only information that is necessary to the outcome required, and not all information they could reveal, but don’t need to. Combined with Verifiable Credentials (VCs), ZKPs offer a unique blend of privacy, flexibility and trust.

At cheqd, we’ve been determined to build ZKPs into the stack we offer to our partners, and fortunately, we haven’t had to do this alone. Thanks to the excellent leadership from the Hyperledger Indy and Hyperledger Aries communities, alongside our partner Animo, we’re thrilled to announce the support for Zero Knowledge Credentials (ZKCreds) on cheqd, using the widely known ‘AnonCreds’ Verifiable Credentials format.

Summary of AnonCreds & Zero Knowledge Creds

Across the SSI landscape, there is, of course, a broad range of use cases, which necessitate varying levels of privacy. For some, revealing more data than necessarily required is not of massive concern, for example, when less personal data is contained within the credential. However, for others, being able to prove the validity of a credential without revealing the claims, attributes or data within the credential itself is vital. For example, “ I don’t need to give up my full name or home address to prove I’m over 18”. Within a Web 3 context, “ I don’t need to reveal my wallet address to prove I hold a certain amount of a token”.

AnonCreds, short for ‘Anonymous Credentials’ — are a flavour of Verifiable Credentials that do this and more. Initially part of Hyperledger Indy, now in the Hyperledger AnonCreds project, Anoncreds have been used since 2017 and are one of the most commonly used Verifiable Credential (VC) formats in the world. Crucially, they are regarded as the standard for ZKP-based verifiable credentials, offering varying levels of privacy to the holder, dependent on the data being embedded.

However, as a Hyperledger native format, they have, for the most part, been tightly wedded to the Hyperledger Indy blockchain and an associated Hyperledger Aries Software Development Kit. This made it difficult for developers that want to reap the ZKP benefits of AnonCreds to leverage other networks’ unique value propositions — for example, the payment rails being built by cheqd.

Now, thanks to the work of the Anoncreds community, and the outstanding leadership from Timo Glastra and the Animo team, developers can issue AnonCreds on other chains. What makes this particularly poignant is that cheqd is one of the very first to offer Anoncreds on a non-Indy chain in a standard-compliant, highly performant and accessible format, which has been an industry-wide initiative, as we’ll come to.

Given the key value proposition of AnonCreds is the capability of zero-knowledge-proofs, we’ve chosen to coin the term ‘ZKCreds’ for their implementation on cheqd, given their zero-knowledge strengths and the broader level of understanding when compared to “Anon” as the key term.

ZKCreds x AFJ: opening the door to cheqd for current and future partners

Early on in our cheqd journey, we realised the Aries frameworks and AnonCreds dominance, reported in our blog post in April 2022 and have been eager to find a solution.

At cheqd, of our 42 SSI Vendors, 20+ are primarily issuing AnonCreds, or intend to, which currently requires the use of an Aries-centred Software Development Kit, such as Aries Framework Javascript — AFJ or Aries-Cloud-Agent-Python — ACA-Py.

With the release of the afj/cheqd-sdk module, cheqd’s current and prospective partners now have the ability to migrate their stack from Hyperledger Indy to cheqd, issuing AnonCreds with Aries Framework Javascript initially, with ACA-Py to follow.

Launching ZKCreds on cheqd also has a direct impact on cheqd’s tokenomics. Earlier this year, we introduced a ‘burn’ to the network as part of Tokenomics Part 4, whereby “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.”

With AnonCreds, the writing of resources (DID-Linked Resources) such as Cred Defs, Schemas and Revocation Registries to the ledger are required, each with an associated price. Currently, 50% of identity transaction fees are burnt, however, recent community discussion has meant a proposal to push this to a 99% burn rate is imminent.

Building ZKCreds into cheqd… how did we do it?

In September last 2022, we released and demoed our AnonCreds MVP, working alongside Animo. The crucial requirement for a ledger-agnostic AnonCreds was the ability to store the required AnonCreds resources on-ledger. These include, Credential Definitions (CredDefs), which create an immutable record of key credential information in one place, schemas used to list a set of attributes a credential contains, and the resources associated with revoking a credential.

Ultimately this was made possible through our pioneering implementation of an on-ledger resource module, offering the capability to store and retrieve resources, known as DID-Linked Resources, due to the way they’re stored from the cheqd ledger.

In tandem with our initial MVP, conversations started heating up around the topic of making ‘ledger-agnostic AnonCreds’, and over the past six months, a phenomenal amount of effort has been put in by organisations, including the IETF and the AnonCreds Specification Working Group amongst others, into making this possible. This culminated in the migration of AnonCreds to Hyperledger (hence why the new AnonCreds format is formally known as ‘Hyperledger AnonCreds’). More than 25 sponsors supported the adoption of AnonCreds by Hyperledger, including representatives of Indicio, Accenture, IBM Research Europe, several universities, BC Gov, and Canadian provincial governments, demonstrating the scale of their adoption and the vast pool of potential partners and end customers.

What's next?

Moving forward, we’ll now be guiding our partners through integrating with cheqd, specifically with Aries Framework Javascript. Stay tuned for tutorials on getting started with ZKCreds using AFJ, and check out the cheqd AnonCreds Method here.

For those whose applications are centred around ACA-Py, we’ll also be working with Animo and other partners to build the support for ZKCreds with ACA-Py on cheqd. If you’re involved in ACA-Py development, we’d love to hear from you — reach out to [email protected] to flag your interest.

Separately, if you’re an identity developer, not yet building on cheqd, let’s connect! Reach out to [email protected] to learn more about cheqd and how we may be able to help you.

We’ll also be hosting a series of webinars and workshops geared towards helping you to ‘Build ZKCreds on cheqd’. If you’re interested in being involved, please reach out to [email protected].