Alex Tweeddale, Author at cheqd

Credential Payments are live 🎉🥳

Announcing the launch of first-of-its-kind Credential Payments

Payment Rails are live! 🎉🥳 cheqd has built the first-of-its-kind mechanism for payments to verify digital credentials and credential status. This incentivises companies to begin adopting credential-based technologies and standards, by providing a clear commercial model for giving individuals self-sovereign control of their data.

Credential Payments is available to use through a set of easily consumable APIs within our Software as a Service offering: Credential Service.

Sign up for your account and get started. Create your first chargeable credential in a few clicks or lines of code using our suite of tutorials and guides.

Credential Payments solve the Chicken-and-Egg Problem

There has been a consistent cold start problem for digital credential ecosystems where organisations do not see a clear commercial model or revenue opportunity to justify the switch up costs to credential-based technologies. This is because the perceived value in Verifiable Credentials is the costs saved when there is a significant amount in circulation (the chicken🐔), but this cannot occur without organisations issuing credentials in the first place (the egg🥚).

Unfortunately, the benefits of credentials, prior to the point of mass adoption, provide no compelling reason for businesses to change their current data collection and retention practices until this is the case.

Since launching cheqd, our hypothesis has been that Credential Payments will be the catalyst for credential adoption, by incentivising issuers to release data back to the holder, and allowing them to set a price for trusted data checks. This thinking has since been validated by data collected by cheqd’s partners and potential customers, where 70% of respondents believed that payment rails would help drive adoption with their customers:

Results from the cheqd Product Survey in 2021

We now believe that credential ecosystems are technically mature enough to scale, especially with new regulations like eIDAS 2.0 accelerating their adoption and providing a template for interoperability. Yet, there is a barrier between the theoretical and philosophical benefits of Verifiable Credentials, and the commercial and business benefits of Verifiable Credentials. A payments or incentive layer is still required to provide a compelling reason for enterprise organisations to make the switch.

To achieve this shift, we’ve built Credential Payments into our Credential Service SaaS product to allow organisations to build trusted data markets easily, with simple REST APIs. This abstracts the complexity and responsibility of handling interactions with the ledger and provides a clear integration pathway for developers that are not familiar with decentralised identity standards or blockchain.

What companies see

Credential Service customers (Issuers and Verifiers) pay a flat SaaS fee and begin simply issuing and verifying chargeable credentials. Once chargeable credentials are issued, Issuers receive recurring revenue every time the chargeable element within each credential is verified.

Verifiers can rely on a Verifiable Credential presented to them, but they can also “Pay to Trust (P2T)” in order to access extra trusted information needed to make a trust decision in the Credential. Extra trusted information may be an assessment of whether:

The credential has been revoked or suspended.
The Issuer belongs to a particular Trusted List or Registry.
Customisable parameters have been met, such as governance rules and permissions set by the Issuer, for the particular credential.

This means that the payment is optional, depending on the Level of Assurance that the Verifier requires. Importantly, this payment between verifier and issuer can be in a fiat currency, a stablecoin, CBDC or other token (such as $CHEQ).

Below is a diagram showing the flow for what the customer sees:

What companies don’t see 🤓

Under the hood, Issuers are writing on-ledger transactions called Decentralised Identifiers (DIDs) and encrypted DID-Linked Resources (DLRs), such as credential Status Lists. These encrypted DLRs are “chargeable” in the sense that an Issuer is able to set a price and a time window to decrypt the DLRs in order to access the information within them.

Once the DLRs are encrypted, the decryption keys are sharded across the nodes on the network, meaning that there is no centralised entity that is able to view or access the DLR. Decryption is only able to occur once the Payment Conditions set when the DLR are met. This is privacy preserving, scalable and fully decentralised.

Unlike what companies see, the payment to decrypt the DLRs is made in cheqd network’s native token, $CHEQ, which can also be used for settlement or as an accounting mechanism to determine how much fiat or stablecoin an organisation has earned for their chargeable credentials.

$CHEQ is necessary under the hood because on-ledger resources cannot be gated using regular currency, so the $CHEQ payment to the Issuers’ address acts as a bona fide smart contract to access the data within the DLR.

You can learn more about how Credential Payments work under the hood by taking a look at our more detailed Veramo SDK tutorials here.

Understanding Payments for your use case

Credential Payments is only as powerful as the use case it supports. Notably, Credential Payments unlocks new use cases and data markets with untapped potential. This is largely centred around one idea: Reducing the Price of Trust.

Reducing the Price of Trust

Businesses are currently limited in the ability to conduct proper checks on their users and customers because it is too costly and time consuming. Identity verification checks cost upwards of $50 for comprehensive checks and between $2 to $10 for more basic checks. This prices many companies out of verifying their users because even $2 per user is too high a cost for the benefits of identity verification.

