Alternatives to the CompuServe of Things

Acoustically Coupled Modem

In Peloton Bricks Its Treadmills, Cory Doctorow discusses Peloton's response to a product recall on its treadmills. Part of the response was a firmware upgrade. Rather than issuing the firmware upgrade to all treadmills, Peloton "bricked" all the treadmills and then only updated the ones where the owner was paying a monthly subscription for Peloton's service.

When I talk about Internet of Things (IoT), I always make the point that the current architecture for IoT ensures that people are merely renting connected things, not owning them, despite paying hundreds, even thousands, of dollars upfront. Terms and conditions on accounts usually allow the manufacturer to close your account for any reason and without recourse. Since many products cannot function without their associated cloud service, this renders the device inoperable.

I wrote about this problem in 2014, describing the current architecture as the CompuServe of Things. I wrote:

If Fitbit decides to revoke my account, I will probably survive. But what if, in some future world, the root certificate authority of the identity documents I use for banking, shopping, travel, and a host of other things decides to revoke my identity for some reason? Or if my car stops running because Ford shuts off my account? People must have autonomy and be in control of the connected things in their life. There will be systems and services provided by others and they will, of necessity, be administered. But those administering authorities need not have control of people and their lives. We know how to solve this problem. Interoperability takes "intervening" out of "administrative authority."

The architecture of the CompuServe of Things looks like this:

CompuServe of Things
CompuServe of Things Architecture (click to enlarge)

We're all familiar with it. Alice buys a new device, downloads the app for the device to her phone, sets up an account, and begins using the new thing. The app uses the account and the manufacturer-provided API to access data from the device and control it. Everything is inside the administrative control of the device manufacturer (indicated by the gray box).

There is an alternative model:

Internet of Things Architecture
Internet of Things Architecture (click to enlarge)

In this model, the device and data about it are controlled by Alice, not the manufacturer. The device and an associated agent (pico) Alice uses to interact with it have a relationship with the manufacturer, but the manufacturer is no longer in control. Alice is in control of her device, the data is generates, and the agent that processes the data. Note that this doesn't mean Alice has to code or even manage all that. She can run her agent in an agency and the code in her agent is likely from the manufacturer. But it could be other code instead of or in addition to what she gets from the manufacturer. The point is that Alice can decide. A true Internet of Things is self-sovereign.

Can this model work? Yes! We proved the model works for a production connected car platform called Fuse in 2013-2014. Fuse had hundreds of customers and over 1000 devices in the field. I wrote many articles about the experience, it's architecture, and advantages on my blog.

Fuse was built with picos. Picos are the actor-model programming system that we've developed over the last 12 years to build IoT products that respect individual autonomy and privacy while still providing all the benefits we've come to expect from our connected devices. I'll write more about picos as a programming model for reactive systems soon. Here's some related reading on my blog:

Our current model for connected devices is in conflict, not only with our ability to functions as autonomous individuals, but also our vision for a well-functioning society. We can do better and we must. Alternate architectures can give us all the benefits of connected devices without the specter of Big Tech intermediating every aspect of our lives.


Photo Credit: modem and phone from Bryan Alexander (CC BY 2.0)


Building an SSI Ecosystem: Health Passes and the Design of an Ecosystem of Ecosystems

Vaccination Card

In The Politics of Vaccination Passports, I wrote about the controversy surrounding proposals to require people to show proof of vaccination to travel–specifically fly. The worry is that once we get used to presenting a heath credential to travel, for example, it could quickly spread. Presenting an ID of some kind could become the default–with bars, restaurants, churches, stores, and every other public place saying "papers, please!" before allowing entry.

My personal take is that while I'd rather avoid that scenario, it is likely inevitable. And if that's true, I'd love to have it designed in a way that respects individual choice and personal privacy as much as possible. This is a tall order because getting the tech right is only the first step on a long road. The air travel industry is global, gargantuan, and incredibly decentralized. Building an interoperable system of travel passes requires not just an ecosystem, but an ecosystem of ecosystems.

Suppose Alice lives in Naruba and has been vaccinated against Covid. The local hospital where she was vaccinated has issued a credential to Alice with the data about her doses, the dates, vaccine batch numbers, and so on. Alice is traveling on business to the Emirate of Kunami which requires proof of vaccination. To fly, Alice must present a health pass to the gate agent who works for Kunami Air in the Soji airport. How does Kunami Air know they can trust a credential issued by a hospital they've never heard located in another country?

Building a global, interoperable health and travel pass network requires both technology and governance. This sort of situation isn't new. In fact, if we replaced "proof of vaccination" with "airline ticket" in the preceding scenario, we wouldn't think anything of it. Different companies from different countries have been figuring out how to interoperate and trust the results for decades, maybe centuries.

But doing that digitally, and quickly, is a big job with lots of moving parts. Below I take a look at a few of those parts and how they come together to solve the problem.

Good Health Pass Collaborative

The Good Health Pass Collaborative (GHPC) is an "open, inclusive, cross-sector initiative" of dozens of companies from the travel, health, and technology industries that is defining the blueprint for health and travel passes that are privacy-protecting, user-controlled, equitable, globally interoperable, and universally-accepted by international travel.

GHPC is very specific about what a "pass" is:

A credential to which data minimization and anti-correlation have been applied and any relevant travel data has been added so it includes only what a verifier needs to make a trust decision in a specific context (such as boarding a plane).

A credential could have lots of health and travel data. The pass contains just the data needed for a specific context.

GHPC published a set of ten principles in February to guide their work. These principles lay out a path that is consistent with self-sovereignty, respects individual autonomy, and promotes good privacy practices.

In June, GHPC published a blueprint that provides recommendations for building a good health pass. The challenge of meeting the principles, while exchanging health data across different industry sectors can be overwhelming. The blueprint provides specific guidance on how to meet this challenge without sacrificing the principles that make a health pass "good." The recommendations include designs for trust registries and frameworks, data and protocol standards, and other components for the global interoperability of COVID certificate ecosystems.

These efforts say what a good health pass is and give guidance for creating a credential ecosystem, but they don't create any such ecosystems. That's a job for other organizations.

The Global COVID Certificate Network

The GHCP Blueprint provides recommendations about trust registries and frameworks, data and protocol standards, and other requirements to create global, interoperability ecosystems for COVID certificates. The Linux Foundation's Global COVID Certificate Network (GCCN) "operationalizes and adapts the GHCP Blueprint recommendations for governments and industry alliances who are working to reopen borders." You can think of GCCN as an instantiation of the GHPC Blueprint.

Going back to our traveler, Alice, we can imagine that Naruba and Kunami both have national health systems that can follow the blueprint from GHCP. When Alice uses her health pass inside Naruba, it is reasonable to expect that Narubian businesses will know what a real Narubian health pass looks like and whether to trust it or not. To make this possible, the Narubian health ministry would determine what data a legitimate pass contains (e.g. its schema) and what forms it takes such as the paper design and digital format. The ministry could also determine who in Naruba can issue these health passes and even set up a registry so others in Naruba can find out as well.

This kind of one-size-fits-all, single-source solution can solve the local problem, but when Alice is interacting with people and organizations outside Naruba, the problem is much harder:

  1. Naruba and Kunami may have adopted different technologies and schema for the credential representing the health pass.
  2. Random organizations (and even people) in Kunami need to be able to establish the fidelity of the credential. Specifically, they want to know that it was issued to the person presenting it, hasn't been tampered with, and hasn't been revoked.
  3. In addition, these same entities need to be able to establish the provenance of the credential, specifically that it was issued by a legitimate organization who is authorized to attest to the holder's vaccination status.

This is where GCCN comes in. GCCN has three components:

  1. a trust registry network
  2. a certificate implementation toolkit
  3. a set of recommended vendors

The trust registry network and its associated protocol not only helps Naruba and Kunami each establish their own registries of authorized health pass credential issuers, but also enables a directory of registries, so an organization in Kunami can reliably find the registry in Naruba and discover if the issuer of Alice's credential is in it.

