Interoperability

Life online would be impossible without interoperability. Without TCP/IP (Transmission Control Protocol/Internet Protocol), a shared set of standards and rules allowing computers to communicate with each other, there would be no internet. Without HTML—Hypertext Markup Language— there would be no World Wide Web. And, as you read this— almost certainly in HTML on the WWW through TCP/IP—a new set of protocols are being built and adopted which aim to create interoperability around new technologies for digital Identity, data sharing, verification, and trust.

What does it mean to have a digital identity? The inter- net and the web evolved with effective ways to identify computers and websites but less so the people using them. Arguably, email addresses became the first way to establish human identity. They are the key building block for creating and accessing user accounts, often as login credentials, in tandem with passwords.

Whether as an email address leased from an email pro- vider, or as a user account brokered by an email account, these digital identities are not owned by us. They can be revoked. Because they are easy to create, they often require additional personal information to be verifiable. All this real-world and virtual data is stored by the “identity leasing agencies”—the myriad companies and services we use online through email and user accounts. This includes the metadata we generate by being online, which is aggre- gated, packaged, and sold on to other parties for undisclosed purposes, but which frequently include marketing and advertising. We must give prior consent to our data being used in this way in order to lease our digital identities. While all of this is presented as either mostly benign or mildly annoying, and unavoidable—a trade-off for the plenitude of goods and efficiencies online—the system isdesigned to fail. Emails are easy to find or guess. Passwords, if easy to remember, are easy to hack. People are easily “phished”into giving up personally-identifying information that can be used to replicate their identity online. Identity fraud is endemic to this system. Data breaches are frequent and expensive, a combination of the cost of lost data, the cost of being fined for losing the data, the cost of meeting increasingly stringent data privacy mandates, the cost of implementing better security, and the reputational cost of lost trust from losing all your customer data. In this system of centralized databases, each identity can be a single point of failure for the entire system. Federated identity, once thought of as a solution, replicates the under- lying problem with higher stakes: if something goes wrong, you lose access to everything tied to your digital identity. New, decentralized identity technologies mean that we can completely overhaul this system. We can establish digital uniqueness independent of any third party. We can generate the kind of verification that enables trust without storing personal information on third-party databases.

Verifiable credentials provide the authentication needed to establish trust in each other and in the data we need to share. They mitigate the compliance burden; they make digital life simpler. Imagine being able to log into any site or service by scanning a QR code. Imagine a world where you can forget your passwords...forever. With the bureaucracy of verification removed and the barrier to trust lifted, the transformation of the digital economy through trusted digital ecosystems can begin. But only if verifiable credentials are interoperable.

Seven aspects of interoperability

All systems are the result of design and technical choices. In designing for interoperability, the following technical aspects of a decentralized identity system must align. Note that some elements in this list (DID methods, some credential formats, etc.) require dependent infrastructure such as a ledger or web-hosted assets. Each element of dependent infrastructure in an interaction must be accessible and acceptable to each party. The scope of interoperability will likely change over time:

Convergence in one area can effectively eliminate its potential for incompatibility, while new technology may introduce new areas of incompatibility. Consider this list as a snapshot in time, subject to adjustment as circumstances require.

  1. DID methods

The fully interoperable stack must be able to resolve the DIDs used by all involved parties. With the number of DID methods available, this is no small feat. The Universal Resolver can solve some of this problem, but only with careful management to avoid relying on the trust of an externally managed system. To trust the results of any given Universal Resolver resolution, one must trust that the code operates properly. To trust the results of a Universal Resolver run by another party, you must trust the other party to have both sufficient security to prevent outside manipulation and to not manipulate the results themselves. This trust is possible but it is not automatic.

  1. Content encryption key types

Information between parties is usually encrypted; there- fore, each party must use compatible encryption keys and a compatible encryption scheme to allow decryption by the other party. Encryption at this level is used to encrypt protocol messaging and credential communication back and forth between parties. 3.

  1. Communication protocols

The methods of communication used between issuers, holders, and verifiers must be common between the parties in any given interaction. Different protocols can be used in each exchange as appropriate, but the combination of protocols must form a continuous chain of communication extending to all parties. Examples of these protocols are CHAPI, OpenID Connect, and DIDComm. 4.

  1. Credential format and signature types

The credential format used must be acceptable to all parties. Credential formats include JSON-LD (as depicted in the W3C verifiable credential data model specification), and JSON-based formats including JWT and AnonCreds. Credentials must also use signature types acceptable to all parties. Signature types include CL-signatures, BBS+, and Linked Data Signatures. Credential revocation methods must also be understood and testable by all parties.

  1. Credential access / storage (wallet)

This may or may not be an issue, depending on how credentials are transferred from one party to another. If transferred directly to and from storage and not via another protocol, the data access needs to be compatible. 6.

  1. Credential protocols and coordination formats

The parties involved in exchanging credentials must communicate with each other about the credential. This includes communicating about the type and content of the credential before it is transferred. Even with identical credential formats, these protocols must be compatible to enable a transaction. Examples of these protocols and formats are the Aries Issue Credential and Present Proof protocols, The W3C Verifiable Presentation Request Specification, and the DIF Credential Manifest and Presentation Exchange formats. 7.

  1. Compatible governance / trust

With digital credentials, the issue of trust is critical but often ignored. Which issuer is the verifier willing to trust? This answer is solved through governance, machine-readable governance, and trust registries.

Examples

  • Aries Interop Profile (AIP) 1.0: This is a leading interoperability standard that is used to ensure a wide range of interoperability between verifiable credential ecosystems. This standard makes it possible for the software components of different ecosystems to “talk” to each other in a way they understand and exchange information.

  • AIP 2.0 Significant coverage

  • OID4VCI

  • OID4VP

  • DIF Credential Trust Establishment V1.0

  • eIDAS 2.0 compatibility (H2 2024)

  • ToIP Machine Readable Governance

  • OWF Credo

  • Aries Cloud Agent Python (ACA-Py) V0.9.0

Copyright 2025 Indicio PBC

PreviousGovernanceNextMediator

Last updated

Was this helpful?