Credential Payments are live 🎉🥳

cheqd network - Credential Payments

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:

  1. The credential has been revoked or suspended.
  2. The Issuer belongs to a particular Trusted List or Registry.
  3. 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.

cheqd - Blog - Payment in $CHEQ

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

cheqd - Blog - Reducing the price of Trust

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 - Reducing the price of Trust

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.

cheqd - Reducing the price of Trust
cheqd - Blog - Google Trend graph for NFTs in past five years

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”:

Google Trend graph for Verifiable Credentials in past five years
Google Trend graph for Verifiable Credentials in past five years

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…

cheqd - Blog - Journey to Payment Rails
cheqd Journey to Payment Rails

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.

Moving Beyond the Limitations of did:web

Moving Beyond the Limitations of did:web

Executive summary

did:web is becoming a honey trap for organisations looking to adopt decentralised identity and credential-based technology. While it is attractive due to its low cost and simplicity (the honey🍯), it is easy to get stuck with it beyond testing environments (the trap 🪤). There are a series of challenges and vulnerabilities with did:web which need to be fully understood before using the method in production environments.

These core issues run deep, to the point where did:web is beginning to falsely represent the true value and core purpose of DIDs, since the DIDs are not decentralised, cryptographically verifiable, tamper resistant, self-certifiable or persistently stored. And while there are proposals to improve did:web, such as did:webs and did:webplus (which do have merit in their own right), we believe that it is now time to reconsider the adoption of a select few ledger-based alternatives.

Ledger-based approaches such as EBSI and cheqd have reached a state of maturity where the value of their DID methods goes beyond simple DID resolution. These additional benefits include:

  1. Historically resolvable, traversable and persistent DID Document states, queryable through standardised DID URL dereferencing.
  2. Fully resolvable, traversable and cryptographically verifiable trust registries, status lists and schemas, using DID-Linked Resources.
  3. Machine readable governance rules and permissions for scalable trust frameworks, using DID-Linked Resources.
  4. DID resolvable and cryptographically verifiable proof of ownership of decentralised, digital data stores, such as Decentralized Web Nodes (DWNs).
  5. New commercial models for verifiable credentials including payments to unlock ledger-based status lists or trust registries.

At the same time, more established ledgers such as Indy and ION have continued to improve their tooling, developer experience and provide excellent options for general ledger-based DID resolution and digital credential ecosystems.

With these innovations, adopters can build fully decentralised trust ecosystems, without relying on centralised web domains or single points of failure. This realigns the value of DIDs far closer to their original purpose, than the regression and reliance on more centralised architecture perpetuated by did:web.

Introduction

The decentralised identity community has gradually drifted away from initially adopted decentralised DID Methods (such as did:sov and did:ethr) and towards the adoption of more centralised approaches, such as did:web (and even regressing to non-DID solutions such as X.509 Certificates).

This is because the simplicity and cost-effectiveness of establishing a credential ecosystem using did:web has led to a general sentiment that did:web is good enough for nowor until something better comes along. At the same, the more established ledger-based approaches (did:sov, did:indy, did:ethr, did:ion) have had challenges with interoperability, regulatory uncertainty, scalability and integration effort.

Although the narrative of moving towards did:web has held sway, we believe that it is time to reassess its legitimacy in light of significant developments and innovations made by alternatives, coupled with the emergence of more accessible tooling to easily integrate with these methods . To illustrate why it is the right time for this, this paper aims to shed light on two key points:

1. We’re sleepwalking back towards “centralised” identity 🧟

 

did:web has significant concerns and vulnerabilities when used in production environments, which were never intended to be part of the design of DIDs.

These issues need to be thoroughly understood before deciding to use this method, and additionally, they are adversely affecting the reputation of DIDs in general. This is having the effect of undoing all the good work of establishing a “decentralised” identifier and has led to adopters regressing back to traditional identifier models like X.509 certificates, since did:web does not offer many significant benefits to justify the switch up costs and additional development.

2. We’re too quick to dismiss new ledger-based innovations 🤔

 

There is no denying that the community has a chequered history with ledger-based approaches to decentralised ID. Owing to these challenges, as well as a handful of illegitimate and immature ledger-based DID methods, there has been a widespread scepticism around any of the developments made in this space.

Yet, in the last year, a few ledger-based methods in particular have seen substantial improvements, many of which have gone unnoticed by the community. These improvements now offer a value proposition extending far beyond simple DID Resolution, including fully resolvable, cryptographically verifiable and persistent DIDs with linked trust registries, status lists and governance rules/permissions.

Therefore, we believe that it is now a viable option to move beyond the limitations of did:web, and begin considering a selection of alternatives, including ledger-based DID methods with greater confidence.