Using Verifiable Credentials and Credential Payments, the core premise is that the cost of identity checks will be greatly reduced and the time to trust someone will be near instantaneous. This unlocks new data markets, which were previously unable to verify users because it was too expensive.

cheqd now supports paid verifications to establish whether a credential is still valid, within a defined usage period, and that it hasn’t been revoked or suspended for any reason; where, the Price of Trust is akin to a “gas fee” ⛽ within Web 3.0 payments or “transaction fee” within traditional payments.

This can be used for incentivising reliance across industries where full identity checks are currently too costly, unlocking new potential data markets across an array of use cases:

1. Accomplishments and Achievements

To trust accomplishment / achievement credentials, Verifiers need to be sure that the Issuers are legitimate. Being able to pay an Issuer to check a list of trusted Issuer identifiers gives Verifiers the ability to build higher levels of assurance in the credential presented to them, and helps to prevent fraudulent actors.

This can be used for a product like Creds where Verifiers will be able to make an optional payment to gain additional trusted information about the Cred and build higher levels of assurance in the reputation of the user.

2. DeFi

Regulations are being written and adopted worldwide for the crypto / DeFi industry with a heavy focus on enforcing KYC or qualified investor status. Credentials allow DeFi protocols to set KYC and investor acceptance requirements whilst allowing users to re-use their information seamlessly, aiming to meet regulations whilst maintaining smooth user experience.

Issuers of KYC and qualified investor credentials can now be paid for these whenever protocols need to check investor statuses, or to verify the authenticity of the KYC issuer.

3. eCommerce & retail (inc. preferences)

Credentials allow users to share relevant details instantaneously without needing to type all of them out, reducing friction. Since this data comes from a trusted source, the merchant can be comfortable that it is accurate and not fraudulent. This reduces friction and risk for the customer, potential fall-out in the checkout process for the merchant, and exposure to fraud.

Both the issuer of the original credentials and the user themselves can be paid or rewarded for providing credentials which reduce likelihood of fraud but also allow merchants or retailers to provide tailored offers.

4. Gaming & virtual / augmented reality

Credentials would allow users to port their avatars, assets, experience and reputation between or out of games seamlessly whilst easily proving their memberships or online identities to each other to prevent scamming. This means that gamers can have a much longer and deeper relationship with content like avatars since they can use them across games and platforms, increasing the volume of content available to players. Players can also flex their reputations outside of the games they have established them in.

Through cheqd, other players or games can check that a user is who they claim to be, with payments made to wherever verified the data.

5. Membership and Loyalty

Credentials are able to be used to establish that a person is a particular member or subscriber of a service or group. However, current credential expiry periods do not establish whether a user has continued to meet the terms of service of the subscription or has paid for the months’ service.

Cheqd now supports paid verification of whether a users’ membership or subscription is still valid and unsuspended. This can be used to cross-sell benefits from one subscription / membership and offer access to other services, based on a valid subscription / membership. This can also be used for incentivising new loyalty schemes, or layering a new revenue stream on top of existing membership and loyalty schemes.

Curating the "Credential Bull Market"

Verifiable Credentials are still quite an unknown concept. Mass media, for example, has focussed far more on the likes of Non-Fungible Tokens (NFTs) and Soulbound Tokens (SBTs) because of the high volatility nature of these types of technologies and their huge hype cycles within the Web 3.0 space.

The graph below, for example, shows the significant attention that NFTs have received in the last few years, including a very large spike in the searches for the term “NFTs” in 2021. And although the interest in NFTs has steadily declined recently, the general levels of knowledge are much higher due to the boom.

Whereas, Verifiable Credentials, while not having anywhere near the same level of hype spike as NFTs, are being increasingly looked at by Regulators, Governments and enterprises as a realistic technology to solve digital trust challenges.

This is reflected in the steady increase in the amount of interest in the term “Verifiable Credentials”:

What we are beginning to see is a consistent interest in Verifiable Credentials to solve trust challenges within and between industries — but there are challenges with breaking the glass ceiling and spiking in a similar way to NFTs.

We believe that creating a financial incentive to use and issue Verifiable Credentials, we will create a “Credential Bull Market” where the volumes of Credential utility begin to spike like the 2021 NFT boom, solving the chicken and egg problem 🐣.

You can learn more about the size of the SSI market and Credential Payment opportunity here.

Looking back and stargazing

In March 2021, Fraser and Ankur announced cheqd to the world with a core idea:

“augmenting the noble goal of giving individual’s control of their data again with solid commercial reasons for companies to embrace the new paradigm. People can re-establish their privacy and companies can establish new businesses or revenue streams which have never before been possible.”

Or, in one word: incentives.

