TBD x cheqd: Accelerating Web5 adoption with payment rails and extensible DID URLs

,

Hey TBD folks :wave:, Alex here - Product Manager and Governance lead over at cheqd. I stumbled across your incubator announcement today, and well, I think there may be an excellent opportunity for TBD and cheqd to collaborate and build together.

In this thread I will explain how I believe TBD and cheqd to be complimentary, and where cheqd’s Resource Module and Payment functionality could help accelerate the adoption of Web5.

What is cheqd?

cheqd is a blockchain network that sits at Layer 1 of the ToIP stack. cheqd acts as a Verifiable Data Registry for anchoring DIDs (and resources as discussed further down). cheqd has a native token, CHEQ, for paying for identity writes to the network, as well as being used to facilitate payment rails for Verifiable Credentials (as discussed further down).

How could TBD and cheqd jam?

There are three main ways cheqd and TBD could benefit from each others’ products and work together:

  1. Improving existing paradigms for schemas, trust registries and revocation registries;
  2. Creating Payment Rails to accompany the flow of Verifiable Credentials;
  3. Striving towards Interop and multi-network support.

I will discuss these three benefits in turn:

Improving existing paradigms for schemas, trust registries and revocation registries

One area cheqd has spent a lot of time working in the previous few months is in improving how ‘Resources’ associated with Web5 ecosystems can be stored and retrieved in a more decentralised and resilient way.

Schemas, for example, are generally still stored on schema.org, which although has its merits, is hosted on a web server, which may act as a centralised point of failure for Web5 ecosystems.

Similarly, revocation models such as StatusList2021 use Verifiable Credentials hosted on a central server to store the relevant bitstring for checking Credential status. Again, if this goes down, so does the Web5 ecosystem.

cheqd has pioneered a new approach for storing and referencing Resources associated with Web5 ecosystems in a more resilient way, using the security features of DIDs and extensible DID URLs.

Let’s take a simple DID to explain:

did:cheqd:testnet:zB5wPyMGYL4LbT424Z7yXHm6nZrrLqZZ

^ This DID resolves to a DID Document, identifying the Verification Method keys used to update/manage the DID.

When creating a resource on cheqd, you must associate a Resource with a ‘Parent’ DID - in a way which organises Resources into Collections, which can be managed using the same Verification Method keys used to update/manage the Parent DID Document.

This is an example of a Resource syntax:

did:cheqd:testnet:zB5wPyMGYL4LbT424Z7yXHm6nZrrLqZZ/resources/4e2ba734-ae3d-4ca3-9657-c717c3dd6184

You can click the link below to resolve the DID or the resource itself to fetch the resource or associated metadata.

https://resolver.cheqd.net/1.0/identifiers/did:cheqd:testnet:zB5wPyMGYL4LbT424Z7yXHm6nZrrLqZZ/resources/4e2ba734-ae3d-4ca3-9657-c717c3dd6184

Via this extension of DIDs, TBD would be able to create more robust and resilient schemas, trust registries and revocation registries as resources, referenced via DID URLs. This could also be used to store visual representations of Verifiable Credentials, like those worked on at OCA. I’d love to discuss this further and explore opportunities to innovate with Resources ft. DID URLs together.

Creating Payment Rails to accompany the flow of Verifiable Credentials

There is a chicken and egg problem in Web5: Large volumes of Verifiable Credentials in circulation will reduce costs for enterprises and incentivise more organisations to issue/consume them. However, prior to large volumes of Verifiable Credentials in circulation, there is little incentive for enterprises to shift their existing data management systems to Web5.

The of the fundamental goals of cheqd is to solve this chicken and egg problem by making it commercially beneficial for issuers to switch to Web5 and begin issuing VCs by providing payment rails to accompany the flows of VCs.

For example:

A Verifier may pay a small fee each time they check a revocation status within a VP. This fee gets accumulated and paid back to the issuer in batches (to preserve privacy and prevent correlation). The issuer therefore gets a recurring revenue stream, and the verifier saves costs in doing KYC.

A Holder may pay a small fee to purchase a VC off an issuer. For example, this could be useful for purchasing a digital University degree, or a Digital Drivers’ License. This gives the holder greater sovereignty and control of their data, and provides the Issuer a recurring revenue stream.

A Verifier may pay a Holder a small fee for sharing extra preference data in the form of a VP. The Verifier benefits by getting higher quality data, and the issuer benefits by making profit / taking ownership of their own data.

cheqd’s payment rails could be layered on top of TBDs existing SDK and technical stack. TBD would not even need to use cheqd DIDs, but could continue using the existing DID methods supported. This is because cheqd is building towards a payment gated (and privacy preserving) Revocation Registry, which could be specified when issuing VCs using TBDs existing SDK.

Payments is a huge unknown in the Web5 space, and I would love to explore the potential of discussing this further and expanding on our approach.

Striving towards Interop and multi-network support

In the world of Web5 there will not be 1 network to rule them all. Instead, multiple different networks and technical stacks will need to work simultaneously, a bit like how VISA, Mastercard, Amex etc., can all work seamlessly together using functional middleware.

I am of the opinion, therefore, that TBD should strive to support:

  1. As many different Layer 1 networks as possible, each maybe with different USPs; and
  2. As many different Verifiable Credential types and exchange methods as possible.

Through a partnership with cheqd, TBD could, firstly, give its customers another option in terms of the network layer, with benefits such as payment rails.

