Premature Standardization & Interoperability

TL;DR: While I applaud the efforts to create “interoperability” in the SSI, decentralized identity, authentic data, and whatever you want to call this domain it is premature to think we actually have real “standards.” We have instead, premature standardization and tiny pockets of very focused interoperability.

NOTE: This is an early document that will likely evolve over time — in that more and more depth may be provided. The content may be re-factored enough that what this document looks like in mid-2022 could look wildly different in a short period of time.

Here’s my premise — we don’t have standards nor do we have interoperability — at least not as people really need. We have been through a process that is powerful and good — but what we have is what I call “premature standardization”. It’s a great start but nowhere near where things will be.

There are many reasons that we haven’t reached “interoperability” and why I believe we are quite a ways away from deep interop.

First off, we have attempted an immaculate conception approach to get to interoperability. We think we could define what the baby will be and not do the hard and messy work of really creating something.

You can’t jump the steps required to generate real Interoperability. The reasons are deeper than I will go into right now, but interoperability is born out of the desire for systems to interact. Sure we have that notionally in the various groups attacking this problem — Trust Over IP Foundation, Decentralized Identity Foundation, W3C CCG, and other places — are working to create various things that are going to be needed in the complex symphony of interoperability that we need.

Here’s the starting point for my premise — you can’t skip steps.

You need to get your industry understanding things at a very, very deep and intimate depth. What is really needed as opposed to proposing ideas that haven’t been used in earnest for long enough.

There are two key dimensions that you need to understand.

• Industry/Ecosystems — Are you talking about a single ecosystem or moving between wildly different ecosystems?
• Technical Stacks — Are you talking about interoperability betweens systems that are using the same stack or different stacks?

These two dimensions need to be handled separately.

Each dimension — the Ecosystems and the Stacks have different needs.

Different ecosystems will have competing requirements. Let’s use SSI as an example. Let’s compare two different industries to see their different needs.

Industry One Industry Two

• credentials need to be small and the devices providing them have a severe limit on power draw

• the credentials used are use in total (i.e. their full data payload is always at play)

• the credentials must work when major parts of the system are disconnected or offline for long periods of time

• High value credentials that contain very private information are key

• Offline is important and in some cases critical, but not expected to be running offline for weeks on end

• Verifiers of the information are legally required to ask only what is necessary for their query

This is a somewhat artificial but not unreal scenario. Compare the IoT industry with the travel industry and you will see that they are quite distinct. There are certainly patterns that are similar though.

Let’s look at different stacks in a similar way.

Stack One Stack Two

• used across various integration cases — data from databases, sensors, governments, etc.

• the system is message-centric

• system is meant to run on mobile and low-power devices

— Broadly created to meet needs of integration with IAM systems (e.g. OIDC).

• Used for data sharing in an API web-centric context.

Both stacks above are valid and meet a particular set of needs.

How can these Ecosystems and Stacks be interoperable?

They do this in stages — and IN ORDER.

They all start in a Single Ecosystem and Single Stack. We’ve seen many of these.

THEN they start crossing into the Multiple side — but they really only add one of the dimensions at a time. A Single Stack & Single Ecosystem approach can do one of the following at a time:

• Add Mulltiple Ecosystems (Path 1) — given various business reasons using the same stack and applying the approaches to multliple industries expands the breadth, and importantly, depth of knowledge of where the Stacks meets/falls short.
• Add Multiple Stack (Path 2) — in the same ecosystem adding other stacks into play begins to learn where different approach work better and where there is no need to duplicate capabilities.

The next two paths are more about pressure from outside and both get pulled into the broader Multiple Ecosystem + Multiple Stack world.

The important thing to understand here is that in order for either of the following paths to be viable, an Interoperability Compliance Suite is required. This compliance suite serves to set the conditions by which competitors can point to a reference as being their definition of interoperability.

Depending on which path (1 or 2) that was taken we have 2 paths:

• A Multiple Stack + Single Ecosystem adds support for Multiple Ecosystems (Path 3) — the compliance suites here hep more about context, ecosystem-specific semantics, and syntax.
• A Single Stack + Multiple Ecosystem adds support for Multiple Stacks (Path 4) — this path required Interoperability Compliance Suites to prove that the competing stacks are not finger-pointing.

I am not aware of any real interoperable solutions that have circumvented these paths. Further each transition is expensive in terms of resources (people, time and funds) so the market pulls it. This is a “you can’t push a rope” scenario.

Originally published at Continuum Loop Inc..