Since cheqd launched its tokenised mainnet in November 2021, we began assembling the building blocks for these “incentives” as a goal we referred to as “Payment Rails”.

First we created our Decentralised Identifier (DID) Method and the first DID on cheqd, followed by implementing our identity functionality into the Veramo SDK. Then in December 2022, we launched our innovative “DID-Linked Resources” ledger update, using this to support ZKCreds and subsequently, on-ledger forms of Credential Status Lists.

We’ve come a long way…

Today, we have taken each of these individual components, fit them together, and are incredibly excited to announce that we have launched an enterprise-ready Credential Payment model, which is easy to use, privacy preserving and highly scalable. 🎉🥳

Credential Payments is available to use through a set of easily consumable APIs within Credential Service or via a deeper integration with our Veramo SDK plugin.

P.s. if you’re a Creds user, stay tuned for Pay to Trust (P2T) Creds 🐣⌛.

Sign up for your account and get started. Create your first chargeable credential in a few clicks or lines of code.

Meet the Successful Applicants of the cheqd Foundation Delegation Programme 2023

Validators play a pivotal role in fostering the growth and security of the cheqd network. Beyond their technical contributions, validators significantly influence the ethos, culture, and future trajectory of cheqd by acting as core community members and advocates of the network.

cheqd network validators have a history of active engagement, both in governance, community building and working with our identity tooling. Acknowledging the ongoing dedication and contributions of these validators, the cheqd Foundation has designed the Delegation Programme to reward their numerous valuable efforts, such as producing educational content, relaying, and helping promote our solutions, alongside validating our network. As an example, Dora Factory is receiving a delegation of 40 million $CHEQ tokens as they’ll work with our team to set up and run future hackathons, one more example is Kleomedes receiving 5 million $CHEQ to help us promote our network and Creds (including testing Creds use cases).

After two months of entries and evaluation, the cheqd Foundation is delighted to announce the 22 validators who will receive delegations in this cycle.

Delegations for 2023 Delegation Programme

Delegating a total of 172,000,000 CHEQ tokens in this cycle, the allocation is based on their meeting of criteria defined in our Foundation Delegation Programme 2023. Since this is the first cycle of the Delegation Programme, we took into account contributions from both the present and the past few years since the cheqd network launch in 2021.

We also have delegated slightly more than the initially allocated 150 million CHEQ tokens, owing to the quality and number of submissions. You can view the list of validators who received our delegations in this cycle at the bottom of this blog.

Commitment to Decentralisation and Increasing Entropy

As the cheqd Foundation, we are committed to leveraging CHEQ to nurture and foster a sustainable network, in line with the principle of increasing entropy written into our Governance Framework. Decentralisation enhances the resilience and security of the cheqd network by reducing its vulnerability to single points of failure or control. It builds trust within the community, as power is distributed among a wider array of validators, promoting fairness and transparency.

Furthermore, a more decentralised network encourages broader participation, enabling smaller and newer validators to contribute and grow, ultimately enriching the ecosystem. By expanding decentralisation and network entropy through the delegations provided in this programme, the cheqd network not only strengthens its own foundations but also contributes to the broader vision of a decentralised, inclusive and robust blockchain ecosystem.

Maintenance of the Network

Once the delegations are distributed, validators who have received a delegation will retain the delegated tokens for a period of 1 year, provided they continue to maintain a healthy node and avoid any infractions (slashing or tombstoning). If a validator does incur an infraction, the delegation will be assessed on a case-by-case basis, depending on how the infraction occurred, how the validator responds, and whether the infraction is remunerated.

Given the nature of delegations, it is important to be clear that these are not the same as grants. It is the sole discretion of the cheqd Foundation to retract a delegation if there is, for example, poor node maintenance or bad behaviour within the active delegation set.

Looking Ahead

Two months before the programme is set to end (June 2024), another application process will be opened. This provides a clear timeline for validators to apply for delegation and allows for a smooth transition between programme’s years. It also ensures that the delegation pool is being allocated efficiently and effectively to support the growth and development of the cheqd ecosystem over the long term.

Finally, a huge congratulations to the 22 validators selected for this cycle of delegations! We hope our delegations to you convey our appreciation and confidence in your contributions to the network — and we hope to see even greater collaboration and innovation in the next year.

Delegation totals

In this cycle, the cheqd Foundation will be distributing a total of 172,000,000 CHEQ tokens to 22 validators. The distribution of CHEQ tokens to individual validators is linked to their performance, contributions to the network, and continual maintenance of their validator, as defined by the Foundation Delegation Programme 2023.

Please be aware that the list of validators and the amounts delegated have been fully distributed as of 25/08/2023.

cheqd Foundation Delegations Programme | Cycle 1

