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.


Decentralized System in a Box

I installed a package of bees in a hive over the weekend. You buy bees in packages that contain 15-20 thousand bees and a queen. The queen is in a cage so she is easy to find. Queens give off a pheromone that attracts the other bees in the hive. The queen is the secret to creating legitimacy for the hive (see Legitimacy and Decentralized Systems for more on legitimacy). If the queen is in the new hive, chances are the other bees will see it as their legitimate home and stick around.

Queen in a cage
Queen in a cage (click to enlarge)

I placed queen cage in the hive using a rubber band to fix the cage on one of the frames that the bees make honeycomb on. I replaced the cork in the cage with a candy stopper. The bees eat through the candy over the course of a few days and free the queen. Hopefully, by that time, the hive is established and the bees stick around.

After placing the queen cage in the hive, you just dump the bees out on top of the frames. I love this part because thousands of bees are flying everywhere trying to make sense of what just happened. But over the course of an hour or two, the hive coalesces on the queen and most of the bees are inside, getting adjusted to their new home.

Bees on top of the hive frames
Bees on top of the hive frames (click to enlarge)
About an hour after the bees get their new home, they're out on the porch, fanning and taking orientation flights.
About an hour after the bees get their new home, they're out on the porch, fanning and taking orientation flights. (click to enlarge)

Besides providing a basis for hive legitimacy, the queen is also the sole reproductive individual, responsible for laying every egg that will be raised in the hive. This is a big job. During the summer, she will lay about 2000 eggs per day and the hive will swell to multiple tens of thousands of bees. But beyond this, the queen’s role is limited. She doesn’t direct the actions of the members of the hive. No one does.

Thermoregulation

So, how does the hive function without central direction? Thermoregulation provides an example. Despite the fact that bees themselves are not homeothermic, the hive is. The bees manage to keep the hive at 93-94°F (34°C) regardless of the outside air temperature.

How do the bees do that? The straightforward answer is that some bees go to the entrance of the hive and fan air to increase circulation when the internal temperature gets too high. When it gets too low, bees cluster in the center and generate heat by shivering.

The more interesting question is “how do the bees know to do that?” All the bees have similar genetic programming (algorithmic governance). But the tasks that they’re inclined to do depend on their age. The youngest workers clean cells, then move onto nursing functions, mortuary activities, guarding the hive, and finally, in the last weeks of their lives, to foraging for water, nectar, and pollen.

Bees have a genetic threshold for carrying out these tasks. The threshold changes as they age. A young bee has a very high threshold for foraging that decreases over her life. Further, these thresholds vary by patriline (even though every bee in the hive has the same mother, there are many fathers), providing diversity.

So as the temperature in the hive climbs, a few bees go down to the hive entrance and fan. As it gets hotter, even more bees will take up the task, depending on their internal threshold. Their genetic programming, combined with the diversity in their thresholds, promotes an even response to temperature swings that could damage the hive. You can read more about hive thermoregulation in an earlier blog post I wrote on the topic.

Swarming and Protecting Against Byzantine Failure

An even more interesting phenomenon is how bees decide to swarm. Because the hive is a super organism, the queen’s efforts to reproduce don’t result in a new hive unless there’s a swarm. Swarming is how new hives are created.

Bees swarm in response to stresses like insufficient food supply, too little space, and so on. But no one really knows how a hive decides it’s time to swarm. In preparation for a swarm, the hive starts to raise new queens. Whether an egg grows into a worker, drone, or queen is determined by how the larva is fed by nurse bees. At some point the bees collectively determine to swarm and the queen produces a pheromone that broadcasts that decision.

The swarm consists of the current queen (and her powerful pheromones), some of the worker bees, and a portion of the honey stores. The swarm leaves the hive and the remaining bees raise the new queen and carry on. The swarm flies a short distance and settles down on some convenient structure to decide where to make their permanent home. Again the swarm centers on the queen. This is where the fun starts.

Thomas Seeley of Cornell has been studying swarms for his entire career. In the following video he describes how bees use collective decision making to choose their new home.

Cornell professor, biologist and beekeeper Thomas Seeley
Cornell professor, biologist and beekeeper Thomas Seeley (click to view)

