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 here1. 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.
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 should 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.
In Figure 4, Alice is selling the truck to Doug. I'm ignoring how Alice and Doug got connected3 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.
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.
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.
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.
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.
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)
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 SSIoT1 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 grinder2.
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.
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.
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 them3. 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 participants4. 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 provide advanced 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.
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.
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.
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.
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)
Most people familiar with SSI equate DIDComm with verifiable credential exchange, but it's much more than that. Credential exchange is just one of an infinite variety of protocols that can ride on top of the general messaging protocol that DIDComm provides. Comparing DIDComm to the venerable TCP/IP protocol suite does not go too far. Just as numerous application protocols ride on top of TCP/IP, so too can various application protocols take advantage of DIDComm's secure messaging overlay network. The result is more than a secure messaging overlay for the internet, it is the foundation for a self-sovereign internet with all that that implies.
DID Communications Protocol
DIDComm messages are exchanged between software agents that act on behalf of the people or organizations that control them. I often use the term "wallet" to denote both the wallet and agent, but in this post we should distinguish between them. Agents are rule-executing software systems that exchange DIDComm messages. Wallets store DIDs, credentials, personally identifying information, cryptographic keys, and much more. Agents use wallets for some of the things they do, but not all agents need a wallet to function.
For example, imagine Alice and Bob wish to play a game of TicTacToe using game software that employs DIDComm. Alice's agent and Bob's agent will exchange a series of messages. Alice and Bob may be using a game UI and be unaware of the details but the agents are preparing plaintext JSON messages1 for each move using a TicTacToe protocol that describes the format and appropriateness of a given message based on the current state of the game.
When Alice places an X in a square in the game interface, her agent looks up Bob's DID Document. She received this when she and Bob exchanged DIDs and it's kept up to date by Bob whenever he rotates the keys underlying the DID2. Alice's agent gets two key pieces of information from the DID Document: the endpoint where messages can be sent to Bob and the public key Bob's agent is using for the Alice:Bob relationship.
Alice's agent uses Bob's public key to encrypt the JSON message to ensure only Bob's agent can read it and adds authentication using the private key Alice uses in the Alice:Bob relationship. Alice's agent arranges to deliver the message to Bob's agent through whatever means are necessary given his choice of endpoint. DIDComm messages are often routed through other agents under Alice and Bob's control.
Once Bob's agent receives the message, it authenticates that it came from Alice and decrypts it. For a game of TicTacToe, it would ensure the message complies with the TicTacToe protocol given the current state of play. If it complies, the agent would present Alice's move to Bob through the game UI and await his response so that the process could continue. But different protocols could behave differently. For example, not all protocols need to take turns like the TicTacToe protocol does.
As an interoperable protocol, DIDComm is not dependent on a specific operating system, programming language, vendor, network, hardware platform, or ledger3. While DIDComm was originally developed within the Hyperledger Aries project, it aims to be the common language of any secure, private, self-sovereign interaction on, or off, the internet.
In addition to being interoperable, DIDComm should be able to make use of any transport mechanism including HTTP(S) 1.x and 2.0, WebSockets, IRC, Bluetooth, NFC, Signal, email, push notifications to mobile devices, Ham radio, multicast, snail mail, and more.
DIDComm is an asynchronous, simplex messaging protocol that is designed for extensibility by allowing for protocols to be run on top of it. By using asynchronous, simplex messaging as the lowest common denominator, almost any other interaction pattern can be built on top of DIDComm. Application-layer protocols running on top of DIDComm allow extensibility in a way that also supports interoperability.
Protocols describe the rules for a set of interactions, specifying the kinds of interactions that can happen without being overly prescriptive about their nature or content. Protocols formalize workflows for specific interactions like ordering food at a restaurant, playing a game, or applying for college. DIDComm and its application protocols are one of the cornerstones of the SSI metasystem, giving rise to a protocological culture within the metasystem that is open, agentic, inclusive, flexible, modular, and universal.
While we have come to think of SSI agents being strictly about exchanging peer DIDs to create a connection, request and issue a credential, or prove things using credentials, these are merely specific protocols defined to run over the DIDComm messaging protocol. Many others are possible. The follow specifications describe the protocols for these three core applications of DIDComm:
Daniel Hardman has provided a comprehensive tutorial on defining protocols on DIDComm. We can imagine a host of DIDComm protocols for all kinds of specialized interactions that people might want to undertake online including the following:
Buying and selling
Enacting and enforcing contracts
Putting things in escrow (and taking them out again)
As you can see from this partial list, DIDComm is not just a secure, private way to connect and exchange credentials. Rather DIDComm is a foundation protocol that provides a secure and private overlay to the internet for carrying out almost any online workflow. Consequently, agents are more than the name "wallet" would imply, although that's a convenient shorthand for the common uses of DIDComm today.
A Self-Sovereign Internet
Because of the self-sovereign nature of agents and the flexibility and interoperable characteristics they gain from DIDComm, they form the basis for new, more empowering internet. While self-sovereign identity is the current focus of DIDComm, its capabilities exceed what many think of as "identity." When you combine the vast landscape of potential verifiable credentials with DIDComm's ability to create custom message-based workflows to support very specific interactions, it's easy to imagine that the DIDComm protocol and the heterarchical network of agents it enables will have an impact as large as the web, perhaps the internet itself.
DIDComm messages do not strictly have to be formatted as JSON.
Alice's agent can verify that it has the right DID Document and the most recent key by requesting a copy of Bob's key event log (called delta's for peer DIDs) and validating it. This is the basis for saying peer DIDs are self certifying.
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.
Fuse with Two Owners shows an introduction protocol for picos I used in building Fuse in 2014 before picos used DIDComm. I'd like to revisit this as a way of building introductions into picos using a DIDComm protocol.
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.
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.
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 wallet1. 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 does2. 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.
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 relationships4.
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 ledger3 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.
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.
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.
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.
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.
Introductory note: I recently read a paper from Sam Smith, Key Event Receipt Infrastructure, that provided inspiration for a way to think about and classify identity systems. In particular his terminology was helpful to me. This blog post uses terminology and ideas from Sam's paper to classify and analyze three different identity system architectures. I hope it provides a used model for thinking about identity online.
John Locke was an English philosopher who thought a lot about power: who had it, how it was used, and how it impacted the structure of society. Locke’s theory of mind forms the foundation for our modern ideas about identity and independence. Locke argued that "sovereign and independent" was man’s natural state and that we gave up freedom, our sovereignty, in exchange for something else, protection, sociality, and commerce, among others. This grand bargain forms the basis for any society.
This question of power and authority is vital in identity systems. We can ask "what do we give up and to whom in a given identity system?" More succinctly we ask: who controls what? In Authentic Digital Relationships I made the argument that self-sovereign identity, supporting heterarchical (peer-to-peer) interaction, enables rich digital relationships that allow people to be digitally embodied so they can act online as autonomous agents. I argued that the architecture of SSI, its structure, made those relationships more authentic.
In this post, I intend to explore the details of that architecture so we can better understand the legitimacy of SSI as an identity system for online interaction. Wikipedia defines legitimacy as
the right and acceptance of an authority, usually a governing law or a regime.
While the idea of legitimacy is most often applied to governments, I think we can rightly pose legitimacy questions for technical systems, especially those that function in an authoritative manner and have large impacts on people and society. Without legitimacy, people and organizations using an identity system will be unable to act because anyone they interact with will not see that action as authorized. My thesis is that SSI provides a more legitimate basis for online identity than administrative identity systems of the past.
While we properly talk of identity systems, identity systems do not manage identities, but rather relationships. Identity systems provide the means necessary for remembering, recognizing, and relying on the other parties to the relationship. To do so, they use identifiers, convenient handles that name the thing being remembered. Identifiers are unique within some namespace. The namespace gives context to the identifiers since the same string of characters might be a phone number in one system and a product ID in another.
Identifiers are issued to or created by a controller who by virtue of knowing the authentication factors can make authoritative statements about the identifier (e.g. claiming it by logging in). The controller might be a person, organization, or software system. The controller might be the subject that the identifier refers to, but not necessarily. The authentication factors might be a password, key fob, cryptographic keys, or something else. The strength and nature of the bindings between the controller, authentication factors, and identifier determine the strength and nature of the relationships built on top of them.
To understand why that's so, we introduce the concept of a root of trust1. A root of trust is a foundational component or process in the identity system that is relied on by other components of the system and whose failure would compromise the integrity of the bindings. A root of trust might be primary or secondary depending on whether or not it is replaceable. Primary roots of trust are irreplaceable. Together, the roots of trust form the trust basis for the system.
The trust basis enabled by the identity system underlies a particular trust domain. The trust domain is the set of digital activities that depend on the binding of the controller to the identifier. For example, binding a customer to an identifier allows Amazon to trust that the actions linked to the identifier are authorized by the controller. Another way to look at this is that the strength of the binding between the identifier and customer (controller) determines the risk that Amazon assumes in honoring those actions.
The strength of the controller-identifier binding depends on the strength of the binding between the controller and the authentication factors and between the authentication factors and the identifier. Attacking either of those bindings reduces the trust we have in the controller-identifier binding and increases the risk that actions taken through a particular identifier are unauthorized.
We can broadly classify identity systems into one of three types based on their architectures and primary root of trust:
Both algorithmic and autonomic are SSI systems. They are distinguished by their trust bases. Some SSI systems use one or the other and some (like Sovrin) are hybrid, employing each for different purposes. We'll discuss the properties of the trust basis for each of these in an effort to understand the comparative legitimacy of SSI solutions to traditional administrative ones.
These architectures differ in who controls what and that is the primary factor in determining the basis for trust in them. We call this control authority. The entity with control authority takes action through operations that affect the creation (inception), updating, rotation, revocation, deletion, and delegation of the authentication factors and their relation to the identifier. How these events are ordered and their dependence on previous operations is important. The record of these operations is the source of truth for the identity system.
Identity systems with an administrative architecture rely on an administrator to bind the identifier to the authentication factors. The administrator is the primary root of trust for any domain with an administrative architecture. Almost every identity system in use today has an administrative architecture and their trust basis is founded on the administrator.
Figure 2 shows the interactions between the controller, identifier and authentication factors in an administrative identity system, the role of the administrator, and the impact these have on the strength of the bindings. The controller usually generates the authentication factors by choosing a password, linking a two-factor authentication (2FA) mechanism, or generating keys.
Even though the identifier might be the controller's email address, phone number, public key, or other ID, the administrator "assigns" the identifier to the controller because it is their policy that determines which identifiers are allowed, whether they can be updated, and their legitimacy within the identity system's domain. The administrator "owns" the identifier within the domain. The administrator also asserts the binding between the identifier and the authentication factors. An employee's mistake, a policy change, or a hack could affect the binding between the identifier and authentication factors or the identifier and the controller. Consequently, these bindings are relatively weak. Only the binding between the controller and authentication factors is strong because the controller generates them.
The administrator's primary duty is to authoritatively assert the controller-identifier binding. Authoritative control statements about the identifier are recorded in the administrator's database, the source of truth in the system, subject to change by employees and hackers. The administrator might be an ecommerce site that maintains an identity system as the basis for its customer's account. In this case the binding is private, and its integrity is of interest only to the web site and the customer. Alternatively, the administrator might provide federated login services. In this case the administrator is asserting the controller-identifier binding in a semi-public manner to anyone who relies on the federated login. A certificate authority is an example of an administrator who publicly asserts the controller-identifier binding, signing a certificate to that effect.
Because the administrator is responsible for binding the identifier to both the authentication factors and the controller, the administrator is the primary root of trust and thus the basis for trust in the overall system. Regardless of whether the binding is private, semi-public, or public, the integrity of the binding is entirely dependent on the administrator and the strength of their infrastructure, policies, employees, and continued existence. The failure of any of those can jeopardize the binding, rendering the identity system unusable by those who rely on it.
Identity systems that rely on a ledger have an algorithmic architecture. 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. Of course, it's not just algorithms. Algorithms are embodied in code, written by people, running on servers. How the code is written, its availability to scrutiny, and the means by which it is executed all impact the trust basis for the system. "Algorithmic" is just shorthand for all of this.
Figure 3 shows how the controller, authentication factors, identifier, and ledger are bound in an identity system with an algorithmic architecture. As in the administrative identity system, the controller generates the authentication factors, albeit in the form of a public-private key pair. The controller keeps and does not share the private key. The public key, on the other hand, is used to derive an identifier (at least in well-designed SSI systems) and both are registered on the ledger. This registration is the inception of the controller-identifier binding since the controller can use the private key to assert her control over the identifier as registered on the ledger. Anyone with access to the ledger can determine algorithmically that the controller-identifier binding is valid.
The controller makes authoritative control statements about the identifier. The events marking these operations are recorded on the ledger which becomes the source of truth for anyone interested in the binding between the identifier and authentication factors.
In an identity system with an algorithmic trust basis, computer algorithms create a ledger that records the key events. The point of the ledger is that no party has the power to unilaterally decide whether these records are made, modified, or deleted and how they're ordered. Instead, the system relies on code executed in a decentralized manner to make these decisions. The nature of the algorithm, the manner in which the code is written, and the methods and rules for its execution all impact the integrity of the algorithmic identity system and consequently any bindings that it records.
Identity systems with an autonomic architecture function similarly to those with an algorithmic architecture. As shown in Figure 4, the controller generates a public-private key pair, derives a globally unique identifier, and shares the identifier and the currently associated public key with anyone.
The controller uses her private key to authoritatively and non-repudiably sign statements about the operations on the keys and their binding to the identifier, storing those in an ordered key event log2. One of the important realizations that make autonomic identity systems possible is that the key event log must only be ordered in the context of a single identifier, not globally. So, a ledger is not needed for recording operations on identifiers that are not public. The key event log can be shared with and verified by anyone who cares to see it.
The controller also uses the private key to sign statements that authenticate herself and authorize use of the identifier. A digital signature also provides the means of cryptographically responding to challenges to prove her control of the identifier. These self-authentication and self-authorization capabilities make the identifier self-certifying and self-managing, meaning that there is no external third party, not even a ledger, needed for the controller to manage and use the identifier and prove to others the integrity of the bindings between herself and the identifier. Thus anyone (any entity) can create and establish control over an identifier namespace in a manner that is independent, interoperable, and portable without recourse to any central authority. Autonomic identity systems rely solely on self-sovereign authority.
Autonomic identifiers have a number of advantages:
Self-Certification—autonomic identifiers are self-certifying so there is no reliance on a third party.
Self-Administration—autonomic identifiers can be independently administered by the controller.
Cost—autonomic identifiers are virtually free to create and manage.
Security—because the keys are decentralized, there is no trove of secrets that can be stolen.
Regulatory—since autonomic identifiers need not be publicly shared or stored in an organization’s database, regulatory concern over personal data can be reduced.
Scale—autonomic identifiers scale with the combined computing capacity of all participants, not some central system.
Independent—autonomic identifiers are not dependent on any specific technology or even being online.
Algorithmic and Autonomic Identity In Practice
We are all familiar with administrative identity systems. We use them all the time. Less familiar are algorithmic and autonomic identity systems. Their use is emerging under the title of self-sovereign identity.
There are several parallel development efforts supporting algorithmic and autonomic identifiers. The Decentralized Identifier specification is the primary guide to algorithmic identifiers that live on a ledger. The DID specification provides for many DID methods that allow DIDs to live on a variety of data stores. There's nothing in the DID specification itself that requires that the data store be a blockchain or ledger, but that is the primary use case.
As algorithmic identifiers, DIDs allow the controller to cryptographically make authoritative statements about the identifier and the keys it is bound to. Those statements are recorded on a ledger or blockchain to provide a record of the key events that anyone with access to the ledger can evaluate. The record is usually public since the purpose of putting them on a ledger is to allow parties who don't have an existing relationship to evaluate the identifier and its linkage to the controller and public keys.
The second option is Peer DIDs. The vast majority of relationships between people, organizations, and things need not be public and thus have no need for the ability to publicly resolve the DID. Peer DIDs fill this need with the benefits of autonomic identifiers listed above.
Like KERI, Peer DIDs maintain a key event log (called "deltas") that records the relevant operations on the keys in a cryptographic manner. The Peer DID key event log can be shared with other parties in the relationship over DIDComm, a protocol that allows parties to a relationship to securely and privately share authenticated messages. The security and authority of a DIDComm channel are rooted in DIDs and their associated authentication factors. DIDComm can be used over a wide variety of transports.
The vast majority of digital relationships are peer to peer and should use autonomic identifiers. Algorithmic identifiers allow for public discovery of identifier properties when relationships are not peer to peer. In the Sovrin Network3, the ledger records public DIDs for verifiable credential issuers. But people, organizations, and things form relationships using peer DIDs without need for the ledger. This hybrid use of both algorithmic and autonomic identity systems was designed so that credential exchange would be practical, secure, and private while reducing the correlation that might occur if individuals used a few DIDs on a ledger.
Comparing Identity Architectures
Table 1 summarizes the architectural properties of identity systems with administrative, algorithmic, and autonomic bases of trust.
The table shows how the locus of control, source of truth, root of trust, and trust basis differ for each of our three architectures. For Administrative systems, the administrator is directly in control of all four of these. In an algorithmic architecture, the controller is the locus of control because the ledger is set up to allow the controller to be in charge of all key operations. Sometimes this is done using special administrative keys instead of the keys associated with the identifier. The organizations or people operating nodes on the ledger never have access to the keys necessary to unilaterally change the record of operations. No third party is involved in autonomic identity systems.
Table 2 summarizes the trust bases of administrative, algorithmic, and autonomic identity systems4.
We can see from the evaluation that algorithmic and autonomic architectures are decentralized while the administrative system has a single point of failure—the third party administrator. As a result administrative systems are less secure since an attack on one party can yield a trove of valuable information. Administrative systems also rely on privacy by policy rather than having privacy preserving features built into the architecture. And, as we've seen, all too often privacy is in direct conflict with the administrator's profit motive leading to weak privacy policies.
Power and Legitimacy
I started this post by talking about power and legitimacy. From our discussion and the summary tables above, we know that power is held very differently in these three systems. In an administrative system, the administrator holds all the power. I argued in Authentic Digital Relationships that the architecture of our identity systems directly impacts the quality and utility of the digital relationships they support. Specifically, the power imbalance inherent in administrative identity systems yields anemic relationships. In contrast, the balance of power engendered by SSI systems (both algorithmic and autonomic) yields richer relationships since all parties can contribute to it.
Clearly, administrative identity systems have legitimacy—if they didn't, no one would use or trust them. As new architectures, algorithmic and autonomic systems have yet to prove themselves through usage. But we can evaluate each architecture in terms of the promises it makes and how well it does in the purposes of an identity system: recognizing, remembering, and relying on other parties in the relationship. These are largely a function of the trust basis for the system.
Administrative systems promise an account for taking actions that the administrator allows. They also promise these accounts will be secure and private. But people and organizations are increasingly concerned with privacy and seemingly non-stop security breaches are chipping away at that legitimacy. As noted above, the privacy promise is often quite limited. Since the administrator is the basis for trust, administrative systems allow the administrator to recognize, remember, and rely on the identifier depending on their security. But the account holder does not get any support from the administrative system in recognizing, remembering, or relying on the administrator. The relationship is strictly one-way and anemic.
SSI systems promise to give anyone the means to securely and privately create online relationships and trustworthily share self-asserted and third-party-attested attributes with whoever they chose. These promises are embodied in the property I call fidelity. To the extent that algorithmic and autonomic identity systems deliver on these promises, they will be seen as legitimate.
Both algorithmic and autonomic identity systems provide strong means for recognizing, remembering, and relying on the identifiers in the relationship. For an algorithmic system, we must trust the ledger as the primary root of trust and the trust basis. Clearly our trust in the ledger will depend on many factors, including the code and the governance that controls its operation.
The trust basis for an autonomic identity system is cryptography. This implies that digital key management will become an important factor in its legitimacy. If people and organizations cannot easily manage the keys in such a system, then it will not be trusted. There is hope that key management can be solved since the primary artifacts that people using an SSI system manipulate are relationships and credentials, not keys and secrets. By supporting a consistent user experience rooted in familiar artifacts from the physical world, SSI promises to make cryptography a usable technology by the majority of people on the Internet.
In this article, we've explored the high-level architectures for the identity systems in use today as well as new designs that promise richer, more authentic online relationships, better security, and more privacy. By exploring the trust bases that arise from these architectures we've been able to explore the legitimacy of these architectures as a basis for online identity. My belief is that a hybrid system that combines algorithmic public identifiers with autonomic private identifiers can provide a universal identity layer for the Internet, increasing security and privacy, reducing friction, and providing new and better online experiences.
Often the term root of trust is used to a hardware device or some trusted hardware component in the computer. The usage here is broader and refers to anything that is relied on for trust in the identity system. Trust anchor is a term that has sometimes been used in the cryptography community to refer to this same concept.
A number of cryptographic systems are trivially self-certifying (e.g. PGP, Ethereum, Bitcoin, etc.). What sets the autonomic identity systems described here apart is the key event log. Sam Smith calls these identifiers “autonomic identifiers” to set them apart from their less capable counterparts and emphasize their ability to self-manage keys without recourse to a third party system.
The Sovrin Network is an operational instance of the code found in the Hyperledger Indy and Aries projects.
This table is borrowed, with permission, from Chapter 10 of the upcoming Manning publication Self-Sovereign Identity by Drummond Reed and Alex Preukschat.
An earlier blog post, Relationships and Identity proposed that we build digital identity systems to create and manage relationships—not identities—and discussed the nature of digital relationships in terms of their integrity, lifespan, and utility. You should read that post before this one.
In his article Architecture Eats Culture Eats Strategy, Tim Bouma makes the point that the old management chestnut Culture Eats Strategy leaves open the question: how do we change the culture? Tim's point is that architecture (in the general sense) is the upstream predator to culture. Architecture is a powerful force that drives culture and therefore determines what strategies will succeed—or, more generally, what use cases are possible.
Following on Tim's insight, my thesis is that identity systems are the foundational layer of our digital ecosystem and therefore the architecture of digital identity systems drives online culture and ultimately what we can do and what we can't. Specifically, since identity systems are built to create and manage relationships, their architecture deeply impacts the kinds of relationships they support. And the quality of those relationships determines whether or not we live effective lives in the digital sphere.
Administrative Identity Systems Create Anemic Relationships
I was the founder and CTO of iMall, an early, pioneering ecommerce tools vendor. As early as 1996 we determined that we not only needed a shopping cart that kept track of a shopper's purchases in a single session, but one that knew who the shopper was from visit to visit so we could keep the shopping cart and pre-fill forms with shipping and billing addresses. Consequently, we built an identity system. In the spirit of the early web, it was a one-off, written in Perl and storing personal data in Berkeley DB. We did hash the passwords—we weren't idiots1.
Early Web companies had a problem: we needed to know things about people and there was no reliable way for them to tell us who they were. So everyone built an identity system and thus began my and your journey to collecting thousands of identifiers as the Web expanded and every single site needed it's own way to know things about us.
Administrative identity systems, as these kinds of identity systems are called, create a relationship between the organization operating the identity system and the people who are their customers, citizens, partners, and so on. They are, federation notwithstanding, largely self contained and put the administrator at the center as shown in Figure 1. This is their fundamental architecture.
Administrative identity systems are owned. They are closed. They are run for the purposes of their owners, not the purposes of the people or things being administered. They provision and permission. They are bureaucracies for governing something. They rely on rules, procedures, and formal interaction patterns. Need a new password? Be sure to follow the password rules of what ever administrative system you're in. Fail to follow the company's terms of service? You could lose your account without recourse.
Administrative identity systems use a simple schema, containing just the attributes that the administrator needs to serve their purposes and reduce risk. The problem I and others were solving back in the 90's was legibility2. Legibility is a term used to describe how administrative systems make things governable by simplifying, inventorying, and rationalizing things around them. Identity systems make people legible in order to offer them continuity and convenience while reducing risk for the administrator.
Administrative identity systems give rise to a systematic inequality in the relationships they manage. Administrative identity systems create bureaucratic cultures. Every interaction you have online happens under the watchful eye of a bureaucracy built to govern the system and the people using it. The bureaucracy may be benevolent, benign, or malevolent but it controls the interaction.
Designers of administrative identity systems do the imaginative work of assigning identifiers, defining the administrative schemas and processes, and setting the purpose of the identity system and the relationships it engenders. Because of the systematic imbalance of power that administrative identity systems create, administrators can afford to be lazy. To the administrator, everyone is structurally the same, being fit into the same schema. This is efficient because they can afford to ignore all the qualities that make people unique and concentrate on just their business. Meanwhile subjects are left to perform the "interpretive labor" as David Graeber calls it of understanding the system, what it allows or doesn't, and how it can be bent to accomplish their goals. Subjects have few tools for managing these relationship because each one is a little different, not only technically, but procedurally as well. There is no common protocol or user experience. Consequently, subjects have no way to operationalize the relationship except in whatever manner the administrator allows.
Cold, impersonal, bureaucratic relations are much like cash transactions, and both offer similar advantages and disadvantages. On the one hand they are soulless. On the other, they are simple, predictable, and—within certain parameters, at least—treat everyone more or less the same.
I argue that this is the kind of thing the internet is best at. Our online relationships with ecommerce companies, social media providers, banks, and others are cold and impersonal, but also relatively efficient. In that sense, the web has kept its promise. But the institutionalized frame of action that has come to define it alienates its subjects in two ways:
They are isolated and estranged from each other.
They surrender control over their online activity and the associated data within a given domain to the administrator of that domain.
The administrative architecture and the bureaucratic culture it creates has several unavoidable, regrettable outcomes:
Anemic relationships that limit the capabilities of the systems they support. For example, social media platforms are designed to allow people to form a link (symmetrical or asymmetrical) to others online. But it is all done within the sphere of the administrative domain of the system provider. The relationships in these systems are like two-dimensional cardboard cutouts of the real relationships they mirror. We inhabit multiple walled gardens that no more reflect real life than do the walled gardens of amusement parks.
A surveillance economy that relies on the weak privacy provisions that administrative systems create to exploit our online behavior as the raw material for products that not only predict, but attempt to manipulate, our future behaviors.3 Many administrative relationships are set up to harvest data about our online behavior. The administrator controls the nature of these relationships: what is allowed and what behavior is rewarded.
Single points of failure where key parts of our lives are contained within the systems of companies that will inevitably cease to exist someday. In the words of Craig Burton: "It's about choice: freedom of choice vs. prescribed options. Leadership shifts. Policies expire. Companies fail. Systems decay. Give me the freedom of choice to minimize these hazards."
The Self-Sovereign Alternative
Self-sovereign identity (SSI) systems offers an alternative model that supports richer relationships. Rather than provisioning identifiers and accounts in an administrative system where the power imbalance assures that one party to the relationship can dictate the terms of the interaction, SSI is founded on peer relationships that are co-provisioned by the exchange of decentralized identifiers. This architecture implies that both parties will have tools that speak a common protocol.
Figure 2 shows the self-sovereign identity stack. The bottom two layers, the Verifiable Data Repositories and the Peer-to-Peer Agents make up what we refer to as the Identity Metasystem. The features of the metasystem architecture are our primary interest. I have written extensively about the details of the architecture of the metasystem in other posts (see The Sovrin SSI Stack and Decentralized Identifiers).
The architecture of the metasystem has several important features:
Mediated by protocol—Instead of being intermediated by an intervening administrative authority, activities in the metasystem are mediated through peer-to-peer protocol. Protocols are the foundation of interoperability and allow for scale. Protocols describe the rules for a set of interactions, specifying the kinds of interactions that can happen without being overly prescriptive about their nature or content. Consequently, the metasystem supports a flexible set of interactions that can be adapted for many different contexts and needs.
Heterarchical—Interactions in the metasystem are peer-to-peer rather than hierarchical. The are not just distributed, but decentralized. Decentralization enables autonomy and flexibility and to assure its independence from the influence of any single actor. No centralized system can anticipate all the various use cases. And no single actor should be allowed to determine who uses the system or for what purposes.
Consistent user experience—A consistent user experience doesn’t mean a single user interface. Rather the focus is on the experience. As an example, consider an automobile. My grandfather, who died in 1955, could get in a modern car and, with only a little instruction, successfully drive it. Consistent user experiences let people know what to expect so they can intuitively understand how to interact in any given situation regardless of context.
Polymorphic—The information we need in any given relationship varies widely with context. The content that an identity metasystem carries must be flexible enough to support many different situations.
These architectural features give rise to a culture that I describe as protocological. The protocological culture of the identity metasystem has the following properties:
Open and permissionless—The metasystem has the same three virtues of the Internet that Doc Searls and Dave Weinbergerenumerated as NEA: No one owns it, Everyone can use it, and Anyone can improve it. Special care is taken to ensure that the metasystem is censorship resistant so that everyone has access. The protocols and code that enable the metasystem are open source and available for review and improvement.
Agentic—The metasystem allows allows people to act as autonomous agents, under their self-sovereign authority. The most vital value proposition of self-sovereign identity is autonomy—not being inside someone else's administrative system where they make the rules in a one sided way. Autonomy requires that participants interact as peers in the system, which the architecture of the metasystem supports.
Inclusive—Inclusivity is more than being open and permissionless. Inclusivity requires design that ensures people are not left behind. For example, some people cannot act for themselves for legal (e.g. minors) or other (e.g. refugees) reasons. Support for digital guardianship ensures that those who cannot act for themselves can still participate.
Flexible—The metasystem allows people to select appropriate service providers and features. No single system can anticipate all the scenarios that will be required for billions of individuals to live their own effective lives. A metasystem allows for context-specific scenarios.
Modular—An identity metasystem can’t be a single, centralized system from a single vendor with limited pieces and parts. Rather, the metasystem will have interchangeable parts, built and operated by various parties. Protocols and standards enable this. Modularity supports substitutability, a key factor in autonomy and flexibility.
Universal—Successful protocols eat other protocols until only one survives. An identity metasystem based on protocol will have network effects that drive interoperability leading to universality. This doesn't mean that one organization will have control, it means that one protocol will mediate all interaction and everyone in the ecosystem will conform to it.
Supporting Authentic Relationships
Self-sovereign identity envisions digital life that cannot be supported with traditional identity architectures. The architecture of self-sovereign identity and the culture that springs from it support richer, more authentic relationships:
Self-sovereign identity provides people with the means of operationalizing their online relationships by providing them the tools for acting online as peers and managing the relationships they enter into.
Self-sovereign identity, through protocol, allows ad hoc interactions that were not or cannot be imagined a priori.
The following subsections give examples for each of these.
Many real-world experiences have been successfully digitized, but the resulting intermediation opens us to exploitation despite the conveniences. We need digitized experiences that respect human dignity and don't leave us open to being exploited for some company's advantage. As an example consider how the identity metasystem could be the foundation for a system that disintermediates the food delivery platforms. Platform companies have been very successful in intermediating these exchanges and charging exorbitant rents for what ought to be a natural interaction among peers.
That's not to say platforms provide no value. The problem isn't that they charge for services, but that their intervening position gives them too much power to make markets and set prices. Platforms provide several things that make them valuable to participants: a means of discovering relevant service providers, a system to facilitate the transaction, and a trust framework to help participants make the leap over the trust gap, as Rachel Botsman puts it. An identity metasystem supporting self-sovereign identity provides a universal trust framework for building systems that can serve as the foundation for creating markets without intermediaries. Such a system with support for a token can even facilitate the transaction without anyone having an intervening position.
Disintermediating platforms requires creating a peer-to-peer marketplace on top of the metasystem. While the metasystem provides the means of creating and managing the peer-to-peer relationship, defining this marketplace requires determining the messages to be exchanged between participants and creating the means of discovery. These messages might be simple or complex depending on the market and could be exchanged using DIDComm, or even ride on top of a verifiable credential exchange. There might be businesses that provide discovery, but they don't intermediate, they sit to the side of the interaction providing a service. For example, such a business might provide a service that allows a restaurant to define its menu, create a shopping cart, and provide for discovery, but the merchant could replace it with a similar service, providing competition, because the trust interaction and transaction are happening via a protocol built on a universal metasystem.
Building markets without intermediaries greatly reduces the cost of participating in the market and frees participants to innovate. Because these results are achieved through protocol, we do not need to create new regulations that stifle innovation and lock in incumbents by making it difficult for new entrants to comply. And these systems preserve human dignity and autonomy by removing administrative authorities.
Digitizing Auto Accidents
As an example of the the kinds of interactions that people have every day that are difficult to bring into the administrative sphere, consider the interactions that occur between various participants and their representatives following an auto accident. Because these interactions are ad hoc, large parts of our lives have yet to enjoy the convenience of being digitized. In You've Had an Automobile Accident, I imagine a digital identity system that enables the kinds of ad hoc, messy, and unpredictable interactions that happen all the time in the physical world.
In this scenario, two drivers, Alice and Bob, have had an accident. Fortunately, no one was hurt, but the highway patrol has come to the scene to make an accident report. Both Alice and Bob have a number of credentials that will be necessary to create the report:
Proof of insurance issued by their respective insurance companies
Vehicle title from the state
Vehicle registration issued by the Department of Motor Vehicles (DMV) in different states (potentially)
Driver's license, potentially from a different agencies than the one who registers cars and potentially in different states
In addition, the police officer has credentials from the Highway Patrol, Alice and Bob will make and sign statements, and the police officer will create an accident report. What's more, the owners of the vehicles may not be the drivers.
Now imagine you're building a startup to solve the "car accident use case." You imagine a platform to relate to all these participants and intermediate the exchange of all this information. To have value, it has to do more than provide a way to exchange PDFs and most if not all of the participants have to be on it. The system has to make the information usable. How do you get all the various insurance companies, state agencies, to say nothing of the many body shops and hospitals, fire departments, and ambulance companies on board? And yet, these kinds of ad hoc interactions confront us daily.
You do not have an accurate operational relationship with your Government.
My thought was "not just government". The key word is "operational". People don't have operational relationships anywhere online.4 We have plenty of online relationships, 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. Scenarios like the ones envisioned in the preceding section happen all the time in the physical world—in fact they're the norm. When we dine at a restaurant or shop at a store in the physical world, we do not do so under some administrative system. Rather, as embodied agents, we operationalize our relationships, whether they be long-lived or nascent, by acting for ourselves. An identity metasystem provides people with the tools they need to be "embodied" in the digital world and act autonomously.
Time and again, various people have tried to create decentralized marketplaces or social networks only to fail to gain traction. These systems fail because they are not based on a firm foundation that allows people to act in relationships with sovereign authority in systems mediated through protocol rather than companies. We have a fine example of a protocol mediated system in the internet, but we've failed to take up the daunting task of building the same kind of system for identity. Consequently, when we act, we do so without firm footing or sufficient leverage.
Ironically, the internet broke down the walled gardens of CompuServe and Prodigy with a protocol-mediated metasystem, but surveillance capitalism has rebuilt them on the web. No one could live an effective life in an amusement park. Similarly, we cannot function as fully embodied agents in the digital sphere within the administrative systems of surveillance capitalists, despite their attractions. The emergence of self-sovereign identity, agreements on protocols, and the creation of a metasystem to operationalize them promises a digital world where decentralized interactions create life-like online experiences. The identity metasystem and the richer relationships that result from it promise an online future that gives people the opportunity to act for themselves as autonomous human beings and supports their dignity so that they can live an effective online life.
Two of my friends at the time, Eric Thompson and Stacey Son were playing with FPGAs that could crack hashed passwords, so we were aware of the problems and did our best to mitigate them.
See Venkatesh Rao's nice summary of James C. Scott's seminal book on legibility and its unintended consequences, Seeing Like a State for more on this idea.
The one exception I can think of to this is email. People act through email all the time in ways that aren't intermediated by their email provider. Again, it's a result of the architecture of email, set up over four decades ago and the culture that architecture supports.
Descartes didn't say "I have a birth certificate, therefore I am." We do not spring into existence because some administrative system provisions an identifier for us. No single administrative regime, or even a collection of them, defines us. Doc Searls said this to me recently:
We are, within ourselves, what William Ernest Henley calls “the captain” of “my unconquerable soul”, and what Walt Whitman meant when he said “I know this orbit of mine cannot be swept by a carpenter's compass,” and “I know that I am august. I do not trouble my spirit to vindicate itself or be understood.” Each of us has an inner essence that is who we are.
Even in the digital realm, and limiting ourselves to what Joe Andrieu calls "functional identity", we are more than any single relationship. Our identity is something we are, not something we have. And it's certainly not what someone else provides to us. We are self-sovereign.
Some shrink from the self-sovereign label. There are some good reasons for their reluctance. Self-sovereignty requires some explanation. And it has political overtones that make some uncomfortable. But I've decided to embrace it. Self-sovereign identity is more than decentralized identity. Self-sovereign identity implies autonomy and inalienability.
If our identity is inalienable, then it's not transferable to another and not capable of being taken away or denied. To be inalienable is to be sovereign: to exercise supreme authority over one’s personal sphere—Whitman’s “orbit of mine.” Administrative identifiers, what others choose to call us, are alienable. Relationships are alienable. Most attributes are alienable1. Who we are, and our right to choose how we present ourselves to the world, is not alienable. The distinction between the inalienable and the alienable, the self-sovereign and the administrative, is essential. Without this distinction, we are constantly at the mercy of the various administrative regimes we interact with.
Self-sovereignty is concerned with relationships and boundaries. When we say a nation is sovereign, we mean that it can act as a peer to other sovereign states, not that it can do whatever it wants. Sovereignty defines the source of our authority to act. Sovereignty defines a boundary, within which the sovereign has complete control and outside of which the sovereign relates to others within established rules and norms. Self-sovereign identity defines the boundary in the digital space, gives tools to people and organizations so they can assert control—their autonomy, and defines the rules for how relationships are formed, authenticated, and used.
In the opening chapter of her groundbreaking book, The Age of Surveillance Capitalism, Shoshana Zuboff asks the question "Can the digital future be our home?" Not if it's based on administrative identity systems and the anemic, ofttimes dangerous, relationships they create. By starting with self-sovereignty, we found our digital relationships on principles that support and preserve human freedom, privacy, and dignity. So, while talking about trust, decentralization, credentials, wallets, and DIDs might help explain how self-sovereign identity works, sovereignty explains why we do it. If self-sovereignty requires explanation, maybe that's a feature, not a bug.
I'm distinguishing attributes from traits without going too deep into that idea for now.
The most problematic word in the term Self-Sovereign Identity (SSI) isn't "sovereign" but "identity" because whenever you start discussing identity, the conversation is rife with unspoken assumptions. Identity usually conjures thoughts of authentication and various federation schemes that purport to make authentication easier. I frequently point out that even though SSI has "identity" in it's name, there's no artifact in SSI called an "identity." Instead the user experience in an SSI system is based on forming relationships and using credentials.
I've been thinking a lot lately about the role of relationships in digital identity systems and have come to the conclusion that we've been working on building building systems that support digital relationships without acknowledging the importance of relationships or using them in our designs and architectures. The reason we build identity systems isn't to manage identities, it's to support digital relationships.
I recently read and then reread a 2011 paper called Identities Evolve: Why Federated Identity is Easier Said than Done from Steve Wilson. Despite being almost ten years old, the paper is still relevant, full of good analysis and interesting ideas. Among those is the idea that the goal of using federation schemes to create a few identities that serve all purposes is deeply flawed. Steve's point is that we have so many identities because we have lots of relationships. The identity data for a given relationship is contextual and highly evolved to fit its specific niche.
Steve's discussion reminded me of a talk Sam Ramji used to give about speciation of APIs. Sam illustrated his talk with a picture from Encyclopedia Britannica to show adaptive radiation in Galapagos finches in response to evolutionary pressure. These 14 different finches all share a common ancestor, but ended up with quite different features because of specialization for a particular niche.
In the same way, each of us have hundreds, even thousands, of online relationships. They each have a common root but are highly contextualized. Some are long-lived, some are ephemeral. Some are personal, some are commercial. Some are important, some are trivial. Still, we have them. The information about ourselves, what many refer to as identity data, that we share with each is just as adapted to the specific niche that the relationship represents as the Galapagos finches are to their niches. Once you realize this, the idea of creating a few online identities to serve all needs becomes preposterous.
Not only is each relationship evolved for a particular niche, but it is also constantly changing. Often those changes are just more of what's already there. For example, my Netflix account represents a relationship between me and Netflix. It's constantly being updated with my viewing data but not changing dramatically in structure. But some changes are larger. For example, it also allows me to create additional profiles which makes the relationship specialized for the specific members of my household. And when Netflix moved from DVDs only to streaming, the nature of my relationship with Netflix changed significantly.
I'm convinced that identity systems would be better architected if we were more intentional about their need to support specialized relationships spanning millions of potential relationship types. This article is aimed at better understanding the nature of digital relationships.
One of the fundamental problems of internet identity is proximity. Because we're not interacting with people physically, our natural means of knowing who we're dealing with are useless. Joe Andrieu defines identity as "how we recognize, remember, and respond" to another entity. These three activities correspond to three properties digital relationships must have to overcome the proximity problem:
Integrity—we want to know that, from interaction to interaction, we're dealing with the same entity we were before. In other words, we want to identify them.
Lifespan—normally we want relationships to be long-lived, although we also create ephemeral relationships for short-lived interactions.
Utility—we create online relationships in order to use them within a specific context.
We'll discuss each of these in detail below, followed by a discussion of risk in digital relationships.
Without integrity, we cannot recognize the other party to the relationship. Consequently, all identity systems manage relationship integrity as a foundational capability. Federated identity systems improve on one-off, often custom identity systems by providing integrity in a way that reduces user management overhead for the organization, increases convenience for the user, and increases security by eliminating the need to create one-off, proprietary solutions. SSI aims to establish integrity with the convenience of the federated model but without relying on an intervening IdP in order to provide autonomy and privacy.
A relationship has two parties, let's call them P1 and P2.1 P1 is connecting with P2 and, as a result, P1 and P2 will have a relationship. P1 and P2 could be people, organizations, or things represented by a website, app, or service. Recognizing the other party in an online relationship relies on being able to know that you're dealing with the same entity each time you encounter them.
In a typical administrative identity system, when P1 initiates a relationship with P2, P2 typically uses usernames and passwords to ensure the integrity of the relationship. By asking for a username to identify P1 and a password to ensure that it's the same P1 as before, P2 has some assurance that they are interacting with P1. In this model, P1 and P2 are not peers. Rather P2 controls the system and determines how and for what it is used.
In a federated flow, P1 is usually called the subject or consumer and P2 is called the relying party (RP). When the consumer visits the RP's site or opens their app, they are offered the opportunity to establish a relationship through an identity provider (IdP) whom the RP trusts. The consumer may or may not have a relationship with an IdP the RP trusts. RPs pick well-known IdPs with large numbers of users to reduce friction in signing up. The consumer chooses which IdP they want to use from the relying party's menu and is redirected to the IdP's identity service where they present a username and password to the IdP, are authenticated, and redirected back to the RP. As part of this flow, the RP gets some kind of token from the IdP that signifies that the IdP will vouch for this person. They may also get attributes that the IdP has stored for the consumer.2
In the federated model, the IdP is identifying the person and attesting the integrity of the relationship to the RP. The IdP is a third party, P3, who acts as an intervening administrative authority. Without their service, the RP may not have an alternative means of assuring themselves that the relationship has integrity over time. On the other hand, the person gets no assurance from the identity system about relationship integrity in this model. For that they must rely on TLS, which is visible in a web interaction, but largely hidden inside an app on a mobile device. P1 and P2 are not peers in the federated model. Instead, P1 is subject to the administrative control of both the IdP and the RP. Further, the RP us subject to the administrative control of the IdP.
In SSI, a relationship is initiated when P1 and P2 exchange decentralized identifiers (DID). For example, when a person visits a web site or app, they are presented with a connection invitation. When they accept the invitation, they use a software agent to share a DID that they created. In turn, they receive a DID from the web site, app, or service. We call this a "connection" since DIDs are cryptographically based and thus provide a means of both parties mutually authenticating. The user experience does not necessarily surface all this activity to the user. To get a feel for the user experience, run through the demo at Connect.me3.
In contrast to the federated model, the participants in SSI mutually authenticate and the relationship has integrity without the intervention of a third party due to the self-certifying nature of the identifiers. By exchanging DIDs both parties have also exchanged public keys. They can consequently use cryptographic means to ensure they are interacting with the party who controls the DID they received when the relationship was initiated. Mutual authentication, based on self-certifying DIDs provides SSI relationships with inherent integrity. P1 and P2 are peers in SSI since they both have equal control over the relationship.
In addition to removing the need for intermediaries to vouch for the integrity of the relationship, the peer nature of relationships in SSI also means that neither party has access to the authentication credentials of the other. Mutual authentication means that each party manages their own keys and never shares the private key with another party. Consequently, attacks, like the recent attack on Twitter accounts can't happen in SSI because there's no administrator who has access to the credentials of everyone using the system.
Whether in the physical world or digital, relationships have lifespans. Some relationships are long-lived, some are short-term, and others are ephemeral, existing only for the duration of a single interaction. We typically don't think of it this way, but every interaction we have in the physical world, no matter for what purpose or how short, sets up a relationship. So too in the digital world, although our tools, especially as people online, have been sorely lacking.
I believe one of the biggest failings of modern digital identity systems is our failure to recognize that people often want, even need, short-lived relationships. Think about your day for a minute. How many people and organizations did you interact with in the physical world4 where you established a permanent relationship? What if whenever you stopped in the convenience store for a cup of coffee, you had to create a permanent relationship with the coffee machine, the cashier, the point of sale terminal, and the customers in line ahead and behind you? Sounds ridiculous. But that's what most digital interactions require. At every turn we're asked to establish permanent accounts to transact and interact online.
There are several reasons for this. The biggest one is that every Web site, app, or service wants to send you ads, at best, or track you on other sites, at worst. Unneeded, long-lived relationships are the foundation of the surveillance economy that has come to define the modern online experience.
There are a number of services I want a long-lived relationship with. I value my relationships with Amazon and Netflix, for example. But there are many things I just need to remember for the length of the interaction. I ordered some bolts for a car top carrier from a specialty place a few weeks ago. I don't order bolts all the time, so I just want to place my order and be done. I want an ephemeral relationship. The Internet of Things will increase the need for ephemeral relationships. When I open a door with my digital credential, I don't want the hassle of creating a long-term relationship with it; I just want to open the door and then forget about it.
Digital relationships should be easy to set up and tear down. They should allow for the relationship to grow over time, if both parties desire. While they exist, they should be easily managable while providing all the tools for the needed utility. Unless there's long term benefit to me, I shouldn't need to create a long term relationship. And when a digital relationship ends, it should really be over.
Obviously, we don't create digital relationships just so we can authenticate the other party. Integrity is a necessary, but insufficient, condition for an identity system. This is where most identity models fall short. We can understand why this is so given the evolution of the modern Web. For the most part, user-centric identity really took off when the web gave people reasons to visit places they didn't have a physical relationship with, like an ecommerce web site. Once the identity system had established the integrity of the relationship, at least from the web site's perspective, we expected HTTP would provide the rest.
Most Identity and Access Management systems don't provide much beyond integrity except possibly access control. Once Facebook has established who you are, it knows just what resources to let you see or change. But as more and more of our lives are intermediated by digital services, we need more utility from the identity system than simple access control. The most that an IdP can provide in the federated model is integrity and, perhaps, a handful of almost-always-self-asserted attributes in a static, uncustomizable schema. But rich relationships require much more than that.
Relationships are established to provide utility. An ecommerce site wants to sell you things. A social media site wants to show you ads. Thus, their identity systems, built around the IAM system, are designed to do far more than just establish the integrity of the relationship. They want to store data about you and your activities. For the most part this is welcome. I love that Amazon shows me my past orders, Netflix remembers where I was in a series, and Twitter keeps track of my followers and past tweets.
The true identity system is much, much larger and specialized than the IAM portion. All of the account or profile data these companies use is properly thought of as part of the identity system that they build and run. Returning to Joe Andrieu:
Identity systems acquire, correlate, apply, reason over, and govern [the] information assets of subjects, identifiers, attributes, raw data, and context.
Regardless of whether or not they outsource the integrity of their relationships (and notice that none of the companies I list above do), companies still have to keep track of the relationships they have with customers or users in order to provide the service they promise. They can't outsource this to a third party because the data in their identity system has evolved to suit the needs of the specific relationship. We'll never have a single identity that serves all relationships because they are unique contexts that demand their own identity data. Rip out the identity system from a Netflix or Amazon and it won't be the same company anymore.
This leads us to a simple, but important conclusion: You can't outsource a relationship. Online apps and services decorate the relationship with information they observe, and use that information to provide utility to the relationships they administer. Doing this, and doing it well is the foundation of the modern web.
Consequently, the bad news is that SSI is not going to reduce the need for companies to build, manage, and use identity systems. Their identity systems are what make them what they are—there is no "one size fits all" model. The good news is that SSI makes online relationships richer. Relationships are easier and less expensive to manage, not just for companies, but for people too. Here's some of the ways SSI will enhance the utility of digital relationships:
Richer, more trustworthy data—Relationships change over time because the parties change. We want to reliably ascertain facts about the other party in a relationship, not just from direct observation, but also from third parties in a trustworthy manner to build confidence in the actions of the other party within a specific context. Verifiable credentials, self-issued or from others, allow relationships to be enhanced incrementally as the relationships matures or changes.
Autonomy and choice through peer relationships—Peer relationship give each party more autonomy than traditional administrative identity systems have provided. And, through standardization and substitutability, SSI gives participants choice in what vendors and agents they employ to manage their relationships. The current state of digital identity is asymmetric, providing companies with tools that are difficult or unwieldy for people to use. People like Doc Searls and organizations like Project VRM and the Me2B Alliance argue that people need tools for managing online relationships too. SSI provides people with tools and autonomy to manage their online relationships with companies and each other.
Unifying, interoperable protocol for data transmission—DIDs and Verifiable Credentials, and DIDComm provides a standardized, secure means of interaction. Just like URLs, HTML, and HTTP provided for an interoperable web that led to an explosion of uses, the common protocol of SSI will ensure everyone benefits from the network effects.
Consistent user experience—Similarly, SSI provides a consistent user experience, regardless of what digital wallet people use. SSI's user experience is centered on relationships and credentials, not arcane addresses and keys. The user experience mirrors the experience people have of managing credentials in the physical world.
These benefits are delivered using an architecture that provides a common, interoperable layer, called the identity metasystem, upon with anyone can build the identity systems they need. A ubiquitous identity layer for the internet must be a metasystem that provides the building blocks and protocols necessary for others to build identity systems that meet the needs of any specific context or domain. An identity metasystem is a prerequisite for an online world where identity is as natural as it is in the physical world. An identity metasystem can remove friction, decrease cognitive overload, and make online interactions more private and secure.
Trust is a popular term in the SSI community. People like Steve Wilson and Kaliya Young rightly ask about risk whenever someone in the identity community talks about trust. Because of the proximity problem, digital relationships are potentially risky. One of the goals of an identity system is to provide evidence that can be used in the risk calculation.
In their excellent paper, Risk and Trust, Nickel and Vaesen define trust as the "disposition to willingly rely on another person or entity to perform actions that benefit or protect oneself or one’s interests in a given domain." From this definition, we see why crypto-proponents often say "To trust is good, but to not trust is better." The point being that not having to rely on some other human, or human-mediated process is more likely to result in a beneficial outcome because it reduces the risk of non-performance.
Relationships imply a shared domain, context, and set of activities. We often rely on third parties to tell us things relevant to the relationship. Our vulnerability, and therefore our risk, depends on the degree of reliance we have on another party's performance. Relationships can never be "no trust" because of the very reasons we create relationships. Bitcoin, and similar systems, can be low or no trust precisely because the point of the system is to reduce the reliance on any relationship at all. The good news, is the architecture of the SSI stack significantly limits the ways we must rely on external parties for the exchange of information via verifiable credentials and thus reduces the vulnerability of parties inside and outside of the relationship. The SSI identity metasystem clearly delineates the parts of the system that are low trust and those where human processes are still necessary.
The exchange of verifiable credentials can be split into two distinct parts as shown in the following diagram. SSI reduces risk in remote relationships using the properties of these two layers to combine cryptographic processes with human processes.
The bottom layer, labeled Identity Metasystem, comprises two components: a set of verifiable data repositories for storing metadata about credentials and a processing layer supported by protocols and practices for the transport and validation of credentials. Timothy Ruff uses the analogy of shipping containers to describe the identity metasystem. Verifiable credentials are analogous to shipping containers and the metasystem is analogous to the shipping infrastructure that makes intermodal shipping so efficient and secure. The Identity Metasystem provides a standardized infrastructure that similarly increases the efficiency and security of data interchange via credentials.
The top layer, labeled Identity Systems, is where people and organizations determine what credentials to issue, determine what credentials to seek and hold, and determine which credentials to accept. This layer comprises the individual credential exchange ecosystems that spring up and the governance processes for managing those credential ecosystems. In Timothy's analogy to shipping containers, this layer is about the data—the cargo—that the credential is carrying.
The Identity Metasystem allows verifiable credentials can be cryptographically checked to ensure four key properties that relate to the risk profile.
Who issued the credential?
Was the credential issued to the party presenting it?
Has the credential been tampered with?
Has the credential been revoked?
These checks show the fidelity of the credential and are done without the verifier needing a relationship with the issuer. And because they're automatically performed by the Identity Metasystem, they significantly reduce the risk related to using data transferred using verifiable credentials. This is the portion of credential exchange that could be properly labeled "low or no trust" since the metasystem is built on standards that ensure the cryptographic verifiability of fidelity without reliance on humans and human-mediated processes.
The upper, Identity Systems, layer is different. Here we are very much relying on the credential issuer. Some of the questions we might ask include:
Is the credential issuer, as shown by the identifier in the credential, the organization we think they are?
Is the organization properly accredited in whatever domain they're operating in?
What data did the issuer include in the credential?
What is the source of that data?
How has that data been processed and protected?
These questions are not automatically verifiable in the way we can verify the fidelity of a credential. They are different for each domain and perhaps different for each type of relationship based on the vulnerability of the parties to the data in the credential and their appetite for risk. Their answers depend on the provenance of the data in the credential. We would expect to see credential verifier's perform provenance checks by answering these and other questions during the process they use to establish trust in the issuer. Once the verifier has established this trust, the effort needed to evaluate the provenance of the data in a credential should cease or be greatly reduced.
As parties in a relationship share data with each other, the credential verifier will spend effort evaluating the provenance of issuers of credentials they have not previously evaluated. Once that is done, the metasystem will provide fidelity checks on each transaction. For the most part, SSI does not impose new ways of making these risk evaluations. Rather, most domains already have processes for establishing the provenance of data. For example, we know how to determine if a bank is a bank, the accreditation status of a university, and the legitimacy of a business. Companies with heavy reliance on properties of their supply chain, like pharmaceuticals, already have processes for establishing the provenance of the supply chain. For the most part, verifiable credential exchange will faithfully present digital representations of the kinds of physical world processes, credentials, and data we already know how to evaluate. Consequently, SSI promises to significantly reduce the cost of reducing risk in remote relationships without requiring wholesale changes to existing business practices.
Relationships have always been the reason we created digital identity systems. Our historic focus on relationship integrity and IAM made modern Web 2.0 platforms and services possible, but has limited use cases, reduced interoperability, and left people open to privacy and security breaches. By focusing on peer relationships supported by an Identity Metasystem, SSI not only improves relationships integrity but also better supports flexible relationship lifecycles, more functional, trustworthy relationship utility, and provides tools for participants to correctly gauge, respond to, and reduce risks inherent in remote relationships.
For simplicity, I'm going to limit this discussion to two-party relationships, not groups.
I've described federation initialization very generally here and left out a number of details that distinguish various federation architectures.
Connect.me is just one of a handful of digital wallets that support the same SSI user experience. Others vendors include Trinsic, ID Ramp, and eSatus AG.
A few days ago I was in a conversation with a couple of my identerati friends. When one used the term "SSI", the other asked him to define it since there were so many systems that were claiming to be SSI and yet were seemingly different. That's a fair question. So I thought I'd write down my definition in hopes of stimulating some conversation around the topic.
I think we've arrived at a place where it's possible to define SSI and get broad consensus about it. SSI stands for self-sovereign identity, but that's not really helpful since people have different ideas about what "sovereign" means and what "identity" means. So, rather than try to go down those rabbit holes, let's just stick with "SSI."1
SSI has the following properties:
SSI systems use decentralized identifiers (DIDs) to identify people, organizations, and things. Decentralized identifiers provide a cryptographic basis for the system and can be employed so that they don't require a central administrative system to manage and control the identifiers. Exchanging DIDs is how participants in SSI create relationships, a critical feature.
SSI supports autonomy for participants. The real value proposition of SSI is autonomy—not being inside someone else's administrative system where they make the rules in a one sided way. Autonomy implies that participants interact as peers in the system. You can build systems that use DIDs and verifiable credentials without giving participants autonomy.
Beyond these there are lots of choices system architects are making. Debates rage about how specifically credential exchange should work, whether distributed ledgers are necessary, and, if so, how should they be employed. But if you don't use DIDs and verifiable credentials in a way that gives participants autonomy and freedom from intervening administrative authorities, then you're not doing SSI.
As a consequence of these properties, participants in SSI systems use some kind of software agent (typically called a wallet for individuals) to create relationships and exchange credentials. They don't typically see or manage keys or passwords. And there's no artifact called an "identity." The primary artifacts are relationships and credentials. The user experience involves managing these artifacts to share attributes within relationships via credential exchange. This user experience should be common to all SSI systems, although the user interface and what happens under the covers might be different between SSI systems or vendors on those systems.
Platforms service two-sided markets. We're all familiar with platform companies like Uber, AirBnB, Monster, eBay, and many others. Visa, Mastercard, and other credit card systems are platforms. Platforms are a popular Web 2.0 business model because they create an attractive way for the provider to extract service fees from one side, and sometimes both sides, of the market. They can have big network effects and tend to natural monopolies.
Platforms provide several things that make them valuable to users:
They provide a means of discovering relevant service providers.
They facilitate the transaction.
They help participants make the leap over the trust gap, as Rachel Botsman puts it.
Like compound interest, small advantages in any of these roles can have huge effects over time as network effects exploit the advantage to drive participants to a particular platform. This is happening rapidly during the recent crisis in food delivery platforms.
But once the lockdowns began, the apps became essentially the only source of business for the barroom restaurant he ran with a partner, Charlie Greene, in Columbus, Ohio. That was when the fees to the delivery companies turned into the restaurant’s single largest cost—more than what it paid for food or labor.
Pierogi Mountain’s primary delivery company, Grubhub, took more than 40 percent from the average order, Mr. Majesky’s Grubhub statements show. That flipped his restaurant from almost breaking even to plunging deeply into the red. In late April, Pierogi Mountain shut down.
"You have no choice but to sign up, but there is no negotiating," Mr. Majesky, who has applied for unemployment, said of the delivery apps. "It almost turns into a hostage situation."
The standard response to these problems from people is more regulation. The article discusses some of the attempts cities, counties, and states have made to rein in the fees that food delivery platforms are charging.
Defining a marketplace requires determining the protocol for interaction between participants and creating the means of discovery. The protocol might be simple or complex depending on the market and could be built on top of DIDComm, or even ride on top of a verifiable credential exchange. There might be businesses that provide discovery, but they don't intermediate, they sit to the side of the interaction providing a service. For example, I might provide a service that allows a restaurant to define it's menu, create a shopping cart, and provide for discovery, but I'm easily replaceable by another provider because the trust interaction and transaction are happening via a protocol built on a universal metasystem.
Building markets without intermediaries greatly reduces the cost of participating in the market and frees participants to innovate. And it does it without introducing regulation that stifles innovation and locks in incumbents by making it difficult for new entrants to comply. I'm hopeful that Sovrin and related technology will put an end to the platform era of the Internet by supporting greater, trustworthyautonomy for all participants.
Photo Credit: BE024003 from Tullio Saba (Public Domain Mark 1.0)