Relationships and Identity

Two People Holding Hands

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

adaptive radiation in Galapagos finches
Adaptive radiation in Galapagos finches (click to enlarge)

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

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.

SSI Stack
SSI Stack (click to enlarge)

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)


What is SSI?

Girl On A Bicycle


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 cryptograhic 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.
  • SSI participants use verifiable credentials exchange to share information (attributes) with each other to strengthen or enrich relationships. The system provides the means of establishing credential fidelity.
  • 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.

I'm hopeful that, as we work more on interoperability, the implementation differences will fade away so that we have a single identity metasystem where participants have choice about tools and vendors. An identity metasystem is flexible enough to support the various ad hoc scenarios that the world presents us and will support digital interactions that are life-like.


Notes

  1. This is not to say I don't have opinions on what those words mean in this context. I've written about "sovereign" in On Sovereignty and Self Sovereign is Not Self Asserted.

Photo Credit: Girl On A Bicycle from alantankenghoe (CC BY 2.0)


Held Hostage

Hostages being freed

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:

  1. They provide a means of discovering relevant service providers.
  2. They facilitate the transaction.
  3. 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.

A recent New York Times article, As Diners Flock to Delivery Apps, Restaurants Fear for Their Future, highlights the power that platforms have over their users:

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.

A better response is to create systems that don't require an intermediary. Sovrin provides an identity metasystem that provides a univeral trust framework for building identity systems that can serve as the foundation for creating markets without intermediaries. When Sovrin has a token it can even facilitate the transaction.

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 replacable 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, trustworthy autonomy for all participants.


Photo Credit: BE024003 from Tullio Saba (Public Domain Mark 1.0)


Get the Bike that Speaks to You

My latest bike, a Trek Supercommuter+ 8S

My middle son Jacob recently asked me about a number of gravel bikes in the $1000-1500 price range. In looking them over, they all had aluminum frames, carbon forks, and mechanical disk brakes. The other components differed a little from bike to bike but nothing stood out. All were from major manufacturers.

How to choose? I've bought a number of bikes over the years (I've only got three right now). I told Jacob that one thing made all the difference in choosing: the test ride. I've often been taken in by the specs on a bike, only to ride it and find that it felt dead. The bikes I've purchased spoke to me. They felt like they were alive, a part of me, and I wanted to ride them. Bottom line: buy the bike you fall in love with.

The implication of this is to buy from a local shop since you need to test ride and they have the bikes. Establishing a relationship with the shop is useful for service and advice too. They often will discount service on bikes they sold. Most bike shops have knowledgeable staff and can help you with everything from accessories to good riding trails. You might pay a bit more, but I think it's worth it.


Using Sovrin for Age Verification

Under 25? Please be prepared to show proof of age when buying alcohol

Kamea, a member of the Sovrin Telegram channel asked this question:

I’m looking for our users to sign up with a Sovrin account, validate their identity, then use it to verify age and passport country on our network using a zk proof so we don’t have to handle any personal data.

There are actually two different things here and it's useful to separate them.

First, there's no such thing as a "Sovrin account". SSI doesn't have accounts, it has relationships and credentials. But your company will have accounts. The way that works is you set up an enterprise agency on your side to create a relationship (technically a peer DID exchange) with anyone who wants to create an account with you. After they establish that relationship, you can begin to collect attributes you need to provide service. Some of those will be self asserted and some you might require credentials depending on your use case.

The second thing is determining which credentials you want to require. If your requirement is an attested proof of age, then there could be several choices. In an ideal world, people would have a number of those (e.g. national ID, drivers license, passport, bank KYC, etc.) In the current world, you might have to partner with someone like Onfido or another KYC company do give people a way to get their age verified and a credential to use in proving it. Once people have this credential, however, it gives them the means of proving their age (and likely other attributes) anywhere, not just to you.

Kamea mentioned the desire to avoid handling personal data and this is a good solution for that. The proof would record that the person was over 18 and their country of residence without seeing or recording any other information.

I recommend running through the demo at Connect.me to see how all this could work. There are a number of vendors who can supply help with enterprise agencies and consulting on how to set this up in your organization.


Photo Credit: Under 25? Please be prepared to show proof of age when buying alcohol from Gordon Joly (CC BY-SA 2.0)


The Impact of a Network of Networks on Censorship

Censorship

SSI credentials are anchored on a distributed ledger. Sovrin Network is based on Hyperledger Indy. In Indy, the credential definition, a public DID, schema, and revocation registry are all stored on the ledger1.

On a purely technical level, because of how credential proofs and DID resolution works, it doesn't really matter which ledger these artifacts are anchored on since if I prove something to you from a credential I hold, then you can use the information in the credential proof to find its definition, schema, the DID of the issuer, and so on. Regardless of where the credential is anchored, the verifier can get everything they need to cryptographically determine the fidelity of the credential.

But, knowing whether to trust the issuer of the credential and the ledger the credential is anchored on is more difficult. This is a matter of provenance and is more about governance than the technical features of the protocols and software.

As a result, we can imagine a world where many ledgers serve as anchors for the credential definitions and the other artifacts necessary for credential exchange to be trusted. In Sovrin, this idea is called "Network of Networks" and it has many proponents. We might have questions about which of those ledgers to trust, but that's the subject of a different post and I think the answer lies in governance frameworks. The issue I want to address in this post is what is the impact of Network of Networks architecture on censorship resistance.

Censorship

Censorship is the ability of one party to stop another from "speaking." I put that in quotes because I'm using the term "speak" in a very general sense. Speaking, on the Internet, is any activity which results in a packet being transmitted from one machine to another on someone's behalf. So, sending an email is speaking, but so is a simple ping, or even a ACK in a TCP three-way handshake.

In the world of credential exchange, you can censor issuers by restricting who can get a DID or write a credential definition. This is why supporting public writes is important. But you can also censor them by not allowing credential holders and verifiers to see the definitions they've written2.

I have found that when people talk about censorship resistance, the discussion often rests on the decentralized nature of distributed ledgers. This happens because decentralization offers good protection against some censoring activities, along with other benefits for adoption and incentives. For censorship, decentralization can remove intermediaries. In any system with intermediaries, the intermediary can censor anyone connecting through them.