The toolkit provides several important components for a working ecosystem:

  • a template for a governance framework that governments and industry alliances can use to make their own policies.
  • schema definitions and minimum data sets for the credentials.
  • technical specifications for the software components needed to issue, hold, and verify credentials.
  • implementation guides and open source reference implementations.
  • guidance for creating the governance framework and technical implementation.

The vendor network provides a commercial ecosystem to which governments and industry associations can turn for support. The vendor network provides a set of organizations who have competence in building credential ecosystems. Over 25 separate companies and organizations support GCCN.

With all this, GCCN doesn't actually build the ecosystems. That falls to organizations who use GCCN to instantiate the framework provided by GHPC.

Building the Ecosystem

One of those organizations is Cardea. Cardea is a fully open-source and field-tested verifiable digital credential that meets the major requirements of the Good Health Pass Blueprint. Cardea was developed by Indicio and is now a community-led project at Linux Foundation Public Health (LFPH).

Cardea was trialed on the island of Aruba by SITA, one of the participating companies in the Cardea initiative. SITA is a good partner for this since they're responsible for a majority of airline industry IT systems. In the pilot, travelers could prove their Covid test status at restaurants and other tourist locations around the island. The combination of a good trust framework, and self-sovereign-identity-based credential technology allowed businesses to trust tourists' health information while preserving their privacy.

Another example of a working health pass credential ecosystem is the IATA Travel Pass. Travel Pass has been developed by the International Air Transport Association (IATA) and leverages verifiable credential technology from Evernym. The IATA Travel Pass is conducting initial pilots with over 50 airlines and the International Airlines Group (IAG).

A third example is Medcreds from ProofMarket. Medcreds uses the Trinsic API to provide service. MedCreds partnered with the Georgia Academy of General Dentistry to provide free COVID-19 test credentials to their providers and patients. MedCreds allows dentists to reduce the risk of spreading and contracting COVID-19 by knowing with greater certainty the status of a patient's most recent test.

Cardea, IATA Travel Pass, and Medcreds have tools for hospitals, labs, and other organizations who issue passes and for the airlines and other venues who verify them. All also have wallet apps for credential holders to use in receiving credentials as well as presenting the proofs that constitute the actual travel pass from those credentials. In addition, all three initiatives include governance frameworks that service their respective ecosystem.

Because all three are compliant with the GHPC's Blueprint and GCCN's architecture and guidance, the ecosystems they each create are part of the global ecosystem of ecosystems for health and travel passes. As more organizations, countries, and technical teams join in this, the global ecosystem of ecosystems will constitute the largest ever verifiable credential use case to date. The planning, design, and implementation show the level of effort necessary to create large credential ecosystems and provide a path for others to follow.

As I said in The Politics of Vaccination Passports, I'm persuaded that organizations like the Good Health Pass Collaborative and Global Covid Credential Network aren't the bad guys. They're just folks who see the inevitability of health and travel passes and are determined to see that it's done right, in ways that respect individual choice and personal privacy as much as possible.


Reciprocal Negotiated Accountability

3D Tin Can Phones

In Self-Sovereign Communication, Oskar Van Deventer, discusses the communications layer enabled by DIDs. This is the same layer that I've labeled the self-sovereign internet.

Oskar lays out nine requirements for self-sovereign communications (emphasis added):

  1. The communication channel shall be usable for machine-readable issuer-holder-verifier interactions .
  2. The communication channel shall be protected against eavesdropping, impersonation, message modification and repudiation.
  3. Parties shall be able to digitally find each other and to establish a communication channel.
  4. The communication channel between counterparties shall be persistent.
  5. The communication channel shall be intrinsically symmetrical.
  6. The communication channel shall not unnecessarily disclose information between counterparties or to third parties.
  7. The communication channel shall be unilaterally closable.
  8. The communication channel shall not depend on third parties more than needed.
  9. The communication channel shall enable compliance with legal requirements, like legal intercept.

I was pleased to see these principles laid out clearly because many of them are often discussed (including by me) as properties of DIDComm, without the precision Oskar imposes.

The last, as Oskar concedes, is likely to be the most controversial. Indeed, when I read it my first reaction was to start arguing. If complying with legal requirements means creating backdoors to DIDComm, I'd oppose it.

The problem with backdoors for complying with legal requirements is that now developers and cloud operators are left with the task of determining who the good guys are. The whole point of decentralized communication systems is to avoid the kind of centralized, single-point-of-failure that backdoors imply.

Reciprocal Negotiated Accountability

In Reciprocal Negotiated Accountability, Daniel Hardman proposes an alternative to backdoors.

Daniel's idea is to combine two capabilities to create a decentralized system for enabling accountability.

The first is digital watermarks and data terms of service. The watermark is a cryptographically signed addition to the original document that states the terms behind the sharing. For example, a sales agreement could include data sharing terms that state the recipient may not disclose named aspects of the document except under legal subpoena.

The second is provisional anonymity where identifying information is encrypted and the encrypted packaged is shared with the recipient. The keys to decrypt the identifying information are shared with a third party under escrow with legal requirements that the keys only be reveled to the recipient under specific conditions.

Daniel combines these into a decentralized system of opt-in agreements between parties that are tailored to the context and circumstances of the specific communications channel and data sharing. The legal agreement defines the requirements that must be met for access.

Daniel calls this "reciprocal negotiated accountability" because both parties negotiate an agreement about how shared data will be treated.

Daniel's solution won't make those who wish for unfettered access to communications channels happy. But it represents an alternative to backdoors that solves many of the problems backdoors present while protecting privacy for legitimate uses–as negotiated by the parties sharing data.


Photo Credit: 3D Tin Can Phones from Chris Potter (CC BY 2.0)


The Self-Sovereign Internet

DIDs and DID-based Communication or DIDComm form the second layer of the SSI stack, providing a secure communications layer for the exchange of identity information via verifiable credentials. But, because of it's flexibility and the ability to define protocols on top of DIDComm messaging, it promises to be as important as the identity layer it enables.

Autonomic Identifiers

The foundation of the self-sovereign internet is built on autonomic identifiers. I'm going to speak about Peer DIDs here, but KERI and other systems provide autonomic identifiers that serve just as well.

Identity systems provide the means to remember, recognize, and rely on other parties in a relationship. To do so, they use identifiers, convenient handles that name the thing being remembered.

Identifiers are issued to or created by a controller (e.g. Alice) who, by virtue of knowing the authentication factors (e.g. password, key fob, cryptographic key), can make authoritative statements about the identifier (e.g. claim it by logging in).

Bindings between Alice, a Peer DID, and the public key it points to.
Bindings between Alice, a Peer DID, and the public key it points to. (click to enlarge)

In an autonomic identity architecture, the controller, Alice, generates a public-private key pair, derives a globally unique identifier, and shares the identifier and the currently associated public key with others to create relationships. Alice uses her private key to sign statements that authenticate herself and authorize use of the identifier. A digital signature also provides the means for Alice to cryptographically respond to challenges so she can prove she controls the identifier. These self-authentication and self-authorization capabilities make the identifier self-certifying and self-managing, meaning that there is no external third party, not even a ledger, needed for Alice to manage and use the identifier and prove to others the integrity of the bindings between herself and the identifier.

Any entity can create and establish control over an identifier in a manner that is independent, interoperable, and portable without recourse to any central authority. Autonomic identity systems rely solely on self-sovereign authority.

Alice can create as many Peer DIDs as she needs, each pointing to a public key that Alice controls. Alice can rotate the keys underneath the Peer DID anytime without impacting the identifier or her ability to prove she controls it. She keeps track of these key events in a key event log. The key event log is a chain of signed change records that can be cryptographically verified. Alice can use it to prove the provenance of her control of the identifier from its inception to the present.

Peer DID Exchange

Alice can exchange Peer DIDs with Bob to create a relationship. Because DIDs are associated with public keys, the exchange ensures that Alice and Bob have each other's public keys. They share key event logs (using a CRDT) for each identifier. If either updates the keys associated with the DID, the other is informed of change.

