Self-Sovereign Communication

1. Self-sovereign identity

Self-sovereign identity (SSI) is a widely-used term for a stack of technologies that promises to empower citizens with new means to manage privacy, to eliminate logins, and to conduct much faster transactions via the internet as well as in real life. SSI promises to empower organisations to speed up and automate transactions with customers, suppliers and partners, resulting in billions of euros savings on administrative costs, and higher customer satisfaction that results from better and speedier decision-making.

2. Requirements for the SSI communication layer

The Trust-over-IP Foundation (ToIP) has developed a four-layer model for an SSI technology stack. Note that we use slightly different naming of the layers than ToIP, as some ToIP naming (“DIDcom”) is rather technology specific.

• Layer 1: utilities. This layer hosts generic register infrastructure to provide technical assurances about identity and integrity of the system, e.g. blockchain or public key infrastructure.
• Layer 2: communication. This layer provides the infrastructure for parties to have their agents (e.g. app or device) find and communicate with each other, satisfying a plethora of requirements elaborated below.
• Layer 3:issuer-holder-verifier. This layer provides the infrastructure for issuer-holder and holder-verifier interactions, like the requesting and presentation of W3C verifiable credentials.
• Layer 4:application ecosystems. This layer provides the application-specific logic and associated business ecosystems for sector-specific use cases that apply SSI, and that provide the organisational assurances to issuers, holders and verifiers.

An essential feature of the ToIP model is the separation between layers 2 and 3. Layer 2 is about the technical communication channel. Any assurances about the human or organisational counterparty is arranged at layers 3 and above. This includes assurances about biometric identity/authentication, as well as other credentials about the counterparty.

This blog focusses on layer 2, the communication layer. The term self-sovereign (“autonomous”) implies that a party acts independently from other parties, based on its own knowledge and interests. In order to interact and transact with counterparties digitally, their agents need a digital communication channel.

Here are a set of requirement on the communication channel, based on a multi-year participation in SSI communities including (pre)standardisation. As is usual in SSI communities, each of these requirements is debatable.

1) The communication channel shall be usable for machine-readable issuer-holder-verifier interactions.
This means that it should fit in the ToIP technology stack.
2) The communication channel shall be protected against eavesdropping, impersonation, message modification and repudiation.
These are the usual security and privacy requirements with their usual public-key encryption and electronic signature solutions. The required level-of-assurance of the electronic signatures depends on the application (ToIP layer 4).
3) Parties shall be able to digitally find each other and to establish a communication channel.
Every new contact starts with the equivalent of exchanging business cards.
4) The communication channel between counterparties shall be persistent.
When a new message arrives, it should be clear that it is from the same counterparty as the previous message.
5) The communication channel shall be intrinsically symmetrical.
This is in contrast with the regular client-server model of the web (http), where the server side can easily impact the self-sovereignty of the party at the client side through unreasonable data demands, coerced by denied service (cf. cookie walls).
6) The communication channel shall not unnecessarily disclose information between counterparties or to third parties.
This is the privacy issue of regular phone numbers, email addresses and other personally identifiable information (PII), which can be stolen or sold to uninvolved third parties, who can use it for e.g. spam, phishing or spoofing.
7) The communication channel shall be unilaterally closable.
This is a related privacy issue, where it is the former counterparty itself that e.g. keeps emailing or calling
8) The communication channel shall not depend on third parties more than needed.
This should isolate self-sovereign parties from data breaches and major malfunctions at third parties. Examples are accidental or malicious errors in DNS resolving and X509 identifications, which rely on complicated trust hierarchies and which have major single-points-of-failure. Note that this requirements should be balanced against requirements 3) and 4) as some support by third parties may be needed to find each other for the first time, and to find each other again at a later time.
9) The communication channel shall enable compliance with legal requirements, like legal intercept.
This may be the most debatable of the set of requirements. Some people argue that the communication channel should even be robust against attacks by nation entities, protecting the transacting counterparties against being thrown in jail or worse based on their communications. The Onion Router network (TOR) is an example of a communication channel that provides such robustness. This blog presumes that the ability of legal compliance is a requirement.

3. Technologies for the SSI communication layer

Several technologies have been developed for the SSI communication layer in the last few years. Some of these are complementary, some are competing, and none of them individually covers all of the above requirements. Most of them aim to be independent of http, DNS, X509 and/or TOR.
We shall discuss the following SSI communication-layer technologies below.

• DID – decentralised identifier
• DIDcomm – DID communication
• PeerDID – DIDs between peers
• KERI – Key Event Receipt Infrastructure
• CHAPI – Credential Handler API

3.1 DID – Decentralised Identifier

Decentralised Identifiers (DID) are being developed by W3C. A DID typically identifies a (persona of an) individual or an (entity of an) organisation. Unlike communication identifiers (email, phone, number, ...), DIDs are easily, cheaply and unilaterally registered, typically onto a distributed ledger or blockchain. As illustrated in Figure 2, a DID has a DID method, which describes how and at what register it can be resolved, and what are the fields in the resulting DID document.

