The Catch-22 of Interoperability

The tension between interoperability and innovation holds IDtech products hostage. Here’s my take on what to do about it.

Photo by Sam Goodgame on Unsplash

New technologies need to provide unique value to be adopted. Web5, which I use as shorthand for verifiable credentials, decentralized identifiers, and personal data stores, offers “an extra decentralized web platform.” Unfortunately, simply being more decentralized or “self-sovereign” doesn’t generally lead to unique value being realized by end-users. The real end-goal of web5 is a universally-accepted and useful digital ID–a goal only achievable through interoperability. Thus, the unique value of web5 is interoperability, or more precisely, the extreme convenience and high trust interoperability delivers to identity products.

But herein lies a “Catch-22”: developers won’t adopt new technology unless it adds unique value, but interoperability requires widespread adoption to pay dividends. It’s the classic network effect, or chicken-and-egg, problem. I call it the Catch-22 of Adoption.

But there is another, highly-related, highly-pernicious, and less-obvious Catch-22 keeping web5 from breaking out and realizing its true potential. I call it the Catch-22 of Interoperability.

The Catch-22 of Interoperability

The Catch-22 of Interoperability is simple: A direct conflict exists between interoperability and innovation–but both are mandatory for web5 to become a breakaway success and achieve its vision of a self-sovereign future.

Let’s first clarify: by innovation, I’m referring to a particular technology’s search for “product/market fit” which involves iterating until it solves a unique problem well. By interoperability, I’m referring to the near-universal acceptance of websites, regardless of browser; email, regardless of which client sent it; bluetooth, regardless of headphone manufacturer; or Visa cards, regardless of merchant. (Juxtapose these examples with the silos and inconveniences resulting from the lack of messaging interoperability–a fate nobody wants identity to conclude with–where iMessage can’t communicate with What’sApp or Signal or Line or Telegram or dozens of others.)

To understand why a conflict exists between interoperability and innovation, it’s helpful to understand that the core tenants of web5 (verifiable credentials, decentralized identifiers, and personal data stores) each have numerous incompatible variants competing* for adoption:

• verifiable credentials: AnonCreds, W3C VCs, SD-JWT, ACDC, ISO 18013–5, etc.
• decentralized identifiers: 100+ DID methods, KERI/ADIs, DNS/x.509-based, etc.
• personal data stores: ID wallets, DWNs, Solid Pods, crypto wallet + decentralized storage, etc.
• interaction protocols: DIDComm, CHAPI, OIDC4VC, WACI-PeX, CESR, DWN routing, etc.

Theoretically, if the teams working on these divergent approaches agreed to converge on a single standard, we’d quickly reach a critical mass sufficient to realize the value of interoperability. I’ve seen people campaign for such an outcome — but prematurely standardizing is a dangerous prospect for a new technology. Standards move at a snail’s pace, and new technologies need to quickly evolve until a “product/market fit” is reached. Standardizing before adoption puts the cart before the horse.

On the other hand, unfettered innovation leads to divergence. The free market will adopt technologies based on their merits — and better technical innovations will lead to better products that lead to more adoption. For example, despite several existing options for using selective disclosure in verifiable credentials, SD-JWT has been introduced as an alternative innovating on simplicity and ability to integrate with existing JWT-based authentication systems. But despite divergence being a healthy part of new technologies finding “product/market fit,” its downsides are obvious: confusion in the market, duplication of efforts, and delaying the benefits of interoperability.

Thus full interoperability leads to minimal innovation, and full innovation leads to no interoperability. So what is the solution? The solution is to strike a balance between these two demands.

Adoption will come from the intersection of these competing forces. The key is to strike a balance.

Four Approaches to Balance Interoperability and Innovation

We’ve established that innovation and interoperability are both necessary, but in opposition to one another. So where does that leave us? As a relative newbie in the identity space (going on 5 years) I’ve seen 4 approaches taken to balance the trade-offs of innovation and interoperability. I don’t intend to make a value judgment on any of these–each approach has its pros and cons.