Validator Name | Delegation Amount ($CHEQ)

1. Dora Factory: 40,000,000

2. Lavender.Five: 19,000,000 (5,000,000)*

3. WhisperNode: 19,000,000 (5,000,000)*

4. Notional: 17,000,000 (10,000,000)*

5. Citadel.one: 14,000,000 (10,000,000)*

6. Monokee: 7,500,000

7. Blockfend Genesis Labs: 7,500,000 (5,000,000)*

8. Empower Validator: 5,000,000

9. Kleomedes: 5,000,000

10. WenProjectBoots: 5,000,000

11. node101: 5,000,000

12. StakeWolle.com: 5,000,000

13. MyContainer: 4,000,000

14. CarbonZero: 4,000,000

15. The Chicken Coop: 2,500,000

16. CosmosCats: 2,500,000

17. AlxVoy: 2,500,000

18. NodeStake: 2,500,000

19. Anonyome Labs: 1,500,000

20. YellowDotPink: 1,500,000

21. Hexnodes: 1,000,000

22. Blockval: 1,000,000

TOTAL

172,000,000

* Bracketed figures indicate previously made and maintained delegations outside of this application process, within the overall total stated here.

Community engagement Cosmos Network Decentralisation Delegation Programme Partnerships

cheqd Foundation Delegation Programme 2023

Introduction

GM cheqmates 👋 Since the turn of the year, we’re beginning to see the cheqd ecosystem flourish: our ecosystem partners are beginning to integrate our tools, clients are kickstarting Trusted Data markets, and we’re all getting our boots fitted!

To continue building momentum and encourage further innovation on top of cheqd, we are announcing our cheqd Foundation Delegation programme. This programme is intended to:

Reward Validators that build with and alongside cheqd, incentivising innovation and collaboration;
Develop closer relationships between our Validator ecosystem and the cheqd Delegator community;
Increase network decentralisation and Entropy in line with our Governance Framework;
Bolster the health and security of the cheqd Validator set with greater incentives for node maintenance, engagement and expansion.

By rewarding contributors to the cheqd network and good network maintenance, the purpose is to create a virtuous cycle, where constructive participation in the network leads to higher rewards, which in turn encourages further participation.

Amounts

We are setting aside a Delegation Pool of up to 150 million CHEQ tokens which may be delegated to Validators that help positively contribute to the cheqd ecosystem.

The range of delegation per Validator is expected to be between four million and 40 million CHEQ based on the eligibility and criteria set out below.

By introducing tokens from the cheqd treasury into the active pool through delegations, this may also, over time, increase the percentage of “bonded” tokens above the “Goal Bonded” of 60%. This would begin to reduce inflation, similar to what is currently occurring with the Cosmos Hub. Currently, it would be very difficult for the community to achieve the “Goal Bonded” given the amount of tokens held by the treasury and not delegated into the active pool. Therefore, we see this as an opportunity for the cheqd community to have more determination over the network inflation tokenomics, specifically with regards to the headline inflation rate (currently at 4%).

Eligibility

All entities are eligible to apply aside from those from sanctioned countries (North Korea, Iran, Syria, Zimbabwe, Belarus, Myanmar, Russia, Sudan, Venezuela, Cuba, Libya, Yemen, Somalia).

Validators who have already received a cheqd Treasury delegation are still eligible, and applications would be reviewed as an increase from their existing Treasury Delegation.

Any validator in receipt of a Treasury Delegation who is either slashed or tombstoned will likely cease to be eligible for the Delegation, which will be removed unless sufficient justification/explanation is provided.

Criteria

To be considered for the cheqd delegation programme, Validators must actively contribute to the growth of the cheqd ecosystem. Contributions can be made in at least one of the following areas:

Technical:

Contributions to cheqd’s identity functionality: Validators who have contributed to cheqd’s existing identity functionality, such as SDKs, DID method, DID resolver, DID-Linked Resources, are given preference in the delegation programme.
Building on top of cheqd’s identity functionality: Validators who have built applications or services that complement cheqd’s identity functionality, such as wallets and credential storage.
Use of cheqd’s identity functionality: Validators who use cheqd’s identity functionality in their operations, such as utilising cheqd’s SDKs for Verifiable Credentials or creds.xyz. Use of cheqd’s identity functionality also burns $CHEQ tokens from supply and, therefore may be prioritised.
Contributions or support with cheqd infrastructure: Validators who have supported or contributed to cheqd’s infrastructure, such as IBC relays, network indexing/explorer services, integrations into Dapps, UI or other Web3 or Cosmos functionality.

Community:

