Following up on my last blog post, From Printing Press to Digital Identity: A Pattern of Moral Crisis, I allude to the idea that Self Sovereign Identity is centralized, but don’t go into great detail how. In this post, I’m going to follow up on this idea to show how we’ve subtly introduced the centralization through the chosen trust architecture. Then I’ll point out some of the ways in which this centralization could be weaponized against the people that we intended to provide more agency too.
To start, we first have to acknowledge that in a claims based model like with verifiable credentials or any other digital credential data model the technology itself is ambivalent to how it’s used. Put simply, all of the various data models are designed to encode “who says what about whom” into a digital form. So, the subtly in this is that the credentials themselves can’t really enforce centralization or decentralization, but rather how we choose to encode information into them are what provides this enforcement.
Let’s take for example the 3 most commonly suggested or deployed use cases of these digital credentials as of yet:
- COVID Passes
- Age Verification
- “Know Your Customer”
In all 3 of these use cases we’ve defined a trust architecture where the structure of the data is: An institution with a well known identifier makes claims about a subject with an untrusted identifier such that an arbitrary verifier can rely upon said claims for any purpose they choose. This is most commonly referred to as a “High Assurance” credential. The alternative approach that’s been described is a self attested model, which is the most common approach on the Web to date.
In a self attested claims model (or could also be referred to as a “low assurance” credential) it works roughly like this. A subject uses an untrusted identifier as an issuer to make claims about themselves as the subject with the same untrusted identifier such that an arbitrary verifier can rely upon said claims. While the technology under the hood isn’t quite the same, the closest example we have to this today is the social login systems like Sign in With Facebook or Google. In each of these systems, at the very beginning when I register my account I self declare my information to Facebook or Google and that information could be correct or not. It doesn’t much matter what my name is or what my date of birth is because Facebook and Google aren’t making any assurances about the claims themselves. They’re simply collect it and relaying it onto third parties using Open ID Connect. In this trust architecture, the ability to self attest this information at the start allows me to falsify claims on registration. I may choose to do that to enhance my privacy while still being able to easily authenticate on the Web or it could be to impersonate another person.
So, what makes something high assurance or low assurance? It essentially boils down to what enforcement mechanisms exist for the verifier to have assurance that the claims are valid and how we’re opting to do this in “high assurance” credentials is to remove agency from the subject and bestow that into well known identifiers that represent institutions that are “trusted”. We assume this trust is valid because we assume the likelihood of falsified records is lower (not zero, it’s actually not economically feasible to achieve this) than that of the self-attested model. But at what cost? The cost comes in the form of the subject’s agency.
Under the new “high assurance” trust models we bestow the subject the ability to share claims made about them which is new, but in exchange for that capability we remove the ability to make claims about themselves. That power is now only granted to well known trusted entities. Does that remind you of any other PKI systems on the Web because it does to me?
If we think about the x509 system for TLS certificates they essentially work in the same way. Our browsers don’t trust a self-signed certificate by default but it does trust an intermediary certificate that’s been signed by a well known trusted root certificate. Now tell me, how many of you regularly allow self-signed certificates when visiting a website today? It probably happens once in a while, but its certainly not the prevalent trust model on the Web anymore. The issue here is that, as soon as we introduced the alternative mechanism for a hierarchical trust infrastructure rooted in a select number of institutions (the root certificate authorities) providing some assurance about the intermediary certificates we stopped using self signed certificates because they were deemed less safe even though they were more decentralized. Furthermore, that same x509 infrastructure which operates on a decentralized trust model has been shown that it can be scaled with PGP. Sure, it’s by no means an enjoyable tool to use, but that’s more a factor of the tooling being built-in 1991 where we hadn’t done much research on human-computer interaction patterns. It therefore, shouldn’t be used as an invalidation of the safety of the trust model itself.
So in my original blog post, I suggest that’s exactly what will happen with digital credentials too and the evidence with the most prevalent use cases suggests that’s already what is happening. In each of these systems, the issuer maps to the root certificate authority, the subject maps to the intermediary certificate, and the verifier is the one setting the rules for the game which effectively means that we’ve recreated a hierarchical trust model. This isn’t a damnation of the technology itself, just as Web certificates isn’t a damnation of x509 as shown by PGP.
So now that we understand how the issuance side has centralized let’s take a look at what this will mean in practice on the Web and in real life. Rather than re-iterate the points we made about the digital credentials API at Brave, I’ll just point back to our formal objection of it because they’re exactly the same as what I’d say here.
To exemplify on this a bit further though let’s take a look at the age verification use case. In this use case, what we’re seeing is that users on the Web are having their agency removed as a byproduct of these problems being solved with a centralized, hierarchical trust model. In advertantly we achieve greater “compliance” from the “higher” assurance (most everyone can think of a few ways that this will be bypassed) and in exchange we lose some agency and privacy because we want better content moderation capabilities for children, a protected class of people. The issue within this specific use case is that that chosen trust architecture then becomes a weapon against speech inadvertantly. Either due to people choosing to self-censor because they don’t want to provide age assurance credentials to websites or because they don’t have a credential such as children not having one or because the issuer revoked it from them. That revocation may occur simply because of the speech they make or it may occur because of a more benign reason such as the person forgot to pay for insurance and had their driver’s license revoked, so the site errors on the side of caution and doesn’t accept it due to strict liability falling on the site.
It’s easy to argue that I’m contriving these sorts of examples in a game of what-ifs, but let’s look at what’s most recently happened in the case of “financial compliance” with KYC and debanking. Within the past decade or so, there’s been a growing trend of debanking people based on how the funds are generated. In the further out example, we saw this happen with operation chokepoint where the US government leveraged a capability they already had (financial compliance afforded through KYC) and repurposed it to limit the capaibilities of people they deemed to be participating in “high risk” activities.
In this previous financial compliance system, the new age assurance mechanisms, and in any other use case that relies upon deferred instituitional trust through high assurance credentials we should expect to see that the technology will also be repurposed for alternative means than what they were designed for. In some cases, people will see this as a feature rather than a bug to protect others, but it remains an unintended consequence by design of the system. This happens because the verifier bestows a new set of hard power in the issuer (trust) by removing hard power from the subject (agency and in some cases privacy) which will eventually be repurposed when the next moral crisis occurs as history suggests. None of this is because of the technical design of the technologies though, it’s simply because this is how we’ve chosen to use them and that’s what makes this such a subtle inversion of power that goes against the original goals many of us have been working towards.