paint-brush
Keys are Not Identities by@rosalindmarino
388 reads
388 reads

Keys are Not Identities

by Rosalind MarinoJune 14th, 2024
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Wallets and Keys are Not Identities. Collapsing Keys and Identities is Dangerous. Decentralized Key Management is Tough but Powerful. We are not our keys nor our data. This is a call for more user centric approaches to digital identity, better consideration of second order effects, and clearer communication and education so that these systems serve users rather then harming them.
featured image - Keys are Not Identities
Rosalind Marino HackerNoon profile picture

The premise of this article is:

  1. Wallets and Keys are Not Identities
  2. Collapsing Keys and Identities is Dangerous
  3. Decentralized Key Management is Tough but Powerful


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.

Wallets and Keys are Not Identities!

Again, for the people in the background, crypto wallets and public keys are not identities.


Even Decentralized Identifiers (DIDs) are not identities but rather simply identifiers.


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 progressive trust as we reveal aspects of ourselves to people over time. Social identities are relational. Each person who knows us knows us a little differently. Thus, there is no one social identity that you hold; rather, social identity exists in the eye of the beholder.


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.

Collapsing Keys and Identities is Dangerous

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.


Molly White describes the potential abuses of publicly visible identity information attached to crypto wallets where users have no recourse to edit or remove data. Even Web3 identity provider Civic points to similar concerns, encouraging the use of more private data stores. And Philip Sheldrake extends the point to talk about the dangers of collapsing our social and legal identities into each other.


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.

Decentralized Key Management is Tough but Powerful

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?

Seed Phrases and Private Key Storage

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 seed phrase storage devices has sprung up around this challenge. But let’s not call any of it user-friendly.

Key Revocation & Replacement

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.

Social Recovery

The other key management tool that is being considered by a number of protocols is the social recovery of keys. Vitalik has talked about this and the Holochain team has also been working on an implementation, but the basic idea is that you can designate other keys as a collective authority that can revoke and rotate your keys for you.


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.

Takeaways

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.