There are several interesting features in this process. First, Seeley has determined that bees don’t just make a good decision, but the best possible decision. I think that’s amazing. Several hundred bees leave the swarm to search for a new home and participate in a debate to choose one of the available sites and settle on the best choice.

This is a process that is potentially subject to byzantine failure. Not that the bees are malicious, in fact they’re programmed to accurately represent their findings. But they can report faulty information based on their judgment of the suitability of a candidate site. The use of reputation signals for sites and voting by multiple inspectors allows the bees avoid bad decisions even in the face of false signals.

Swarm lodged in a fruit tree in my garden
Swarm lodged in a fruit tree in my garden (click to enlarge)

The process is further protected from error because bees are programmed to only advertise sites they’ve actually visited. Again, they don’t have the ability to be malicious. Each bee advertising a potential site has done the work of flying to the site and inspecting it. As bees signal their excitement for that site in a waggle dance, even more bees will fly out to it, perform an inspection, and return to advertise their findings. I don’t know if I’d characterize this as proof of work, but it does ensure that votes are based on real information. Once a quorum of bees in the swarm reach consensus about a particular site, the swarm departs and takes up residence in their new home.

Honeybee Democracy by Thomas D. Seeley

Honeybees make decisions collectively--and democratically. Every year, faced with the life-or-death problem of choosing and traveling to a new home, honeybees stake everything on a process that includes collective fact-finding, vigorous debate, and consensus building. In fact, as world-renowned animal behaviorist Thomas Seeley reveals, these incredible insects have much to teach us when it comes to collective wisdom and effective decision making.

You may not be thrilled if a swarm determines the best new home is in your attic, but you can be thrilled with the knowledge that ten thousand decentralized bees with sophisticated algorithmic programming achieved consensus and ranked it #1.

The hive is a super organism with its intelligence spread out among its tens of thousands of members. Life and death decisions are made on a daily basis in a completely decentralized fashion. Besides thermoregulation of the hive and finding a new home, the bees in a hive autonomously make millions of other decentralized decisions every day that result in the hive not only surviving but thriving in hostile conditions. I find that remarkable.


Legitimacy and Decentralized Systems

Major General Andrew Jackson and his Soldiers claim a victory in the Battle of New Orleans during the War of 1812.

As an undergraduate engineering major, I recall being surprised by the so-called three body problem. In Newtonian mechanics, there are nice closed-form solutions to problems involving the motion of two interacting bodies, given their initial position and velocity. This isn’t true of systems with three or more points. How can adding just one more point to the system make it unsolvable?

N-body systems are chaotic for most initial conditions and their solution involves numerical methods—simulation—rather than nice, undergraduate-level math. In other words, it’s messy. Humans like simple solutions.

Like the n-body problem, decentralized systems are chaotic and messy. Humans aren’t good at reasoning about emergent behavior from the coordinated, yet autonomous, behavior of interacting agents. We build bureaucracies and enact laws to try to make chaotic systems legible. The internet was our first, large-scale technical system where decentralization and governance clashed. I remember people in the 90’s asking “Who’s in charge of the internet?”

In The Most Important Scarce Resource is Legitimacy, Vitalik Buterin, the creator of Ethereum, discusses why legitimacy is crucial for the success of any decentralized endeavor. He says:

[T]he Bitcoin and Ethereum ecosystems are capable of summoning up billions of dollars of capital, but have strange and hard-to-understand restrictions on where that capital can go.
From The Most Important Scarce Resource is Legitimacy
Referenced 2021-04-26T14:46:43-0600

These “strange and hard to understand restrictions” are rooted in legitimacy. Decentralized systems must be considered legitimate in order to thrive. That legitimacy is tied to how well the systems and people enabling them, like programmers and miners, are seen to be following “the rules” both written and unwritten. Legitimacy isn’t a technical issue, but a social one.

Wikipedia defines legitimacy as

the right and acceptance of an authority, usually a governing law or a regime.

While this is most often applied to governments, I think we can rightly pose legitimacy questions for technical systems, especially those that have large impacts on people and society.

With respect to legitimacy, Philip Bobbit says:

The defining characteristic … of a constitutional order is its basis for legitimacy. The constitutional order of the industrial nation state, within which we currently live, promised: give us power and we will improve the material well-being of the nation.