What was the initial goal of DIDs? 🥅

To help frame our argument, a good question to explore, reflect upon, and use as a reference point is: why were DIDs initially created?

The idea for a Decentralised Identifier (DID) was initially conceived around 2015, close to the same time when Self-Sovereign Identity (SSI) emerged as a concept. One of the earliest documents that influenced this development was “Decentralised Public Key Infrastructure” (DPKI), drafted at Rebooting-the-Web-of-Trust (RWoT) #1 and co-authored by notable thought leaders in the SSI space, as well as Vitalik Buterin, who went on to found Ethereum.

This work recognised that the problem with traditional identity systems is that they were based on centralised and hierarchical roots of trust, which ultimately revolved around a small set of actors. In contrast, the DKPI paper proposed that a new type of identifier was needed: one which was independent of central authorities and control.

At the time, a theoretical concept known as Zooko’s triangle was often used to describe three desirable properties of identifier systems:

  1. Human-meaningful 💡
  2. Secure 🔒
  3. Decentralised 🕸️

The existing “identifier” system, the Domain Name System (DNS), fulfilled the “secure” and “human-meaningful” properties, but did not fulfil the “decentralised” property.

DIDs on the other hand were designed to be “secure” and “decentralised”, but not necessarily “human-meaningful”. This was why many of the original DID methods were based on distributed ledgers (did:sov, did:ethr). It was only several years later that other derivations of DID methods such as did:web, did:key, did:peer and did:jwk were developed.

Why is this important to understand?

 

The invention of, specifically, the did:web method, had a profound impact on the W3C DID Working Group, as it was seen as a DID method that could fulfil the technical requirements of a DID (with regard to its syntax and capability for DID resolution), but it was not a “Decentralised Identifier” in the original sense. This is because it was not decentralised, persistent or cryptographically verifiable.

This created a level of dissonance between did:web, which has gained increasing adoption, and the actual purpose, utility and extensibility of DIDs — prompting a rhetorical question that we will consider throughout — if a DID is not decentralised, why use DIDs at all?

The did:web honey trap 🍯

did:web is undoubtedly very simple to use, cost-effective and is functional for proving the concept of DID resolution. Yet, it’s a bit like a honey trap.

This is because the reliance on did:web as the primary DID method supported in client applications, beyond testing environments, has significant vulnerabilities as well as having a negative effect on the reputation of DIDs. It pulls a lot of adopters in, who then get stuck with it as their idea of what DIDs are capable of eroding many of the fundamental properties of DIDs, which we will discuss in turn.

DID Document Provenance and Versioning

One unique and largely underappreciated feature of the DID Core specification is the feature of provenance, i.e. the ability to resolve DIDs back to a specific point in time, even if the DID Document has been significantly updated since that period.

DID Document provenance enables important use cases such as data and service portability, stable address books, key rotation, and key updates. To support this, the DID Core specification defines various DID parameters (versionId, versionTime) and metadata properties (updated, nextUpdate).