Supporting other validators: Validators who support other validators by sharing knowledge, providing technical assistance, and collaborating on community initiatives.
Creating educational content: Validators who create educational content, such as tutorials, guides, and video content, help to onboard new users to the cheqd ecosystem and promote its use and adoption.
Building community: Validators who work to build community by organising events, hosting meetups, and fostering discussion and collaboration among users and validators.
Onboarding delegators: Validators who actively work to onboard new delegators to the cheqd ecosystem help to grow and strengthen the network.
Community Governance: Validators who have contributed to projects selected by a community vote or community pool spend are also given preference in the cheqd delegation programme
Other initiatives: Validators who engage in other initiatives that help grow and engage the cheqd community, such as participating in hackathons, creating new tools and resources, and collaborating with other blockchain projects, are highly valued in the cheqd delegation programme. These initiatives demonstrate a commitment to the growth and sustainability of the cheqd ecosystem and help to position the network for long-term success.

Participation:

History of participation: Validators who have a history of participating in both the cheqd mainnet and testnet are given preference in the delegation programme. This demonstrates a commitment to the network and a track record of supporting the ecosystem.
Governance participation: Validators who have a record of governance participation, such as voting on proposals and engaging in discussions about network upgrades and improvements, are also given preference in the delegation programme. This demonstrates a willingness to engage in the governance process and contribute to the decision-making that shapes the network’s future.
Communication and transparency: Validators who prioritise communication and transparency with their delegators are highly valued in the delegation programme. This includes providing regular updates about network performance, sharing technical details about the node’s operation, and being responsive to questions and concerns from delegators.
Jailed Validators: If a Validator has been jailed, meaning they have not been able to validate on cheqd due to financial reasons or otherwise, they may still be considered for delegation. However, they must demonstrate a commitment to maintaining the health of their node, even if they are not able to actively participate in validation. This could include keeping the software up-to-date, monitoring the node’s health, and taking steps to address any issues that arise.

Reputation:

Validators with a strong uptime record, which avoid slashing events, and run up-to-date software on cheqd.
Validators with a strong record of running Validators across other top networks with healthy maintenance and uptime.
Of course, any Validator that can provide Creds attesting to this will be viewed more favourably!

Duration & process

The delegation programme will be in effect for an entire year from the date of the blog’s publication. During this time, eligible Validators can apply for a delegation from the pool of 150 million CHEQ tokens.

The application window will be open for a full two months, giving Validators ample time to submit their applications for consideration.

Two months before the programme is set to end, another application process will be opened for the subsequent year. This provides a clear timeline for Validators to apply for delegation and allows for a smooth transition between programme years. It also ensures that the delegation pool is being allocated efficiently and effectively to support the growth and development of the cheqd ecosystem over the long term.

The delegation process will begin as soon as the first applications are received and reviewed. However, it is important to note that delegations at the beginning of the programme, especially within the first month, may not be the final amount awarded.

If there are not enough eligible applications, or the quality of the applications is not sufficient, the application window may be extended for a certain period, possibly up to the duration of the programme. This ensures that the delegation pool is allocated to the most qualified and deserving Validators who will contribute to the growth and development of the cheqd ecosystem. It is recommended that Validators apply as early as possible to increase their chances of receiving a delegation, but they should also ensure that their application is of high quality and meets the eligibility criteria.

Key Dates + Timelines

May 30 — application opens
July 30 — application deadline for Cycle 1 delegations
June — August — selected validator participants will be notified

Apply

To apply for the Delegation programme, you will need to fill out the application form below:

🟢 Click this link to access the application form.

Decentralised Identity Delegation Programme Digital Identity Self-Sovereign Identity Verifiable Credentials

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

In our previous blog we discussed the thematic strands that underscore trust in markets, specifically data markets. We suggested that by introducing verifiable data into various interactions undertaken by market participants, we could add a new dynamic that reduced time-to-reliance whilst preserving self-selective disclosure of information.

Through introducing a new form of trust, we are able to invert the data paradigm of shadow markets — enabling new transactions, commercial models and use-cases to form. By altering these trust dynamics, cheqd provides infrastructure to support the advent of a new type of data economy, what we call: Trusted Data Markets.

This blog will look at how cheqd supports Trusted Data Markets from a technical perspective, and how components such as: Decentralized Identifiers (DIDs), Verifiable Credentials (VCs) and Trust Management Infrastructure (TMI) (such as Trust Registries (TRs) or Status Registries (SRs)) complement each other and provide different dynamics of a Trusted Data Market.

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.

The Technical Components of a Trusted Data Market

The crux of establishing a Trusted Data Market using cheqd centres around the interplay of three technical components, used to create digital trust:

Decentralized Identifiers (DIDs)
Verifiable Credentials (VCs)
Trust Management Infrastructure (TMI) such as Trust Registries (TRs) or Status Registries (SRs).

When used together, these three components each tackle a different property of a Trusted Interaction, which will be discussed in turn:

