I've been contemplating a self-sovereign internet of things (SSIoT) for over a decade. An SSIoT is the only architecture which frees us from what I've called the CompuServe of Things. Unlike the CompuServe of Things, the SSIoT¹ supports rich, peer-to-peer relationships between people, things, and their manufacturers.

In the CompuServe of Things, Alice's relationships with her things are intermediated by the company she bought them from as shown in Figure 1. Suppose, for example, she has a connected coffee grinder from Baratza.

In this diagram, Alice uses Brataza's app on her mobile device to connect with Baratza's IoT cloud. She registers her coffee grinder, which only knows how to talk to Baratza's proprietary service API. Baratza intermediates all of Alice's interactions with her coffee grinder. If Baratza is offline, decides to stop supporting her grinder, goes out of business, or otherwise shuts down the service, Alice's coffee grinder becomes less useful and maybe stops working all together.

In an SSIoT, on the other hand, Alice has direct relationships with her things. In Operationalizing Digital Relationships, I showed a diagram where Alice has relationships with people and organizations. But I left out things because I hadn't yet provided a foundational discussion of DIDComm-enabled digital relationships that's necessary to really understand how SSI can transform IoT. Figure 2 is largely the same as the diagram in the post on operationalizing digital relationships with just a few changes: I've removed the ledger and key event logs to keep it from being too cluttered and I've added a thing: a Baratza coffee grinder².

In this diagram, the coffee grinder is a fully capable participant in Alice's relationship network. Alice has a DID-based relationship with the coffee grinder. She also has a relationship with the company who makes it, Baratza, as does the coffee grinder. Those last two are optional, but useful—and, importantly, fully under Alice's control.

DID Relationships for IoT

Let's focus on Alice, her coffee grinder, and Baratza to better understand the contrast between the CompuServe of Things and an SSIoT.

In Figure 3, rather than being intermediated by the coffee grinder's manufacturer, Alice has a direct, DID-based relationship with the coffee grinder. Both Alice and the coffee grinder have agents and wallets. Alice also has a DID-based relationship with Baratza which runs an enterprise agent. Alice is now the intermediary, interacting with her coffee grinder and Baratza as she see's fit.

Figure 3 also shows a DID-based relationship between the coffee grinder and Baratza. In an administrative CompuServe of Things, we might be concerned with the privacy of Alice's data. But in a Self-Sovereign Internet of Things, Alice controls the policies on that relationship and thus what is shared. She might, for example, authorize the coffee grinder to share diagnostic information when she needs service. She could also issue a credential to Baratza to allow them to service the grinder remotely, then revoke it when they're done.

The following sections describe three of many possible use cases for the Self-Sovereign Internet of Things.

Updating Firmware

One of the problems with the CompuServe of Things is securely updating device firmware. There are many different ways to approach secure firmware updates in the CompuServe of things—each manufacturer does it slightly differently. The SSIoT provides a standard way to know the firmware update is from the manufacturer and not a hacker.

As shown in Figure 4, Baratza has written a public DID to the ledger. They can use that public DID to sign firmware updates. Baratza embedded their public DID in the coffee grinder when it was manufactured. The coffee grinder can resolve the DID to look up Baratza's current public key on the ledger and validate the signature. This ensures that the firmware package is from Baratza. And DIDs allow Baratza to rotate their keys as needed without invalidating the DIDs stored in the devices.

Of course, we could also solve this problem with digital certificates. So, this is really just table stakes. The advantage of using SSIoT for secure firmware updates instead of digital certificates is that if Baratza is using it for other things (see below), they get this for free without also having to support the certificate code in their products or pay for certificates.

Proving Ownership

Alice can prove she owns a particular model of coffee grinder using a verifiable credential.

Figure 5 shows how this could work. The coffee grinder's agent is running the Introduction protocol and has introduced Alice to Baratza. This allows her to form a relationship with Baratza that is more trustworthy because it came on an introduction from something she trusts.

Furthermore, Alice has received a credential from her coffee grinder stating that she is the owner. This is kind of like imprinting. While it may not be secure enough for some use cases, for things like a coffee grinder, it's probably secure enough. Once Alice has this credential, she can use it to prove she's the owner. The most obvious place would be at Baratza itself to receive support, rewards, or other benefits. But other places might be interested in seeing it as well: "Prove you own a Baratza coffee grinder and get $1 off your bag of beans."

Real Customer Service

We've all been in customer hell where we call a company, get put on hold, get ask a bunch of questions to validate who we are, have to recite serial numbers or model numbers to one agent, then another, and then lose the call and have to start all over again. Or been trapped in a seemingly endless IVR phone loop trying to even get to a human.

The DID-based relationship Alice has created with Baratza does away with that because DIDComm messaging creates a batphone-like experience wherein each participant knows they are communicating with the right party without the need for further authentication, reducing effort and increasing security. As a result, Alice has a trustworthy communication channel with Baratza that both parties can use to authenticate the other. Furthermore, as we saw in the last section, Alice can prove she's a bona fide customer.