The did:web method simply does not support these features; and while it would theoretically be possible to extend the did:web method to add a version history (see did:web issue #61), it would never be immutable and cryptographically verifiable as it is in other DID methods. Recently, we’ve seen proposals such as did:webs which aims to use KERI to witness and relay did:web event logs to add an extra layer of provenance.

This is a welcome improvement to did:web 👏 but may create interoperability challenges between did:webs witness “smart” applications and others, unless it’s implemented within something like the Universal Registrar / Resolver.

Data Integrity and Tamper-Resistance

Using centralised hosting providers, such as a web-domain, to store DIDs may have a significant difference in the longevity, authenticity and auditability of DIDs and any Verifiable Credentials reliant on the DID authentication. This is because:

  1. DIDs may be spoofed or compromised: DIDs and DID Documents stored at a centralised web endpoint can be compromised and replaced by malicious actors.
  2. Hosting providers are known for down-time: Hosting providers (even highly reputable and sophisticated providers) could terminate accounts due to factors such as non-payment of fees, violation of Terms of Service, etc.
  3. did:web links may be deprecated and throw errors: A link pointing to a DID Document may be changed, resulting in a dead-link and error for a client application relying on the verification of a Credential signed by a deprecated DID.

Privacy and the “Phone Home” problem

The “Phone Home” problem is a significant privacy and confidentiality issue associated with the did:web method. With did:web, the issuer can track or record:

  1. Any time your DID is requested by a verifier,
  2. The frequency of requests,
  3. Timestamps of requests,
  4. IP addresses,
  5. User agent details.

This information can be correlated, allowing the “issuer” to potentially identify the interactions of specific “holders” — which is a significant risk to privacy and the legitimacy of DIDs and Verifiable Credential solutions. This is something that is incredibly important for adopters of the method to consider, because this results in the use of Verifiable Credentials replicating the same problems as “Web2” in terms of tracking and big data analytics.

Self-Certifiability

did:web DIDs have no inherent “self-certifiability”. This means that the DID identifier itself does not cryptographically link to the DID Document at all. This reduces the level of assurance a relying party will have in a did:web DID because the DID Document contents and associated keys may have been edited or spoofed without any cryptographic checks validating the DID’s authenticity.

There have been proposals to improve this aspect of did:web, such as did:webplus, but again, while it is a reasonable attempt to paper over the cracks, it will still be vulnerable to other issues, which may be mitigated through alternative methods. Ultimately, while using did:web has been a practical approach to set up a decentralised identity solution quickly and efficiently, this comes at the cost of security, cryptographic integrity and provenance.

The Slope of Enlightenment for Ledger-based DID Methods 📈

There has undoubtedly been a history of hesitancy and scepticism around the need or requirement for ledger-based DID methods because centralised methods such as did:web, did:key and did:jwk can largely accomplish the same core value in terms of simple DID resolution.

Ledger-based DID Methods have also historically built a poor reputation. There are a myriad of ledger-based DID methods (likely over 100) within the DID Spec Registries, and largely these methods come with a catch, including

  1. Interoperability challenges: with unique transaction types which require a particular software stack to utilise
  2. Scalability issues: with high transaction volumes and high volumes of requests
  3. Integration blockers: with poor/incomplete documentation and long integration timelines
  4. Blockchain hysteria: with too many projects professing to “put everything on the blockchain”, leading to privacy nightmares and valid questions of their legitimacy.

However, more recently, we are beginning to see a level of maturity in a select few ledger-based DID methods that are starting to take advantage of the broader aspects of the DID Core spec.

We have also seen substantial developments in the interfaces for consuming and using ledger-based DID methods, with the Universal Resolver and Registrar projects providing a way to consume an array of ledger-based DID methods with interoperability, without bespoke integrations.

gartner
Gartner Hype Cycle Graphic

Having initially peaked and then dropped off into the “Trough of Disillusionment”, we now think that a select few ledgers, with recent innovations, are climbing into the “Slope of Enlightenment”.

For this reason, we want to reiterate that not all ledgers should be viewed with the same hesitancy as the majority, and it is worth reassessing their maturity, legitimacy and capability to deliver on the fundamental components of DID Core, including:

Persistent DID Document Version Lookup and Retrieval ↩️

As described earlier as a omission of did:web, being able to persist and query historic versions of DID Document states is highly valuable in production environments, where Credentials are expected to have a long life span or in use cases where issuers frequently rotate their keys or update their DID Documents.

Going into production environments, it is very important for a “holder” to be able to prove that the keys signing their Credential were valid at the point of issuance, even if the issuer has rotated to new Verification Method keys multiple times since issuance.

Without version lookup and retrieval, Credentials will have a far shorter life cycle and Level of Assurance — these Credentials will likely need to be issued more frequently because key rotations will overwrite previous keys unless the historic information is persisted.

DID methods, for example, “did:cheqd” and “did:ebsi” both currently have working, production-ready DID Resolvers with query parameters to fetch historic versions of DID Document states from their respective methods, including standardised query parameters such as “versionId” and “versionTime”. For example:

  • did:example:38428720–301e-4168-abac-c93581f08a3c?versionId=X
  • did:example:38428720–301e-4168-abac-c93581f08a3c?versionTime=X

Service providers like Godiddy.com provide the same functionality for several additional DID methods, creating the first of many value adds between ledger-based methods and did:web.

Verifiable Trust Registries and Status Lists 🍏

Trusted Issuer Lists are a critical component in the world of Decentralised Identifiers (DIDs) and Verifiable Credentials. They serve as a registry of trusted entities that are authorised to issue credentials or conduct other actions, thereby enhancing the trustworthiness and reliability of the credentials issued within the system. However, Trusted Issuer Lists have experienced a similar teething problem to did:web, in the sense that most approaches to them are based on centralised, traditional infrastructure.

Recently, several organisations and initiatives have made significant strides in implementing ledger-based Trusted Issuer Lists, including:

  1. European Blockchain Services Infrastructure (EBSI)’s Trusted Issuer Model, enabling DIDs and their associated Verifiable Attestations to be written to a permissioned Trusted Issuers Registry.
  2. cheqd’s approach to DID-Linked Trust Registries, enabling DID Controllers to create Trusted Issuer Lists within a “Collection” of “Resources” associated and linked with their DID. This is made possible via an emerging W3C specification called DID-Linked Resources.
  3. Open Credentialing Initiative (OCI)’s Trusted Issuer Registry, managed through a smart contract deployed on the public Ethereum blockchain.

Similarly, Verifiable Credentials Status List v2021 is the most commonly adopted way of currently tackling credential revocation. However, this method requires an issuer to publish a public Verifiable Credential to a centralised server, which displays the latest revocation status of issued Credentials within a bitstring. The centralised nature of the server reflects similar issues to those raised earlier around did:web, particularly in terms of persistence, uptime, security, verifiability and data integrity.

Again, this is being solved by ledger infrastructure, with approaches such as:

  1. cheqd’s ledger-based Status List 2021 which publishes each Status List entry and bitstring as a distinct DID-Linked Resource, resolvable and identifiable via a DID URL.
  2. Ethereum’s Ethereum Improvement Proposal (EIP) worked on by the team at Spherity, which uses similar logic to Status List v2021, but with additional improvements to delegation.
  3. Hyperledger’s AnonCreds revocation which uses cryptographic accumulator based Status Lists, written on ledger, to calculate whether a Credential is part of a revoked set in a privacy-preserving way (note that there has also been great work by the Indy and AnonCreds communities to update the AnonCreds spec and make it ledger-agnostic, meaning that this is no longer an Indy-specific approach).

In combination with a ledger-based DID method, these on-chain trust lists create a robust, and importantly, decentralised way of managing additional contexts such as trusted issuers and credential statuses. They offer a balance of security, transparency, auditability, and control, while also providing resilience, privacy, and usability. All of which cannot currently be achieved using did:web or centralised alternatives.

Universal Resolver and Registrar 💫

One fundamental aspect of DIDs that should be kept in mind is that by the use of “methods”; this technology has always been designed to be an abstraction layer on top of pretty much any identifier system. No matter if an application uses did:web, a ledger-based DID method, or any other method such as did:key, there is always a common syntax and the common DID Document format which describes the subject. The exact process of obtaining the DID Document for a given DID of course is defined by the method and can vary greatly. In fact, this design has been a common point of discussion within the W3C DID WG, and there have been questions whether such an abstraction layer provides sufficient “useful interoperability”, considering the differences between DID methods.

Initiatives such as the well-known Universal Resolver and Universal Registrar open-source projects at the Decentralized Identity Foundation (DIF) make it easy to use this abstraction layer not only in theory, but also in practice.

These components can be used to perform the standard DID operations (Resolve, Create, Update, Deactivate) across many different DID methods via a single “universal” interface. Building on top of such standard interfaces removes the complexity of bespoke integrations with each method and creates a more “future proof” way of interfacing with DIDs, since applications can easily plug in support for additional DID methods at any time, and layers of concern are cleanly separated. Commercially hosted services such as Godiddy.com also offer this type of interoperability interface as a service.

Realising the True Power of DIDs 💪

A crucial point and takeaway is that did:web adoption presupposes that the power of a DID is in its ability to be resolved to fetch the keys listed in the DID Document. While this is often all that is required for a use case, it only uses a fraction of the potential of the DID Core specification’s extensible design.

Ledger-based DID methods haven now taken DIDs beyond simple resolution, and utilise the persistence and immutability of the architecture to provide trusted resolvable DID URLs to external ledger-rooted resources, such as Decentralized Web Nodes (DWNs), Trusted Issuer Lists, Status Lists, schemas and other governance information.

DID-Linked Resources (DLRs) are game changers ⚡

DID-Linked Resources (DLRs) is an emerging W3C specification that takes ledger-based resources (such as Trusted Issuer Lists, Status Lists, Schema Registries, Overlay Capture Architecture etc) and identifies/retrieves them using DID URL patterns and dereferencing.

It enables organisations to leverage the benefits of on-chain, persistent and verifiable lists and resources, while creating a common syntax for identifying and retrieving them, across any ledger-based DID method. It also reuses the same trust patterns established in the DID Core spec, since the author of a DLR needs to sign the transaction with the same key material within the linked DID Document.

This generic architecture for DID-Linked Resources is shown in the diagram below, and for readers who want to learn more, we’d suggest reading cheqd’s Architecture Decision Record on their technical composition.

DID-Linked Resources diagram

The DLR specification additionally provides a set of query parameters to identify and retrieve different derivations of digital resources, associated with a DID, which may be combined to create rich filters, including (but not limited to):

  • did:example:38428720–301e-4168-abac-c93581f08a3c?resourceId=X
  • did:example:38428720–301e-4168-abac-c93581f08a3c?resourceCollectionId=X
  • did:example:38428720–301e-4168-abac-c93581f08a3c?resourceName=X
  • did:example:38428720–301e-4168-abac-c93581f08a3c?resourceType=X
  • did:example:38428720–301e-4168-abac-c93581f08a3c?resourceName=X&resourceType=X
  • did:example:38428720–301e-4168-abac-c93581f08a3c?resourceName=X&resourceType=X&resourceVersionTime=XMLDatetime
  • did:example:38428720–301e-4168-abac-c93581f08a3c?resourceName=X&resourceType=X&resourceMetadata=true

DID-Linked Resources has currently been fully implemented by chains such as cheqd and Cardano with EBSI also interested in supporting them. DLRs can be applied for various use cases, such as:

  1. Ledger-agnostic AnonCreds
  2. DID-Linked and fully verifiable Trust Registries
  3. DID-Linked and fully verifiable Schemas
  4. DID-Linked and fully verifiable Status Lists
  5. Encrypted DID-Linked Status Lists, Trust Registries or Schemas with Payments required to unlock.

Through using DID-Linked Resources, issuers can include ledger-based Resource in the contents of issued Verifiable Credentials. These resources can be relied upon by Verifiers with full confidence in their authenticity, data integrity and security. Not only can this add additional value to Credentials, but also does not create interoperability challenges as these are only optional “add ons”.

These benefits however, can only be realised using ledger-based DID methods, as with did:web, it would be possible to create DID-Linked Resources, but they would again be vulnerable to the same limitations as the DID method itself.

For this reason, DID-Linked Resources complement ledger-based DID methods, and ledger-based DID methods enable innovations like DID-Linked Resources. This specific development takes the benefits of using a ledger much further than simple DID resolution, allowing issuers to create far more robust roots of trust for full scale, production-ready Self-Sovereign Identity ecosystems.

Decentralized Web Nodes (DWNs) and DID-Relative URLs to establish trust

A Decentralized Web Node (DWN) is a data storage and message relay mechanism which entities can use to locate public or private permissioned data related to a given Decentralised Identifier (DID). DWNs were created by the team at TBD for the furtherance of Web5, an internet based on identity primitives and digital credentials.

The DWN specification utilises the “services” section of the DID Core spec alongside query-based DID URL dereferencing to allow DID Controllers to point to specific storage or messaging endpoints. For example:

  • did:example:alice?service=DecentralizedWebNode &message= toBase64Url( JSON.stringify( { MESSAGE } ) )

This syntax not only uses the security and provenance of a DID, but extends the value of DIDs away from purely resolution, and provides DIDs the ability to authoritatively identify external data and resources, where third parties can be confident that the data belongs to the DID Controller. This has a lot of overlap with DID-Linked Resources, and builds on very similar principles.

With did:web on the other hand, extensibility via the “services” section, while possible, is limited by the same vulnerabilities as the method itself.

Looking ahead

With one eye on the fragilities of centralised DID methods such as did:web, and another on the developments made by a selection of ledger-based DID methods, we hope to see a general movement away from the vulnerabilities of the former.

Already, several initiatives are underway that attempt to combine the benefits of did: web and ledger-based approaches. These include the did:webs, did:webplus and the recent RWOT advanced topic paper on moving beyond did:web, which use the current did:web design as a starting point and propose to add a layer of cryptographic verifiability, auditability and persistence. While such improvements do not fully eliminate the downsides that come with a dependence on DNS and web infrastructure, they do provide good stepping stones away from some of the fragilities of their predecessor.

Looking forward towards the latter, we hope that some of the legitimate players and innovators in the ledger space can begin to undo some of the scepticism rooted here, for three reasons:

  1. Technical innovation: As described above, DID URL dereferencing, service discovery and DID-Linked Resources provide additional benefits to the use of DIDs, in line with their initial conception; where notably, these benefits cannot be gained from using did:web.
  2. Regulatory clarity: We are now seeing strides made in regulatory clarity for ledger-based approaches in the context of eIDAS 2.0, with “electronic ledgers” now set to be listed as valid “qualified trust services” under the European Electronic Identification (‘eID’) framework. 🤞
  3. Accessibility and interoperability: Open Source projects such as the Universal Resolver and Registrar provide interfaces for developers to utilise any supported DID method without a time-consuming integration, using REST APIs.

Although we do not expect a full movement to ledger-based methods overnight, we hope that the information and explanations provided here help readers recognise the benefits that some ledger approaches can now provide over did:web; and, where the use case makes sense, we hope that adopters may be more open to considering these methods into their design decisions.