Legitimacy established by DIDs
Integrity established by VCs
Reputability established by TMI

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:

Legitimate;
Associated with a particular DID Document (discussed in point 2);
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

DID Documents may contain additional information about a particular entity (the DID Subject), through URI endpoints. Commonly, information about the DID Subject is written into the service section of a DID Document, which natively allows serviceEndpoints, pointing to other relevant information about the entity, such as perhaps their website, an email address or a social media profile.

This helps provide another layer of legitimacy for third parties who resolve a DID.

Resources

DID Documents may contain additional metadata about DID-Linked Resources (DLRs). DLRs are an extension to the DID Core spec, which may allow DIDs to be cryptographically associated with other digital resources, such as logos, documents or registries.

Using the same challenge and authentication mechanism, these associated DID-Linked Resources can be afforded a greater degree of legitimacy using the power of DIDs.

Importantly, DLRs can be used to create Trust Management Infrastructure (TMI) in a decentralized way, where Trust Registries (TRs) or Status Registries (SRs) may be made available and accessible using DID URLs.

The legitimacy provided by the DID authentication mechanism is the first ingredient needed to create a trusted digital relationship for a Trusted Data Market to function.

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:

Legitimacy — since it is signed by a particular entities DID; and
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:

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).
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:

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:
Legitimacy (as previously discussed)
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.

This diagram illustrates the following flows:

A DID cryptographically signs a VC, which establishes Legitimacy and Integrity in the data the VC contains
A VC references a TR (or other TMI), which establishes Legitimacy and Integrity that a TR is intended to be used by the verifier
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

The combination of DIDs, VCs and TMI goes a long way to move digital interactions beyond mere-reliance, since a “holder” (H) is able to prove that their claim is:

Legitimate, since it is attested to by a particular “issuer” (I)
Cryptographically untampered because the VC data model enables proof serialisation and data integrity
Reputable, since one or multiple TRs can be referenced to where the issuer’s DID is attested to by third parties

For a relying party verifying the VC, “verifier” (V), this obfuscates the need to fully trust the “holder”, instead moving the burden of trust onto the strength of the technology and cryptography within the VC itself. This greatly closes the “Trust Gap” from necessitating a wide-berthed “interpersonal” human relationship, to a far narrower “inter-network” technical relationship.

Crucially, this combination of technologies also makes trust instantaneous. Since legitimacy, integrity and reputability can all be presented in one single proof. This significantly reduces the “Trust Gap” between mere-reliance and full trust. Thus, not only do these technologies create a new paradigm for digital trust, but they greatly increase the operational efficiency at which trust can be achieved — reducing the need for burdensome due-diligence checks and back-and-forths.

Using this type of instantaneous, inter-network trust, organisations can have have full confidence that:

Other parties they are interacting with meet compliance requirements for their industry or use case, creating trusted markets;
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.

This type of inter-network and instantaneous digital trust, up until the advent of these technical components, has not been possible. Only now are we beginning to have the technical tooling to bridge the “Trust Gap”.

Making the Market

Up to this point we have largely discussed the technical components that constitute Trusted Data. This section will explain how cheqd supports the commercialisation of Trusted Data to build the fundamental concept here: Trusted Data Markets.

Core to cheqd’s objective of building Trusted Data Markets is the understanding that different digital interactions necessitate different levels of trust. Some interactions will be low-value interactions — such as using a VC attesting to a “name” and “DoB” to sign up for a gym membership. Others may be very high-value transactions — such as using a VC containing a “CCT General Practitioners’ Certificate” to onboard efficiently at a new hospital.

For this reason, the “Price of Trust” will vary depending on the determined value of the digital interaction, where low-value interactions may be free or low-cost; whereas, high-value interactions may be higher-cost.

To account for this differentiation, it was important when designing the infrastructure for Trusted Data Markets to ensure that the “verifier” has a choice in determining how much they want to spend on achieving “trust”. The outcome of associating a price with levels of trust is as follows:

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

The logic here is that low-value interactions will generally not need to check a TR or verify reputability; yet, they should still be able to use the integrity and legitimacy benefits of DIDs and VCs at low-cost. A cost at this level would risk disincentivising the use of the technology because the potential financial loss from mere-reliance on a bad actor in low-value interactions would often be chosen over the price of trust.

Whereas, charging for reputability is a market that is already well established, for example existing KYC, KYB and general due-diligence checks are highly frequent in enterprise. Charging for the additional reputation of a Credential or DID will provide:

A cost saving opportunity for entities to achieve a high-level of trust, compared to existing KYC and KYB mechanisms
A time-efficiency bonus for achieving a high-level of trust, with trusted data being instantaneously verifiable — reducing the burden of regualtory compliance
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).

