Using Picos for BYU's Priority Registration

Maeser Building

Every semester over 30,000 BYU students register for two to six sections out of about 6,000 sections being offered. During the priority registration period this results in a surge as students try to register for the classes they need.

One proposed solution for handling the surge is to create a microservice representing sections that can spawn copies of itself as needed. Thinking reactively, I concluded that we might want to just have an independent actor to represent each section. Actors are easy to create and the underlying system handles the scaling for you.

Coincidentally, I happen to have an actor-style programming system. Picos are an actor-model programming system that supports reactive programming. As such they are great for building micorservices.

Bruce Conrad and Matthew Wright are reimplementing the KRE pico platform using Node JS. We call the new system the "pico engine." I suggested to Bruce that this class registration problem would be a fun way to test the capabilities of the new pico engine. What follows is the results of Bruce's experiment.

Experimental Setup

We were able to get the add and drop requests for the first two days of priority registration for Fall 2016. This data included 6,675 students making 44,505 registration requests against 5,393 sections.

The root actor in a pico system is called the Owner Pico. The Owner Pico is the ancestor of all other picos. For this experiment, Bruce created two child picos for the Owner Pico to represent the collection of sections and the collection of students. The Section Collection Pico is the parent of a pico for each section. The Student Collection Pico is the parent of a pico for each student. The resulting pico system looked like the following diagram from the Pico Engine's developer console:

Overall Setup for Registration System
Overall Setup for Registration System (click to enlarge)

Bruce chose not to create picos for each student for this experiment. He programmatically created picos for each section. The following figure shows the resulting pico graph:

Picos for Every Section Taught in Fall 2016
Picos for Every Section Taught in Fall 2016 (click to enlarge)

Each section pico has a unique identity and knows things like it's name, section id, and seating capacity. The pico also keeps a roster of students who have registered for the course. The picos instantiated themselves with this data by calling a microservice with the data.

Using this configuration, Bruce replayed the add/drop requests as events to the pico engine. Events were replayed by sending an section:add or section:drop event to the Section Collection Pico (which routed requests to the individual section picos).

After the requests have been replayed, we can query individual section picos to ensure that the results are as expected. This figure shows the JSON result of querying the section pico for STDEV 150-3. Queries were done programmatically to verify all results.

Querying a section pico shows it has the right state
Querying a section pico shows it has the right state (click to enlarge)

Results

Bruce conducted two tests using a pico engine running on a Macbook Pro (2.6 GHz Intel Core i5).

The first replay, done with per-event timing enabled, required just under an hour for the 44,504 requests. The average time per request was about 80 milliseconds (of which approximately 30 milliseconds was overhead relating to measuring the time).

A second replay, done with the per-event timing disabled, processed the same 44,504 add/drops in 35 minutes and 19 seconds. The throughput was 21 registration events per second or 47.6 milliseconds per request.

For reference, the legacy system, running on several large servers, sustains a peak rate of 80 requests per second, while averaging one request about every 3.9 seconds.

These tests show that the pico engine can handle a significant number of events with a good event processing rate.

Conclusions and Going Further

Based on the results of this experiment, I believe we're closing in on the performance goal we set for Pico Engine rewrite. I believe we could achieve better results by running picos across multiple engines. Since every pico is independent, this is easily done and would avoid resource contention by better parallelizing pico operation.

The current pico engine does not support dynamic pico assignment where any free engine in a group can reconstitute and operate a pico as necessary. KRE, the original pico platform, does this to make use of multiple servers for parallelizing requests. The engineering to achieve this is straight forward.

If you're interested in programming with picos, the quickstart will guide you through getting it set up (about a five minute operation) and the lessons will introduce you to reactive programming with picos.


Photo Credit: Maesar Building from Ken Lund (CC BY-SA 2.0)


Sovrin Use Cases: GPG as a Sovrin Client

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

As I read I’m throwing in the towel on PGP, and I work in security from Filippo Valsorda, I couldn't help but think that it illustrates a real problem that Sovrin solves. Valdorda says:

But the real issues, I realized, are more subtle. I never felt confident in the security of my long-term keys. The more time passed, the more I would feel uneasy about any specific key. Yubikeys would get exposed to hotel rooms. Offline keys would sit in a far away drawer or safe. Vulnerabilities would be announced. USB devices would get plugged in.

A long-term key is as secure as the minimum common denominator of your security practices over its lifetime. It's the weak link.

To see how Sovrin can help, let's talk about DIDs and DDOs.

DIDs and DDOs