Alice and Bob exchange Peer DIDs to create a relationship
Alice and Bob exchange Peer DIDs to create a relationship (click to enlarge)

Having exchanged DIDs, Alice and Bob can now exchange signed and encrypted messages with each other using DIDComm. DIDComm is a messaging protocol that rides on top of this Peer DID relationship.

Alice and Bob use DIDComm to exchange messages
Alice and Bob use DIDComm to exchange messages (click to enlarge)

Alice and Bob are using digital wallets to store the keys (and manage their key event logs). The DIDComm messages are being exchanged using software agents that understand the DIDComm messaging protocol and use the keys in the wallet.

Alice can have DID-based relationships with multiple people, organizations, and even things. Each relationship includes a secure DIDComm-based messaging capability.

Some of Alice's Relationships
Some of Alice's Relationships (click to enlarge)

This network of DID-based relationships forms an overlay network. An overlay network comprises virtual links that correspond to a path in the underlying network. Secure overlay networks rely on an identity layer based on asymmetric key cryptography to ensure message integrity, non-repudiation, and confidentiality.

DIDComm messaging has several important properties that, taken together, provide a generative, secure network overlay for the Internet.

  1. Secure - DID-based relationships are mutually authenticating.
  2. Private - messages can be encrypted.
  3. Interoperable - messages can be exchanged between any agents that support the DIDComm protocol.
  4. Transport-agnostic - DIDComm does not rely on any specific network technology–it is as happy on Bluetooth as on TCP/IP or anything else.
  5. Extensible - DIDComm is designed to support other protocols riding on top of its general secure messaging infrastructure.

Protocological Power

The extensibility of DIDComm is one of its most powerful features because it makes DIDComm generative–just like the Internet itself.

Protocols describe the rules for a set of interactions, specifying the kinds of interactions that can happen without being overly prescriptive about their nature or content. Protocols formalize workflows for specific interactions like ordering food at a restaurant, playing a game, or applying for college.

The Hyperledger Aries project has a collection of RFCs that describe protocols for DIDComm messaging. While we have come to think of SSI agents being strictly about exchanging peer DIDs to create a connection, request and issue a credential, or prove things using credentials, these are merely specific protocols defined to run over the DIDComm messaging protocol. The follow specifications describe the protocols for these three core applications of DIDComm:

Dozens, even hundreds, of other protocols are possible.

Daniel Hardman has provided a comprehensive tutorial on defining protocols on DIDComm. One of the Aries RFCs is sample protocol definition of a protocol for playing TicTacToe over DIDComm messaging.

Alice and Bob play Tic Tac Toe
Alice and Bob play Tic Tac Toe (click to enlarge)

The TicTacToe protocol defines types of messages that are allowed, the game state, and what messages are allowed in each game state. I recommend it as a way to understand DIDComm protocols since it's familiar and easy to understand. Bruce Conrad who works on picos with me implemented the TicTacToe protocol for picos, which act as DIDComm agents.

Generativity

In 2005, Jonathan Zittrain wrote a compelling and prescient examination of the generative capacity of the Internet and its tens of millions of attached PCs. Zittrain defined generativity thus:

Generativity denotes a technology's overall capacity to produce unprompted change driven by large, varied, and uncoordinated audiences.
From The Generative Internet
Referenced 2021-06-14T13:41:18-0600

Generative systems use a few basic rules, structures, or features to yield behaviors that can be extremely varied and unpredictable. Zittrain goes on to lay out the criteria for evaluating the generativity of a technology:

Generativity is a function of a technology's capacity for leverage across a range of tasks, adaptability to a range of different tasks, ease of mastery, and accessibility.

I have made the case elsewhere that the self-sovereign internet meets Zittrain's criteria for generativity.

Generativity provides decentralized actors with the ability to create cooperating, complex structures and behavior. No one person or group can or will think of all the possible uses, but each is free to adapt the system to their own use. The architecture of the self-sovereign internet enables adaptation of DIDComm messaging to any circumstance.

I am bullish on the possibilities for verifiable credentials to allow people to live digital lives with dignity and effectiveness, addresses the problems of social inclusion, and support economic equality to everyone around the globe. With all that, I believe the possibilities for the self-sovereign internet are even larger, promising a more secure and private, albeit no less useful, internet for tomorrow. DIDComm may turn out to be the most important part of self-sovereign identity.


Building an SSI Ecosystem: MemberPass and Credit Unions

My work in self-sovereign identity began with credit unions. It was March of 2016 and I was having a conversation with Timothy Ruff and Jason Law of Evernym about how difficult it would be to get a multi-sided verifiable credential market going. Timothy's response was "You've got to come to Denver next week!" I showed up at a hotel ballroom in Denver to find almost 100 executives from credit unions all across the US clamoring (no, really) for verifiable credentials. I was hooked.

Over five years later, with a few fits and starts, credit unions are deploying credential-based identification systems for their members. To date, seven credit unions have issued credentials to over 22,000 members or about 2% of the eligible membership of those same credit unions.

Why do credit unions care? One word: fraud. Or maybe two: fraud reduction.

It's All About Authentication

Credit unions and their members face the threat of fraud on all sides. And credit unions employ lots of tools to fight it. But ultimately, the problem comes down to the member and credit union authenticating each other. The problem is that doing this securely annoys people.

None of us like to spend a minute–or more–answering security questions at the start of a customer service call. And SMS-based multi-factor authentication is becoming increasingly fraught. Is that text you just got warning you about fraudulent charges on your credit card really from the credit union? It's hard to tell.

Early on, a few intrepid people in the credit union industry recognized that self-sovereign identity (SSI) offered a way out of this mess. Credit unions are often small and band together to form credit union service organizations (CUSOs) that provide them the services they can't build on their own. They formed a CUSO called CULedger (later renamed Bonifii) to make that vision a reality. Bonifii offers an SSI-based solution for credit unions called MemberPass.

MemberPass Trust Triangle
MemberPass Trust Triangle (click to enlarge)

MemberPass allows credit unions to offer their members a verifiable credential that they can use to prove their member number to the credit union. Initially, the MemberPass credential schema is fairly simple, containing only the following attributes:

  • CredentialDescription
  • CredentialId
  • MemberSince
  • MemberNumber
  • CredentialName
  • Institution

Of course, credentials could be much more complicated than this, but this simple schema is sufficient for a member to prove they are in possession of a credential for a specific member number. Members use the MemberPass wallet to connect to the credit union and hold the MemberPass credential.

MemberPass relies on Bonifii's partner Evernym for technical services. Credit unions integrate their back office applications with the MemberPass platform at Bonifii which relies on cloud services provided by Evernym.

MemberPass Architecture
MemberPass Architecture (click to enlarge)

Growing Adoption

While much of the response to fraud is reactive, MemberPass is proactive. Credit unions work to get members using MemberPass as an active measure to prevent fraud. As I said earlier, to date, seven credit unions have issued credentials to over 22,000 members or about 2% of the eligible membership of those same credit unions. Julie Esser, Bonifii's SVP of Client Engagement expects the number of credit unions using MemberPass to more than double in 2021 and the number of eligible members to jump by almost an order of magnitude.

Increasing the number of credit unions using MemberPass is the first segment in the adoption journey. MemberPass is already integrated with some of the back office platforms that credit unions use, easing the journey. Bonifii is also working with third party integrators to ensure they're technically ready to do the integrations for the rest.

The second segment of the adoption journey is increasing the percentage of members enrolled from the current 2% to 5% and then 10% over the next year. To do that, Bonifii works with credit unions to train frontline staff in the enrollment process. Early enrollments are happening in the branch. But enrollment can also happen on the phone. The phone enrollment process takes 3-5 minutes. The member receives the MemberPass credential while they're on the phone so the call center agent can help with any problems.