But the ability of DIDComm messaging to support higher-level application protocols means that the experience can be much richer. Here's s simple example.

In Figure 6, Alice has two coffee grinders. Let's further assume that Alice has a specialized wallet to interact with her things. Doc Searls has suggested we call it a "briefer" because it's more capable than a wallet. Alice's briefer does all the things her credential wallet can do, but also has a user interface for managing all the things she owns and the relationships she has with them³. Students in my lab at BYU have been working on a prototype of such an interface we call Manifold using agent-enabled digital twins called "picos".

Having two things manufactured by Baratza presents a problem when Alice wants to contact them because now she is the intermediary between the thing and its vendor. But if we flip that and let the thing be the intermediary, the problem is easily resolved. Now when Alice wants to contact Baratza, she clicks one button in her briefer and lets her coffee grinder intermediate the transaction. The grinder can interject relevant information into the conversation so Alice doesn't have to. Doc does a great job of describing why the "thing as conduit" model is so powerful in Market intelligence that flows both ways.

You'll recall from DIDComm and the Self-Sovereign Internet, that behind every wallet is one or more agents. Alice's briefer has an agent. And it has relationships with each of her things. Each of those has one or more agents. These agents are running an application protocol for vendor message routing. The protocol is using sub protocols that allow the grinder to act on Alice's behalf in customer support scenarios. You can imagine that CRM tools would be fitted out to understand these protocols as well.

There's at least one company working on this idea right now, HearRo. Vic Cooper, the CEO of HearRo recently told me:

Most communications happen in the context of a process. [Customers] have a vector that involves changing some state from A to B. "My thing is broken and I need it fixed." "I lost my thing and need to replace it." "I want a new thing and would like to pay for it but my card was declined." This is the story of the customer service call. To deliver the lowest effort interaction, we need to know this story. We need to know why they are calling. To add the story to our context we need to do two things: capture the intent and manage the state over time. SSI has one more super power that we can take advantage of to handle the why part of our interaction. We can use SSI to operationalize the relationships.

Operationalized relationships provide persistence and context. When we include the product itself in the conversation, we can build customer service applications that are low effort because the trustworthy connection can include not only the who, but also the what to provide a more complete story. We saw this in the example with two coffee grinders. Knowing automatically which grinder Alice needs service for is a simple bit of context, but one that reduces effort nonetheless.

Going further, the interaction itself can be a persistent object with it's own identity, and DID-based connections to the participants⁴. Now the customer and the company can bring tools to bear on the interaction. Others could be invited to join the interaction as necessary and the interaction itself now becomes a persistent nexus that evolves as the conversation does. I recently had a month long customer service interaction involving a few dozen calls with Schwab (don't ask). Most of the effort for me and them was reestablishing context over and over again. No CRM tool can provide that because it's entirely one-sided. Giving customers tools to operationalize customer relationships solves this problem.

A Self-Sovereign Internet of Things

The Sovrin Foundation has an IoT working group that recently released a whitepaper on Self-Sovereign Identity and IoT. In it you'll find a discussion of some problems with IoT and where SSI can help. The paper also has a section on the business value of SSI in IoT. The paper is primarily focused on how decentralized identifiers and verifiable credentials can support IoT. The last use case I offer above goes beyond those, primarily identity-centric, use cases by employing DIDComm messaging to ease the burden of getting support for a product.

In my next blog post, I'll extend that idea to discuss how SSI agents that understand DIDComm messages can support relationships and interactions not easily supported in the CompuServe of Things as well as play a bigger role in vendor relationship management. These and other scenarios can rescue us from an administrative, bureaucratic CompuServe of Things and create a generative IoT ecosystem that is truly internet-like.

Notes

1. Some argue that since things can't be sovereign (see Appendix B of the Sovrin Glossary for a taxonomy of entities), they shouldn't be part of SSI. I take the selfish view that as a sovereign actor in the identity metasystem, I want my things to be part of that same ecosystem. Saying things are covered under the SSI umbrella doesn't imply they're sovereign, but merely says they are subject to the same overarching governance framework and use the same underlying protocols. In the next post on this subject, I'll make the case that even if things aren't sovereign, they should have an independent existence and identity from their owners and manufacturers.
2. The choice of a coffee grinder is based simply on the fact that it was the example Doc Searls gave when we were having a discussion about this topic recently.
3. This idea has been on my mind for a while. This post from 2013, Facebook for My Stuff discusses it in the "social" venacular of the day.
4. The idea that a customer service interaction might itself be a participant in the SSIoT may cause some to shake their heads. But once we create a true internet of things, it's not just material, connected things that will be on it. The interaction object could have its own digital wallet, store credentials, and allow all participants to continue to interact with it over time, maintaining context, providing workflow, and serving as a record that everyone involved can access.

Photo Credit: Coffee Beans from JoseAlbaFotos (Pixabay license)