A decentralized architecture reduces dependence on someone else to speak, and so is more resistant to censorship. Decentralization can also help with censorship by ensuring access to the ledger and that no single entity can disrupt the validation of new entries on the ledger. But decentralization alone isn't enough to create a network that resists censorship. Censorship resistance depends on how the decentralization is employed.

For an example of why this is so, let's talk for a minute about another feature that distributed ledgers are made to solve, the so-called double spend problem where a digital token is used more than once. Paradoxically, the way ledgers solve the double spend problem is to create a single ledger that everyone agrees on through eventual consistency. So, the users and validators on the ledger may be decentralized, but they are relying on a single, centralized artifact, the ledger.

A Network of Networks

I spoke of the network of networks model above. To understand that better, let's look at the Sovrin SSI Stack. This figure is modified from one's I've shared before in that layer one contains more than one DID directory (my name for the combination of a DID method and a DID repository like a ledger).

The Sovrin SSI Stack
The Sovrin SSI Stack (click to enlarge)

As I've said, the nature of DID resolution lets any agent at layer two resolve a DID, regardless of which DID Directory it is stored in. A Sovrin agent, based on Hyperledger Aries also uses the DID directory to discover credential definitions, schema, and revocation registries. Ideally, these DID directories are public utilities that are, at least, readable by anyone.

Anyone can use the open-source Indy code to create a fully functional DID directory. And people will, for reasons good and bad. As a consequence, there is not a single, shared ledger where credentials and public DIDs are anchored, but many.

Consequences

If we filter this all through the lens of decentralization as an unalloyed good, then a network of networks seems like a wonderful idea. The logic is inescapable: more networks == more decentralization == more good. But a network of networks has consequences for censorship resistance that we may not like.

Suppose the country of Naruba decides that they need their own DID directory to feel comfortable that citizen's credentials are anchored in a ledger with validator nodes that are trusted entities inside the country. There's an element of trust here and different governments and organizations will have their own trust criteria.

Within a proper governance framework, Naruba's DID directory could be known to be trustworthy by other international players (a property I call "provenance"). Sovrin Foundation has plans to extend the Sovrin Governance Framework to support a network of networks model and provide the rules for establishing the provenance of DID directories functioning within the Sovrin ecosystem.

Now, imagine you're a business based in Naruba, anchoring credentials on the Naruba DID directory. Your credentials will be trusted within Naruba because the government has set up governance for the Naruba DID directory and told Narubians to trust it. Your credentials might be trusted outside of Naruba if the Naruba DID directory is operating within some governance framework that organizations outside Naruba trust. So far, so good.

The Emirate of Kunami and Naruba are not on friendly terms. In an effort to punish Narubian businesses and keep them from buying Kumani oil, the Emir declares that the Narubian DID directory is off limits and the country carefully blocks the nodes on the Narubian ledger so that it is not accessible from Kunami. As a result, Narubian oil refineries can no longer do business with Kumani oil suppliers. Because the entire world economy depends on SSI and verifiable credentials, this is devastating because there are no other mechanisms to validate the complex supply chain transactions.

Now imagine a different scenario where there's one, predominant ledger where credential definitions are anchored. In this world, when Kunami wants to block Narubian credentials, blocking access to the DID directory would also block credentials their own economy depends on. So, they're forced to try to attack credentials one-by-one. A single, trusted anchor for credential definitions protects everyone from censorship. If any actor can isolate their core credential definitions on a network that they control, they can censor other networks without too much impact on themselves. Large, mixed pools of credential definitions provide a sort of herd immunity for everyone against censorship.

Of course, you can't stop someone from standing up their own network and, in the case of a government, forcing their citizens to use it. But if businesses and agencies inside the country need to interact with others outside the country, they may need to anchor credentials off that nationalized ledger to do business and then they can't censor. So, whether or not the Kunami DID directory would facilitate censorship depends on whether or not the international community would recognize it as a trustworthy source. If others don't trust it, Kumani can't use it as a weapon.

Network of Networks Governance

Don't get me wrong. I understand the drive to create a DID directory controlled by a government or industry organization. And some of those reasons form the basis for gaining traction and getting the adoption necessary for SSI to become a dominant means of creating trustworthy connection on the Internet.

Consequently, Sovrin supports a Network of Networks model. Right now adoption is the most important thing. Over time, multiple DID directories will likely coalesce into a few large directories. In the meantime, shared governance and community activity will compensate for the danger of censorship that multiple DID directories can create.

What does that governance look like? In a Network of Networks world, censorship resistance depends on strong governance that champions and facilitates convergence and cooperation while tolerating independence and innovation. The ability to censor depends on a network's ability to ignore other networks in favor of themselves. Governance must be carefully designed so that cooperation and mutual support are incentivized. Governance may need to institute measures like staking and quadratic membership fees to discourage natural monopolies. Without strong measures people, organizations, and governments will at best lose confidence in the network and at worst be held hostage to it.

Care must be taken to ensure that no single network gets so large that others cannot ignore it, but it can ignore them. Alternatively, we have to ensure that that network is one that is governed by the SSI principles that are consistent with the mission of Identity for All. The Sovrin Governance Framework is a start, but there is much work to be done. The Governance Framework Working Group has begun early work on the governance structure of a network of networks. The conversation is not over, but has only just begun.


Notes

  1. For details, see What Goes on the Ledger (PDF)
  2. This can also impact credential holders, but the biggest way to censor credential holders is to control their wallet. That's the subject of a different, future post.

Photo Credit: Censorship from Bill Kerr (CC BY-SA 2.0)


Supporting LESS and Trustless Identity

If you haven't yet seen Christopher Allen's excellent presentation on How to avoid another identity tragedy with SSI?, I encourage you to review the slides or watch the video of his recent presentation on SSIMeetup.org.

Christopher Allen Slides

Christopher's point is simple: identity systems have real-world, sometimes life and death, consequences. Designers of identity systems must take care to ensure they're not unwittingly enabling some future identity dystopia. He uses the recent remembrance of Jews killed by Nazis in the Netherlands as an example of a well-intentioned identity system being used later by the Nazis to efficiently find and kill a larger percentage of the Jewish population there than elsewhere in Europe. The Neatherlands built the system in the 1930's as part of a civil registration project.