In other words, legitimacy comes from the constitutional order: the structure of the governance and its explicit and implicit promises. People grant legitimacy to constitutional orders that meet their expectations by surrendering part of their sovereignty to them. In the quote from Vilaik above, the "strange and hard to understand restrictions" are promises that members of the Bitcoin or Ethreum ecosystems believe those constitutional orders have made. And if they're broken, the legitimacy of those system is threatened.

Talking about “legitimacy” and “constitutional orders” for decentralized systems like Bitcoin, Ethereum, or your favorite NFT might feel strange, but I believe these are critical tools for understanding why some thrive and others wither. Or why some hard forks succeed and others don't.

In Bobbitt’s theory of constitutional orders, transitions from one constitutional order to a new one always requires war. While people seeking legitimacy for one decentralized system or another might not use tanks or missiles, a hard fork is essentially just that—a war fought to cause the transition from one constitutional order to another because of a question of legitimacy. For example, Vitalik describes how the Steem community did a hard fork to create Hive, leaving Steem’s founder (and his tokens) behind because the constitutional order he represented lost its legitimacy because people believed it could no longer keep its promises.

So when you hear someone talking about a decentralized system and starting sentences with phrases like “Somebody should…” or “Why do we let them…” or “Who’s in charge of…”, beware. Unlike most of the easy to understand systems we’re familiar with, decentralized systems are heterarchical, not hierarchical. Thus the means of their control is political, not authoritarian. These systems are not allowed to exist—they're called "permissionless" for a reason. They simply are, by virtue of their legitimacy in the eyes of people who use and support them.

This doesn’t mean decentralized systems are unassailable, but changing them is slower and less sure than most people would like. When you “know” the right way to do something, you want a boss who can dictate the change. Changing decentralized systems is a political process that sometimes requires war. As Clausewitz said “War is the continuation of politics by other means.”

There are no closed-form solutions to the n-body problems represented by decentralized systems. They are messy and chaotic. I’m not sure people will ever get more comfortable with decentralization or understand it well enough to reason about it carefully. But one thing is for sure: decentralized systems don’t care. They simply are.


A version of this article was previously published in Technometria Newsletter, Issue #6, April 13, 2021.

Photo Credit: Major General Andrew Jackson and his Soldiers claim a victory in the Battle of New Orleans during the War of 1812. from Georgia National Guard (CC BY 2.0)


The Politics of Vaccination Passports

CDC Covid-19 Vaccination Card

On December 2, 1942, Enrico Fermi and his team at the University of Chicago initiated the first human-made, self-sustaining nuclear chain reactions in history beneath the viewing stands of Stagg Field. Once humans knew how nuclear chain reactions work and how to initiate them, an atomic bomb was inevitable. Someone would build one.

What was not inevitable was when, where, and how nuclear weapons would be used. Global geopolitical events of the last half of the 20th century and many of the international questions of our day deal with the when, where, and how of that particular technology.

A similar, and perhaps just as impactful, discussion is happening now around technologies like artificial intelligence, surveillance, and digital identity. I’d like to focus on just one small facet of the digital identity debate: vaccination passports.

In Vaccination Passports, Devon Loffreto has strong words about the effort to create vaccination passports, writing:

The vaccination passport represents the introduction of the CCP social credit system to America, transmuting people into sub-human data points lasting lifetimes.
From Vaccination Passports
Referenced 2021-04-12T11:13:58-0600

Devon’s larger point is that once we get used to having to present a vaccination passport to travel, for example, it could quickly spread. Presenting an ID could become the default with bars, restaurants, churches, stores, and every other public place saying “papers, please!” before allowing entry.

This is a stark contrast to how people have traditionally gone about their lives. Asking for ID is, by social convention and practicality, limited mostly to places where it’s required by law or regulation. We expect to get carded when we buy cigarettes, but not milk. A vaccination passport could change all that and that’s Devon’s point.

Devon specifically calls out the Good Health Pass collaborative as "supporting the administration of people as cattle, as fearful beings 'trusting' their leaders with their compliance."

For their part, participants of the Good Health Pass collaborative argue that they are working to create a “safe path to restore international travel and restart the global economy.” Their principles declare that they are building health-pass systems that are privacy protecting, user-controlled, interoperable, and widely accepted.

I’m sympathetic to Devon’s argument. Once such a passport is in place for travel, there’s nothing stopping it from being used everywhere, moving society from free and open to more regulated and closed. Nothing that is, unless we put something in place.