First Education Credit Union's President, Jim Yates, says that most new members are signing up. Signing up the larger body of existing members will likely require a move to self-enrollment since many never come into a branch. Self-enrollment is possible within the authenticated context of the credit union's web site. If the member chooses to enroll, they'll be directed to download the MemberPass app and then scan a QR code. This establishes a secure DIDComm connection. The credit union can then make the MemberPass credential offer. UNIFY Financial Credit Union allows self-enrollment now their online banking application.

Once a member is enrolled, the credential can be used in-person at the branch, in the drive-thru lane (with or without interactive teller machines), on the phone, or online. This is not only more secure, but often more convenient as well. For example, someone going through the drive-thru lane can authenticate without passing plastic credentials back and forth. Logging in no longer involves receiving a text and then typing in the code. And calling into the call center no longer requires answering a series of questions of questionable value.

Instead, a push notification on the member's phone asks them to verify they're the one transacting with the teller, call-center employee, or web site. The member clicks "accept" and they're done. Behind the scenes, this is a proof request made through the already established DID connection. By clicking "accept", the member is responding to the request and proving attributes from their MemberPass verifiable credential.

And it's a win for the credit unions too. Desert Financial's EVP Ron Amstutz says it's an important step in reducing fraud. Desert Financial knows they're talking to a member and the member knows they're talking to Desert Financial. Desert Financial is initially recruiting members for the program who call into the call center frequently since that's a big pain point.

Zach Eychaner from 4Front Credit Union says the call center is the first focus for them as well. They are able to shave 30-40 seconds off of each call. With 20,000 calls a year, that time adds up.

The Road Ahead

The MemberPass credential with its limited set of attributes is just a start. The future could include using MemberPass at an ATM or to open account at another credit union. Bonifii's Esser says "Once they get used to MemberPass, members will expect to use it everywhere."

Here are a few things that credit unions could do to make more use of credentials and SSI:

  • As we've seen, the current MemberPass schema is very simple–it doesn't even include the members name. A schema with more information in it–information that's been validated by the credit union–would make it usable outside the narrow use case of authenticating the member to the credit union and offer more value to members.
  • Credit unions could offer a pre-approval credential for loans that the member could hold and then use when they were ready for a loan.
  • Bonifii could issue a credential for KYC use at credit unions, banks, and in other financial transactions.
  • Shared branching is a hot topic in the credit union industry right now. Twenty-three thousand branches looks like a mega bank. But the identity fraud problems are even harder to solve across credit unions. MemberPass can help make shared branching a reality.
  • Employers and employee groups historically make up the foundation of credit unions. Credit unions could partner with employers to create a credential ecosystem.
  • The DIDComm connection is a secure messaging system. Credit unions can use this secure channel for sending notifications to members, or for customer service.

The lessons from MemberPass and the credit union industry are important for anyone launching a credential effort:

  1. Pay attention to the process and tailor it to your industry. Fraud reduction is the focus. Credit unions are evolving their enrollment process and targeting the parts of the process where they can get the most leverage.
  2. Start simple. MemberPass is a simple credential but it serves an important purpose: reliably authenticating the member to reduce fraud.
  3. Plan for the future, but don't get distracted. There are a thousand use cases for credentials in financial services. Get some early wins with your simple "MVVC", minimum viable verifiable credential, before you move on to the rest.
  4. Stay the course. Building a credential ecosystem is more about human factors than technology. In the words of Julie Esser "The technology is baked." But that's just the start. The MemberPass ecosystem is complicated by regulation, scale, and a decentralized collection of players, each with their own problems and goals. Building an ecosystem in this environment isn't easy, but it's where the reward is.

The Covid-19 pandemic caused credit union branches to close and call center volume skyrocketed and drive-thru lanes were crowded. As a result, fraud also increased. This created a heightened awareness of the importance of digital identity across the credit union industry. But while the pandemic might have pushed things along, many in the credit union industry had already concluded that self-sovereign identity was an answer that was not only flexible, interoperable, and secure, but also one that was aligned with the values of the member-owned cooperatives that make up the credit union industry.


SSI Interaction Patterns

Last year, I wrote about how digital relationships are operationalized in response to a post from Doc Searls about SSI wallets. The wallet (and the agent it is paired with) is a key player in SSI workflows. A recent exchange with the good folks at TechVision Research made me realize that I hadn't ever written about the patterns that an SSI wallet uses to realize operational digital relationships. Today I'm going to take a stab at three simple authentication and authorization patterns in SSI to show the interactions necessary to accomplish these foundational workflows. Finally, I'll show how all three are just specializations of the standard verifiable credential exchange pattern.

DID Authentication Pattern

The simplest authentication pattern uses decentralized identifiers (DIDs) as autonomic identifiers to establish a peer relationship. Because of their mutual authentication capabilities, DID relationships can be used for authentication.

Simple DID Authn Interaction Pattern
Simple DID Authn Interaction Pattern (click to enlarge)

This pattern has two parties:

  • Alice has an SSI wallet on her mobile phone.
  • Bravo Corp has an enterprise wallet tied to an IAM system that is protecting some resource.

The interaction pattern has the following steps:

  1. Alice and Bravo establish a Peer DID relationship (blue arrow). This means that they each generate a Peer DID and send it to the other, along with the associated public key. These identifiers are self-certifying and each party can use the information associated with the DID to authenticate the other.
  2. Alice tries to access the protected resource (red arrow). The request is intermediated by Bravo's IAM system. As part of this request, Alice makes her DID known. There are a number of sub-scenarios for the different ways this may happen. For example, she could scan a QR code or enter an associated human-readable identifier.
  3. The IAM system, working in concert with Bravo's enterprise wallet, issues a DID Auth challenge to Alice's wallet through her phone.
  4. Alice is notified by her wallet of the challenge and approves the response from her wallet to Bravo.
  5. Bravo verifies Alice's response.

A few things to note about this interaction:

  • Because Alice and Bravo are using Peer DIDs, no ledger is involved in the authentication. In a Peer DID relationship, both parties keep the other informed of relevant key events (e.g. key rotation) and store that information in a cryptographic key event log.
  • Any authorization would have to be done based on information the IAM system has from another source. For example, if the Peer DID relationship were established within a different authenticated context, Alice could have been assigned a group for RBAC or other attributes could have been associated with Alice's DID within Bravo's IAM system.
  • The interaction pattern shown here is leaves out a number of details. Markus Sabadello identifies ten different variations of this pattern in his talk Introduction to DID Auth for SSI.

Single-Party Credential Authorization Pattern

While the DID Authn pattern is simple, it is not as flexible as we need in some situations. For more complicated scenarios, we can use verifiable credentials. The first scenario we'll consider is where the same organization is issuing and verifying the credential.

Single-Party Credential-Based Authn Pattern
Single-Party Credential-Based Authn Pattern (click to enlarge)

The parties in this scenario are the same: Alice and Bravo Corp.

The interaction pattern proceeds as follows:

  1. Since Bravo Corp will be issuing a credential, they write a Public DID and credential definition to the ledger. They might also write a schema and revocation registry, if necessary.
  2. Alice and Bravo establish a Peer DID relationship (blue arrow). Note that the DID that Bravo uses for this relationship is not the public DID created in (1), instead Bravo creates a Peer DID especially for the relationship with Alice.
  3. Bravo issues a credential to Alice (green arrow). The nature, content, and context of this credential issuance depend on Bravo and Alice's specific needs. Bravo is the credential issuer and Alice is the credential holder.
  4. Alice tries to access a protected resource (red arrow). The request is intermediated by Bravo's IAM system. Like the DID Authn pattern, the IAM system is working in concert with an enterprise wallet.
  5. Bravo is using a policy-based access control (PBAC) system that relies on knowing attributes about Alice. The IAM system makes a credential request to Alice that asks for specific attributes based on the attributes needed by the policy for the resource Alice is accessing.
  6. Alice sees the request and authorizes her wallet to issue a proof of attributes based on the credential she holds. The response contains only the attributes that Bravo needs, not the entire credential to minimize the information that is shared.
  7. The PBAC system uses the attributes in the proof presentation to authorize Alice's access.