Christopher points to two major "tracks" in self-sovereign identity: LESS Identity and what Christopher terms "Trustless" (or "trust minimized") identity.

LESS Identity is a concept from Tim Bouma that is an acronym for "legally-enabled self-sovereign" identity. Tim defines the key characteristics of LESS Identity as:

  • Minimum Disclosure: I want to disclose the absolute minimum to get a service or entitlement. If a service only needs to know I am legal to buy or receive something (because of age and/or residency) that's all they should get —not my name, date-of-birth, or my address.
  • Full Control: I want full control over what I disclose. Not only at the point in time of the transaction, but all future uses that I may, or may not allow.
  • Necessary Proofs: I understand that someone might not believe what I am providing — that’s ok — I should be able to provide proofs from the right authority—my age as proven by my local government, my academic degree as proven by my university.
  • Legally-Enabled: All of the preceding requirements backed up by the necessary or applicable legal framework to protect me, and to protect those who are providing services to me (risk goes both ways in any transaction).

On the other hand, Christopher defines Trustless Identity as having the following characteristics:

  • Anonymity
  • Web of Trust
  • Censorship Resistance
  • Defend Human Rights against Powerful Actors (nation states, multi-national corps, mafias, etc.)

I've used the concepts of monument and tapestry credentials to talk about these different needs. Too many of our online (and physical world) interactions have come to rely on what Yuliya Panfil and Christopher Mellon call "monument credentials." Monument credentials are the foundational documents upon which most of us build our legal identity, things like birth certificates, property titles, and passports. This is the world of LESS Identity. But, for many, monument credentials suffer from two primary challenges: access and accuracy.

On the other hand, an identity metasystem can provide an alternative to monument credentials in many situations. Panfil and Mellon call these "tapestry credentials." Tapestry credentials are built from the data trails that we all leave as we navigate the digital world. These many credentials can provide a tapestry of evidence that can be trusted for things for which we’d otherwise rely on monument credentials. Taken together, they can be more accurate than a single monument credential. And because they're based on many small interactions, they are more immediately available to many, especially under-documented populations. Panfil and Mellon discuss, for example, how a system of tapestry credentials could be used in land administration.

More simply, think of things that you could prove through a credential-base web of trust where those whom you interact with day-to-day can say about you: things you've purchased, places you have been, flights you've taken, relationships you have, where you live, your family, where you work, and many other things can be attested by local organizations or the people you know. For many purposes, a tapestry of credentials can provide a sufficiently trustworthy foundation for achieving social goals.

A properly designed identity metasystem can balance the legitimate commercial and legal interests in credential exchange with the needs of everyone, in different contexts, for digital interactions that are privacy-preserving and autonomy-protecting. The Sovrin identity metasystem can provide for both LESS Identity (monument credentials) and Trustless Identity (tapestry credentials). There are several important characteristics of this identity metasystem that allow it to be useful in either context:

  • Censorship Resistant—Censorship is broadly defined in an identity system as being able to keep someone from accessing and using the system for any reason. There are several features that increase resistance of the metasystem to censorship including removing intermediaries, anchoring credentials in a large, global pool of other credential definitions, and state proofs for easily verifying the integrity of a ledger lookup—even offline.
  • Guardianship—There are many who won’t be in a position to manage their credentials directly for several reasons including not having access to the appropriate digital infrastructure, being too young, or otherwise lacking legal capacity (e.g. in a coma). We've spent considerable time on the legal and technical architectures necessary to support guardianship in Sovrin.
  • Correlation Minimization—Our work on and support for the Peer DID Method Specification is one example of how we work to reduce correlation. Peer DIDs reduce correlation, increase privacy, and scale to trillions of connections. Peer DIDs are easy to rotate or cancel because each relationship uses a different identifier.
  • Public DIDs for People—At the same time, people should be able to issue credentials to enable the wide use of tapestry credentials. GDPR, at present, limits the use of public DIDs for people (the root of an issued credential). Sovrin Foundation is engaged in discussions to balance data protection regulations with the legitimate needs of people to anchor credential definitions in a public ledger.
  • Minimal Disclosure—Credential holders use the Sovrin identity metasystem to share information from credentials using zero-knowledge proofs The agent protocols include the infrastructure and tools to enable the process of communicating, negotiating, sending, and verifying the fidelity of zero knowledge proofs (ZKPs). This is a secure way to minimize the information that is disclosed in a credential exchange without limiting functionality or security.

Many people, focused on the needs of LESS Identity, have claimed these features are too costly and unnecessary. But Sovrin Network provides an existence proof that these are not only possible, but efficient and usable. There's no excuse to not implement these vital features, when the code for them is open and usable. Without these important features, we risk building an identity metasystem that meets the demands of LESS Identity, but runs the risk of a future catastrophe. By supporting these, the Sovrin Network shows that LESS Identity is not necessarily in conflict with the goals of Identity for All.

This support for both is vital. Support for LESS Identity is needed for wide adoption. Without that, a Trustless Identity system is worthless since it is immediately identifiable as "an other" and therefore easily censored. When both are running on the same infrastructure, would-be censors can't kill one without damaging the other. One of the biggest factors in resisting censorship is making censorship too costly.

Sovrin Foundation has been dedicated to the goal of Identity for All since its inception. This must include both monument and tapestry credential models supporting legally-enabled and trustless self-sovereign identity. Ensure Identity for All requires that we balance the needs of all stakeholders by ensuring the metasystem remains independent.


Credentials and Covid-19 Recovery

Food Handler

In a recent Gates Foundation AMA on Reddit, Bill Gates said the following in response to a questions about the impact of Covid-19 on businesses:

Eventually we will have some digital certificates to show who has recovered or been tested recently or when we have a vaccine who has received it.

The responses from the Reddit community were predictable, with people wondering how such a document could be used against them.

Similarly, in a Wired Magazine interview with epidemiologist Larry Brilliant, he postulated a similar, albeit less high-tech, solution to the problem of knowing who's safe:

[We will] begin to see large numbers of people—in particular nurses, home health care providers, doctors, policemen, firemen, and teachers who have had the disease—are immune, and we have tested them to know that they are not infectious any longer. And we have a system that identifies them, either a concert wristband or a card with their photograph and some kind of a stamp on it. Then we can be comfortable sending our children back to school, because we know the teacher is not infectious.

Both of these are discussing credentials that can be used to know who is safe to have working. Imagine, for example, that you run a restaurant, live-in care facility, or other place where food is prepared and want to know that the people in the kitchen are safe.

Bill's solution would rely on the public key infrastructure and it presents privacy concerns from correlation to other information about the individual. Larry's solution is familiar, but hard to scale in a way that's trustworthy.

Verifiable credentials present an alternative that meets the needs of the use cases Bill and Larry foresee without the attendant privacy and scaling problems. Credentials based on Sovrin would protect individual privacy and autonomy while also ensuring credential fidelity. Specifically, anyone accepting a credential proof would know with certainty (1) who issued the credential, (2) that the credential is being presented by the person who it was issued to, (3) that the credential hasn't been tampered with, and (4) that it hasn't been revoked.

COVID-19 Credential Exchange
A testing organization issues a credential to the patient who can use it to prove to anyone they want that they've been tested for COVID-19 and found disease-free.

Further, an authoritative institution like the NIH could set up a governance framework that says who can authoritatively issue credentials for people who are immune, have been tested, or have been vaccinated. They would make this public in a credential issuer registry like OrgBook that the Government of British Columbia developed. Such a registry would be used to ensure credential provenance.

With this system in place, people don't have to be in a public registry and relying parties who verify the credential can trust that the attestation from the certifying organization about the person presenting the credential is true. People carry their own credentials and present them on request, protecting privacy. And the decentralized nature of the Sovrin Network ensures that it can scale to any degree required.

And the best news is that it can be built on Sovrin, right now. With multiple commercial software vendors offering products for credential issuers, credential holders, and credential verifiers and widespread support by a diverse community. A group of volunteers has formed to develop a pilot and support broad, scalable deployment of credentials that aid in preventing the spread of the disease and the economic recovery that needs to follow.

For more information, you can visit this Google Doc and find out how you can get involved.


The Sovrin SSI Stack

This post is based on Section 2 of the Sovrin Technical Architecture paper that Drummond Reed and I authored (to be published). Many others contributed to the thinking and provided useful critique and editing.

The Sovrin Network is a metasystem for building identity systems. The metasystem provides the means for anyone to issue, hold, present, accept, and verify credentials. The metasystem provides a universal means of discovering issuer identifiers and credential definitions in the ledger layer, and a universal protocol, called DIDComm, for connecting and sharing credentials in the agent layer. This universal protocol, combined with interoperable agents, creates an interoperable ecosystem. Participants share this interoperable ecosystem while exchanging credentials to solve their own individual problems.

The issuance, presentation, and verification of credentials in the Sovrin Network takes place within a stack of protocols and technologies. The Sovrin Stack comprises four layers:

  1. The Ledger Layer
  2. The Agent Layer
  3. The Credential Exchange Layer
  4. The Governance Layer

These layers are shown in Figure 1. The rest of this paper will discuss each layer in detail.

The Sovrin SSI Stack
The Sovrin SSI Stack (click to enlarge)

Layer One: The Sovrin Public Ledger

The bottom layer of the stack is the Sovrin Public Ledger. This decentralized ledger is specifically designed to support identity transactions and has several important properties:

  • Publicly accessible—this ledger is publicly readable and writable so that anyone can use it without an intermediary. This makes the network resistant to censorship. By having a decentralized network of nodes run by Sovrin Stewards around the world, anyone will be able to access the network at any time, even if one or many nodes get shut down or become inoperable.
  • Open source—the ledger nodes each run Hyperledger Indy, an open-source distributed ledger purpose-built for decentralized identity.
  • It enables the generation of state proofs—the ledger is capable of generating state proofs1 that can be used by Sovrin-compatible clients to know the state of the ledger without having to download and access the entire ledger. Each state proof contains a time stamp so the client can decide if the state proof is current enough for their use case or needs to be refreshed. This makes it ideal for use in credential verification where the clients may not have internet access for a period of time, a key requirement for universal adoption of digital credentials.

    In addition, state proofs can be cross anchored on other ledgers to increase reliability, trustworthiness, and resistance to censorship. This allows any holder to present a verified credential stored in their digital wallet—such as a driver’s license—anywhere and at any time in order to prove an attribute about themselves—such as their age—as needed, for example, to purchase a product requiring a legal minimum age.

  • Inexpensive to operate—transaction validation on the ledger is performed by known entities under proof-of-authority, making ledger access inexpensive enough to support the Network’s mission of establishing Identity for All (I4A). This means everyone—regardless of circumstances—has access to the Sovrin Network. The Sovrin Foundation’s I4A Council partners with NGOs, civil society organizations, and other groups promoting more inclusive identification systems to help bring identity network technology to populations who may not otherwise be served.
  • Provides support for the Sovrin Protocol Token—the ledger supports transactions of the Sovrin Token and ties it to identity transactions.

Unlike many other blockchain-based identity systems, using the Sovrin Network does not require storing personal identifying information, encrypted or otherwise, on the ledger. Rather, the Sovrin Network uses the ledger to store credential definitions, decentralized identifiers (DIDs) for issuers, schema definitions, and revocation registries. Without a decentralized ledger to store these, the Sovrin Network would have a single point of failure for these critical objects.

Objects like DIDs are created by Transaction Authors and added to the ledger by Stewards acting as Transaction Validators. Because the Sovrin Network is public, anyone can be a Transaction Author. But only organizations that function as Sovrin Stewards can validate the transactions that enable proof-of-authority consensus. Validation is done using a modified Redundant Byzantine Fault Tolerance algorithm implemented as Indy Plenum.

Storing credential definitions, and supporting data, on the ledger ensures that a credential verifier can test the fidelity of the credential without having to talk directly to the issuer. Fidelity allows the verifier to know the identifier of the issuer and that the credential was issued to the holder who is presenting it, hasn't been tampered with, and hasn't been revoked. The ledger breaks the circuit so that issuers don't know who is using a credential or when the credential is being used, a critical privacy provision. The ledger also lowers the cost and complexity for credential issuers since they don't have to maintain an always-on API for verifiers to use.

