In The Self-Sovereign Internet of Things, I introduced the role that Self-Sovereign Identity (SSI) can play in the internet of things (IoT). The self-sovereign internet of things (SSIoT) relies on the DID-based relationships that SSI provides, and their support for standardized protocols running over DIDComm, to create an internet of things that is much richer, secure, and privacy respecting than the CompuServe of Things we're being offered today. In this post, I extend the use cases I offered in the previous post and discuss the role the heterarchical relationships found in the SSIoT play.

For this post, we're going to focus on Alice's relationship with her F-150 truck and its relationships with other entities. Why a vehicle? Because in 2013 and 2014 I built a commercial connected car product called Fuse that used the relationship-centric model I'm discussing here¹. In addition, vehicles exist in a rich, complicated ecosystem that offers many opportunities for interesting relationships. Figure 1 shows some of these.

The most important relationship that a car has is with its owner. But there's more than one owner over the car's lifetime. At the beginning of its life, the car's owner is the manufacturer. Later the car is owned by the dealership, and then by a person or finance company. And, of course, cars are frequently resold. Over the course of its lifetime a car will have many owners. Consequently, the car's agent must be smart enough to handle these changes in ownership and the resulting changes in authorizations.

In addition to the owner, the car has relationships with other people: drivers, passengers, and pedestrians. The nature of relationships change over time. For example, the car probably needs to maintain a relationship with the manufacturer and dealer even after they are no longer owners. With these changes to the relationship come changes in rights and responsibilities.

In addition to relationships with owners, cars also have relationships with other players in the vehicle ecosystem including: mechanics, gas stations, insurance companies, finance companies, and government agencies. Vehicles exchange data and money with these players over time. And the car might have relationships with other vehicles, traffic signals, the roadway, and even potholes.

The following sections discuss three scenarios involvoing Alice, the truck, and other people, institutions, and things.

Multiple Owners

One of the relationship types that the CompuServe of Things fails to handle well is multiple owners. Some companies try and others just ignore it. The problem is that when the service provider intermediates the connection to the thing, they have to account for multiple owners and allow those relationships to change over time. For a high-value product, the engineering effort is justified, but for many others, it simple doesn't happen.

Figure 2 shows the relationships of two owners, Alice and Bob, with the truck. The diagram is simple and hides some of the complexity of the truck dealing with multiple owners. But as I discuss in Fuse with Two Owners some of this is simply ensuring that developers don't assume a single owner when they develop services. The infrastructure for supporting it is built into DIDComm, including standardized support for sub protocols like Introduction.

Lending the Truck

People lend things to friends and neighbors all the time. And people rent things out. Platforms like AirBnB and Outdoorsy are built to support this for high value rentals. But what if we could do it for anything at any time without an intermediating platform? Figure 3 shows the relationships between Alice and her friend Carol who wants to borrow the truck.

Like the multiple owner scenario, Alice would first have a connection with Carol and introduce her to the truck using the Introduction sub protocol. The introduction would give the truck permission to connect to Carol and also tell the truck's agent what protocols to expose to Carol's agent. Alice would also set the relationship's longevity. The specific permissions that the "borrower" relationship enables depend, of course, on the nature of the thing.

The data that the truck stores for different activities is dependent on these relationships. For example, the owner is entitled to know everything, including trips. But someone who borrows the car should be able to see their trips, but not those of other drivers. Relationships dictate the interactions. Of course, a truck is a very complicated thing in a complicated ecosystem. Simpler things, like a shovel might simply be keeping track of who has the thing and where it is. But, as we saw in The Self-Sovereign Internet of Things, there is value in having the thing itself keep track of its interactions, location, and status.

Selling the Truck

Selling the vehicle is more complicated than the previous scenarios. In 2012, we prototyped this scenario for Swift's Innotribe innovations group and presented it at Sibos. Heather Vescent of Purple Tornado created a video that visualizes how a sale of a motorcycle might happen in a heterarchical DIDComm environment². You can see a screencast of the prototype in operation here. One important goal of the prototype was to support Doc Searls's vision of the Intention Economy. In what follows, I've left out some of the details of what we built. You can find the complete write-up in Buying a Motorcycle: A VRM Scenario using Personal Clouds.