Like the direct line from Fermi’s atomic pile to an atomic bomb, the path from nearly ubiquitous smartphone use to some kind of digital vaccination passport is likely inevitable. The question for us isn’t whether or not it will exist, but where, how, and when passports will be used.

For example, I’d prefer a vaccination passport that is built according to principles of the Good Health Pass collaborative than, say, one built by Facebook, Google, Apple, or Amazon. Social convention, and regulation where necessary, can limit where such a passport is used. It’s an imperfect system, but social systems are. More important, decentralized governance processes are necessarily political.

As I said, I’m sympathetic to Devon’s arguments. The sheer ease of presenting digital credentials removes some of the practicality barrier that paper IDs naturally have. Consequently, digital IDs are likely to be used more often than paper. I don’t want to live in a society where I’m carded at every turn—whether for proof of vaccination or anything else. But I’m also persuaded that organizations like the Good Health Pass collaborative aren’t the bad guys. They’re just folks who see the inevitability of a vaccination credential and are determined to at least see that it’s done right, in ways that respect individual choice and personal privacy as much as possible.

The societal questions remain regardless.


Photo Credit: COVID-19 Vaccination record card from Jernej Furman (CC BY 2.0)


Building Decentralized Applications with Pico Networks

Picos are designed to form heterarchical, or peer-to-peer, networks by connecting directly with each other. Because picos use an actor model of distributed computation, parent-child relationships are very important. When a pico creates another pico, we say that it is the parent and the pico that got created is the child. The parent-child connection allows the creating pico to perform life-cycle management tasks on the newly minted pico such as installing rulesets or even deleting it. And the new pico can create children of its own, and so on.

Building a system of picos for a specific application requires programming them to perform the proper lifecycle management tasks to create the picos that model the application. Wrangler is a ruleset installed in every pico automatically that is the pico operating system. Wrangler provides rules and functions for performing these life-cycle management tasks.

Building a pico application can rarely rely on the hierarchical parent-child relationships that are created as picos are managed. Instead, picos create connections between picos by creating what are called subscriptions, providing bi-directional channels used for raising events to and making queries of the other pico.

This diagram shows a network of temperature sensors built using picos. In the diagram, black lines are parent-child relationships, while pink lines are peer-to-peer relationships between picos.

Temperature Sensor Network
Temperature Sensor Network (click to enlarge)

There are two picos (one salmon and the other green) labeled a "Sensor Community". These are used for management of the temperature sensor picos (which are purple). These community picos are performing life-cycle management of the various sensor picos that are their children. They can be used to create new sensor picos and delete those no longer needed. Their programming determines what rulesets are installed in the sensor picos. Because of the rulesets installed, they control things like whether the sensor pico is active and how often if updates its temperature. These communities might represent different floors of a building or different departments on a large campus.

Despite the fact that there are two different communities of temperature sensors, the pink lines tell us that there is a network of connections that spans the hierarchical communities to create a single connected graph of sensors. In this case, the sensor picos are programmed to use a gossip protocol to share temperature information and threshold violations with each other. They use a CRDT to keep track of the number of threshold violations currently occuring in the network.

The community picos are not involved in the network interactions of the sensor picos. The sensor network operates independently of the community picos and does not rely on them for communication. Astute readers will note that both communities are both children of a "root" pico. That's an artifact of the way I built this, not a requirement. Every pico engine has a root pico that has no parent. These two communities could have been built on different engines and still created a sensor network that spanned multiple communities operating on multiple engines.

Building decentralized networks of picos is relatively easy because picos provide support for many of the difficult tasks. The actor model of picos makes them naturally concurrent without the need for locks. Picos have persistent, independent state so they do not depend on external data stores. Picos have a persistent identity—they exist with a single identity from the time of their creation until they are deleted. Picos are persistently available, always on and ready to receive messages. You can see more about the programming that goes into creating these systems in these lessons: Pico-Based Systems and Pico to Pico Subscriptions.

If you're intrigued and want to get started with picos, there's a Quickstart along with a series of lessons. If you want support, contact me and we'll get you added to the Picolabs Slack.

The pico engine is an open source project licensed under a liberal MIT license. You can see current issues for the pico engine here. Details about contributing are in the repository's README.