Decentralized Discovery and Governance of the Ledger

If the ledger is the basis for decentralized discovery, then we must ensure that no single organization controls the ledger and that it is protected from being taken down or corrupted by a single entity or by multiple entities.

The Sovrin Foundation and its Technical Governance Board (TGB) has designed the ledger and its governance to ensure that the ledger is public, open, and decentralized. This design includes three main groups: Sovrin Stewards, who operate the ledger nodes; Transaction Authors, who write DIDs and other cryptographic objects to the ledger; and Transaction Endorsers, who have permission to write to the ledger on behalf of Transaction Authors under the current Permissioned Write Access policies (PDF). These policies are only transitional until the Sovrin Foundation is able to provide Public Write Access. Sovrin infrastructure is designed to be censorship resistant such that no company or special interest can control who can use the protocol. All transactions are assigned validation priority through a transparent and fair algorithm maintained by the TGB. Public authorship of Sovrin transactions on a ledger via Public Write Access policies represent the best means available to combat censorship.

One key idea in decentralized systems is that different parts of the system are under the control of different organizations. Censorship resistance requires that even though Stewards must meet certain requirements to participate, it must still be assumed that any node might be hostile because of an attack or other circumstances beyond the control of the Steward. The Hyperledger Indy distributed ledger architecture provides this important property.

Because the Sovrin Network is based on blockchain technology and run by a large number of diverse validators (Sovrin Stewards), censorship becomes extremely difficult, if not practically impossible. Even if one or several of these access points stops actively participating in the Sovrin Network, there will still be someone who will provide access, as long as the governance rules are followed.

Because transaction authoring is a public function, the use of a ledger also ensures that under Public Write Access policies people can access, write, and update identifiers without being subject to gatekeeping. Note that it is possible that a specific gatekeeper—a Sovrin Steward—might restrict access to certain people, groups, or jurisdiction as a result of a compromised server, legal restrictions in its own jurisdiction, or other circumstances beyond its control. However, because the Sovrin Network is decentralized, people will still be able to access the ledger by using another Sovrin Steward’s node.

Decentralized Identifiers and Their Properties

Decentralized identifiers, or DIDs, are a new kind of identifier that provides the means of managing relationships in a self-sovereign identity system. DIDs resolve to DID Documents. DID Documents describe the public keys, authentication protocols, and service endpoints necessary to initiate trustworthy interactions with the identified entity. A DID Document is associated with exactly one DID. The W3C Credentials Community Group has published a global DID specification that is used in the Sovrin Network (and the W3C is currently forming a full W3C DID Working Group for further standardization of DIDs).

Decentralized identifiers in Sovrin infrastructure have these important properties:

  • Non-reassignable—DIDs are permanent, persistent, and non-reassignable. Permanence ensures that the identifier always references the same entity. As a result, DIDs are more private and more secure than identifiers that can be reassigned, such as a domain name, IP address, email address, or mobile number. Permanence is vital for identity holder control and self-sovereignty.
  • Resolvable—Resolution is the act of looking up the DID Document for a specific DID as defined by the specification for that particular type of DID, called the DID method. All Sovrin DIDs use the Sovrin DID method. Taken as a whole, DID infrastructure functions as a global, decentralized key-value store where DIDs act as the keys and DID Documents are the values.
  • Cryptographically verifiable—DIDs are associated with cryptographic keys, and the entity controlling the DID can use those keys to prove ownership (a process known as DID authentication). The result of resolving a DID may be cryptographically signed to ensure its integrity. The resolution also provides one or more public keys associated with the DID. Using cryptographic keys, the owner can prove they are in control of the DID. Parties who have exchanged DIDs directly with each other—called a peer-to-peer connection—can mutually authenticate each other and encrypt their communication.
  • Decentralized—DIDs are designed to function without a central registration authority. Sovrin DIDs can be created by anyone, anywhere, and for any purpose.

The Sovrin Network uses two kinds of DIDs: public and peer. Each has a different role in the operation of the network.

Public DIDs are created by people or organizations who are issuing credentials. The DID for a credential issuer must be written to the Sovrin Ledger so that they are capable of being resolved by anyone. When someone wishes to verify a credential, they retrieve the issuer's DID from the credential definition and then resolve—look up—the public DID to retrieve the associated DID Document of the issuer. Then, they use the public key in the DID Document and the digital signature of the credential to ensure it is is valid and has not been tampered with. They can also cryptographically verify that the credential was issued to the holder and that it has not been revoked.

Peer DIDs are not written to the Sovrin Ledger because they don’t need to be publicly resolvable. Instead, identity owners can issue a peer DID directly to another identity owner for peer-to-peer identity verification. By decentralizing verification, peer DIDs transform communication between verifiable entities in important ways (for full details, see the Peer DID Method Specification).

First, peer DIDs improve security because there is no need to use correlatable identifiers, such as email addresses, phone numbers, or credit card numbers, for verification. Therefore, decentralizing identity through peer DIDs eliminates the honey pots of data that centralized identity systems create and which become recurring targets of data breaches. Even if a peer DID was hacked in some way, it would be easy to cancel. Cancelling a peer DID is like cancelling a single-use credit card number—it does not affect any other relationship except the one party it was shared with.

Second, peer DIDs increase privacy because people are no longer dependent on centralized messaging systems (like WhatsApp or iMessage) to communicate with other parties; communication is peer-to-peer and cannot be “overheard”.

Third, peer DIDs provide more reliable communication as a decentralized network is more resistant to service interruption than centralized identity systems (almost every single node on the network would have to be disrupted). Peer DIDs also make communication between entities frictionless and controllable in ways not possible within centralized systems. If we want to sever a relationship with a particular entity, there is no impact on any other entity we have a relationship with. DID messaging through the use of peer DIDs is like having a dedicated private phone for every entity you engage with.

Finally, the use of peer DIDs allows for much greater scalability of the DID resolution infrastructure, since the vast majority of DIDs are private and those are resolved on a peer-to-peer basis rather than through access to the Sovrin Ledger or some other blockchain.