Using cheqd’s payment infrastructure, there are two market making operations at play here:

“Issuers” (and in some cases “Regulators”) are able to set the market price of unlocking a TR or SR
“Verifiers” are able to choose whether they want to pay to unlock the result of a TR or SR to achieve
Payments will be made back to the “issuers” of the VC that is being presented to the “verifier”

Where it is hypothesised that:

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.
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)
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.

This interplay of the use of DIDs, VCs and TMI, providing the composition of “Trusted Data” as one modality of market regulation; and, the economic cost of “instantaneous trust” vs the potential economic risk of “mere-reliance” as another modality, is ultimately what cheqd’s architecture facilitates as a “Trusted Data Market”.

The next blogs in this series will focus on the use-cases for Trusted Data Markets, and where we see markets requiring “instantaneous trust” for either: regulatory compliance, cost and time-saving, new revenue opportunities or a combination of all three.

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.

Data Privacy Decentralised Identity Digital Identity Self-Sovereign Identity Verifiable Credentials

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:

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.
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.
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.

Mainnet Open Source Tokenomics

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.

Mainnet Open Source Tokenomics

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:

0.4.0 and 0.5.0: Upgrades to the cheqd DIDs, DID Documents and DID Resolution, building on top of the cheqd DID method;
0.6.0: The feature addition of DID-Linked Resources which is creating waves in the SSI / #IDTech space;
1.0.x: Updated pricing for identity transactions and CHEQ tokenomics v4 (Testnet & Mainnet due to release in Jan 2023).

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:

Feature parity with all other SSI networks;
Identity functionality that goes beyond existing SSI networks; and
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:

Identity: Core identity functionality for our partners to build compelling self-sovereign identity use-cases on top of the cheqd network.
Web 3.0 Core: Core Web 3.0 functionality adds deeper integration for our network and token into the Cosmos and other blockchain ecosystems.
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

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

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

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

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

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:

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

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

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!

3. Improved automation and tooling

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

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

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

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:

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

Mainnet Open Source Tokenomics

Verifiable Credentials to streamline the events and ticketing industry

The ticketing industry has been in the press this week for failing to provide loyal and “Verified Fans” the early access to tickets they deserve. New types of data files, known as Verifiable Credentials, are here to help, enabling punters to easily present verified identity information to secure the process of buying tickets and entering events. Here’s how.

We’ve grown too accustomed to the way events handle ticketing. Long queues, ticket touts, and ticket handling fees are all part of the scenery if we were attending a gig, sports event or festival.

Every time we register for an event or purchase a ticket, we are constantly providing the same information over and over again. Meanwhile, each time we attend an event, the organisers need to spend time and money verifying our name, ticket validity and sometimes our age.

This process is repetitive, insecure, costly and, most importantly, easily avoidable. The use of Verifiable Credentials (VC) – a tamper-evident data file with a set of claims about a person, organisation, or thing that can be cryptographically verified – is poised to streamline the entire events industry. Using VCs, however, it would be far more difficult for bots and scalpers to get the requisite level of trust necessary to bulk-buy and resell tickets, while event-goers will be able to prove trusted attributes about themselves and a level of reputation that they are who they claim to be.

Problem one: Scalpers

Taylor Swift has been in the news this week for the wrong reasons. The release of tickets for her latest tour has been met with a clear demonstration of one of the events industry’s biggest issues: ticket scalpers and bots.

Just minutes after the pre-sale release, her face-value tickets, which cost between $49 and $449 each, had sold out, Ticketmaster had crashed; and simultaneously, on the secondary market, the same tickets were being resold and flipped for as much as US$22,700 (£19,100) each.

This is not a one-off. It is a problem that has consistently plagued the ticketing industry. This can be shown by the research conducted at Distil Research Labs, which concluded that bot activity was estimated to be behind 42.2% of activity in online ticket sales.

There have been attempts to resolve the issue. For example, in 2017, Ticketmaster introduced a new scheme for “Verified Fans”, where the most clued-in fans could pre-register their personal information for the event prior to the tickets coming on sale. Through this process, lucky fans would receive an email with a presale code to access an early-bird ticket sale.

This process was in effect for the Taylor Swift gig, however, bots had been able to register themselves with fake names and fake email addresses in advance, skirting around the extra measures put in place.

The issue here is that becoming a “Verified Fan” does not actually “Verify” your identity in any way, it relies on self-attestations.

Problem two: Security

There is a lack of security around ensuring the identity of the attendees of an event because the existing process is too clunky. It usually involves one physical ticket or digital QR code PLUS a physical identity document check. More recently, it may even involve a Covid vaccination certificate.

Since traditional tickets aren’t tied to an identity, bouncers and door staff are tasked with the role of ascertaining people’s identities. This is expensive for the organisers, inefficient as it causes long queues, and ultimately, insecure.