A DID can be used as an identifier for issuers, holders and verifiers (requirement 1). The DID document resulting from the resolving process encryption keys and signing keys to send encrypted messages to an agent of the party that created the DID and to provide some assurance that messages originate from that party (requirement 2). The optional service end point provides a way to reach the party for subsequent communication (requirement 4). Moreover, DID resolving enables simple key roll-overs and changes in delegation, while keeping the DID unchanged (also requirement 4) and without lots of communication overhead. Most DID methods use a blockchain to reduce the single-point-of-failure risk (requirement 8).

DID has several issues. One issue is the current proliferation of DID methods, which impedes economies of scale and causes security risks. Another issue is the lack of an enforced namespace of DID methods, which creates uncertainty in the market. Some prominent DID methods, like the European EBSI DID method, have not yet been published in the voluntary W3C DID-method registry . Nothing legally prevents an ill-willed party from developing a centralised-database DID registry or overloading an existing DID method by creating an incompatible version with the same method identifier. The recently proposed DID method for registering a DID method (“did:did”) may not significantly alleviate these issues. Also, blockchain-based DIDs seem ill-suited for use by private citizens, as the keys can be considered PII (violation of requirement 6), and the effort and cost to register a new DID ($10 for did:sov) may be too high to treat them as disposable (violation of requirement 8).

Nevertheless, DIDs already satisfy several of the requirements.

3.2 DIDcomm – DID communication

Complementary to DID, DID communication is a set of protocols that was originally developed by Hyperledger Aries, and that is now being maintained by DIF. The DID Connection Protocol acts like the exchange of business cards and bootstraps the DID communication (requirement 3). DIDcomm’s simplex messaging is intrinsically symmetrical (requirement 5), as it does not involve turn-taking and request-response.

The messaging does not have time-outs and can use any combination of underlaying transports, which helps the persistence (requirement 4). A DID routing agent service, as illustrated in Figure 3, may provide herd anonymity for incoming and outgoing communications (requirement 6), while remaining available for legal intercept (requirement 9). Other than optionally using a DID routing agent service, a DIDcomm communication channel does not depend on third parties (requirement 8). Moreover, DIDcomm’s message structure enables a party’s domain to have multiple domain endpoints (e.g. multiple smartphones) as well as cloud functionality (e.g. routing agents, or cloud endpoints), and hence high flexibility for individual and corporate use, and maintaining multilateral communications.

3.3 PeerDID – DIDs between peers

PeerDID was originated by OpenSSI, developed by Hyperledger Aries and now maintained by DIF. It addresses the privacy issue of registering DIDs on a blockchain (requirement 6). PeerDID works bilaterally or multilaterally. Instead of publishing a DID document onto a blockchain, a PeerDID is communicated with the relevant peer(s) directly. Several cryptographic and protocol solutions assure the origin, provenance, integrity and consistence of a PeerDID. The creation of a PeerDIDs is for free as they don’t involve third parties (requirement 8).

PeerDID is compatible and complementary with DID and DIDcomm, enabling the compliance to requirements by using them in combination. For example, a patient identified by a PeerDID could privately and securely communicate with a hospital identified by a blockchain DID, and use DIDcomm messaging for this.

3.4 KERI – Key Event Receipt Infrastructure

The KERI protocol was developed with the insight that most of the requirements ultimately relate to decentralised key management infrastructure, and that much of the above stuff may be overkill, especially the blockchains. The KERI protocol bears similarity to PeerDID, as it also uses cryptographic self-certifying identifiers and it also operates both bilaterally and multilaterally. The KERI protocol is used to communicate key events about cryptographic keys including key creation, key roll-over, key recovery and key deprecation. As such, it satisfies requirements 2, 5, 6 and 9.

3.5 CHAPI – Credential Handler API

CHAPI is the specification of a browser-based application programming interface, that enables a user to store credentials obtained from an issuer website and to send them to a verifier website (requirement 1). The benefit of CHAPI is that it integrates with browsers, including their https, DNS and X509 support. It is unclear whether or how CHAPI would support the other requirements. It has been suggested that CHAPI could be combined with DIDcomm.

4. Conclusion: work in progress

All of the above-mentioned technologies are work in progress. Whereas full SSI-layer-2 solutions do not yet exist, there exist implementations of each of the individual technologies.
Some SSI-layer-2 work is being performed in the European eSSIF-Lab programme, including a Universal DID Resolver to deal with the proliferation of DID methods; an eIDAS bridge that combines DIDs with legally-binding eIDAS seals; FIDO2 multi-factor authentication for citizen DIDs; and a universal backup of DID and credentials. More work is being performed with W3C, Hyperledger, DIF and ToIP.

Time will tell how technologies will be combined and evolved into a full SSI layer-2, and whether there exists enough political and market drive to satisfy all requirements and to outcompete centralised solutions that do not even guarantee issuer-verifier-separation privacy, or attribute-based credential solutions that use more traditional https, DNS and X509 technologies (e.g. IRMA).