# SSI Protocol Stack

## Goals
The intended goal of this document is to outline the different layers of compatability that have been discovered which could break **interoperability** and eventually **portability** of self sovereign identities. One of the key concerns that has arisen is that in order to even discuss the differences, we need to first understand the layers of the architecture. This is the current state of layers that have been identified which need to have commonality to keep interoperability and portability with the exception of the application layer. It is not certain at this time that this is all layers or areas of concern that need to be addressed. More may be added in the future.

## Usages

While this document outlines these layers as being decoupled it is possible that layers may be coupled in order to acheive simplicity, scalability, or usage of other standards. Whatever the reasoning may be, it is possible that a 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.

## Layers

| Layer Name | Example|
| -------- | -------- |
| Application | Selective disclosure, music app, rideshare service, extensions, etc |
| Implementations | DIF Hubs, Indy Agents, uPort app, etc |
| Payload structure | JSON-LD, JWT, COSE Web token, etc |
| Encoding | ProtoBuf, Cap'n Proto, Message Pack, JSON, CBOR, etc|
| Encryption |Ciphersuites , JWE, etc|
| DID Authn | Key ownership, verification |
| Transport | QR Code, HTTP, BLE, NFC, FTP, SMTP, etc |
| DID Resolution | DID -> DID Doc / Service and Key resolution |
| DID Operations | CRUD support for a DID Doc |
| DID Storage Layer | Optional, separate storage of DID metadata - e.g. IPFS |
| Anchor Layer | Bitcoin, Ethereum, Veres.One, Sovrin, etc. |

#### Application layer description

The intention of this layer is to provide real world value to consumers. This layer should be the integration of a UI layer, implementation interfaces, and payload structures. Additonally, the "message flows" or "subprotocols" are optionally open-source or proprietary message protocols which will define how the implementation interface and the payload will be used in combination with a UI/UX layer to create an application or extension that relies upon SSI.

#### Implementations layer description

The implementations layer is a way to wrap the layers below in an easy to consume library or service which is intended to run "Standardized" interfaces. Underneath the standard interfaces may be different optimization strategies for syncronization and communication, while still allowing for interoperability and portability of data and applications. Examples that are being worked on currently are DIF Hubs, Indy Agents, and the uPort application 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 Self sovereign identity into their own projects.

#### Payload layer description

Payloads are intended to be standardized or proprietary message families (a set of standardized 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 be able to strongly identify users through the other layers. It's expected that payloads can be either proprietary or open source standardized formats depending on the needs they're serving. For example, a standardized 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 own ridesharing service ontop 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 description

This layer is designed to focus on key ownership and verification of keys that are listed in DID Docs. It will need to be able to address how two DIDs that use different key suites will authenticate ownership of a DIDs. There's been discussion about some aspects of ideal situations which outline different methods to prove ownership of a key and verify ownership of a key. These are outlined in the Spring 2018 DID-Auth document which can be found [here](https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/blob/master/final-documents/did-auth.md).

#### Encoding layer description

With the encoding layer, the purpose is to focus on how will data at the encryption layer and the payload layer will be encoded. It's 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, Message Pack.

#### Encryption layer description

The encryption layer is intended to be focused on how messages, data, and other related paylods 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 ciphersuites that are used and how the ciphersuites are agreed upon. Some current examples of standards that currently cover this (and other layers) is the [JWE specification](https://tools.ietf.org/html/rfc7516). Examples that would fall under the ciphersuites part of this layer would be XSalsa20-Poly1305, AES-GCM, XChaCha20-Poly1305, etc.

#### Transport layer description

This layer is intended to outline the different types of transport layers which are supported. In some implementations (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 transport layer.

#### DID Resolution layer description

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 recentaly 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 description

In the DID operation layer the concerns are focused on how to perform CRUD (Create, Read, Update, Delete) functionality on a DID document. This is something that is defined a DID method specification, but without a standardized method of operation it will create challenges on implementation developer to achieve portability. Some examples of where these are being defined can be found in this [W3C draft document](https://w3c-ccg.github.io/did-method-registry/).

#### DID storage layer description

Storage of DIDs and DID Docs are sometimes handled in this layer. Typically, this is used when a DID method has seperated the storage of the DID Docs and DIDs from the trusted network which resides at the DID Anchor Layer. Examples of this may be the [sidetree protocol](https://github.com/decentralized-identity/did-methods/blob/master/sidetrees/explainer.md) or could be built directly into the Anchor layer as is the case with Veres.One and Sovrin.

#### DID Anchor layer description
The anchor layer is focused on the network which is hosting and validating the DIDs onto the ledger to provide a state of the DID to those who have access to the ledger. The differences in this layer typically comes from a difference in architectures of the network. Examples of different anchor layers would be Bitcoin, Ethereum, Veres.One, Sovrin, RChain, etc.