Lately, I’ve been thinking a lot about use cases for self-sovereign identity. This series of blog posts discusses how Sovrin can be used in different industries. In this article I discuss Sovrin and Picos.

Anyone who reads this blog regularly knows that I've been working on a system for creating online agents using an event-driven, actor-model programming system called "persistent compute objects" or "picos" for short. Picos support a personal, decentralized model for the Internet of Things. Fuse, a connected-car platform, was designed to show how this model works.

Picos support a hosting model that supports the same properties that the Internet itself has, namely decentralization, heterarchy, and interoperability. Central to these features is the idea of portability—a pico should be movable from one hosting platform (something we call a "pico engine") to another without loss of functionality.

I believe that the future Internet of Things will require architectures where online "device shadows" (as Amazon calls them) are not only under the control of the owner, but hostable in a variety of places, not just on the manufacturer's servers. For example, I might buy a toaster that has a device shadow hosted by the Black and Decker and later decide to move that device shadow (along with its interaction history) to a hosting platform I control. Picos are a way of imagining postable device shadows that are under owner control.

Names

The most difficult problem standing in the way of easily moving picos between hosting engines is that picos receive messages using a URL that follows the format defined by the Sky Event Protocol. Because it's a URL, it's a location. Moving a pico from one engine to another requires updating all the places that refer to that pico, an impossible task. HTTP redirects could potentially be used, but they have scaling limitations I'd rather stay away from. Specifically, frequent moves might create long chains of redirects that have to be maintained since you can never be sure when every service with an interest in the pico had seen the redirect and updated their records.

The more general solution is to have picos refer to each other by name and have some way of resolving a name to the current location of the pico. In the past this always led me to an uncomfortable reliance on some kind of centralized registry, but recent developments in distributed ledgers have made name resolution possible without reliance on a central registry.

DIDs and DDOs

A distributed ledger like Sovrin is a key-value store with entries that are temporally ordered and immutable. Decentralized Identifiers (DIDs) are intended to be one kind of key for a ledger. A DID is similar to a URN (universal resource name) and has a similar syntax. Here's an example DID:

did:sov:21tDAKCERh95uGgKbJNHYp

The ternary structure includes a schema identifier (did), a namespace identifier (sov in this case) and an identifier within that namespace (21tDAKCERh95uGgKbJNHYp) separated by colons. DIDs are meant to be permanently assigned and not reused. DIDs can be used to identify anything: person, organization, place, thing, or even concept.

DIDs point to DDOs, or DID Descriptor Objects. A DDO is a JSON-LD-formatted data structure that links the DID to public keys, signatures, and service endpoints. We can use the signatures to validate that the DDO has not been tampered with, the service endpoint to discover more information about the DID, and the public key to secure communication with the entity identified by the DID.

Using Sovrin with Picos

DIDs on the Sovrin ledger provide a convenient way to name picos with an identifier that can be resolved to the current location of the pico without relying on a centralized registry. The figure below shows how this could work.

The figure shows two pico engines and five picos. Two of the picos are acting as decentralized directories. The Sovrin ledger is associating a DID for each pico with a DDO that names the directory as the service endpoint. The databases representations on the right show the persistent state of the directory picos and map DIDs to the current location of the pico (which engine).

We use a directory pico, rather than writing the engine directly in the DDO, to allow for frequent updates. Suppose we wanted to move the pico between engines frequently. A directory can be easily updated, multiple times per second if necessary. There can be many directories. The location of the directories is arbitrary and unimportant. You'll notice I put them both in the same engine, but they could be anywhere because they're located using the DDO.

Finding a pico, given its DID, is simply a matter of looking up the DDO for the DID on the ledger, retrieving the directory from the service endpoint entry, consulting with the directory to find the engine (and any other important information) and constructing a location pointer (what we call an ESL or Event Service Location).

Multiple Identifiers

This model easily supports a pico having multiple identifiers (an important feature of picos that prevents correlation). This is supported in the Sky Event Protocol by what are called Event Channels. Each event channel has a unique event channel identifier, or ECI. In addition to preventing correlation, having separate event channels allows the pico to manage, permission, and respond to messages independently. The figure below shows how this is supported:

In the figure, Pico 2 has two DIDs. Each points, arbitrarily, to a different directory. The directories not only contain the location of the pico engine, but a unique ECI. The information in the directory can be used to construct an ESL from each DID that can't be correlated with others.

Creating a New Pico

The process for creating and registering the name for a new pico is straightforward as shown in the following figure. The new pico is created and appropriate entries are added to the directory. A new entry is written to the ledger associating the DID for the pico with a DDO pointing to the directory.

Discovery

Pico discovery is simple using the DID. Suppose Pico 2 has the DID for the newly created Pico 4. The following figure shows the discovery process.

1. Pico 2 uses the DID to discover the directory using the DDO written on the ledger.
2. Pico 2 queryies the directory.
3. The directory returns the data about Pico 4
4. Pico 2 contructs an ESL.

When a pico wants to send a message to another pico, it may have to repeat the discovery process to find out where it is. The ESL that is generated from the discovery process can be cached and expired based on time or failure.

Creating a Subscription

Picos create relationships with each other that are called subscriptions. The primary task in creating a subscription is key exchange. DIDs allow this to happen easily. In the following figure, assume that Pico 2 has already gone through the discovery process outlined above and has an ESL for Pico 4.

1. Pico 2 sends a signed subscription request that includes a DID to Pico 4.
2. Pico 4 uses the discovery process to get Pico 2’s public key and other information from the DDO in the ledger.
3. Pico 4 uses the public key it gathers in (2) to validate that the request in (1) came from Pico 2.
4. Pico 4 stores Pico 2’s public key, name, and other relevant data; caches the directory and engine; and sends a subscription response.
5. Pico 2 validates the response and stores subscription information for Pico 4.

Moving Picos

As shown in the following figure, when a pico is moved from one engine to another, only the directory need be updated.

Changing Directories

There will be reasons to change what directory a pico is using for a given DID. That requires updating the ledger as shown in the following figure.

The crossed out entry in the ledger is meant to indicate that it's been superseded, not that it's been deleted. Ledger entries are immutable.

Conclusion

The preceding scenarios describe the methods picos can use to make them portable while maintaining maximal decentralization. The use of names (DIDs) recorded on the Sovrin distributed ledger that reference directories for pico location provide an efficient, flexible, and complete means of maintaining connectivity between picos even if they are moved often. There are no centralized services that could create a single point of failure.

---

Photo Credit: sunrise_sequence_01w by Jan (Arny) Messersmith (CC BY-NC-ND 2.0)