Layer Two: The Agent-to-Agent Protocol

Agents are the basis for peer relationships in Sovrin infrastructure. The protocol used by agents, called DIDComm2, is defined in an open, public process inside the Hyperledger Aries project.

The Sovrin Network is designed so that personal identifying information does not need to be stored on the ledger. The design does this by using software agents that provide people with a place to hold, manage, and use keys and credentials. Sovrin identity owners usually have at least two agents, one on a device and one in the cloud3. If an identity owner has more than one device, all of their devices are likely to each have an agent.

Sovrin agents operate independently from each other in a heterarchical peer-to-peer topology. Agents communicate with each other for DID and credential sharing without an intermediary. They do not need the ledger to communicate. Communication between agents is done via peer-to-peer signed and encrypted DIDComm messages. The two agents in a peer relationship authenticate each other using the keys associated with the peer DIDs they exchanged when they established a relationship. Each agent has its own keys, and keys are never copied between agents.4

The use of device agents is highly decentralized because all keys and credentials are stored on the device at the very edges of the internet. Cloud agents, though hosted in the cloud, are also decentralized because they can be either self-hosted or run by any qualified service provider, called an agency. The cloud agent, like the edge agent, is always, wholly under the control of the person or organization who owns it. Most people using the Sovrin Network will opt to use an agency. There can be any number of agencies, and cloud agent operation is standardized so that identity owners should be able to easily switch agencies.

An agency does not have access to the data stored in a cloud agent. As a rule, cloud agent data is stored encrypted and can only be decrypted by device agents using keys stored at the edge of the network where they are safest. So, barring a coding problem that opens a security hole, there is no honey pot of information in an agency. The use of open source code for agencies should further reduce risk because the contributed code is constantly monitored and tested for quality and security by a global community of expert engineers and security professionals.

The peer-to-peer architecture of agents and their availability from multiple agencies creates a decentralized system for storing, managing, and using keys and credentials. This not only is a boon to identity owner privacy and autonomy, it also gives Sovrin infrastructure the potential to support an unlimited number of relationships.

Self-sovereign identity needs to be robust. It should be difficult for an accident or malice to wrest control of an identity away from its rightful owner, and it should be easy to fix problems if they arise. The DIDComm protocol includes strong decentralized key management and support for people to recover from accidents5 and attacks.

Layer Three: Credential Transmission

The third layer of the Sovrin technology stack is the credential transmission protocol that determines how the issuer’s agent issues credentials to the credential holder, how the credential verifier requests information from the credential holder, and how the credential holder presents a proof of information from their credentials that the verifier can trust (as explained in 1.4.2).

Credentials are defined by their issuer using a credential definition. The credential definition links the public DID of the issuer, the schema for the credential, and a revocation registry for the credential. The definition, public DID, schema, and revocation registry are all stored on a distributed ledger that is used for decentralized discovery—on the Sovrin Network, this is the Sovrin Ledger. The use of a publicly visible and verifiable credential definition provides credentials with important properties:

  1. Credentials are remotely verifiable. The public DID links the credential to its issuer, its public key, and other service information.
  2. Credentials are machine readable and understandable. The schema provides verifiers with information about the meaning and structure of the credential.
  3. Credentials can be revoked. The revocation registry allows the holder to prove to the verifier that the credential has not been revoked without the verifier needing to contact the issuer.

A single credential definition can be the root of millions of individual credentials because it links and records the public DID of the issuer, the schema, and revocation registry on the ledger. None of that information changes for credentials of the same type from the same issuer. It's like a rubber stamp that can be used to stamp many documents. By way of example, the Canadian provinces of British Columbia and Ontario have issued more than 1.4 million credentials proving official business registration for 529,000 companies using the Sovrin Network based on only a few credential definitions posted to the Sovrin Ledger.

Credential Exchange
Figure 2: Credential Exchange (click to enlarge)

Figure 2 shows an example of how the British Columbia credential issuing system operates: (1) Mary registers her Eco Tours business and receives a digital incorporation credential from the government of British Columbia. (2) Now Mary needs a loan for a new tour bus. When the bank’s online loan service asks for proof of incorporation, she presents her digital incorporation credential issued by British Columbia. Using the Sovrin Network, the bank verifies Mary’s credential and (3) uses it as part of the loan transaction.

Credential Exchange Using Zero Knowledge Proofs

Credential holders can share information from multiple credentials with minimal disclosure using Zero Knowledge Proofs (ZKPs). ZKPs are cryptographic techniques that allow users to share information without relinquishing their security and privacy. ZKPs use cryptography to prove a statement from the holder to the verifier without revealing any additional information that is not required by the verifier.

Zero Knowledge Proofs must have three properties to be usable:

  1. Completeness: If the statement is true, the verifier believes the result of the proof.
  2. Soundness: If the statement is false, the holder is unable to create a false proof to fool a verifier into thinking that it is true.
  3. Zero-knowledge: The verifier does not learn any other information about the holder other than what is in the proof.

A classic example is date of birth. Driver’s licenses and identification cards are often the primary means of proving age. However, this type of identification also contains other valuable private information, such as a person’s home address, which is frequently used in identity theft. Selective disclosure uses ZKPs to turn a digital copy of a driver’s license into a cryptographic proof of specific information in the driver’s license. It’s as if you’re creating a custom copy of your driver’s license that is every bit as reliable, and conveys the same personally identifiable information, as the real thing; but, based on who is asking, you control what information actually appears to them on that particular copy.

A Sovrin modile wallet can create a ZKP for each situation where the credential holder needs to prove their age. ZKP technology allows her to quickly, easily, and securely verify she is over 18, or 21, or 65 without actually having to share a specific date of birth.

