Illusion of interoperability

True interoperability is critical in preventing vendor and technology platform lock-in. Here are some pointers to pierce the illusion of interoperability being peddled by people seeking to lock you into their blockchain and SSI products.

Let us start out with two relatively easy things to look out for:

1. A hub and spoke platform play where one platform or technology is required to mediate interactions between multiple, independent organizations. Often, the platform provider’s service arm will work to on-board the organization into its platform. The demonstration of interoperability is seeing the organization interacting with all the other organizations that are connected to the platform using the platform’s APIs or bespoke connectors. This is in no way demonstrating interoperability but simply the 21st century version of the enterprise service bus (ESB).
2. A subtly different approach is the requirement that each independent organization use the same technology stack. The demonstration of interoperability in this scenario tends to be multiple, independent organizations who have chosen the same technology stack, often with an open source branding and associated technical governance, using its well documented APIs to showcase how they can all work together. This will work within that particular technical ecosystem, but this is software monoculture and not interoperability.

Start with architecture and standards

The common thread that runs thru both of the above situations is of choosing a product first, and having the solutions to the problems you have be constrained and limited by what the product can and cannot do. Classic golden hammer problem which many product vendors love and encourage!

Instead, what I would recommend is to start with a broadly applicable architectural model for issuing attestations and credentials and verifying them. The one that is directly applicable to the blockchain and the SSI ecosystem is the W3C Verifiable Credential Data Model:

The model brings with it a set of actors including the issuer of credentials, holder of the issued credentials, verifier of issued credentials and verifiable data registry of identifiers and schemas used. In a majority of the cases, the holder and the subject of the credential are one and the same.

The specification that can be used to uniquely identify these entities in a privacy respecting manner is the W3C Decentralized Identifier (DID) specification. A DID solves the long lived problem that comes about with the conflation of identifiers and authenticators, by enabling the clear separation between a globally resolvable but meaningless and unique string and the ability for an entity to strongly prove their ownership of that meaningless but unique string.

Require swappable pieces

The key point that ensures that you are working in a truly interoperable environment is by verifying that each entity in the model can be swapped out with another technology provider using a completely different stack or platform by supporting the same standards and specifications.

Some items to pay particular attention to are:

• Can the same Credential Issuer API be used by an issuer with different holder wallets and different verifiable data registries?
• Can the same Credential Verifier API be used by a verifier with different holder wallets and different verifiable data registries?
• Can the wallet used by the holder support multiple issuers, multiple verifiers, and multiple verifiable data registries using a common set of APIs?
• Can the issuers and the verifiers support a common set of APIs to interact with DID resolvers they consider to be trustworthy?
• Can the issuance infrastructure, wallets, verification infrastructure and the verifiable data registry all support common or pluggable cryptographic algorithms for hashing, encryption, digital signatures, random number generation and any other relevant cryptographic operations?
• Is there a way to provide selective disclosure of credential information without building in a dependency on a specific verifiable data registry?

I’ve noted before my concerns with wallets, but I also wanted to point out that if those concerns are properly mitigated, you also end up in place where the holder of the wallet has significant agency, and the issuers and verifiers have flexibility while not being locked into a particular vendor or platform:

By explicitly setting the expectation that all of the entities in the model above are not built, managed or operated by a single entity, but instead by an ecosystem that enables a pluralism of operators and technologies, you can ensure interoperability, encourage diversity, and prevent technology and vendor lock-in.

Keeping it on the rails

The pointers I am providing are at the foundational layer of the model and there is active work going on that is building on top of it. It would behoove those who have a vested interest in interoperability to track and champion this work to ensure that it does not derail.

cyberLinks: random and relevant

• Secure Data Store (formerly known as Encrypted Data Vaults) is a joint work item at the Decentralized Identity Foundation (DIF) and the W3C Credential Community Group (W3C CCG) and “.. describes a privacy-respecting mechanism for storing, indexing, and retrieving encrypted data at a storage provider. It is often useful when an individual or organization wants to protect data in a way that the storage provider cannot view, analyze, aggregate, or resell the data. This approach also ensures that application data is portable and protected from storage provider data breaches.”

• Universal DID Resolver is a work item at the DIF. You can find an explanation here and implementations by the DIF here and by Transmute Industries here. I can envision a future where organizations may choose to run their own resolver or only trust external resolvers they have confidence in.

• BBS+ Signature Linked Data Proofs - This work on Selective Disclosure was shared with the community by MATTR at the last Internet Identity Workshop. The video of the presentation can be found here. Now a work item at the W3C CCG.