A distributed ledger like Sovrin is a key-value store with entries that are temporally ordered and immutable. Decentralized Identifiers (DIDs) are intended to be one kind of key for a ledger. A DID is similar to a URN (universal resource name) and has a similar syntax. Here's an example DID:

did:sov:21tDAKCERh95uGgKbJNHYp

The ternary structure includes a schema identifier (did), a namespace identifier (sov in this case) and an identifier within that namespace (21tDAKCERh95uGgKbJNHYp) separated by colons. DIDs are meant to be permanently assigned and not reused. DIDs can be used to identify anything: person, organization, place, thing, or even concept.

DIDs point to DDOs, or DID Descriptor Objects. A DDO is a JSON-LD-formatted data structure that links the DID to public keys, signatures, and service endpoints. We can use the signatures to validate that the DDO has not been tampered with, the service endpoint to discover more information about the DID, and the public key to secure communication with the entity identified by the DID.

Sovrin is designed to support a different key pair for each DID. Consequently, a DID represents an identifier that can be specific to a particular relationship. Say I give 20 DIDs to friends I want to communicate with. Each associated DDO would contain a public key that I generated just for that relationship. I would sign these with a key that is well known and associated with social media and other well known online personas I maintain.1

The keys associated with these DIDs can be rotated as frequently as necessary since people never store my key, they only store the DID I give them for communicating with me. The ledger ensures that the most recent public key for a given DID can always be validated by checking the signature against the key associated with my well known DID.

Of course, I've also stored DIDs for my friends and can check communications from them in the same way.

These features, taken together, do away with the need for long-term keys and ease the burden of knowing the public key for someone you want to communicate with. So long as you know DID for the person, you can encrypt messages they can read. 2

A Proposal: GPG and Sovrin

Which brings me to my proposal. Sometime in the first part of 2017, the Sovrin identity network will go live. The sandbox is available now. Many of the most advanced features of Sovrin will not be available in the MVP, but DIDs, DDOs, and public-private key pairs will be.

Could GPG be modified to perform as a Sovrin Client? I believe the following would be required:

  1. Create DIDs with valid public keys on the Sovrin ledger3
  2. Store and manage the private keys associated with those public keys
  3. Store DIDs and associate them with contacts on the user's computer
  4. Look up the DDO and public key for a given DID on the Sovrin ledger
  5. Check signatures on the DDOs
  6. Use the keys in the DDO for cryptographic operations

I'll admit to being a naive user of GPG, so perhaps there are problems in what I'm proposing that I can't see. Please let me know. But if GPG could be made to work with Sovrin, it would seem to solve some of the problems that have long plagued PGP-based message exchange and present a great use case for the Sovrin ledger.


  1. This feature makes DID-based public keys superior to other solutions where the users is identified everywhere by a single identifier (say a phone number) since it prevents correlation.
  2. I recognize that this proposal doesn't solve the very real issue of private key management on the client.
  3. Key creation would be aided by a agency run by the Sovrin Foundation to save GPG from having to do the heavy lifting.

Photo credit: The Enigma Machine from j. (CC BY 2.0)


Sovrin Use Cases: Portable Picos

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

Anyone who reads this blog regularly knows that I've been working on a system for creating online agents using an event-driven, actor-model programming system called "persistent compute objects" or "picos" for short. Picos support a personal, decentralized model for the Internet of Things. Fuse, a connected-car platform, was designed to show how this model works.

Picos support a hosting model that supports the same properties that the Internet itself has, namely decentralization, heterarchy, and interoperability. Central to these features is the idea of portability—a pico should be movable from one hosting platform (something we call a "pico engine") to another without loss of functionality.

I believe that the future Internet of Things will require architectures where online "device shadows" (as Amazon calls them) are not only under the control of the owner, but hostable in a variety of places, not just on the manufacturer's servers. For example, I might buy a toaster that has a device shadow hosted by the Black and Decker and later decide to move that device shadow (along with its interaction history) to a hosting platform I control. Picos are a way of imagining postable device shadows that are under owner control.

Names

The most difficult problem standing in the way of easily moving picos between hosting engines is that picos receive messages using a URL that follows the format defined by the Sky Event Protocol. Because it's a URL, it's a location. Moving a pico from one engine to another requires updating all the places that refer to that pico, an impossible task. HTTP redirects could potentially be used, but they have scaling limitations I'd rather stay away from. Specifically, frequent moves might create long chains of redirects that have to be maintained since you can never be sure when every service with an interest in the pico had seen the redirect and updated their records.

The more general solution is to have picos refer to each other by name and have some way of resolving a name to the current location of the pico. In the past this always led me to an uncomfortable reliance on some kind of centralized registry, but recent developments in distributed ledgers have made name resolution possible without reliance on a central registry.

