Lately, I’ve been thinking a lot about use cases for self-sovereign identity. This series of blog posts discusses how Sovrin can be used in different industries. In this article I discuss Sovrin and education.
Last spring I wrote about how deconstructing the student information system at BYU is allowing us to create a virtual university. The idea is to create a decentralized system of student profiles that contain both profile data as well as learning records. These learning records can attest to any kind of learning activity from the student having read a few paragraphs to the completion of her degree. By making the student the point of integration, we avoid having to do heavy, expensive point-to-point integrations between all the student information systems participating in the educational initiative.
This diagram shows a number of players in the virtual university (VU) system (labeled CES Initiative). They have no direct connections to each other, but present their own APIs, as does the student profile. As students interact with the various institutions, they present data in their profile (using an API). That's the only point of integration for these institutions, including VU itself.
One of the design requirements for the student profile is that it be hostable where ever the student desires. We also put the student in control of authorizations to use data. These features mitigate regulatory requirements around privacy of student data. With millions of potential student spread among 188 different countries, this saves significant cost and headache trying to meet various regulatory hurdles. When the student is an active participant in sharing their data, the hurdles can be more easily overcome.
The Role of Self-Sovereign Identity
Self-sovereign identity can simplify many of the most difficult challenges of building the student profile. One of the key features of Sovrin is support for verifiable claims shared by their subject. Nearly everything in the student profile looks like a verifiable claim. Sovrin provides the infrastructure for issuing claims and using them in disclosures. Sovrin enables the receiver of the disclosure to verifying the claims in it.
Verifiable claims also significantly ease the integration burden between the various systems involved in the virtual university. Say Alice wants to be a book keeper, but the book keeping microcourse has requirements for English language proficiency and secondary school completion, that she lacks. There could be four institutions involved in this scenario: Virtual University (VU), the English language certifier (ELC), the secondary education provider (SEP), and the college offering book keeping (BK). These last three institutions all have agreements with VU, but no technical integration with VU or each other.
Alice has be admitted to VU and paid for the book keeping microcourse along with the require pre-requisites.1 She goes to ELC. Alice can prove she's a VU student and has paid for the English language certification by disclosing that information from the verifiable claims that VU wrote to her student profile. ELC can validate that the disclosure is true without talking VU directly. Alice registers for a course and, after she completes it, ELC writes a claim that she passed to her student profile.
Alice, guided by the Student Profile, heads to SEP and discloses that she's a VU student. SEP validates her student status and that she's paid for the SEP program. They ask her to prove that she has the required level of english competancy and she provides a disclosure based on the claim that ELC wrote. She completes the secondary education program and SEP writes a claim stating such.2
The same thing happens for Alice's book keeping course at BK. One notable difference is that the microcourse that Alice signed up for might be made up of courses offered at different univerisities. You might be shocked to know that even in 2016, transcripts are still largely shared on PDF, or even fax, and processed using teams of people that transcribe them. Verifiable claims provide a solution to this problem that is decentralized, open, standards-based, and non-proprietary. Because the claims are anchored in the Sovrin ledger, they can be hosted anywhere in the world and still be usable by any participant in the system.
Alice may have the option of choosing the take the same course from several institutions. Alice can share her current status with VU and they can give her recommendations based on the possibilities. Alice can go to any available institution. They simply read disclosures she's created about the past courses she's taken to ensure that the meets the pre-requisites and write claims each time she completes a course. Once all the courses are complete, VU issues a claim for the book keeping certificate that Alice can use when she applies for jobs or if she decides to talk additional courses.
Student Profiles as Sovrin Agencies
One of the interesting factors of Virtual University is that many participants will be subject to different legal jurisdictions. Trust frameworks can be built on Sovrin to ensure that they can trust each other regardless. For example, Sovrin's built-in system of consent receipts allows a student's consent regarding data use to be recorded and notarized by a system outside the University. So long as Sovrin can be trusted to record and notarize these consent receipts properly, they can be trusted by participants regardless of where they reside.
The preceding case study was a little vague about where things are stored, merely talking about "writing claims" and "creating disclosures." As a rule, it's not a good idea to write claims, disclosures, and other data directly to the Sovrin ledger. Instead, these are generally written to some kind of data store and then anchored in the ledger by writing a signature of the data on the ledger. The student profile and learning record store functions as a Sovrin Agent. Agents are Sovrin-enabled systems that store and process information on their owner's behalf.
As education is increasingly deconstructed, a trustworthy system for issuing and relying on verifiable claims and consent receipt enables decentralized, interoperable education ecosystems. Sovrin significantly decreases the number of heavy integrations necessary to realize the virtual university. Universities exist, to some degree, because they are trustworthy issuers of credentials. Sovrin provides a foundation for extending that trust outside these traditional institutions.
She could, of course pay for them as she takes them, but this makes the case study a little simpler.
Alice isn't necessarily involved in the details of any of this. The Student Profile could be acting as her agent to automatically disclose this information to institutions she trusts based on policy.
Lately, I've been thinking a lot about use cases for self-sovereign identity. This is the second in a series of blog posts that discuss how Sovrin can be used in different industries. In this article I discuss Sovrin and healthcare.
Healthcare is broken and many look to information technology to help solve the problem. But that's not working out as well as we'd like. The root of the problem, like many, is identity. Self-sovereign identity is the solution.
Consent and Privacy
One of the fundamental tenants of healthcare is patient consent. Patients have the right to determine their care and treatment. And they have a right to privacy in their healthcare. But consent and privacy are not the strong suits of today's Web architectures. Consequently, they're a poor match for building online patient services and it shows. Take two examples, the patient portal and the health information exchange.
If you've been to the doctor lately, you've probably been directed to their "patient portal." What a nightmare. The security is too good, forcing you through their generally awful user experience just to perform tasks like reading short, low-value messages. As Bruce Fryer notes, these portals don't link to each other and they use name and date of birth to probabilistically correlate patients across systems.
Health Information Exchanges
A health information exchange (HIE) is another new piece of healthcare software that "allows doctors, nurses, pharmacists, other health care providers and patients to appropriately access and securely share a patient's vital medical information electronically—improving the speed, quality, safety and cost of patient care." These are supposed to help with interoperability between patient portals, but without clear identifiers for each patient, it's hit and miss.
What's more, as Dr. Adrian Gropper points out, current HIEs store massive amounts of patient data with little accountability and don't properly allow patients to control access to data or grant consent for specific uses.
Adrian has rethought how a HIE could work to put the patient in the consent flow and has a wonderful concept he calls HIE of One. He's got numerous demos to illustrate different flows. Adrian's HIE of One solves the problem of exchanging information between healthcare professionals while allowing for patient consent and control by putting the patient in the flow. This is a huge step forward and shows that decentralized solutions can better solve consent problems than centralized solutions.
Self-sovereign identity systems plug right into the HIE of One to provide patient credentials, but that's just table stakes. Using a system like Sovrin, a patient-centric HIE would provide verifiable claims about patient data including test results, clinical findings, past treatment, and drug history. Insurance companies and other payers could also use claims to exchange critical information in a trustworthy, secure manner. Sovrin allows for disclosure and records consent. These claims would be anchored in the Sovrin ledger to ensure they can be validated.
The Role of Self-Sovereign Identity
The healthcare industry has reopened the universal patient identifier (UPI) debate as a potential solution to the problem of correlating patients across portals and exchanges, but there are several problems with this.
First, an UPI would be subject to all the same kinds of problems that the social security number (SSN) has been. Once there's a single identifier anyone can correlate patient activity wherever it shows up. This puts privacy at the mercy of agreements rather than providing structural mechanisms to support privacy.
Second, an UPI doesn't solve the integration problem because it's just an identifier, not an integration method. We still have to rely on multiple point-to-point integrations or a centralized hub to integrate the hundreds of organizations that are helping with a patient's health.
Third, an UPI doesn't help with consent (other than allowing consent agreements to be correlated). There's no built-in mechanism for helping healthcare providers, who want to do the right thing, manage patient consent in a world that's increasingly mediated by online systems.
A self-sovereign identity system like Sovrin helps with all of these:
Sovrin supports trustworthy, patient-shared attributes using a built-in mechanism of verifiable claims. This avoids both myriad, costly point-to-point integrations as well as a centralized hubs
Sovrin provides consent receipts for memorializing promises made to patients about how their data will be used as well as recording patient consent for both procedures and data use.
Sovrin puts patients in a position of controlling claims made about them.
Trust and Intermediaries
One of the primary benefits of self-sovereign identity like that provided by Sovrin is removing the need for intermediaries as holders and conveyors of trust. Currently, hospitals and others provide electronic health records (EHR) as trusted intermediaries. Doctors, pharmacies, labs, and other healthcare providers trust the hospital as a centralized location where patient data is held. EHR providers sometimes abuse this practice by using a practice called data blocking to favor healthcare services they control. Moreover, patient privacy is at risk when EHRs are treated as the hospital's property rather than the patient's.
A self-sovereign identity system removes the need for trusted intermediaries by separating the trust mechanism from the service of holding the record. Patient health data can be held, as verifiable claims in a variety of places so long as it is accessible by the healthcare provider.
Trust in the data is established by technology as well as business and legal processes. Verifiable claims are signed by the provider of the claim. So, a physician writing to a health record would sign the entry using a digital signature that can be validated using the physician's well-known public key. Any other healthcare provider with whom that patient shares that entry could validate the signature and know that the data hadn't been changed. Further, they could use a hash written to the ledger to know with certainty when the entry was made.
But how do we know whether to trust the physician? Professionals can also create proofs from verifiable claims written about them to show that they have specific qualifications, certifications, or work at specific institutions. These claims are, in turn, verifiable in the same manner, creating a chain of trust.
By removing the need for the holder of the record to also be the conveyor of trust, we reduce the power of intermediaries to control data.
Being able to identify qualified professionals in a trustworthy manner has other benefits. In the US, hospitals are often the source institutional trust for healthcare professionals. As an intermediary, the hospital is put in a position of power that they often exploit. Significant money is spent in healthcare proving medical staff are correctly qualified. In the UK, £4bn is spent on short-term agency staff, of which the agencies themselves take 20-25% mainly for doing the ID proofing piece.
Sovrin's verifiable claims could allow a medical society or other credentialing body to issue claims about the healthcare professionals certifications and hospitals to validate they are getting a correctly qualified doctor, nurse, radiologist or other specialist. The impact would be much faster onboarding, lower costs, and better treatment from verified staff.
Moving Past Administrative Identity
Many of the problems with portable patient health records and patient consent are rooted in the administrative identity systems that have developed over the past 15 years. We don't have to create an uber administrative domain in the form of a Universal Patient Identifier to solve these problems. In fact, that will only make many of them worse. A self-sovereign identity can solve the problem of correlation and do it in a way that respects the time-tested principles of patient consent and privacy.
Healthcare-centric uses for Sovrin won't be built from scratch. There has already been important work on patient-centric solutions to electronic health records such as the Fast Healthcare Interoperability Resources (FHIR) standard and Health Relationship Trust (HEART).
Sovrin is seeking to work with experts in healthcare to build healthcare-centric identity solutions on top of the Sovrin platform, join us in our governance efforts, and participate in the Sovrin identity network.
Lately, I've been thinking a lot about use cases for self-sovereign identity. This is the first in a series of blog posts that discusses how Sovrin can be used for various purposes. We'll begin with authentication.
Authentication has several facets. I’m going to discuss two of them below: enrollment and login. In this use case, a person named Alice will be enrolling and logging into a service provided by Bob’s Bait Shop.
How does Alice get a self-sovereign identity? If you read my How Sovrin Works article, you should be aware that there’s no such thing as “an identity” in Sovrin. Instead, Sovrin creates a unique identifier for each relationship that Alice has. Alice controls her identifiers and can correlate them, but no one else can without her permission. So, enrollment consists of Alice generating a key pair for a new relationship and the Bob’s Bait Shop associating that with an account.
There are different ways this could work, but let’s explore just one that involves a Sovrin app called a connector. The connector runs on the person’s device and helps them manage their keys. In some ways, it would feel like a password management app such as 1Password. The connector is secured by the operating-system security services on Alice's device as well as app-specific mechanisms.
When Alice wants to connect with Bob’s Bait Shop via a Web site or mobile app, she uses the connector to generate a new Sovrin public-private key pair for that relationship. The connector securely stores the private key, then uses the public key to generate and register a new identifier on Sovrin. Alice gives the identifier to Bob’s Bait Shop, who creates an account and associates the internal account identifier with the Sovrin identifier. This association could be memorialized as a claim.
If desired, Bob’s Bait Shop could generate a challenge that Alice signs with her connector to prove that she gave them a real Sovrin identifier.
Bob’s Bait Shop might also ask Alice to provide information for creating the account. The connector would automatically determine which claims (either verifiable or self-asserted) can be used to satisfy the request, obtain permission from Alice, and then transmit those claims to Bob’s Bait Shop. Sovrin can partially disclose the information in the claims to protect Alice’s privacy.
As part of requesting information from Alice, Bob’s Bait Shop could send a consent receipt that records promises made to Alice about how her disclosed information will be used. The connector stores a hash of the consent receipt on the Sovrin ledger to notarize it.
Note that Alice didn’t create a password or fill out forms. And she received a receipt documenting her consent. The connector remembers all of the services with which she’s enrolled and gives her a single place where she can see everyone with whom she has a relationship1.
Bob’s Bait Shop doesn’t store or manage passwords. They didn’t have to validate email addresses or phone numbers (provided they received claims they trust). And yet, they have a secure method of authenticating Alice and account information they can trust.
User authentication is the most obvious use case for any identity system. Based on the discussion of enrollment above, assume Alice and Bob’s Bait Shop have already exchanged an identifier and that Alice’s connector is storing the corresponding private key as well as an identifier for Bob’s Bait Shop that can be used as a public key.
Authentication is done using any of the standard public-private key authentication schemes. One method consists of Bob’s Bait Shop presenting Alice with a one-time challenge string (i.e. a nonce) that her connector signs with the private key associated with the service. Bob’s Bait Shop can then use the identifier they have stored to validate the signature. Since only someone with the private key could generate the signature for that identifier, they know they are dealing with someone who has the private key.
Because the challenge is a one-time random string, the authentication can’t be replayed. And Bob’s Bait Shop is not relying on passwords that they have to store (and could lose). In fact there’s nothing for hackers to break in and steal.2 From Alice's perspective, logging in feels as simple as pushing a button in the app and touching the fingerprint sensor on her device.
Benefits of Sovrin Authentication
Authentication might not be very sexy as use cases go, but it’s universal. Sovrin provides an identity system supporting easy enrollment and strong, cryptographically verified authentication that reduces cost, friction, risk, and liability.
The connector, like a password management app, has a way to sync keys across different devices the person uses. They are not dependent on a single device.
By stealing account information, hackers could still set-up a phishing attack where they pretend to be the the original service in an effort to trick the account holder. To counter this, the connector could simultaneously issue a challenge to the service that they have to sign using the private key associated with their well-known public identifier.
There's a lot of confusion about self-sovereign identity.
Many people hear sovereign and think "sovereign means the individual has complete control." Not really. As Scott David pointed out, "declaring yourself king of a deserted island isn't very useful."
Sovereignty is about relationships and boundaries. When we say a nation is sovereign, we mean that it can act as a peer to other sovereign states, not that it can do whatever it wants. Sovereignty defines a boundary, within which the sovereign has complete control and outside of which the sovereign relates to others within established rules and norms.
Self-sovereign identity (SSI) describes the same situation. A self-sovereign identity system (SIS) defines the things over which an entity (person or organization) has complete control along with the rules of engagement for its relations with other entities in the SIS system.
For example, an SIS might give entities complete control over what claims they share in response to queries about them. But sovereignty doesn't mean that a party relying on a claim has to accept it. The relying party's sovereignty allows it to determine what claims satisfy its demands and which don't.
But sovereignty means that all powers are reciprocal. Continuing the example, anyone can reject the claims others choose to present to them. The key to sovereignty is that all entities are peers. I have the same rights you do. The beauty of sovereignty isn't complete and total control, but rather balance of power that leads to negotiations about the nature of the relationships between various entities in the system.
In the physical world, people carry credentials to prove to others that they have certain attributes or hold certain privileges. Online, this is not possible.
For example, a driver's license contains attributes like name, address, and date of birth that have been validated by the Driver's License Division. The driver’s license is widely viewed as trustworthy. Consequently, people use driver's licenses for purposes other than driving. For example, a school or pharmacy can easily verify that a license belongs to the person presenting it, and confirm the validity of the license without ever contacting the Driver's License Division directly.
In other words, in the physical world, people hold and are the conveyors of their own trustworthy attributes (called “claims” by identity experts). These attributes can be used when needed and without prior agreement. Online, such interactions are only possible through pre-arranged integrations between the APIs of specific computer systems.
Identity systems in use today include federation for business-to-business credential sharing, and social login for consumer authentication1. Neither of these offers a foundation upon which third-party claim issuers can easily build services that allow for the kind of ad hoc attribute sharing that happens in the physical world. Consequently, entities who want to rely on attributes from many parties have to perform integrations with all of them. This is slow, complex, and costly, so it typically happens only for high-value applications.
Decentralized identity systems, like Sovrin, have built-in support for third-party claims that function in the same way physical credentials work: they’re presented directly by the identity owner. The identity owner can use a claim from one party to disclose attributes to another party without those parties even having a relationship, much less a technical integration2. Claims can be used in ad hoc situations, just as they can in the physical world, allowing individuals to function as integration points. When you can instantly trust what someone says about themselves, workflows and integrations are dramatically simplified.
There are other benefits to owner-provided attribute sharing. First, when owners share attributes, the receiver automatically gains consent to use the attributes for the requested purpose. This significantly reduces liability. Second, when the owner is part of the process, they can check the accuracy of the attributes as they’re being shared, resulting in better data.
Owner-provided attributes are a powerful driver that will push decentralized identity systems well beyond the current uses of federation and social login. Businesses can reduce or even eliminate API integrations and manual verification processes, and instead trust what's presented to them by customers, because the claims can be verified. Customers become the source of what's true about them. Businesses will find great value in this, driving adoption by individuals as customers are brought into decentralized identity systems through day-to-day business activities.
Sovrin is an open-source identity network built on distributed ledger technology. Sovrin is public and permissioned. Public means everyone can use it. Permissioned means that the network nodes that ensure consensus of transactions on the ledger are governed, in this case by the non-profit Sovrin Foundation.
In this discussion we're going to look at the interactions of a Sovrin user named Jane with her bank, her local government, a potential employer, her school and a retailer.
The following figure shows Jane's view of her identity on Sovrin. Right now there's nothing there, but we're going to add things as we discuss Sovrin's capabilities in the following sections. Jane's identity doesn't really exist as depicted. The view is a virtual representation. Jane's Sovrin identity is the collection of all of her Sovrin identifiers, claims, disclosures, and proofs. The things in the box labeled "Jane's identity" are stored in various places. Most, but not all will be on the Sovrin ledger itself, some might be stored off the ledger in other repositories like the private ledger we'll discuss later.
The diagram also shows the Sovrin Ledger. The ledger is shown to emphasize that everything we talk about is using the ledger. There are far too many lines for the diagram to show all the various interactions with the ledger itself, so I've chosen to merely represent it and use it as a place to show the diagram's legend.
The Sovrin Identity Network (SIDN) consists of multiple, distributed nodes located around the world. Each has a copy of the ledger. Nodes are hosted and administered by stewards. Each node has a copy of the ledger. Stewards are responsible for validating identity transactions to assure consistency about what is written on the ledger and in what order. They do this using a combination of cryptography and an advanced Byzantine fault tolerance algorithm. See the Sovrin whitepapers The Inevitable Rise of Self-Sovereign Identity (PDF) and The Technical Foundation of Sovrin (PDF) for more details.
Keys, Identifiers, and Relationships
Sovrin tracks keys and identifiers. One of the major concerns with identity is correlation. If Jane were to use one identifier in multiple places, those places might collude to correlate that identifier and amass significant data about her without her permission. Sovrin avoids this by allowing Jane to use a different identifier with everyone she relates to.
By default, Sovrin identifiers are cryptonyms, an encoded Ed25519 digital signature verification key. Sovrin also supports DID’s (Distributed Identifiers), which are identifiers with no cryptographic properties. These identifiers also have an associated Ed25519 verification key. In the diagram the signing key is represented by a small letter and the verification key is represented by a big letter. These two keys represent a private-public key pair. Jane never shares her signing key, only the verification key.
Jane has a relationship with her bank. She shares a verification key, A, with the bank that created specifically for this relationship. This key represents Jane's identity to the bank and can be used to verify any interactions that they have. The bank also has its own key, K. This is a well-known key that represents the bank to the world. Jane would also have a copy of that so that she can validate communications she has with her bank. The verification keys of both Jane and the bank are found on Sovrin, so they can both know they are using the latest verification keys of the other party.
As we add new relationships to this diagram, you'll see that Jane uses a unique key pair for each of her relationships1.
In addition to identifiers, Jane has claims on Sovrin. Claims are a fundamental component of Sovrin. They are assertions or attestations made by a party about itself or another. Claims are digitally signed so that anyone receiving the claim can know who issued it.
There are several types of claims. In the following diagram, claim 1 and 4 are self-asserted. Jane might, for example, create a claim that asserts her gender or that her name is Jane.
The other claims are verifiable claims made by others about Jane. Claim 2 was asserted (and signed) by the local government. This claim might be a driver's license. Jane could use this verifiable claim to prove to someone else that she's authorized to drive.
A claim in Sovrin is specific to an identity owner, its subject. Claims are linked to the identity owner and the party issuing the claim. For example, claim 2, Jane's driver's license, can be validated as being about Jane and as having been issued by her local government.
Claims are defined so that they are understandable by parties that rely on them. Sovrin makes provision for claim types to be defined with a schema or ontology. Claim definitions are recorded on the Sovrin ledger. The local government would create a claim definition that describes a driver's license claim. Jane's claim includes a reference to the definition so that anyone to whom Jane presents her driver's license can look up its definition and make sense of it.
Claims also have keys that are specific to the claim so that relying parties can validate that the claim is legitimate. Claim keys are linked to the issuer. A claim key can be changed, but old keys are saved, so that a relying party can verify a claim based on the keys that were used to issue it.
And, of course, claims can expire or be revoked when needed.
Claims can be reused and tailored to the applied purpose at hand using disclosure proofs. Disclosure proofs allow claims to be used without disclosing unnecessary information about the subject.
In this diagram, Jane is applying for a job. She can combine the verifiable claims from her school and government along with information she's self-asserted into a disclosure. Jane can pick the attributes she wants to share from each of these without disclosing the entire claim. For example, she might choose to include a proof from the government of her address and that she's over 18, a proof that she has a certain degree from her school, and a proof of her gender from herself. Jane uses a master secret, a special key, to create the disclosure using a zero-knowledge proof algorithm. The disclosure proof links the attributes so that the employer knows that they were made about the same person.
The employer can verify each of these attributes were asserted by the party who makes the claim. The employer has a verification key from Jane that allows them to validate claims that Jane makes herself. Jane can disclose additional details as the relationship with the employer progresses. While the algorithms behind this are complex, the user experience is simple and natural.
An important point about disclosure proofs is that they are non-correlatable. Suppose someone at the employer had a friend who worked in the local government. These two people couldn't collude to use the proof Jane sent to the employer to discover additional information about Jane that the government holds. Neither the proof nor the identifier the employer holds for Jane correlate to any identifier that the government holds and thus can't be used as a key to look Jane up in the government's systems.
Claims Can Be Made About Anybody
Jane has a relationship with a retailer (we can tell since they have her verification key). Suppose that Jane wants some evidence that the retailer is in good standing with the local chamber of commerce. In the same way that Jane created a disclosure for a potential employer from claims, the retailer can use a verifiable claim from the chamber of commerce to create a disclosure proof and send it to Jane. She now has proof of what the chamber of commerce said about the retailer.
As part of buying from the retailer, Jane has shared personal information. The retailer can provide an attestation that they will treat Jane's personal data in a specific way (e.g permission to use expires after 30 days, attributes used only for completing transactions, and so on). That attestation is called a consent receipt. Jane uses Sovrin to keep track of the consent receipts she's received. Consent receipts are just one type of agreement that Jane can manage with Sovrin.
Public and Private Attributes
Claims can be public or private. For example, the school might have a public attribute showing its address. That isn't sensitive information, so it can be stored publicly on the Sovrin ledger. Anyone can read it and validate that it really is the self-asserted address of the school. Furthermore, others can attest to the validity of the claim, leading, over time, to increased trust that the address is legitimate. This kind of social proof is critical to establishing reputation and building trust.
Encrypted attributes are not normally stored on the Sovrin ledger. The following diagram shows that Jane has a private ledger. Things like proofs from others and encrypted attributes can be stored there.
One important purpose of the private ledger is to track the time and order that things are written. Hashes of the private ledger can be written to Sovrin's public ledger periodically to provide evidence of Jane's holdings. These are called anchors. Jane can thus generate audit proofs that any particular interaction happened at a particular time without disclosing the details of the interaction.
Jane may have a private ledger on her mobile phone, and in her browser. An agency could help her manage them and facilitate synchronization between her devices. Agencies are service providers that help Jane manage her identity. You can think of them as analogous to Internet Service Providers. They are substitutable for one another and Jane can choose a new agency without losing any of her identifiers, attributes, proofs, or claims. Because all of the information stored in Jane's private ledger is encrypted, there's a low security risk in using an agency as they never see Jane's transactions except in an encrypted state. Agencies are under legal contract to Sovrin Foundation to behave in specific ways to ensure Jane's security and privacy.
Advantages of Sovrin
We've seen in the preceding examples a number of advantages that Sovrin holds over other identity systems.
Public—everyone can use Sovrin. Both individuals and organizations will be relying parties and claim issuers.
Permissioned—the Sovrin Foundation establishes rules for network nodes like stewards and agencies to hold them legally accountable for their actions.
Reputation enhancing—Sovrin allows for the social proof of information people claim to be true, building reputation and thus enhancing trust.
Trustworthy—identifiers and claims can be trusted because they are based on strong cryptography and governed by the Sovrin Foundation.
Privacy enhancing—claims can be reused without risking correlation between identities. Sovrin reduces the hesitancy people might feel by enhancing privacy and thus reducing risk.
The Internet was created without any way for people and organizations to be identified. On the Internet, only machines get identities in the form of IP numbers. This is understandable given what the creators of the Internet were trying to achieve. But the lack of a decentralized, heterarchical, and interoperable identity system has created an environment where the services most people use online are a lot more centralized than the Internet they're built upon.
Sovrin Foundation aims to rectify that. Using the virtues of Internet as a model, The Sovrin identity protocol uses a distributed ledger to replace today's centralized identity intermediaries. I believe an Internet-like identity system will create new opportunities for everyone by streamlining interactions and enabling stronger levels of trust.
A permissioned ledger needs a governance process to determine the business processes and overarching legal framework that validators on the network must follow to ensure that2 SIDN can be trusted. Sovrin Foundation provides the lightweight governance that is needed to do that. Sovrin Foundation governs the network and the open-source code that makes it work, but we don't own or control people's identities, they are sovereign.
The Foundation has four primary duties:
Develop and maintain the Sovrin Trust Framework, governing the selection and monitoring of Sovrin stewards and operation of the Sovrin Ledger.
Coordinate and monitor steward activity to ensure the ledger is stable, correct, and trustworthy.
Manage the Sovrin Project—the open source code that operates, validates, and provides access to the ledger.
Promote universal acceptance of the Sovrin ledger for self-sovereign identity.
I've agreed to serve as the inaugural chair of the foundation. I co-founded the Internet Identity Workshop with Kaliya Hamlin and Doc Searls a dozen years ago with the goal of promoting what we then called "user-centric identity." My motivations in doing that were the same as they are here: find a way to unlock the vast potential of people who own and control their online identity.
We have a tremendous, global Board of Trustees who have agreed to serve and help organize the foundation. Each person on the board brings unique talents and perspective. I'm excited to work with them in organizing Sovrin Foundation and bringing this to fruition.
Evernym developed the code that makes Sovrin work and has generously gifted that code to Sovrin Foundation. Making it open source wasn't enough. Sovrin Foundation can't govern SIDN without also owning the code that makes it work. Timothy Ruff and Jason Law, Evernym's founders, saw early on that the best way to make Sovrin successful was to give it away. Sovrin Foundation is grateful for their support and this demonstration of trust.
You can get more information from the following links:
My last blog post was about creating an Internet for identity, a decentralized system that allows people and organizations to create identities independent of intervening administrative authorities. The post describes this system as self-sovereign and I call the system a self-sovereign identity system or SIS.
I believe the right way to construct SIS is using a public, permissioned distributed ledger. Permissioned ledgers have important properties that make them specifically useful for identity systems.
But permissioning implies governance. Someone has to determine who has permission to participate in approving transactions. If there are people making these kinds of decisions, how can a governed, permissioned ledger justify a claim that it supports self-sovereign identity?
John Locke and Sovereignty
John Locke was an English philosopher who had a big impact on the thinking of America’s founding fathers. Locke was concerned with power, who had it, how it was used, and how society is structured. More importantly, Locke’s theory of mind forms the foundation for our modern ideas about identity and independence.
Locke argued that “sovereign and independent” was man’s natural state and that we gave up freedom, our sovereignty, in exchange for something else, protection, sociality, commerce, among others. This grand bargain forms the basis for any society. As a community, the Internet proposes a similar bargain.
The goal of being self-sovereign isn't to be completely independent. With regard to the Internet: only machines without a network connection are completely independent. In the case of identity: only people without any relationships are completely independent. Seen from Locke's viewpoint, sovereignty is a resource each person combines with that of others to create society. Voluntarily giving up some of our rights to a state confers legitimacy on that state and its constitution.
The defining characteristic ... of a constitutional order is its basis for legitimacy. The constitutional order of the industrial nation state, within which we currently live, promised: give us power and we will improve the material well-being of the nation.
In other words, legitimacy comes from the constitutional order: the structure of the governance. Citizens grant legitimacy to constitutional orders that meet their expectations by surrendering part of their sovereignty to them.
Regarding constitutional orders, Bobbitt says the following:2
The constitutional order of a state and its strategic posture toward other states together form the inner and outer membrane of a state. That membrane is secured by violence; without that security, a state ceases to exist. What is distinctive about the State is the requirement that the violence it deploys on its behalf must be legitimate; that is, it must be accepted within as a matter of law, and accepted without as an appropriate act of state sovereignty. Legitimacy must cloak the violence of the State, or the State ceases to be. Legitimacy, however, is a matter of history and thus is subject to change as new events emerge from the future and new understandings reinterpret the past.
Without legitimacy, the state cannot take action because neither it's citizens nor those on the outside who interact with it will see that action as authorized and thus it won't be accepted. Again, I believe these same principles can be applied to technical systems with broad societal impact. Without the support of it's users and the organizations rely on it, technical systems fail to be accepted.
My goal in this article is to apply these ideas about sovereignty, legitimacy, and constitutional orders to identity systems. Identity systems that seek to have large adoption and a broad spectrum of applications must have the support of a large class of users (analogous to citizens) and many relying parties (analogous to other states). They make promises that users and relying parties use to judge their legitimacy. Without legitimacy, they cannot succeed in their goals.
Social login, using your social media account to log into other sites, has become a popular means of reducing the identity management burden for users and relying parties alike. As I said earlier, my last post analyzed an emerging class of identity systems based on distributed ledger technology I called sovereign-identity systems (SIS).
My thesis is that we are in the early stages of a change in the constitutional order for identity systems from social login to sovereign-identity systems. The rest of this article will focus on these two constitutional orders for identity systems, the promises they make, and their claims to legitimacy.
The Legitimacy of Social Login
Social media sites have become the largest providers of online identity through the use of social login. When you use Facebook to log into a third party Web site (known in identity circles as a relying party), you are participating in an identity regime that has a particular constitutional order and granting it legitimacy by your participation. Further, the relying party has also chosen to recognize the legitimacy of social login.
The constitutional order of social login is found in the terms and conditions in the contracts of adhesion that social login identity providers impose on people and relying parties alike. The system is a "take it or leave it" proposition with terms that can be changed at will by the social login identity provider.
A constitutional order makes different promises to those in the system (the users) and those on the outside (the relying parties). Let's examine the promise that social login makes:
To people social login says "use the identity we provide to you and we will make logging into sites you visit easy."
To relying parties, social login promises "use the identity we provide and trust us to accurately authenticate your users and we will reduce your costs, increase flexibility, and give you more accurate information about your users."
As successful as social login has been, there are a lot of places that social login has failed to penetrate. By and large, financial and health care institutions, for example, have not joined in to use social login. Why is this?
A constitutional theorist would say that they've failed the legitimacy test. Some relying parties and some people (either completely or for some use cases) have failed to yield their sovereignty to them. Legitimacy ultimately rests on trust that the regime can keep its promises. When that trust is missing or lost, the regime suffers a legitimacy crisis.
For people, the lack of trust in social login might be from fear of identity correlation, fear of what data will be shared, or lack of trust in the security of the social login platform.
For relying parties, the lack of trust may result from the perception that the identity provider performs insufficient identity proofing or the fear of outsourcing a critical security function (user authentication) to a third party. An additional concern is allowing a third party of have administrative authority for the relying party's users—not being in control of a critical piece of infrastructure. That is, they don't trust that the rules of the game might change arbitrarily based on the fluctuating business demands of the identity provider.3
These trust failings ultimately stem from the structure of the trust framework, the constitutional order, of social login. Because it's based on terms and conditions imposed by the identity provider whose primary business is something else, people and relying parties alike have less confidence in the future state of the identity system. So, it's good enough for some purposes, but not all.
The Legitimacy of Distributed Ledger Identity Systems
A distributed ledger identity system, what we've been calling SIS, has a different constitutional order. As we discussed in An Internet for Identity, nobody owns SIS, everybody can use it, and anyone can improve it. There are no identity providers. Anyone can create multiple identities on SIS to suit their needs. SIS is a public infrastructure for identity.
There's another important structural difference: SIS allows third party claim issuers to read and write claims about identifiers on the ledger. For example, the DMV (Department of Motor Vehicles) might write a claim about your authority to drive to the ledger. This claim would be sharable, by you, with others who are willing to trust the DMV. Anyone you share this claim with can verify that it came from the DMV and that it hasn't been tampered with.
Claims issuers are distinguished from identity owners and relying parties.4 Their relationship with identity owners is that they issue claims about them. Relying parties rely on the claims that claims providers issues when they are shared by the identity owner. Allowing third party claim issuers to participate in the identity ecosystem opens up new and powerful opportunities for participants in an SIS ecosystem.
Because claim issuers and relying parties are distinguished, we will refer to them collectively as "other parties."
SIS makes the following promises:
To people: "Create as many identities as you like and use them how you see fit. You can keep them forever. We will ensure that you can use them privately and securely, sharing claims on those identities with other parties as you see fit."
To claim issuers: "Write claims about the identities with whom you have a relationship. We will ensure that your claims are secure and private (where appropriate)."
To relying parties: "Use claims made by yourself and others (when they are shared with you). We will ensure that these claims are secure and that you can trust them."
There are two ways we can presently realize SIS: with a permissionless ledger or a permissioned ledger. I'm going to assume that both of these are public, meaning anyone can use them. There are private, permissioned ledgers that are used within specific administrative domains. But SIS has to be public—everybody can use it—to meet the criteria of being like the Internet.
One factor in the constitutional order of permissionless and permissioned ledgers is who can validate (and thus, ultimately, write) to the ledger. While it's public and anyone can use it, the transactions have to be validated to prevent fraud.
In a permissionless system, anyone can be a validator. This leads to permissionless ledgers, like the Bitcoin blockchain, having to use some mechanism to ensure that validator voting is fair. Specifically, a permissionless ledger has to protect against Sybil attacks. If pseudonyms are cheap, cheaters can create as many a they like and use them in the validation process to vote for fraudulent transactions. Permissionless ledgers, therefore, use techniques like proof of work or proof of stake to increase the cost of participation and mitigate attacks.
Permissioned systems, on the other hand, control who can be a validator. Sybil attacks are not possible when the validators are known beforehand. But this creates a different problem: someone has to vet the validators and ensure that they are known and play by the rules. When a validator breaks the rules, there has to be a judicial process to review the issue and possibly ban the offending node from participating in future transaction validations. Consequently, we need a
governance process to identify validators, set rules for their behavior, bind them to contracts, and adjudicate their behavior.
These different structures will affect how well these two different systems can meet the promises upon which an SIS stakes its legitimacy. While I don't believe it's necessarily a competition and that both kinds of ledgers will co-exist to meet different needs, I believe that permissioned ledgers have an edge in establishing trust with claim issuers and relying parties alike. A governance process allows a clear case to be made about trust and process.
In particular, we've seen instances in permissionless ledgers that led to blocks being orphaned or a smart contract being hacked. In both cases, code maintainers had to choose how to resolve the issue in the ledger. Their choice was a legitimacy problem because they had to convince the validators to move with them and support it. A permissioned system doesn't necessarily prevent these problems, but it can provide a clear, unambiguous judicial process for solving the problem. This provides clarity to everyone about what happens when something goes wrong. This is a clear advantage.
How will permissioned systems fare with people? That depends on the details of their constitutions. To the extent that governance is limited to controlling validators, and not limiting how identities are created and used in the system, people will see clear advantages in permissioned ledgers because they will attract claim issuers and relying parties that people want to interact with. Heavy-handed governance that limits individual control of identity, on the other hand, will turn people off and push them to permissionless systems where anything goes. This isn't binary, there's a spectrum of choices between these two extremes.
Surviving the Transition
In Bobbitt's theory of constitutional orders, transitions from one constitutional order to a new one always requires war. After all, since state constitutions represent a structure seeking legitimacy for its monopoly on violence, violence is necessarily the founding tenet of the state.
Technological systems aren't using their constitution in the same way. I believe one critical difference is that holding multiple citizenships in different online systems is entirely practical. Consequently, I believe people will continue to use social login alongside newer distributed-ledger identity systems for some time to come.
Claim issuers and relying parties might be another story. There very well could be a competition for other parties between different identity regimes and that is where I believe we'll see the benefits of these different constitutional orders being carefully weighed and hotly debated.
At least for some time, social login is going to win the "we have the most users" contest. But as we saw with Internet adoption, that didn't hold true very long for CompuServe, AOL, and Prodigy (among others). AOL was the only online service company to survive the transition. If SIS can fulfill its promise, the scales could tip swiftly as more and more claim issuers and relying parties see the benefit of SIS and adopt it, bringing their users with them.
Different Sovereign Identity Systems will have different constitutions. Not just whether they are permissionless or permissioned, but also within these broad classes. For example, there can be significant differences in the governance of permissioned ledgers. The most successful ones will be more like republics or democratic governments: they exert authority, but only that which is granted to them by the users, for the sake of the users.
Note that identity providers in the social login regime are not primarily in the business of providing identity. Their business is something else (mostly selling ads) and providing identity for social login is, from their perspective, part of serving that end.
Note that in practical usage, any given entity might play any of these three roles at different times.