The ZKP-based query language for credentials used by the Sovrin Network is currently implemented by open source code in the Hyperledger Aries project using the underlying crypto code of the Hyperledger Ursa project. The query language is sophisticated and designed to support a good holder experience while ensuring minimal disclosure. Attributes on a credential (also called “claims”), such as an address or social security number are individually signed by the issuer. ZKPs are created using these attributes. Using the Sovrin Network, identity holders create ZKPs to prove one or more of the following things about their attributes.

  1. Equality: if the attribute is equal to the value or an identity holder can just reveal the attribute itself in the proof.

    Example: [Are you employed?] = Sovrin ZKP: [Yes] or [Employer: IBM]

  2. Inequality: if an attribute lies in a specific range without revealing the actual value. This is helpful when dealing with something that has a numerical attribute, like age or money.

    Example: [Are you over 21] = Sovrin ZKP: [Age >= 21]

  3. Set Membership: ZKPs can prove if a value is contained in a set without revealing which value.

    Example: Do you live in Europe? = Sovrin ZKP: [Country of residence is: a European country] or [Country of residence is: not in a European country]

The Ledger in Use: What is Written, What is Not

Every credential issuer must write a credential definition to the ledger so that a verifier can look up the credential definition to ensure its integrity. Every credential issuer will also have to write a public DID. Most issuers will write revocation registries, and many will write schema definitions.

By contrast, most individuals will not need to write DIDs to the ledger or issue credentials. This is because peer DIDs are exchanged pairwise each time a new peer-to-peer relationship is formed (see also previous section: Decentralized Identifiers and Their Properties).

The following table summarizes what goes on the ledger and what does not.

Goes on the ledger Does not go on the ledger
Public DIDs and associated DID documents with verification keys and endpoints Peer DIDs
Schemas and credential definitions Issued credentials
Revocation registries Consent receipts or records of credential exchange transactions
Agent authorization policies

Layer Four: Governance

Although the Sovrin Network is decentralized, it still operates under a community-driven governance process whose goal is to maximize trust in the Sovrin Network as a global identity network. This governance process is essential to producing a system that can both meet governmental and jurisdictional requirements for data security, privacy, protection, and portability, while at the same time preventing censorship and ensuring individual sovereignty over the sharing of identity data.

The Sovrin Governance Framework (SGF) is the legal foundation of the Sovrin Network as a global identity network for self-sovereign identity. It is developed by the Sovrin Governance Framework Working Group (SGFWG), currently chaired by Sovrin Trustee Drummond Reed. Each new version is approved by the Sovrin Foundation Board of Trustees to become the official set of governance documents for the operation of the Sovrin Ledger and the Sovrin Network.

The Sovrin Network enforces rules through a mixture of open-source code and an active, open-governance process for rulemaking. This ensures that everyone can see the process for creating the rules, not just the methods by which they are enforced.

The SGF V2 was initially approved by the Sovrin Board of Trustees in March 2019. A subsequent set of revisions to add the legal support for compliance with the EU General Data Protection Regulation (GDPR) and other global data protection regulations as explained on the Sovrin Foundation’s Data Protection page was approved on December 2019. The primary documents include:

  1. The Sovrin Governance Framework Master Document (PDF)—The "constitution" of the Sovrin Network, this document defines the purpose, core principles, and core policies—and also references all other documents in the SGF V2, including all the Controlled Documents, which contain policies managed by specific subgroups within the Sovrin Foundation, listed in Appendix A.
  2. The Sovrin Glossary—A comprehensive glossary of almost 250 terms used in the Sovrin and digital identity communities throughout all the SGF V2 documents and all of Sovrin infrastructure, plus eight appendices that provide in-depth explanations of core groups of terms.
  3. The Sovrin Trust Assurance Framework (PDF)—This document defines criteria and processes for assessing the conformance of different Sovrin actors to the policies of the Sovrin Governance Framework.

The SGF V2 also includes five legal agreements:

  1. The Sovrin Steward Agreement (PDF)—between the Sovrin Foundation and a Sovrin Steward
  2. Steward Data Processing Agreement (PDF)—between the Sovrin Foundation and a Steward establishes the responsibilities of each for complying with GDPR and other data protection regulations.
  3. Transaction Author Agreement (PDF)—between the Sovrin Foundation and any person or organization initiating a write transaction to the Sovrin Ledger.
  4. Transaction Endorser Agreement (PDF) —between the Sovrin Foundation and any organization requiring permissioned write access to the Sovrin Ledger.
  5. Transaction Endorser Data Processing Agreement (PDF) —between the Sovrin Foundation and a Transaction Endorser establishes the responsibilities of each for complying with GDPR and other data protection regulations.

Lastly, the SGF V2 has seven Controlled Documents:

  1. Sovrin Governing Body Policies (PDF)—the governance policies that apply to all Sovrin Governing Bodies.
  2. Sovrin Ledger Access Policies (PDF)—governing reading and writing to the Sovrin Ledger and processing Sovrin Ledger Transaction Data.
  3. Sovrin Steward Business Policies (PDF)—governing qualification, application, activation, operation, suspension, and termination of Sovrin Stewards.
  4. Sovrin Steward Technical and Organizational Policies (PDF)—governing the security, node operation, node selection, and reporting requirements for Sovrin Stewards.
  5. Transaction Endorser Technical and Organizational Policies (PDF)—governs the security and operational policy requirements for Transaction Endorsers.
  6. Sovrin Economic Policies (PDF)—governing economic incentives, fees, and regulatory compliance.
  7. Sovrin Trust Mark Policies (PDF)—governs the use of the Sovrin Trust Mark by Stewards, agencies, and developers.

2.2 Operational Status

Anyone abiding by the Sovrin Governance Framework can use the network to issue verifiable digital credentials by writing transactions via a Transaction Endorser. Similarly, anyone can access the network for the purposes of verifying a proof of a Sovrin-based verifiable credential. Developers, organizations, and businesses working on Sovrin-based projects are currently using the Sovrin Public Ledger, including the Agent-to-Agent protocol, to issue and verify verifiable digital credentials under the current Permissioned Write Access policies. Issuers of Sovrin-based credentials, including Sovrin Stewards and Transaction Endorsers, are currently writing the information they need directly to the Sovrin Public Ledger. See Write to the Sovrin Public Ledger for information on how to get write to the ledger. Examples of these ledger writes include public decentralized identifiers (DIDs), schema, credential definitions, and other GDPR compliant pieces of public information that abide by the Sovrin Governance Framework and Transaction Endorser Agreement. Under Perimissioned Write Access, the Sovrin Foundation is collecting a fee from these organizations through a manual billing process to support the Foundation’s administration of the network.

