The premise of this article is:
Public/private key pairs have been around for a long time. Useful for encryption and addressing, they are a cryptographic way to ensure that data is flowing between the right entities. While this article touches on public key infrastructure (PKI) and decentralized public key infrastructure (DPKI), I want to focus on the user perspective more than the systems of authentication.
This is an article about user safety, socio-technical systems, and new technology.
Again, for the people in the background, crypto wallets and public keys are not identities.
Even
Identifiers within the space of digital identity include DIDs, crypto wallets, and many other implementations of public/private keys. The public key acts as a unique identifier, an address specific to the holder of the private key. It provides no other information about that key holder. The key could be held by anything from an IoT device to a profile on a personal computer to a server. The nature of that device or who has access to it is not held as part of the key itself.
Identity is a little more complicated.
Identity can be a legal tool: who you are in the eyes of the state — e.g., passports and driver's licenses. This is what is needed for KYC. This is the form of identity needed for a bureaucratic system to function and recognize you as a unique, unchanging entity.
Identity is also social. It’s our relationships, personalities, hobbies, and cultures. These things aren’t really definable as discrete metrics, and as much as marketing companies want to capture them as such, we probably don’t want that. Social identities are all about
Social and legal identity are separate things, and using digital identity to bind them together will have unintended negative consequences; for instance, platforms that monitor your activities and build a social profile that they attach to your legal identity abuse that data in turning you into a product sold to advertisers. The digital flattens nuance. We don’t want that sort of data going to our peers, either. Just as texting makes it hard to read tone, digital identities can give both too much and too little information at the same time.
Keys are, of course, used to address and attach identity data, using documents that point to the key, signed by others making the claim — with implementations and proposals such as Soulbound Tokens, Disco, and more under the general banner of decentralized digital identity. Being able to attach verifiable data to an identifier in a decentralized system is massively powerful. However, it is very dangerous if the system is designed without consideration for second-order effects and if identities and identifiers are not properly differentiated.
“Identity data” is used broadly here because, depending on the implementation, anyone can make any sort of claim about you and attach it to a digital identifier you control. Everything from web tracking data, to legal documents, to criminal records, to your concert tickets are all potential data points depending on how a system is implemented.
At the end of the day, I don’t want to use a system designed to present my legal identity and other data collected about me first and foremost. We must think about these systems beyond individual interactions and rather consider the way users will interact across time in emergent patterns. Protecting users should be the primary concern of digital identity solutions.
We need to remember that keys are not people and have much broader uses than simply addressing identity data.
In a lot of centralized systems, users do not have direct access to the private keys on their devices. This makes UX easy — offloading key management actions like revocation and replacement to the central service eases the burden on the user. A simplified analogy is: if you have forgotten your password, you can reach out to whatever entity you were trying to log into and prove your identity through other means to get a new password set up. With decentralized systems, where your key is authorized by itself alone, there is no such recourse. If you forget the password that decrypts your locally held private key, there is no central entity you can approach to ask them to revoke and replace your keys.
So, how do we do decentralized key management well? And what are some ways we can make it safer and more empowering for users?
Anyone who has used a crypto wallet will be familiar with seed phrases. They are a series of random words which are used to generate the key pair. This allows the key pair to be regenerated by using the same seed phrase. To maintain the same identifier or access the same wallet on different devices, you need the same key. This is why seed phrases have to be kept secure: anyone who has access to your seed phrase has access to your private key and can act with the same authority as you can.
So keep your seed phrase private and secure, but also don’t lose or forget it.
A whole industry of
Key revocation might not be so familiar to those using crypto wallets. This is because, for the most part, wallets cannot be revoked. This is something like never being able to change your address. You can move, but you can’t forward your mail. Literally a nightmare if someone manages to compromise your wallet, leaving you no recourse.
Revocation in centralized systems is usually managed by public lists held by centralized entities, showing which keys have been compromised or replaced and pointing to the alternative, updated keys to be used in their place. As long as the central entity can be trusted, you can track which keys are relevant through their revocation lists, just like a forwarding address.
The other key management tool that is being considered by a number of protocols is the social recovery of keys. Vitalik has
In a public document (like a smart contract on a blockchain, or a public DHT entry in Holochain) you list a set of keys that can revoke and rotate your key in the case that it is compromised. This document is then signed with your original key, proving the right to assign those custodians. Usually, this will follow some sort of multi-sig pattern where M (3) of N (5) keys need to sign the update to the document by rotating the keys. Who controls these custodial keys is up to the user, but usually, they might assign friends, family, or trusted institutions, along with keys that they keep backed up separately.
The thing that makes this different from central systems is choice.
This begins to reach the ideal of good user experience and user empowerment. People need to be able to choose what data they share and who is involved in the management of their keys, and those need to be easy ongoing decisions rather than technical nightmares.
We are not our keys. We are not even our data. (Or should I say the data that talks about us?)
Social and legal identity are separate things. Conflating them through digital identity tools and attaching them to identifiers in ways that remove user agency will have negative consequences.
Key management isn’t currently user-friendly. It’s worth putting effort into making it user-friendly. This will be required for safe adoption.
We can do some cool things with decentralized key management. Personally, I’m looking forward to my passwords no longer being leaked in data breaches. But as we move the technology out of the realm of crypto and geeks to the general user, we need to be thoughtful about how we build technical, legal, and social norms around its use.
Special thanks to Philip Sheldrake, Camila Hanada, Jarod Holtz, and Paul d’Aoust for their enriching reviews and assistance with this article’s feature image. All mistakes and opinions remain my own.