In Figure 4, Alice is selling the truck to Doug. I'm ignoring how Alice and Doug got connected³ and am just focusing on the sale itself. To complete the transaction, Alice and Doug create a relationship. They both have relationships with their respective credit unions where Doug initiates and Alice confirms the transaction. At the same time, Alice has introduced the truck to Doug as the new owner.

Alice, Doug, and the truck are all connected to the DMV and use these relationships to transfer the title. Doug can use his agent to register the truck and get plates. Doug also has a relationship with his insurance company. He introduces the truck to the insurance company so it can serve as the service intermediary for the policy issuance.

Alice is no longer the owner, but the truck knows things about her that Doug shouldn't have access to and she wants to maintain. We can create a digital twin of the truck that is no long attached to the physical device, but has a copy of all the trip and maintenance information that Alice had co-created with the truck over the years she owned it. This digital twin has all the same functionality for accessing this data that the truck did. At the same time, Alice and Doug can negotiate what data also stays on the truck. Doug likely doesn't care about her trips and fuel purchases, but might want the maintenance data.

Implementation

A few notes on implementation:

• The relationships posited in these use cases are all DIDComm-capable relationships.
• The workflows in these scenarios use DIDComm messaging to communicate. I pointed out several places where the Introduction DIDComm protocol might be used. But there might be other DIDComm protocols defined. For example, we could imagine workflow-specific messages for the scenario where Carol borrows the truck. The scenario where Doug buys the truck is rife with possibilities for protocols on DIDComm that would standardize many of the interactions. Standardizing these workflows through protocol (e.g., a common protocol for vehicle registration) reduces the effort for participants in the ecosystem.
• Some features, like attenuated permissions on channel are a mix of capabilities. DIDComm supports a Discovery protocol that allows Alice, say, to determine if Doug is open to engaging in a sale transaction. Other permissioning would be done by the agent outside the messaging system.
• The agents I'm envisioning here are smart, rule-executing agents like those available in picos. Picos provide a powerful model for how a decentralized, heterarchical, interoperable internet of things can be built. Picos provide an DIDComm agent programming platform that is easily extensible. Picos live on an open-source pico engine that can run on anything that supports Node JS. They have been used to build and deploy several production systems, including the Fuse connected-car system discussed above.

Conclusion

DIDComm-capable agents can be used to create a sophisticated relationship network that includes people, institutions, things and even soft artifacts like interaction logs. The relationships in that network are rich and varied—just like relationships in the real world. Things, whether they are capable of running their own agents or employ a soft agent as a digital twin, are much more useful when they exist persistently, control their own agent and digital wallet, and can act independently. Things now react and respond to messages from others in the relationship network as they autonomously follow their specific rules.

Everything I've discussed here and in the previous post are doable now. By removing the intermediating administrative systems that make up the CompuServe of Things and moving to a decentralized, peer-to-peer architecture we can unlock the tremendous potential of the Self-Sovereign Internet of Things.

Notes

1. Before Fuse, we'd built a more generalized IoT system based on a relationship network called SquareTag. SquareTag was a social product platform (using the vernacular of the day) that promised to help companies have a relationship with their customers through the product, rather than merely having information about them. My company, Kynetx, and others, including Drummond Reed, were working to introduce something we called "personal clouds" that were arrayed in a relationship network. We built this on a actor-like programming model called "picos". The pico engine and programming environment are still available and have been updated to provide DID-based relationships and support for DIDComm.
2. In 2012, DIDComm didn't exist of course. We were envisioning something that Innotribe called the Digital Asset Grid (DAG) and speaking about "personal clouds" but the envisioned operation of the DAG was very much like what exists now in the DIDComm-enabled peer-to-peer network enabled by DIDs.
3. In the intentcasting prototype, Alice and Doug would have found each other through a system that matches Alice's intent to buy with Doug's intent to sell. But a simpler scenario would have Alice tell the truck to list itself on Craig's List so Alice and Doug can meet up there.

Photo Credit: F-150 from ArtisticOperations (Pixabay License)