DIDs and DDOs

A distributed ledger like Sovrin is a key-value store with entries that are temporally ordered and immutable. Decentralized Identifiers (DIDs) are intended to be one kind of key for a ledger. A DID is similar to a URN (universal resource name) and has a similar syntax. Here's an example DID:

did:sov:21tDAKCERh95uGgKbJNHYp

The ternary structure includes a schema identifier (did), a namespace identifier (sov in this case) and an identifier within that namespace (21tDAKCERh95uGgKbJNHYp) separated by colons. DIDs are meant to be permanently assigned and not reused. DIDs can be used to identify anything: person, organization, place, thing, or even concept.

DIDs point to DDOs, or DID Descriptor Objects. A DDO is a JSON-LD-formatted data structure that links the DID to public keys, signatures, and service endpoints. We can use the signatures to validate that the DDO has not been tampered with, the service endpoint to discover more information about the DID, and the public key to secure communication with the entity identified by the DID.

Using Sovrin with Picos

DIDs on the Sovrin ledger provide a convenient way to name picos with an identifier that can be resolved to the current location of the pico without relying on a centralized registry. The figure below shows how this could work.

Intial State (click to enlarge)

The figure shows two pico engines and five picos. Two of the picos are acting as decentralized directories. The Sovrin ledger is associating a DID for each pico with a DDO that names the directory as the service endpoint. The databases representations on the right show the persistent state of the directory picos and map DIDs to the current location of the pico (which engine).

We use a directory pico, rather than writing the engine directly in the DDO, to allow for frequent updates. Suppose we wanted to move the pico between engines frequently. A directory can be easily updated, multiple times per second if necessary. There can be many directories. The location of the directories is arbitrary and unimportant. You'll notice I put them both in the same engine, but they could be anywhere because they're located using the DDO.

Finding a pico, given its DID, is simply a matter of looking up the DDO for the DID on the ledger, retrieving the directory from the service endpoint entry, consulting with the directory to find the engine (and any other important information) and constructing a location pointer (what we call an ESL or Event Service Location).

Multiple Identifiers

This model easily supports a pico having multiple identifiers (an important feature of picos that prevents correlation). This is supported in the Sky Event Protocol by what are called Event Channels. Each event channel has a unique event channel identifier, or ECI. In addition to preventing correlation, having separate event channels allows the pico to manage, permission, and respond to messages independently. The figure below shows how this is supported:

Supporting Multiple DIDs (click to enlarge)

In the figure, Pico 2 has two DIDs. Each points, arbitrarily, to a different directory. The directories not only contain the location of the pico engine, but a unique ECI. The information in the directory can be used to construct an ESL from each DID that can't be correlated with others.

Creating a New Pico

The process for creating and registering the name for a new pico is straightforward as shown in the following figure. The new pico is created and appropriate entries are added to the directory. A new entry is written to the ledger associating the DID for the pico with a DDO pointing to the directory.

Creating a New Pico (click to enlarge)

Discovery

Pico discovery is simple using the DID. Suppose Pico 2 has the DID for the newly created Pico 4. The following figure shows the discovery process.

Discovering a Pico (click to enlarge)

  1. Pico 2 uses the DID to discover the directory using the DDO written on the ledger.
  2. Pico 2 queryies the directory.
  3. The directory returns the data about Pico 4
  4. Pico 2 contructs an ESL.

When a pico wants to send a message to another pico, it may have to repeat the discovery process to find out where it is. The ESL that is generated from the discovery process can be cached and expired based on time or failure.

Creating a Subscription

Picos create relationships with each other that are called subscriptions. The primary task in creating a subscription is key exchange. DIDs allow this to happen easily. In the following figure, assume that Pico 2 has already gone through the discovery process outlined above and has an ESL for Pico 4.

Creating a Subscription (click to enlarge)

  1. Pico 2 sends a signed subscription request that includes a DID to Pico 4.
  2. Pico 4 uses the discovery process to get Pico 2’s public key and other information from the DDO in the ledger.
  3. Pico 4 uses the public key it gathers in (2) to validate that the request in (1) came from Pico 2.
  4. Pico 4 stores Pico 2’s public key, name, and other relevant data; caches the directory and engine; and sends a subscription response.
  5. Pico 2 validates the response and stores subscription information for Pico 4.

Moving Picos

As shown in the following figure, when a pico is moved from one engine to another, only the directory need be updated.

Moving a Pico (click to enlarge)

Changing Directories

There will be reasons to change what directory a pico is using for a given DID. That requires updating the ledger as shown in the following figure.

Updating the Directory (click to enlarge)

