[This post was originally submitted by Oliver Terbu to DIF's medium.com]
For anyone who isn’t working on the emerging technologies and concepts being developed in the self-sovereign identity (SSI) community, it can be difficult to track and digest all the concepts, tools, and specifications it generates. Further, with an explosion of interest and work in the community from countless people and organisations, SSI technologies are evolving very quickly. Active development happens across a wide range of technical areas, so it is crucial to have a common terminology and define the boundaries between them, while still allowing room to innovate in a way that drives interoperability and portability of SSI technologies.
At the Internet Identity Workshop (IIW) XXVII in Mountain View,
Oliver TerbuandRouven HeckfromuPort|ConsenSysinvited other experts from theDecentralized Identity Foundation (DIF), and people in the identity space (e.g.,W3C Verifiable Claims Working Group) to jointly work on an SSI stack definition. Usually, these groups work closely together, and in fact, many members have multiple and overlapping affiliations. It is key that in order to discuss the differences, we need to first understand the layers of the architecture.
The idea of having an SSI stack was inspired by the OSI model, which today is mostly obsolete, but at the time of development, promoted interoperability by establishing abstractions.
The purpose of the OSI reference model is to guide vendors and developers so the digital communication products and software programs they create will interoperate, and to facilitate clear comparisons among communications tools.
During the session, we drafted a first version of the SSI stack, defined layers that depend on each other, discussed responsibilities, and boundaries between them. The result also facilitates understanding by providing an overview of what the SSI community is building. The workshop was very well attended by a full room of rock stars from the SSI and related identity communities.
First Version
The following is a summary of what we have achieved so far, based on the results of the workshop and the great wrap-up provided by
Kyle Den Hartog(Evernym) andDaniel Buchner(Microsoft). These are the layers required to keepinteroperabilityandportabilityup to the Application layer. The compatibility layers described here may not be final layers required for SSI interoperability and portability; additions or modifications may be made as we iterate.
The intended goal is to outline the different layers of compatibility that have been discovered which could break interoperability and eventually portability of SSI.
Usages
While this document outlines these layers as being decoupled, it is possible that layers may be coupled to achieve simplicity, scalability, or usage of other standards. Whatever the reasoning may be, it is possible that an SSI stack can be achieved while coupling these layers. An example of how this may occur is through JWEs. If JWEs were used, they would define the Encoding and Encryption layers by adapting the specification that is already outlined. Additionally, DID method specs could stretch over the DID resolution, DID operations, DID storage, and Anchor layers. This is acceptable assuming that it allows for interoperability and portability still.
Application Layer
This layer intends to provide real-world value to consumers. This layer should be the integration of a UI layer, implementation interfaces, and payload structures. Additionally, the “message flows” or “subprotocols” are optionally open-source or proprietary message protocols which will define how the implementation interface and payload will be used in combination with a UI/UX layer to create an application or extension that relies upon SSI.
Implementations Layer
The Implementations layer is a way to wrap the layers below in an easy to consume library or service intended to run “standardised” interfaces. Underneath the standard interfaces may be different optimisation strategies for synchronisation and communication, while still allowing for interoperability and portability of data and applications. Examples that are being worked on are DIF Hubs, Indy Agents, and the uPort app which encompass many different aspects of the layers below. Implementations will be extensible through the creation of non-standard payloads that can be used by a developer to easily integrate SSI into their projects.
Payloads Layer
Payloads are intended to be standardised or proprietary message families (a set of standardised or proprietary schemas) which will be used to pass data between identity owners. Payloads enable the richness of applications to exist like they do today while being able to strongly identify users through the other layers. It’s expected that payloads can be either proprietary or open source standardised formats depending on the needs they’re serving. For example, a standardised admin payload would be open sourced to remotely control an implementation which is hosted on a different device. On the other hand, a rideshare service could develop proprietary message flows to develop their ridesharing service on top of SSI. Additionally, the structures of the format of the schemas must be considered at this layer. Currently, JSON-LD, JWT, and CWT (COSE web tokens) have been options that have been discussed.
DID Authn Layer
This layer is focused on proving control of a DID based on verifying ownership/access to keys listed in its corresponding DID Document. It aims to address how two DIDs using different key suites can negotiate proof of control and authentication. Within the community, many different methods for proving ownership of a key have been discussed. These are described in the Spring 2018 DID-Auth document.
Encoding Layer
With the encoding layer, the purpose is to focus on how data at the encryption layer and the payload layer will be encoded. It is likely that multiple encoding schemes will be required depending on other layers. For example, to send a message through a URL, the encrypted JWE might be Base64URL encoded and embedded in the URL. Alternatively, if the message is being sent through an HTTP request, it may be passed as a JSON structure. Some other options that may fit in this layer are ProtoBuf, Cap’n Proto, and MessagePack.
Encryption Layer
The encryption layer determines how messages, data, and other related payloads are encrypted between two or more devices owned by an identity owner. Additionally, this layer determines the method in which two identity owners can encrypt messages between themselves to create an end-to-end encryption model between two or more devices running either the same or different implementations. This layer should also define the cipher suites that are used and how the cipher suites are agreed upon. Some current examples of standards that currently cover this (and other layers) are the JWE specification. Cases that would fall under the cipher suites part of this layer would be XSalsa20-Poly1305, AES-GCM, XChaCha20-Poly1305, etc.
Transport Layer
This layer is intended to outline the different types of transport layers which are supported. In some implementations (e.g., uPort, Indy agents) it’s been discussed that the transport layer should be transport agnostic (supports any transport protocol) whereas, in other implementations, it may be limited to one or a few transport layers. This layer is important to consider as it will affect the ability to send messages between two identity owners. Some examples of transport layers which have been considered are QR Code, HTTP, BLE, NFC, FTP, SMTP, and Avian Carrier.
DID Resolution Layer
The DID resolution layer is intended to cover how a piece of software or a developer who is writing software can convert a DID into a DID Document and ultimately get the cryptographic keys, service endpoints, and additional metadata that describe usage of the DID. Currently, there’s a few ways that resolution can occur. One of the ways that has been worked on recently is the Universal Resolver which is a service that can be locally ran or queried through a HTTP service. Additionally, an SSI stack could use a native method of DID resolution that is defined in a DID method specification.
DID Operation Layer
In the DID operation layer the concerns focus on how to perform CRUD (Create, Read, Update, Delete) functionality on a DID Document. This is something that is defined in a DID method specification, but without a standardised method of operation it will create challenges an implementation developer to achieve portability. Some examples of where these are being defined can be found in the W3C draft DID method registry document.
DID Storage Layer
Storage of DIDs and DID Documents are sometimes handled in this layer. Typically, this is used when a DID method has separated the storage of the DID Documents and DIDs from the trusted network which resides at the DID Anchor layer. Examples of this may be the sidetree protocol or could be built directly into the Anchor layer as is the case with Veres.One and Sovrin.
DID Anchor Layer
The Anchor layer is focused on the network which provides the environment where DIDs live. It is usually used to validated the DIDs onto the ledger to give a state of the DID to those who have access to the ledger. The differences in this layer typically come from a difference in architectures of the network. Examples of different anchor layers would be Bitcoin, Ethereum, Veres.One, RChain, Sovrin, etc.
What’s next?
Weinvited everyone in DIF to describe what they are building into the SSI stack and have already received contributions from Blockstack, Danube Tech, Jolocom, Microsoft, Hyperledger Indy, and uPort. We have scheduled follow-up meetings within DIF to get feedback from implementers on the usefulness of the approach and fine-tune the stack as needed. Many thanks to all participants at this point.