Premature Standardization & Interoperability
TL;DR: While I applaud the efforts to create “interoperability” in the SSI, decentralized identity, authentic data, and whatever else you want to call this domain, it’s premature to think we 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 – 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.
Here’s my premise – we don’t have standards nor 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 we haven’t reached “interoperability,” and I believe we are far away from deep interop.
First, we have attempted an immaculate conception approach to achieve 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 multiple things that will be needed in the complex symphony of interoperability that we require.
Here’s the starting point for my premise – you can’t skip steps.
It would help if you got 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 between systems 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 used 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 extended periods | – High-value credentials that contain very private information are key – Verifiers of the information are legally required to ask only what is necessary for their query – Offline is essential and, in some cases, critical, but not expected to be running offline for weeks on end |
This is a somewhat artificial but not unreal scenario. Compare the IoT industry with the travel industry; you will see that they are pretty distinct. There certainly are similar patterns, though.
Let’s similarly look at different stacks.
| Stack One | Stack Two |
– used across various integration cases – data from databases, sensors, governments, etc. – the system is message-centric – the system is meant to run on mobile and low-power devices | – Broadly created to meet integration needs 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 sides – 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 multiple industries expands the breadth and significantly: the 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 approaches work better and where there is no need to duplicate capabilities.
The following two paths are more about pressure from outside, and both get pulled into the broader Multiple Ecosystem + Multiple Stack world.
The critical thing to understand here is that an Interoperability Compliance Suite is required for either of the following paths to be viable. This compliance suite sets the conditions by which competitors can point to a reference as their definition of interoperability.
Depending on which path (1 or 2) was taken, we have two courses:
- A Multiple Stack + Single Ecosystem adds support for Multiple Ecosystems (Path 3) – the compliance suites here help 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 unaware of any real interoperable solutions that 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.
Visit our blog, follow us on social media, and subscribe to our newsletter to stay up-to-date and learn more.
