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 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.

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.

Relationship Integrity

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.¹ 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.²

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 is 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.me³.

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.

Relationship Lifespan

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 world⁴ 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.

Relationship Utility

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.
• Better, more secure communications—DID exchange provides a private, secure messaging channel using the DIDComm protocol. This messaging channel is mutually recognized, authenticated, and encrypted.
• 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.
• Support for ad hoc digital interactions—The real world is messy and unpredictable. SSI is flexible enough to support the various ad hoc scenarios that the world presents us and supports sharing multiple credentials from various authorities in the ways the scenario demands.

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.

Relationships, Risk, and Trust

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.

1. Who issued the credential?
2. Was the credential issued to the party presenting it?
3. Has the credential been tampered with?
4. 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.

Conclusion

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.

---

Notes

1. For simplicity, I'm going to limit this discussion to two-party relationships, not groups.
2. I've described federation initialization very generally here and left out a number of details that distinguish various federation architectures.
3. 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.
4. Actually, imagine a day before Covid-19 lockdown.

Photo Credit: Two People Holding Hands from Albert Rafael (Free to use)