A few things to note:

  • Bravo does not need to access the ledger to verify the credential since they already know the information necessary to perform the validation since it's their credential. Even so, Bravo writes the public DID and credential definition to the ledger so that Alice can present the credential to others who can verify it, supporting use cases beyond Bravo's.
  • Using a credential held by Alice to validate her authority to access the protected resource is more flexible for Bravo, and potentially more reliable, than a centralized attribute store. Rather than building a central attribute store and linking every system in the enterprise to it, each system can stand alone from the central store and make decisions based on the policies in place for that system.
  • Astute readers will read the last bullet and think "but don't they all have to be linked to the same digital wallet to take advantage of the Peer DID relationship?" The answer is "no." Each service can have its own Peer DID relationship with Alice, verify the attributes from the credential, and know it's Alice. The only thing they need to know is the public DID their organization uses and the credential definition for the credential.

Multi-Party Credential Authorization Pattern

We can extend the single-party pattern, to include multiple parties. In this pattern, one entity, Bravo Corp, is issuing credentials, but another entity, Certiphi Corp, is verifying the credential and using its attributes to authorize Alice's access to a resource.

Multi-Party Credential-Based Authn Pattern
Multi-Party Credential-Based Authn Pattern (click to enlarge)

The interaction proceeds as follows:

  1. Since Bravo Corp is issuing a credential, they write a Public DID and credential definition to the ledger. Again, they might also write a schema and revocation registry, if needed.
  2. Alice and Bravo establish a Peer DID relationship (blue arrow).
  3. Bravo issues a credential to Alice (green arrow).
  4. Alice and Certiphi establish a Peer DID relationship.
  5. Alice tries to access the protected resource (red arrow) at Certiphi. The request is intermediated by Certiphi's IAM system.
  6. Certiphi is using a policy-based access control system so, the IAM system makes a credential request to Alice that asks for the specific attributes needed by the policy for access to the resource.
  7. Alice sees the request and authorizes her wallet to issue a proof of attributes based on the credentials she holds. The wallet automatically chooses the credential from Bravo since it has the attributes needed to satisfy Certiphi's request.
  8. Certiphi cryptographically validates the fidelity of the proof to ensure it's from Bravo, is about Alice, hasn't been tampered with, and hasn't been revoked. They might also need to validate the provenance of the attributes in the proof. Certiphi is the credential verifier in this pattern.
  9. The PBAC system uses the attributes in the proof presentation to authorize Alice's access.

A few things to note:

  • The DID relationship Alice and Certiphi create in (4) could be ephemeral, it needn't be permanent unless the parties need it to be.
  • There is no direct connection or link between Bravo Corp and Certiphi Corp. They needn't have any pre-existing business or technical relationship. Certiphi needn't connect to a Bravo Corp API.
  • The primary difference between the single-party and multi-party patterns is step (8), checking the fidelity and provenance of the credential. The fidelity can be done automatically using cryptography. Determining provenance is not a trivial thing since it involves Certiphi determining they can trust attributes attested by Bravo. This is a governance issue, not a technical one.
  • The governance issue could be simple or complex. Perhaps Bravo is known to Certiphi (e.g., a local business next to a large university). Certiphi might ask Bravo to prove things about itself using credentials issued to Bravo by someone Certiphi already trusts (e.g., the government). Bravo and Certiphi might already be part of some established governance framework (e.g., a university accreditation organization).

Generalized Trustworthy Data Transfer Pattern

Authentication and authorization are table stakes for any identity interaction. The general data transfer pattern moves beyond simple authentication and authorization patterns to using identity data in workflows.

Credential-Based Data Transfer Pattern
Credential-Based Data Transfer Pattern (click to enlarge)

In this pattern, all of the interactions are identical to the pattern for multi-party authorization in the last section with a few exceptions:

  1. Alice is accessing a web service that needs data to proceed in (5) rather than a protected resource.
  2. The web service uses the data from the proof presentment as part of its workflow (e.g. fill out a form).

We can view all of the previous patterns as specializations of this pattern:

  • The Peer DID relationship provides a mutually authenticated communications channel in every case that can always be used to know that you're talking to the entity with whom the relationship was originally established–the core requirement for any authentication.
  • Transferring attributes using verifiable credentials for PBAC is just a special case of transferring attribute data in a trustworthy manner. The difference is the end-use of the attributes: the PBAC system or some other service.
  • There's no need for the data transferred in the general pattern to come from a single credential. In fact, the service can ask for attributes without knowing what credentials Alice holds. Alice's wallet will match the requested attributes to the credentials Alice holds. Alice can choose which credentials to use for specific attributes (e.g. date of birth) if she wants.
  • While the figure shows Alice accessing a web service, this can be further generalized beyond the web. Any data transfer for an online workflow can happen using verifiable credentials.
  • While this pattern involves Alice and two organizations, there's no reason why people can't be credential issuers and verifiers. Indeed, any party in these diagrams could play any of the roles.

Viewing traditional IAM functions like authentication and authorization as special purpose data transfers broadens SSI significantly beyond what we have traditionally seen as "digital identity." The uses for verifiable credentials are vast and include many things we may not think of as "credentials". While this expanded view of digital identity may make some uncomfortable, I think it is perfectly aligned with my belief that we build identity systems to manage relationships, not identities. Every relationship is unique. Flexible, trustworthy digital credentials serve that uniqueness and introduce the means of moving digital identity beyond just authentication and authorization.


Photo Credit: Phone Icon from Fast Icon Design (Linkware)


Comparing X.509 Certificates with SSI

I sometimes talk to people who ask "Why do we need SSI? What's wrong with X.509 certificates?" Here's some thoughts.

X.509 is a standard that defines the format for public key certificates. Public key certificates can be used to tie a public key to other information. The most common use, by far, is TLS/SSL, the basis for trust in HTTPS, the protocol that secures the Web. In TLS, the certificate binds a public key to a domain name (and perhaps other information).

The first challenge for many people is determining whether X.509 certificates are more like verifiable credentials or DIDDocs. This is understandable since X.509 combines the functions of these two separate SSI standards. X.509 certificates themselves are like DIDDocs in that they bind information to a public key. But the hierarchical public key infrastructure (PKI) of X.509 is meant to attest to the veracity of the the X.509 certificate. And X.509 extensions allow other information to be included. So, X.509 certificates also bind the public key (as an identifier) to real-world attributes. DIDDocs don't have anything like PKI. Rather SSI uses verifiable credentials to assert information about a decentralized identifier in a trustworthy way.

Another important difference between X.509 certificates and DIDDocs is that the primary purpose of the DIDDoc is to bind the public key in the DIDDoc to a decentralized identifier, or DID, whereas X.509 certificates can bind the public key to a subject name and other information like a domain name. Extensions to the certificate allow it to also bind the public key to other information. The important distinction is that the DID is required and represents a unique name for the DIDDoc. A DID must have some means of resolving to the DIDDoc1. The DID provides a level of indirection to the public key. Consequently, the public key associated with a DID can be rotated without changing the DID and so it can be used as a permanent identifier. I won't get into the details around how this is done securely, but you can read far more detail at The Architecture of Identity Systems if you're curious.

The veracity of an X.509 certificate is usually determined from the strictly hierarchical public key infrastructure (PKI). For example, when you visit a web site, your browser uses the X.509 certificate from the web site to establish a secure connection. If you click on the lock, you'll see information about that certificate. The web site's certificate was signed by some organization that is attesting to the information in the certificate. You can use the certificate of the signing organization to know its public key to do the check. But how do you know that certificate is valid? It's signed using the private key whose public key is in yet another certification, and so on. Eventually this has to stop and it does when you get to a certificate that was stored in browser when it was built. CA Browser Forum is the organization that determines what certificates are worthy to be inside browsers.

Showing the Certificate Hierarchy in Brave
Showing the Certificate Hierarchy in Brave (click to enlarge)