The open-source, community-developed code for decentralized self-sovereign identity that enables the Sovrin stack is available in three Hyperledger Projects: Hyperledger Indy, Hyperledger Aries, and Hyperledger Ursa. The source code for Hyperledger Indy was originally contributed to the Linux Foundation by the Sovrin Foundation. To operate the nodes on the Sovrin Network, the Sovrin Stewards use the code housed in the Hyperledger Indy project.

Conclusion

The Sovrin Network is composed of a sophisticated stack of protocols, implemented in open source, backed and supported by organizations of every size around the world. The Sovrin Network is not an identity system for solving a narrow set of identity problems in a few contexts, but a metasystem, supporting the creation of millions of identity systems for any context one can imagine.

The goal of an identity metasystem, like Sovrin Network, is to connect individual identity systems and allow them to interoperate since no single system meets the needs of every digital identity scenario. By providing a set of unifying protocols and consistent user experience, the metasystem creates the framework within which these identity systems are built and operate. A sophisticated system of governance allows organizations, large and small, to participate in a regulatory-compliant network and fuel adoption while protecting the autonomy of people around the world—truly providing Identity for All.


Notes:

  1. A state proof requested from a node that provides cryptographic verification that the response reflects the current state of the Sovrin Ledger.
  2. DIDComm is defined in a set of Hyperledger Aries specification documents called RFCs. See the repository README.
  3. The cloud agent, at a minimum, performs routing functions for edge agents that don't have reliable inbound IP connectivity.
  4. Hardman, Daniel. How DIDs, Keys, Credentials, and Agents Work in Sovrin, Sovrin Foundation, 2019.
  5. Hardman, Daniel. What if I lose my phone? Evernym, 2019.


Decarbonizing Locally

The same, but different (Carbon)

I recently listened to Saul Griffith on the Ezra Klein show about decarbonization. In contrast to a lot of the climate-change discussion we hear, Griffith's message is one I've always resonated with: a decarbonized future is better than what we have now. Too often, climate change is all about the sacrifices we have to make for the planet. That won't sell. I've got personal experience that informs my decision.

I've spent my career in the identity industry and there's an issue, privacy, where the discussion is much the same. I've long maintained that people won't pay for privacy, or will readily give up privacy for convenience. But privacy is foundational to personal autonomy. So if we're going to build a digital life for ourselves, we can't ignore privacy. What to do? Make a system that respects privacy and is a better identity system. Cake eaten; but still there.

Griffith says:

All of the politicians are pitching their climate plans from some top-down economic view, saying things like, “We’ll decarbonize this industry by this date.” It all sounds very abstract. No one has presented the Green New Deal from the kitchen table out: What will it look like in my home?

So, I started thinking about my personal efforts to decarbonize. Something we all should think about. Here's what we're done (in roughly the order we did them):

  • We've replace all our incandescent bulbs with LED bulbs.
  • I've replaced most our gas-powered yard tools with battery-powered versions.
  • We've put 40 solar panels on the house that produce about 14 Mwh of electricity per year. I studied this carefully before we got solar and concluded we had about a ten to twelve year payback on a system with at least a twenty year life, so it made financial sense. We're blessed to have retail net metering, so we also have, for a small monthly fee to the electric company, a great big battery.1
  • Since we had solar, when we replaced the dryer, we went electric instead of gas.
  • Last year, we traded in a 2004 Suburban we'd driven since the kids were little for a Tesla Model 3. Again, having solar influenced that decision because it made it more economically viable.
  • We recently replaced the upstairs air conditioner and furnace with one that is more efficient and includes a heat pump. So, unless the temperature is below 27 degrees, we use electricity to heat the upstairs instead of gas. That's most of the time in Utah. Again, the fact that we have solar influenced this decision because it made electricity the cheaper option, rather than a sacrifice.

With all that, there's still more we can do:

  • We still have a Ford F-150 pickup truck. I use the truck as a truck quite a bit, so until a good electric option becomes available, I'll keep the Ford. That said, I could get another electric car to use as our second vehicle and just use the truck when I really need a truck.
  • The downstairs air conditioner and furnace will probably need to be replaced soon and I'll go with the same set up I did upstairs.
  • I bought a brand new snow blower the winter before we went solar. I didn't know enough to look at the electric versions. I only use it 3-4 times per winter, so it's not very economical to replace it.

And there are some things that are hard:

  • Our hot water heater is gas and an electric water heater would cost more to operate and might even require upgrading our electrical service, an expensive proposition. I'll continue to monitor this for new options and see if we can discover one that makes financial sense.
  • I can't really see cooking on an induction range instead of gas. I've tried them; I know people swear by them. But I'm really in love with our gas range.

I started this post with Saul Griffith's proposition that decarbonization ought to lead to a better life, an amazing future. I believe our efforts are in line with that vision. The Tesla is amazing. The new furnace produces nicer heat than the old one (not as big of swings). I worry less about someone leaving the lights on. And we're saving money (even with the capital costs).

I recognize that I'm blessed to have the means to make capital investments that pay off over time. Not everyone can do that. But I think of our efforts as a vanguard that explores possibilities. Much of this is doable on a larger scale if new construction just built houses this way. They'd be cheaper to operate, safer, and cleaner and the capital cost would be managed alongside the other large capital costs of housing.

The point isn't that everyone should do what I've done. Rather, my point is find out what you can do and do it, especially if it makes your life better in some way.


Notes

  1. I realize we're cheating a bit here, but this is about our personal decarbonization. We can't solve the problem of demand shifting solar electricity production on our own.

    The demand shifting problem is an interesting one. There are two types: daily and seasonal. Daily demand shifting can be done with batteries in the home. My net metering situation reduces the financial incentive to do this since I don't save money by buying batteris (whereas if I didn't have a good net metering situation, I would). Still, there are advantages that tempt me, like being somewhat self sufficient during power outages.

    Seasonal demand shifting isn't something I can do much about on my own. No battery I could buy is big enough to store summer energy for use in the winter. This is an area where commercial and regulatory efforts can make a big impact.

Photo Credit: The same, but different (Carbon) from Tatters (CC BY-SA 2.0)