As we all know, interest in the Self-Sovereign Identity (SSI) idea is exploding. More and more projects, companies and initiatives appear every day, working on enabling a world where individuals and organizations (and even things) are in control of their digital identity, without a need for central authorities and intermediaries. As the number of projects and networks increases, we also see growing interest in interoperability and connectivity between such initiatives. After all, what point is there in building more SSI networks that are isolated and only work for themselves? This would only lead to pointless competition between SSI silos, and it would be like a World Wide Web where you need different web browsers for accessing different websites.
Due to the importance of this vision, work has been happening to consolidate technological building blocks and develop interoperability profiles, see for example efforts such as the SSI stack, Aries Interoperability Profiles, Interoperability Matrix, Dual Stack Strategy, Verifier Universal Interface, and eSSIF-Lab.
There is definitely still a lot of work to do, but the good news is: On the lowest layer of the SSI stack, there already exists a solution!
By that, of course we mean Decentralized Identifiers (DIDs). They are used for Verifiable Credentials, various DID Auth protocols such as OIDC SIOP v2, as well as discovery of Secure Data Stores and other building blocks of an SSI architecture. Identifiers such as DIDs are a fundamental prerequisite for the ability to refer to subjects and resources, to establish connections and relationships, and to provide functionality such as authentication, data sharing, and messaging. On the technical level, the DID document contains verification methods and service endpoints that enable this functionality, and on the human level, DIDs are essentially the link between a physical and digital identity.
Or to quote the W3C DID Core specification:
„DIDs are URIs that associate a DID subject with a DID document allowing trustable interactions associated with that subject.“
The beauty of this basic building block is that it has been designed from the beginning to not be limited to a single specific technology. There is no need to work on interoperability layers between DIDs, because DIDs are that interoperability layer. They provide an abstraction via a common syntax and common data model, and they support any network that is capable of creating and maintaining DIDs, using so-called DID methods. Such DID methods may be implemented in many different ways and may use a variety of concrete technologies such as blockchains, distributed ledgers, file systems, or even existing centralized or hierarchical infrastructure such as the domain name system or the web. Even though not all DID methods may be considered strictly decentralized, this design where DIDs fit on top of any technology is itself a form of decentralization, and a key enabling technology for the Network-of-Networks.
Figure 1: Entities using different SSI networks for the DIDs that identify them.
A wide variety of networks already exist today, such as the European Blockchain Service Infrastructure (EBSI), Sovrin, IDunion, the Dutch Trust Network (DTN), Findy, Alastria, Indicio, Bedrock, and others. The Trust-over-IP foundation calls these DID networks „Layer 1“ and envisions an ecosystem of „public utilities“ that will provide „technical trust“ for higher layers such as agents, credentials, and concrete end-to-end use cases.
In order to use DIDs, tools known as DID resolvers are used. These come in many forms, with different architectures and various capabilities. Some DID resolvers are designed to be integrated directly with wallets and agents (and maybe in the future even with operating systems!), while other DID resolvers are operated as hosted services (which of course has certain tradeoffs in terms of security and trust).
Figure 2: Verifier using a DID Resolver to resolve Issuers from multiple SSI networks.
Perhaps the best-known DID resolver project is the Universal Resolver at the Decentralized Identity Foundation (DIF). This is actually an aggregation of smaller resolvers called „drivers“, which are contributed by the community and together implement many different DID methods. With this, it is easy to demonstrate how multiple networks can be supported within a single application or service, e.g.:
Example EBSI DID:
https://dev.uniresolver.io/#did:ebsi:zuoS6VfnmNLduF2dynhsjBU
Example Sovrin DID:
https://dev.uniresolver.io/#did:sov:WRfXPg8dantKVubE3HX8pw
Example IDunion DID:
https://dev.uniresolver.io/#did:sov:idu:6iHBriJn1DVJt3AjLEuHYL
Example Gataca DID:
https://dev.uniresolver.io/#did:gatc:2xtSori9UQZdTqzxrkp7zqKM4Kj5B4C7
Example Jolocom DID:
Whereas more experiments, pilots and implementations are needed to demonstrate this network-of-networks interoperability in practice, it clearly shows that on the foundational technical layer, the Network-of-Networks is already possible today!