In contrast, the veracity of the DID and associated DIDDoc is ascertained by a heterarchical method. The DID and DIDDoc are self-asserted and self-certifying. You can use cryptographic means to determine that the binding asserted in the DIDDoc has not been tampered with, but the DID infrastructure itself does nothing to tell you who or what the DID is bound to in a verifiable way. For that, we use verifiable credentials.

Suppose the DID in question is one Alice generated to give to Bravo Corp, her mortgage processor. Bravo knows nothing about the DID they've received except that it's bound, in the associated DIDDoc, with a specific public key (and possibly an endpoint of some kind). They ask Alice to prove things about herself as part of the mortgage application process and over time learn quite a bit. Alice proves her name and date of birth using a verifiable credential representing her driver's license. She proves her income using a verifiable credential from her employer, and her banking information using a verifiable credential from her bank. The information in each of these verifiable credentials is attested by its issuer: the DMV, the employer, and the bank. Bravo's reasons for trusting these organization are up to Bravo:

  • The may be well known.
  • Bravo may have a prior relationship with them.
  • Bravo might ask them to prove things about themselves (using verifiable credentials, of course).
  • Or they may belong to a trust framework that Bravo can use access publicly.

Furthermore, zero-knowledge proofs (ZKPs)2 allow Alice to combine the attributes in these various credentials (and others) in a way that only discloses what Bravo is asking for and nothing more. And her digital wallet was able to do this for her automatically without Alice having to pick and choose the various attributes from various credentials herself. The proof shows that the information from these three credentials is all bound to the person who controls the DID that Alice gave to Bravo. The proof also shows that these credentials have not been revoked.

You can imagine Alice having X.509 certificates from the DMV, her employer, and her bank that attest these same things (through X.509 extensions). She would also have a personal certificate with her public key that she used to anchor each of these other certificates. The X.509 certificates are not linked in any way other than Alice's public key. She has to use the same public key in all of them so they can be correlated. She uses her personal certificate to prove she's in control of the public key she provides to the DMV, employer, and bank. If she changes her public key, so has to get new certificates. This is a good example of the dual nature of X.509 certificates. Alice's personal certificate looks like a DIDDoc, but the certificates with extensions look like verifiable credentials.

There's no easy way for Alice to restrict what attributes she shares when she shares these certificates. She has to share the entire certificate. Bravo would trust these certificates in the same way your browser does, by following the chain to some smallish set of trusted certificate authorities fo each kind of certificate (driver's license, employer, or bank). Bravo would also check certificate revocation lists for each certificate to ensure they're still valid.

The advantage of X.509 certificates is that the technology, processes, and governance behind them are well-known and understood. No small thing. The public key infrastructure is well developed with a long history of securely communicating trustworthy public keys. DIDs and verifiable credentials are relatively new. Although standards, open source code, and multiple vendors exist, they are unproven compared to X.509.

So, why do something new? DIDs, DIDDocs, and verifiable credentials have several advantages over X.509 certificates:

  1. DIDs are more secure. DIDs allow public keys to be rotated in a trustworthy manner. Consequently, Alice can rotate the key underlying the DID at will without having to get new credentials. The identifier lives as long as Alice needs it to. Alice won't be tempted to hold onto a potentially comprimised key because she's worried about the inconvenience.
  2. SSI uses the right tools for each part of the process. The SSI architecture cleanly separates providing an identifier for Alice from proving things about Alice. The binding between the DID and its associated public key can be verified cryptographically without relying on a hierarchical chain of authorities. The fidelity of the credential exchange can be verified cryptographically using information in a public credential registry (often a ledger of some sort). This separation allows the methods and tools to be crafted to the needs of each kind of document.
  3. Verifiable credentials minimize information disclosure. Sharing only what's necessary protects Alice's privacy. This Webinar on ZKP-oriented Credentials from Daniel Hardman is an excellent, approachable tutorial on the many benefits of ZKPs for credential exchange.
  4. SSI data sharing UX is safer. ZKPs provide convenience for Alice saving her time, and reducing the chance of her oversharing through human error (i.e. they are safer from a privacy perspective).
  5. SSI has a consistent UX. SSI wallets and agents provide a good user experience for managing relationships, storing credentials, and responding to proof requests. As far as I know, X.509 certificate wallets do not exist as such, so they would need to be developed to provide a comparable user experience.
  6. Verifiable credentials provide better interoperability. Alice is able to use multiple credentials from different issuers and prove things to many verifiers because of standards, not just for data formats, but also protocols for issuace and presentment. I know of no standards for how X.509 credentials can be used to prove the kind of information in the mortgage example in an interoperable way. They have been around for over 40 years and yet they are almost exclusively used for TLS and nothing else.

The high-level goals of X.509 certificates are similar to those of DIDs and verifiable credentials. But DIDs and verifiable credentials represent an innovation that takes learnings from 40 years of experience and new developments in cryptography into account to provide a better, more flexible solution to the problem of exchanging data in a trustworthy way. SSI in the form of DIDs and verifiable credentials promise a global, interoperable data exchange metasystem that is cryptographically sound with an excellent user experience.


Notes

  1. The resolution need not be global or public. For Peer DIDs, the resolution is local.
  2. Note that not all credential exchange methods use ZKPs. They should.


Life-Like Anonymity and the Poison Web

Poison Apple Sugar Cookies

Doc Searls published a piece last week entitled "How the Cookie Poisoned the Web". Doc points to various privacy ills of Web 2.0 and in each instance says "Blame the cookie." Doc's larger point is that the web started out as a peer-to-peer publishing system that was wholly decentralized and gave everyone equal voice.

Doc continues:

But gradually a poison disabled personal agency. That poison was the cookie.

Very few web sites in the early web had identity systems. For the peer-to-peer sharing of documents and discovery via embedded links, none were needed. HTTP, the foundational protocol of the web is stateless, meaning the HTTP server does not know whether any two requests are related to each other.

Stateless is fine for document sharing and linking using hypertext. But it makes building a shopping cart really hard. Back in the mid-90's figuring out how to build a functional shopping cart was on everyone's mind, mine included. I was the cofounder and CTO of an early ecommerce site, imall.com. Without changing HTTP, the most promising strategy was to include a correlation identifier in all the links generated by the site, so we'd know who was making the request. But this was buggy and caused lots of customer support issues.

A correlation identifier is a unique string that can be used to link requests. Ultimately, the the HTTP community added a correlation identifier called a "cookie" (which took its name from a correlation identifier used in unix). HTTP cookies are generated by the server and stored on the browser. Whenever the browser makes a request to the server, it sends back the cookie, allowing the server to correlate all requests from that browser.

That all sounds innocuous enough and in theory, it is. But the devil is in the details. If I'm shopping on imall.com, I want the site to keep track of me because that provides utility and convenience. But it turns out that most web pages are not a single chunk of HTML that the server sends down. They have lots of other things, like javascript files and images, embedded in them too. These other things don't have to be from the same server. Each of those servers can set a cookie as well. And since they know where they were linked from, they can correlate activity across multiple websites.

This is how (simple) ad tracking works. When you see an ad on web site A, it's being served from a server owned by an ad company that web site A has an agreement with. The ad server plants a cookie in your browser. Now you visit web site B that also includes ads from the same ad server. Your browser dutifully reports the ad server cookie back to the ad server along with the information that the ad was on web site B. The company running the ad server now knows you were on web site A and web site B (along with lots of other metadata). Rather than correlating requests on a single web site, they are using cookies to correlate your activity across the web.

This is the poison Doc is talking about. The web cookie, as designed, goes well beyond correlating activity on a single web site for purposes of creating some utility like a shopping cart or a chat server. The web cookie allows correlating activities of people across the web. And it doesn't stop with your browsing history. The ad company starts knowing other things about you (because the web sites you visit tell them) and soon they can develop a comprehensive dossier.

Like-Like Anonymity and the Administrative Internet