1. The innovate-by-committee: In this model, interoperability is consistently maintained by suggesting new features & improvements in a committee of other companies, likely in a working group, community group, or through an RFC process. While great for interoperability, it’s tragic for innovation. It’s infeasible to expect even the most brilliant people to be able to effectively build the “right” thing sitting in a boardroom. Does Feature A need to support Capability X? A Zoom-call debate with like-minded individuals is no match for customer evidence. The only way to truly innovate is to iterate, with real-world usage, which requires speed.
2. The fit-and-start: In this model, interoperability is achieved periodically while minimizing the need to slow innovation. Implementers race forward with innovation and contribute the things that are working well back into the community. Usually vendors need to support older (interoperable) versions and newer (more innovative) versions of their products, which is a costly trade-off of this model. Success with this model is challenging in practice — the interoperability devil is in the details which can confuse the market.
3. The interop-as-feature: This is where interoperability is viewed as a means to unlocking product value as opposed to an end in and of itself. In this model products are usually not interoperable until a specific reason arises, like a partnership or customer demand. Other times, products are built using interoperable standards because those standards unlock features out of the box — but not because of interoperability itself.
4. The “de-facto” maximalism: This approach cares only about innovation, believing that the best mousetrap will become the de-facto standard that the marketplace adopts regardless of most other factors. While great for innovation, there is a graveyard of failed identity companies who’ve attempted this strategy. Builders beware.

Web5 has a Bright and Interoperable Future

The Catch-22 of Interoperability is surely an obstacle to widespread adoption of web5 — but I believe it’s surmountable. I hope that by getting more specific and nuanced in our discussion of interoperability, we’ll better navigate the trade-offs and requirements we all face.

I have a short list of suggestions that I believe will help the community press forward on this complex topic.

1. Above all, focus on building products people love. I can’t stress enough that the most elegant, interoperable technology on earth will be meaningless without end-user adoption. People adopt products, not technologies. Luckily, we’re seeing IDtech companies launch faster than ever before thanks to web5.
2. Brand loyalty for standards is silly. Different requirements matter for different use cases. Rational implementers should evaluate technical decisions based on business requirements. But instead, I consistently see people so intoxicated with JSON-LD or Aries or KERI or <insert flavor of the month> that their rhetoric borders on religious fervor. Force-fitting round pegs into square holes is no way to accomplish goal #1 of building great products.
3. Interop-shaming is short-sighted. I hope I’ve made it clear in this post that interoperability and innovation both matter. Teams delaying interoperability are simply making a different set of trade-offs compared to teams obsessively maintaining interoperability. The market will decide which approach is rewarded. Despite my cautioning builders to beware “de-facto” maximalism, we need a marketplace full of various approaches to maximize our odds of adoption.
4. Interoperability for demo’s sake can be a good use of time. Despite pockets of compatibility in some ecosystems, little-to-no real-world interoperability has been realized (let me know if I’ve missed something!). That said, demos of interoperability have driven more developers, interest, and investment into the space. Sometimes the best way to visualize the future is to see it in the form of working code — as long as it doesn’t detract too much from point #1 😊. I’m grateful for people at ToIP, OWF, DIF, Hyperledger, and other places for their efforts to prove and demo interoperability.

As always, these thoughts and learnings continue to evolve. Please tweet at me if you think I’m wrong, or want to add to my points, or add me on LinkedIn to follow our journey. As always, if you’re building an IDtech product and are curious about how interoperability fits into your roadmap, I’d love to workshop it with you — find me at Riley (at) trinsic.id.

Footnotes:

* I’m aware that not all of these standards are necessarily in direct competition. It’d be possible to package a verifiable credential proof inside a mDL container, or serializing DIDComm messages using CESR, for example. But for all practical intents and purposes, these variants are each substitutes for one another.