Secondly, cheqd currently supports all three main Verifiable Credential types (JSON (JWT), JSON-LD and AnonCreds) in various SDKs (Veramo SDK for cheqd, Aries Framework JavaScript).

(The AnonCreds support has been facilitated by being able to store Credential Definitions and AnonCreds Revocation-based accumulators on cheqd via the Resource Module.)

While TBD currently only focusses on the former, it could extend its SDK to support the latter Credential types for clients/customers with more nuanced preferences (such as predicate proofs with AnonCreds, or BBS+ sigs). Having decoupled AnonCreds from Hyperledger Indy, this is no longer as much of a vendor-lock-in problem.

Furthermore, we’d also love to explore the option of using the Decentralised Web Node model with our existing SDKs for storage etc. This could see greater adoption of both cheqd and TBDs product offerings.

Conclusion

I’ve rambled for a while here, but I hope there are some nuggets that resonate with the TBD team. Ultimately, the cheqd team and community would love to explore the possibility of a partnership, alliance or collaboration with what you’re building on Web5 and with DWN. There are many avenues we could go down, so looking forward to hearing your thoughts!

4 Likes

Just chiming in here as well, hi I’m Ankur (CTO/co-founder) at cheqd. We love the work and open-source packages that TBD has been releasing, and would love to collaborate with your teams. In particular, I’d really like to see if we can work together on our idea on payment rails for identity exchanges, since this is close to the area Square/Block are involved in.

Always happy to have a chat!

Welcome, and thanks for the insightful post. I too have been wondering about payment integration into VC/DID flows. My biggest concern is how to do this in a privacy preserving manner. Without careful design, I believe adding monetization schemes to VCs/DIDs could undermine most if not all of the privacy benefits the technology can enable.

I’m most interested in the “privacy preserving Revocation Registry” you are working on, and how this addresses phone-home issues that plague other monetization schemes. I have been thinking for a while that issuers should never host their own revocation lists, instead we need a network that enables issuers to incentivizes others to store and replicate revocation/status lists on their behalf. Neutral network fees (treating the DWN/DID network as a utility) could be a monetizaiton mechanism. I’m curious to learn more about your thinking and experience here.

I agree with you here in principle. In practice, this is what we’ve done too. The SDK today supports both Data Integrity and JWT style integrity wrappers. We don’t think we should pick winners. However, at some points this distinction is tougher. Should we support DIDComm? If we do, we could undermine the chances of DWNs reaching widespread adoption, and we believe they are a more complete solution.

At some point we reach a tradeoff between optionality and complexity. We want to make the standards and tech as simple to use as possible and also support interoperability. These values can be at odds - as mentioned above we could be harming adoption and interoperability by supporting ‘competing’ specifications.

At the same time as I believe that there are no clear winners yet in terms of payments, DID methods, transport mechanisms, signature schemes, VC encodings, and semantic messaging I also believe there will be winners and easy to use opinionated software can help crown those winners, and achieve wide-spread interoperability throughout the ecosystem, which I think we would all agree is a shared goal for the acceptance and adoption of the SSI stack.

I’m also interested in ZKP and selective disclosure schemes. I would like to first support BBS+ and have an open issue. The go-aries project has an implemented, though it does seem tightly coupled to the aries world. I have mostly watched AnonCreds from the sidelines because they make a number of changes that deviate from the VCDM without highly specialized technology. I have loosely been following the decoupling effort – it could be the right time to take another look.

That said, @csuwildcat has advocated for us to look into the SPARTAN scheme as an improvement over Anoncreds, providing predicate proofs and having mechanisms that reduce correlation risk. I know the work for SPARTAN is on-going in DIF. Microsoft has a Rust library that implements the scheme, and which we will explore integrating into the SDK.

Great questions! To take those in turn:

My biggest concern is how to do this in a privacy preserving manner. Without careful design, I believe adding monetization schemes to VCs/DIDs could undermine most if not all of the privacy benefits the technology can enable.

The basic idea is to only ever do payments in aggregate, into escrow accounts, so that there are no direct, atomic payments between verifiers and issuers. An atomic payment would be the same as the way some revocation mechanisms such as StatusList2021 et al “leak” whose revocation record was looked up. @Tweeddalex and I gave a talk at DIF’s conference last year called Seven Deadly Sins of Commercialising SSI where we spoke of the privacy leakage vectors and how we’re looking at addressing them.

Even for other revocation mechanisms such as Hyperledger Indy tails files, the tails file server is a privacy leakage vector since it can at the very least record IP addresses, client headers, or understand how frequently a client app is waking up to fetch updates. We want to avoid that through the mechanisms we describe in the video.

Should we support DIDComm?

No, that’s not how I think we achieve interoperability, i.e., it doesn’t need to go that far down in the pipes. My baseline is that someone might not have an identity wallet, and therefore should be able to save an expiry-gated copy in Apple/Google Wallet as a pass file. This is the same as having an offline copy printed on paper. QR/JSON should be the lowest common denominator and it should be up to the recipient/verifier whether they find this acceptable. If it can be upgraded to live exchange like VP Present, DIDComm, etc great - but it shouldn’t be mandatory.

Would love to explore what you’re looking at for Spartan! I’m catching up with @benboeser on Friday in case you wanna join. I’m also in San Francisco for IIW and staying a couple of days extra that week in person.

1 Like

It took a while for me to write this up… This is one way I see DWNs and DIDComm and DIDComm Agents playing well together: check out the Layer 6 Web 7.0 DIDComm Agent Architecture Model in the DIDComm-ARM whitepaper