In real life, we often interact with others—both people and institutions—with relative anonymity. For example, if I go the store and buy a coke with cash there is no exchange of identity information necessary. Even if I use a credit card it's rarely the case that the entire transaction happens under the administrative authority of the identity system inherent in the credit card. Only the financial part of the transaction takes place in that identity system. This is true of most interactions in real life.

In contrast, in the digital world, very few meaningful transactions are done outside of some administrative identity system. There are several reasons why identity is so important in the digital world:

  • Continuity—While web sessions can be pseudonymous, as we've seen, they are often correlated across multiple independent sessions and devices using an authenticated correlation identifier. This allows, for example, the customer to have a shopping cart that not only persists across time but also on different devices.
  • Convenience—So long as the customer is authenticating, we might as well further store additional information like addresses and credit card numbers for their convenience, to extend the shopping example. Storing these allows the customer to complete transactions without having to enter the same information over and over.
  • Trust—There are some actions that should only be taken by certain people, or people in certain roles, or with specific attributes. Once a shopping site has stored my credit card, for example, I ought to be the only one who can use it. Identity systems provide authentication mechanisms as the means of knowing who is at the other end of the wire so that we know what actions they're allowed to take. This places identifiers in context so they can be trusted.
  • Surveillance—Unfortunately, identity systems also provide the means of tracking individuals across transactions for purposes of gathering data about them. This data gathering may be innocuous or nefarious, but there is no doubt that it is enabled by identity systems in use on the internet.

In real life, we do without identity systems for most things. You don't have to identify yourself to the movie theater to watch a movie or log into some system to sit in a restaurant and have a private conversation with friends. In real life, we act as embodied, independent agents. Our physical presence and the laws of physics have a lot to do with our ability to function with workable anonymity across many domains.

So, how did we get surveillance and it's attendant affects on natural anonymity as an unintended, but oft-exploited feature of administrative digital identity systems? Precisely because they are administrative.

Legibility

Legibility is a term used to describe how administrative systems make things governable by simplifying, inventorying, and rationalizing things around them. James C. Scott's seminal book, Seeing Like a State, nicely analyzes legibility and its unintended consequences. Venkatesh Rao has a great summary if you'd like the TL;DR.

Seeing Like a State: How Certain Schemes to Improve the Human Condition Have Failed by James C. Scott

In this wide-ranging and original book, James C. Scott analyzes failed cases of large-scale authoritarian plans in a variety of fields. Centrally managed social plans misfire, Scott argues, when they impose schematic visions that do violence to complex interdependencies that are not—and cannot—be fully understood. Further, the success of designs for social organization depends upon the recognition that local, practical knowledge is as important as formal, epistemic knowledge.

Identity systems make people legible in order to offer continuity, convenience, and trust. But, as we've seen, that legibility also allows surveillance. In some respects, this is the trade off we always get with administrative systems. By creating legibility, administrative systems threaten privacy.

Administrative systems are centralized. They are owned. They are run for the purposes of their owners, not the purposes of the people or things being administered. They are bureaucracies for governing something. They rely on rules, procedures, and formal interaction patterns. Need a new password? Be sure to follow the password rules of what ever administrative system you're in.

Every interaction you have online happens under the watchful eye of a bureaucracy built to govern the system and the people using it. The bureaucracy may be benevolent, benign, or malevolent but it controls the interaction and people pay the price of the interpretive work necessary to figure out how it functions.

Real Life is Decentralized

On the other hand, in real life we interact as peers. We do interact with administrative systems of various sorts, but no one would describe that as real life. When I go to a store, I don't think about shopping within their administrative system. Rather, I walk in, look at stuff, talk to people, put things in a cart, and check out. The administrative system is there, but it's for governing the store, not the customers.

We can't have online interactions that feel like real life until we redecentralize the internet. The internet started out decentralized. The early web was decentralized. But the need for continuity, convenience, and trust led more and more interactions to happen within someone's administrative system.

Most online administrative systems make themselves as unobtrusive as they can. But there's no getting around the fact that every move we make is within a system that knows who we are and monitors what we're doing. In real life, I don't rely on the administrative system of the restaurant to identify the people I'm having dinner with. The restaurant doesn't need to check our IDs or surveil us in order to create an environment where we can talk and enjoy a meal together.

The good news is that we're finally developing the tools necessary to create decentralized online experiences. What if you could interact with your friends online on the basis of an identity that they bring to you directly—one that you could recognize and trust? You wouldn't need Facebook or WhatsApp to identify and track your friends for you.

Decentralized identity is the foundation for a decentralized web—a web that flexibly supports the kind of ad hoc interactions people have with each other all the time in real life. Until we do, we'll never get an online world that mirrors real life and its natural anonymity.


Photo Credit: Poison Apple Sugar Cookies from Angelica Made Me (unknown)


Can the Digital Future Be Our Home?

I recently read Shoshana Zuboff's book on surveillance capitalism. Not only is the book thought provoking, but Zuboff's writing verges on the poetic at times, making it a delightful read. In her opening chapter she asks the question "Can the digital future be our home?"

This question is perhaps one of the most important of our age. More and more of our lives are being intermediated by digital systems. And yet those systems are not ours, but rather belong to the companies that provide them. And our experience on them is predicated on the goals, desires, and needs of those companies, not ours. I call these systems "administrative" because they are built to administer our experience in a particular domain for the administrator's specific purposes.

The Age of Surveillance Capitalism: The Fight for a Human Future at the New Frontier of Power by Shoshana Zuboff

The challenges to humanity posed by the digital future, the first detailed examination of the unprecedented form of power called "surveillance capitalism," and the quest by powerful corporations to predict and control our behavior. In this masterwork of original thinking and research, Shoshana Zuboff provides startling insights into the phenomenon that she has named surveillance capitalism. The stakes could not be higher: a global architecture of behavior modification threatens human nature in the twenty-first century just as industrial capitalism disfigured the natural world in the twentieth.

Zuboff makes a number of compelling arguments about why surveillance capitalism represents a significant threat to humanity's future. An overarching conclusion is that by putting everyone inside their administrative systems to make our lives legible to their surveillance, these companies become tyrants.

[T]yranny is the obliteration of politics. It is founded on its own strain of radical indifference in which every person, except the tyrant, is understood as an organism among organisms in an equivalency of Other-Ones.

Contrary to what many might believe, the obliteration of politics is not a good thing. As we discovered a few issues ago (see Legitimacy and Decentralized Systems), politics is how decentralized, democratic systems achieve legitimacy and coherence. Getting rid of politics requires putting everyone and everything in the centralized administrative system of the surveillance capitalist—making them subject to the dictates of the tyrant who has radical indifference to their autonomy, individuality, and humanity.

Zuboff's statement echos David Graeber's discussion of bureaucracy in The Utopia of Rules. Bureaucratic interactions are simple and predictable. But they are soulless. They are transactional and cannot provide the basis for authentic digital relationships (see Authentic Digital Relationships ).

The Utopia of Rules: On Technology, Stupidity, and the Secret Joys of Bureaucracy by David Graeber

Where does the desire for endless rules, regulations, and bureaucracy come from? How did we come to spend so much of our time filling out forms? And is it really a cipher for state violence? To answer these questions, the anthropologist David Graeber—one of our most important and provocative thinkers—traces the peculiar and unexpected ways we relate to bureaucracy today, and reveals how it shapes our lives in ways we may not even notice...though he also suggests that there may be something perversely appealing—even romantic—about bureaucracy.

Living our lives inside the administrative systems of Big Tech is akin to living your life inside an amusement park. Not altogether unpleasant, but a far cry from authentic. Stippled with moments of joy, but devoid of real happiness and freedom. Treated identically and transactionally despite pretensions to personalization.

In How to Destroy Surveillance Capitalism, Cory Doctorow argues that while Zuboff's observations are not incorrect, her conclusions about what constitutes surveillance capitalism's real dangers are mistaken. Where Zuboff sees companies who are getting better and better at predicting and controlling our actions, Doctorow sees companies selling the power to persuade, poorly. The real harm is the surveillance, not mind control.