The crossed out entry in the ledger is meant to indicate that it's been superseded, not that it's been deleted. Ledger entries are immutable.

Conclusion

The preceding scenarios describe the methods picos can use to make them portable while maintaining maximal decentralization. The use of names (DIDs) recorded on the Sovrin distributed ledger that reference directories for pico location provide an efficient, flexible, and complete means of maintaining connectivity between picos even if they are moved often. There are no centralized services that could create a single point of failure.


Photo Credit: sunrise_sequence_01w by Jan (Arny) Messersmith (CC BY-NC-ND 2.0)


Sovrin Use Cases: Education

University Lecture hall

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.

A virtual university using a student profile

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.


  1. She could, of course pay for them as she takes them, but this makes the case study a little simpler.
  2. 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.


Notes from Defrag 2016

Defrag logo

The following are my live tweets from Defrag at the Omni Interlocken in Denver, November 16-17, 2016.

Eric Norlin:

Defrag is 10 years old. Happy birthday.

Announcing that this is the last time Defrag exists independently. Combining with Glue. #sad

Tim Wagner:

Going server less with AWS lambda

Does serverless mean no servers? No, but there are no software servers (web server framework, etc.)

Serverless goes beyond VMs and containers so that functions are the unit of abstraction

Serverless enforces good design: small individual units of code, persistence separated from compute, one way to do things

Triggers by events or calls from APIs. Easy to do real-time processing, event processing

Bring your own code, Lambda is the web server, uses simple resource model, processes are stateless

Economic proposition for lambda is "never pay for idle"

Lambda economic model makes building a service simple by removing need to understand servers, availability zones, scaling

Would you rather carry a giant beachball of 700 marbles without a bag. Both suck. Monoliths and microservices...

Lambda provides the bag for the marbles.pen spec and tools to package and deploy entire serverless model #comingsoon

Serverless means bring your own frameworks. No need to learn a new framework

Lambda is a universal webhook receiver platform.

Lambda reduces the need for understanding complex distributed computing concepts

Future is a hybrid of containers and serverless to bridge these two worlds

Prediction: we go from abstracting compute infrastructure to abstracting computational systems

Lorinda Brandon:

Marketing person at a tech conference gets "you have stickers, right?"

Marketing smells funny: they always have to good news, they're perky. Makes you think they're hiding something

Marketing thinks developers are mean and scary.

developers are great conversationalists. Developer marketing has to take the bad with the good. Get feedback

Tips for developer marketing: Start with GOOD; respond with truth; actively listen be flexible; get out of the way

API == assume positive intent

Duncan Johnston-Watt:

Hyperledger is a project of the Linux foundation; lots of fancy sponsors

A world of many chains. There will not be a chain of all chains. There will be many public chains and millions of private chains

Blockchain allows everyone to agree on who owns what (for example) rather than having central registry for the asset

Hyperledger fabric is permissioned blockchain network written in Go, chaincode in Go or Java

Cloudsoft's interest in Hyperledger is deploying managing the consensus network and deploying applications on it.

For example: Sotheby's want to run an auction. Cloudsoft could manage the deployment and management of Sotheby's auction code

Mike Zaccardo:

Now Mike Zaccardo is demoing the Sotheby's auction demo

Hyperledger fabric has a notion of containers that allow multiple blockchain apps to run on the Hyperledger fabric

demo shows transferring lots from one client to another, ensuring ownership

Duncan Johnston-Watt

Hyperledger is too big to be owned by a single entity. We should own it in common.

See http://www.cloudsoft.io/gethlf for more info


Sovrin Use Cases: Healthcare

An ambulance

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.

Patient Portals

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 prevents unwanted correlations by creating and managing one-to-one identifiers for each relationship. Pairwise pseudonymous identifiers reduce opportunities for surveillance.
  • 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.

If you're interested in knowing more, you can find more information in the library, ask questions in the forum, or contact us.


  1. An agent is a piece of software that acts on Maria's behalf and in accordance with rules she has created.


Sovrin Use Cases: Authentication

Login road sign

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.

Enrollment

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.

Login

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.


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


On Sovereignty

Parliament and Big Ben

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.


When People Can Share Verifiable Attributes, Everything Changes

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.


  1. See Self-Sovereign Identity and the Legitimacy of Permissioned Ledgers for more on the difference between self-sovereign identity systems and social login.
  2. See How Sovrin Works for details on how claims can be received, stored, and shared as verifiable disclosures.


TL;DR: How Sovrin Works

If you're too busy to read How Sovrin Works, here's a short animation that summarizes the post using my graphics. Thanks to Andy Tobin for putting it together.

Animation of How Sovrin Works