Various UK YouTubers such as Niko Omilana, Max Fosh and The Zac & Jay Show have shown how farcical the existing ticketing system is by creating videos of themselves sneaking their way through bouncers into various events. The most telling was Max Fosh getting into the International Security Expo in London, armed with only a fake lanyard and a strut of confidence.

This is potentially a huge risk vector for event organisers, which they need a new answer for.

Additionally, due to the lack of options to prove your identity, around 10,000 passports are lost each year while on a night out in a bar or club in the UK, according to the Identity and Passport Service (IPS). It makes little sense that there is no digital way to represent the same identity data or level of trust for entering a venue.

Verifiable Credentials to the rescue

Verifiable Credentials are a new digital standard from the World Wide Web Consortium (W3C) to create a more trustworthy way of holding and presenting data. From a more technical lens, VCs are tamper-evident data files with a set of claims about a person, organisation, or thing that can be cryptographically verified. Using Verifiable Credentials, it would be possible to reduce the risk of identity fraud, ticket scalpers and unauthorised access to events.

This is because a Verifiable Credential that has been issued to you from a trustworthy party is:

Verifiable: affording a much higher degree of trust than something like Ticketmasters’ “Verified Fan” service, which is self-attested.
Tamper-evident: meaning it’s much more difficult to fake or copy without being caught out.
Reputable: You can combine credentials from multiple sources to present a digital reputation, not just an attestation.

For example, if a music artist issues you a VC for being a loyal fan, this becomes something that cannot be replicated as easily by a bot and becomes far more meaningful. Event organisers could then create a gated presale, requesting trusted attestations from multiple sources – requesting, for example:

A loyal fan credential issued by a band; and
A credential for authenticating with a social media platform

Having both of these would make it much more difficult for bots and scalpers to be included in the presale. For more high-profile events or with higher risk involved, you could request additional higher Level of Assurance (LoA) credentials, such as:

A credential issued by a bank or government (trusted third party); or
A credential issued by an employer attesting to your name and identity.

Therefore, with digital credentials, it becomes a lot harder to fake your way into an event, or scalp tickets, since you need to prove a level of reputation to get them in the first place. Currently, it is easy to spin up a new identifier like an email, but Verifiable Credentials make it much harder to fake a digital reputation.

Verifiable Credentials in action

From theory to action, to illustrate how easy this solution is, cheqd demoed how VCs could address this exact issue at Internet Identity Week (IIW). In this demo, Verifiable Credentials were used to combine: a verified identity; and an event ticket into one QR code proof.

Check out the demo recording here, or feel free to have a go yourself at wallet.cheqd.io

Learn from the demo how you could:

Sign in to a web-based application using a wallet (in this case, the Cosmos-based Keplr wallet)
Prove your identity with a social media account (authentication)
Get a credential with your name and social media details
Add your event ticket to your wallet, providing a QR code
Present your event ticket alongside your name and social media details.

The combined proof could be shown on the door of the event to securely “scan in”. This would hugely reduce the amount of time needed to physically check identity documentation and would make it much more secure for event organisers, who could rely on a combined proof of “identity” plus an “event ticket”, all issued by trusted third parties.

You can play with the cheqd wallet and get yourself a credential here.

You can learn more about Verifiable Credentials here and their interaction with Decentralised Identifiers (DIDs).

Conclusion

Using Verifiable Credentials would greatly streamline the events and ticketing industry, solving some of the core problems that have been causing huge financial losses and frustrating punters over the past decade.

Firstly, requesting Verifiable Credentials in a ticket sale would make it far more difficult for bots and scalpers to get the requisite level of trust necessary to bulk-buy tickets and resell them.

Secondly, using Verifiable Credentials to enter an event venue would streamline the process, reducing queue times and giving organisers a greater level of confidence in who is attending the event.

Overall, the technology is developing quickly, and we at cheqd are ready to provide the backbone and network for the growing adoption of Verifiable Credentials for events, with Decentralised Identifiers anchored on the cheqd network. If this blog resonates with you and you are in the events industry, please get in touch with our partnerships team here, or you can try out our SDK for issuing and verifying credentials here!

Finance Gaming Metaverse NFT Web3

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:

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.

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.

Mainnet Open Source Tokenomics

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:

Camenisch-Lysyanskaya (CL-Signatures) to encode individual claims for the purpose of enabling selective disclosure.
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.
Hyperledger-Indy specific transaction syntax for on-ledger schemas, credential definitions, revocation registry definitions and revocation registry entries.
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:

Ledger level: What must be written to a verifiable data registry for AnonCreds to be created and functional in practice?
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:

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;
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.

Mainnet Open Source Tokenomics