How to Destroy Surveillance Capitalism by Cory Doctorow

For years, we've been hearing about the ills of surveillance capitalism --- the business of extracting, collecting, and selling vast reams of user data that exploded with the rise of tech giants like Google, Facebook, and Amazon. But what if everything we've been hearing is wrong? What if surveillance capitalism is not some rogue capitalism or a wrong turn taken by some misguided corporations? What if the system is working exactly as intended—and the only hope of restoring an open web is to take the fight directly to the system itself?

Zuboff's conclusion that surveillance capitalism is a new "rogue" form of capitalism leaves us with little recourse but to regulate the ills that surveillance capitalists bring about. Not unreasonably, Zuboff's prescription for this predicament is to protect, trust, and utilize democratic processes—to collectively push back. To not let our cynicism dissuade us or cause us to lose hope.

But, merely regulating a big monopoly only further entrenches it, locking the world into the status quo. If we want to destroy surveillance capitalism, Cory argues, we have to break it up and decentralize, making "big tech small again." Ultimately, the choice is to fix Big Tech or fix the internet. Cory argues for the second and I'm on board.

Fixing the internet is hard, but not impossible. Cory references Lawrence Lessig, saying "our lives are regulated by four forces: law (what's legal), code (what's technologically possible), norms (what's socially acceptable), and markets (what's profitable)." We can bring all four to bear on this problem.

Antitrust, post Reagan, has lost its teeth and come to focus only on consumer harm instead of other anti-competitive behaviors like buying up large rivals and new competitors. If the problem with "Big Tech" is that it is "big" then restructuring antitrust laws to break up large tech companies is a critical tool.

Many will fear that breaking up big tech will diminish the fruits of the digital world we've come to enjoy, and even rely on. Centralization, they will say, is the only way to safely and efficiently build messaging platforms, app stores, social networks, and other features of Web 2.0 that we've come to enjoy.

This is where Lessig's other three forces come into play. As I've written, in numerous ways, the means exist to decentralize most of the centralized Web 2.0 platforms (i.e. it's "technologically possible" in Lessig's words). The internet itself and more recent decentralized networks like Bitcoin and Ethereum show that large, decentralized systems can achieve legitimacy to accomplish global goals.

Beyond tech, I have hope that norms are changing. People are more aware and wary of the dangers of surveillance and the need for better online privacy. Collecting data is becoming less socially acceptable. Security breeches affect more and more people, waking them up to the problem of companies collecting and holding large caches of personal data. And competitors to big tech with decentralized solutions are always emerging. A little antitrust help could be what it takes to make them viable.

There's no single act that's going to change the way things work now. Getting Congress to act on antitrust requires a big shift in norms. Changing norms requires new technical possibilities, new applications, and, frankly, more privacy problems. Change is predicated on a web of interrelated actions that we must iterate over.

Returning to Zuboff's opening question: "Can the digital future be our home?" Fixing Big Tech just leaves us where we're at, with slightly fewer problems. It's a dead end road that doesn't lead to a digital home. But fixing the internet, redecentralizing it, promises a future where we can live authentic digital lives that compliment our physical lives. I choose to fight for that future.


Building an SSI Ecosystem: Digital Staff Passports at the NHS

Dr Manny Nijjar is an infectious disease doctor with Whipps Cross Hospital in the UK. He’s also an innovator who quickly saw how verifiable credentials could be applied to health care. I first met Manny at the launch of Sovrin Foundation in London in September 2016. He’s been working to bring this vision to life with his company Truu, ever since.

SSI For Healthcare: Lessons from the NHS Frontline

In this video, Manny discusses why he became interested in digital credentials. He also speaks to the influence medical ethics has had on his journey. In 2015, he was training to become an infectious disease specialist. Manny was the most senior clinician on site in the evenings, in charge of about 500 beds.

Manny kept getting called by, and about, a temporary agency doctor every night. Manny and other medical staff had questions about this doctor’s skills, qualifications, and the decisions he was making. But there were shortages and the hospital needed to fill the gap. Manny was so discouraged by seeing an unqualified physician slip through the cracks, that he was about to quit his career, but instead he determined to do something about it.

Serendipitously, Manny came across self-sovereign identity (SSI) at the same time and, as I said, spoke at the launch of Sovrin Foundation. Over the next several years, Manny and his partners worked to create an SSI solution that the National Health Service in the UK could use to instantly verify the identity and skills of temporary and permanent clinical staff. There were three primary problems that this solves:

  1. Patient Safety - Verifying the identity and skills of temporary and permanent clinical staff.
  2. Burden on Clinical Staff - Admin time for repeated identity and pre-employment checks.
  3. Organizational Risk and Operational Inefficiencies - Failure of manual checks. Time and cost to onboard healthcare staff.

Manny’s first thought had been to use a traditional, administrative scheme using usernames and passwords. But he saw the problems with that. He realized a digital credential was a better answer. And his journey into self-sovereign identity commenced.

Manny's paper credentials
Manny's paper credentials (click to enlarge)

Over the past five years, Manny and his team at Truu have worked with clinicians, various parts of the NHS, employers, HR departments, and locum agencies to understand their needs and build a solution that fits.

In 2019, Truu conducted a pilot with the NHS where the General Medical Council (GMC) issued “license to practice” credentials to SSI wallets controlled by medical staff. Medical staff could present that credential to Blackpool Teaching Hospitals. The hospital, in turn, issued a “sign in” credential to the staff member who could then use it to log into clinical systems at the hospital.

Digital Credentials for People and Organizations
Digital Credentials for People and Organizations (click to enlarge)

The Covid-19 pandemic increased the pressure on the NHS, making the need to easily move staff between facilities acute. Truu worked with NHS to use this critical moment to shift to digital credentials and to do it in the right way. Truu’s early work, including the pilot, positioned the idea so that it could be quickly adopted when it was needed most. Digital credentialing in healthcare simplifies onboarding for providers, enables the secure expansion of telehealth services, and enhances information exchange—providing a path to interoperability for healthcare data.

The National Health Service in the UK has a program to issue staff passports to medical personnel, confirming their qualifications and ability to work. NHS staff passports are based on verifiable credentials. Eighty-four NHS organizations are participating to date.

Locations of Participating Organizations in the NHS Staff Passport Program in April 2021
Locations of Participating Organizations in the NHS Staff Passport Program in April 2021 (click to enlarge)

The work that Manny, his team at Truu, and partners like Evernym have done has already had a big impact. The UK Department of Health and Social Care recognized the importance of the program, promising to expand the use of staff passports in their Busting Bureaucracy report. They said:

NHSE/I, NHSX and HEE are working to provide multiple staff groups with access to digital staff passports in line with People Plan commitments to improve workforce agility and to support staff training and development.

  • Junior doctors, who frequently rotate to different healthcare providers, are being prioritized and the ambition is that they will have access to staff passports in 2021/22. The passports will hold digital credentials representing their skills, competencies and occupational health checks.
  • Other target groups include specialists such as maternity and stroke care staff who often need to be rapidly deployed to a neighboring hospital or care home. The use of digital staff passports will save agency fees and release time for care.

Medical staff passports are catching on in the UK where they are solving real problems that ultimately impact patient care, staff fatigue, and patient access and privacy. The journey hasn’t been short, but the NHS Staff Passport program is illustrative of a successful credential ecosystem.

Related Videos

In this 11 minute video, I explain how trust frameworks function in an ecosystem like the one that the NHS has created.

Phil Windley on Trust Frameworks

In this hour-long meetup, Drummond Reed talks with CU Ledger (now Bonifii), about their work to establish a trust framework for credit union credentials. I’ll be writing more about the credit union industry’s MemberPass credential in a future newsletter.

Trust Frameworks and SSI: An Interview with CULedger on the Credit Union MyCUID Trust Framework

A version of this article was previously published in the Technometria Newsletter, Issue #9, May 4, 2021.

Images are from the SSI For Healthcare: Lessons from the NHS Frontline video referenced above.