Operationalizing Digital Relationships

Summary

Phil Windley
6 min readNov 30, 2020

An SSI wallet provides a place for people to stand in the digital realm. Using the wallet, people can operationalize their digital relationships as peers with others online. The result is better, more authentic, digital relationships, more flexible online interactions, and the preservation of human freedom, privacy, and dignity.

Recently, I’ve been making the case for self-sovereign identity and why it is the correct architecture for online identity systems.

  • In Relationships and Identity, I discuss why identity systems are really built to manage relationships rather than identities. I also show how the architecture of the identity system affects the three important properties relationships must have to function effectively: integrity, lifespan, and utility.
  • In The Architecture of Identity Systems I introduced a classification scheme that broadly categorized identity systems into one of three broad architectures: administrative, algorithmic, or autonomic.
  • In Authentic Digital Relationships, I discuss how the architecture of an identity system affects the authenticity of the relationships it manages.

This post focuses how people can operationalize the relationships they are party to and become full fledged participants online. Last week, Doc Searls posted What SSI Needs where he recalls how the graphical web browser was the catalyst for making the web real. Free (in both the beer and freedom senses) and substitutable, browsers provided the spark that gave rise to the generative qualities that ignited an explosion of innovation. Doc goes on to posit that the SSI equivalent of the web browser is what we have called a “wallet” since it holds, analogously to your physical wallet, credentials.

The SSI wallet Doc is discussing is the tool people use to operationalize their digital relationships. I created the following picture to help illustrate how the wallet fulfills that purpose.

Relationships and Interactions in Sovrin Network

This figure shows the relationships and interactions in SSI networks enabled by the Hyperledger Indy and Aries protocols. The most complete example of these protocols in production is the Sovrin Network.

In the figure, Alice has an SSI wallet¹. She uses the wallet to manage her relationships with Bob and Carol as well as a host of organizations. Bob and Carol also have wallets. They have a relationship with each other and Carol has a relationship with Bravo Corp, just as Alice does². These relationships are enabled by autonomic identifiers in the form of peer DIDs (blue arrows). The SSI wallet each participant uses provides a consistent user experience, like the browser did for the Web. People using wallets don’t see the DIDs (identifiers) but rather the connections they have to other people, organizations, and things.

These autonomic relationships are self-certifying meaning they don’t rely on any third party for their trust basis. They are also mutually authenticating: each of the parties in the relationship can authenticate the other. Further, these relationships create a secure communications channel using the DIDComm protocol. Because of the built-in mutual authentication, DIDComm messaging creates a batphone-like experience wherein each participant knows they are communicating with the right party without the need for further authentication. As a result, Alice has trustworthy communication channels with everyone with whom she has a peer DID relationship.

Alice, as mentioned, also has a relationship with various organizations. One of them, Attester Org, has issued a verifiable credential to Alice. They issued the credential (green arrows) using the Aries credential exchange protocol that runs on top of the DIDComm-based communication channel enabled by the peer DID relationship Alice has with Attester. The credential they issue is founded on the credential definition and public DID (an algorithmic identifier) that Attester Org wrote to the ledger.

When Alice later needs to prove something (e.g. her address) to Certiphi Corp, she presents the proof over the DIDComm protocol, again enabled by the peer DID relationship she has with Certiphi Corp. Certiphi is able to validate the fidelity of the credential by reading the credential definition from the ledger, retrieving Attester Org’s public DID from the credential definition, and resolving it to get Attester Org’s public key to check the credential’s signature. At the same time, Certiphi can use cryptography to know that the credential is being presented by the person it was issued to and that it hasn’t been revoked.

This diagram has elements of each architectural style described The Architecture of Identity Systems.

  • Alice has relationships with five different entities: her friends Bob and Carol as well as three different organizations. These relationships are based on autonomic identifiers in the form of peer DIDs. All of the organizations use enterprise wallets to manage autonomic relationships⁴.
  • As a credential issuer, Attester Org has an algorithmic identifier in the form of a public DID that has been recorded on the ledger. The use of algorithmic identifiers on a ledger³ allows public discovery of the credential definition and the public DID by Certiphi Corp when it validates the credential. The use of a ledger for this purpose is not optional unless we give up the loose coupling it provides. Loose coupling provides scalability, flexibility, and isolation. Isolation is critical to the privacy protections that verifiable credential exchange via Aries promises.
  • Each company will keep track of attributes and other properties they need for the relationship to provide the needed utility. These are administrative systems since they are administered by the organization for their own purpose and their root of trust is a database managed by the organization. The difference between these administrative systems and those common in online identity today is that only the organization is depending on them. People have their own autonomic root of trust in the key event log that supports their wallet.

Alice’s SSI wallet allows her to create, manage, and utilize secure, trustworthy communications channels with anyone online without reliance on any third party. Alice’s wallet is also the place where specific, protocol-enabled interactions like credential exchange happen. The wallet is flexible tool that Alice uses to manage her digital life.

We have plenty of online relationships today, but they are not operational because we are prevented from acting by their anemic natures. Our helplessness is the result of the power imbalance that is inherent in bureaucratic relationships. The solution to the anemic relationships created by administrative identity systems is to provide people with the tools they need to operationalize their self-sovereign authority and act as peers with others online. When we dine at a restaurant or shop at a store in the physical world, we do not do so within some administrative system. Rather, as embodied agents, we operationalize our relationships, whether they be long-lived or nascent, by acting for ourselves. The SSI wallet is the platform upon which people can stand and become digitally embodied to operationalize their digital life as full-fledged participants in the digital realm.

Notes

  1. Alice’s SSI wallet is like other wallets she has on her phone with several important differences. First, it is enabled by open protocols and second, it is entirely under her control. I’m using the term “wallet” fairly loosely here to denote not only the wallet but also the agent necessary for the interactions in an SSI ecosystem. For purposes of this post, delineating them isn’t important. In particular, Alice may not be aware of the agent, but she will know about her wallet and see it as the tool she uses.
  2. Note that Bob doesn’t have a relationship with any of the organizations shown. Each participant has the set of relationships they choose to have to meet their differing circumstances and needs.
  3. I’m using “ledger” as a generic term for any algorithmically controlled distributed consensus-based datastore including public blockchains, private blockchains, distributed file systems, and others.
  4. Enterprise wallets speak the same protocols as the wallets people use, but are adapted to the increased scale an enterprise would likely need and are designed to be integrated with the enterprise’s other administrative systems.

Photo Credit: Red leather wallet on white paper from Pikrepo (CC0)

Originally published at https://www.windley.com.

--

--

Phil Windley
Phil Windley

Written by Phil Windley

I build things; I write code; I void warranties

No responses yet