Passwords, Account Recovery, and the Privacy We Give Away

After years of building and using apps, a few things still frustrate me.

The first is that most apps still expect us to log in with a username and password. Who remembers all those credentials anymore? Keychain and AutoFill help, but there are plenty of exceptions. Some apps put their login flow inside an embedded web page. Others present username and password fields alongside social login and several other sign-in options. When app sandboxing and missing or incorrectly configured domain associations get in the way, AutoFill is little help. Every time I see a page like that, I am left wondering: which method did I use a few months ago?

Then there are financial institutions in Taiwan that require three pieces of information to match: a national ID number, a username, and a password. Some mask the username field as well. In practice, the username becomes the first password, and the actual password becomes the second. In the flows I have run into, my iPhone ends up treating that masked username as the password and saving it, while the actual password is left unsaved. So I still end up writing the real password down somewhere. That is ridiculous.

The second frustration is that apps often ask for additional information, such as an email address or a phone number to receive a verification code. The usual reasons are to check that you are a real person and to help you recover your account if you forget your login details. I often see this even in simple utility apps.

The third is that some apps ask for more sensitive and detailed information: a national ID number, a name, or an address. One reason is to make sure you register only once in their system. But why should I give a supermarket app my name and national ID number just so it can check that I have not signed up twice? Yes, PX Mart, I am talking about you. I am just buying groceries.

Passkeys help, but recovery still matters

The technical answer to the first problem is passkeys. Passkeys do not inherently require personal information, and they do not ask users to remember a secret. They move the secret from our heads to the devices we carry. There is no password-style “I forgot my passkey” flow. But a credential stored in a device or software can still become completely inaccessible. Account recovery still needs to be designed.

The second problem—account recovery and checking that someone is a real person—and the third—making sure that person has only one account in a system—are commonly addressed by collecting personal information. I keep wondering: do people simply not care about giving that information away? Do they care, but want the service enough to make the trade? Or has every app made this so normal that we just think, “What else am I supposed to do?”

A working idea: an app-specific Signature VC

After building several services with verifiable credentials (VCs), I started to think that VCs based on verification of official identity documents might offer a better approach: protecting privacy while helping with account recovery, proof of personhood, and uniqueness within an app. Here is the idea I want to explore.

My Personhood Credential system can already verify passports and issue an Anchor Credential. Next, I want to experiment with issuing another credential on that foundation. For now, I am calling it a Signature VC.

The idea is to hash user attributes, such as their name, date of birth, and place of birth, into an identifier scoped to a single application. I am considering the client app's private key as a secret input, together with the application ID as an additional input, with the aim of producing a high-entropy hash value. The application could store that identifier and compare it during account recovery. It could also use it during registration to check whether an account already exists.

I am wondering whether the Signature VC could be issued directly on the user's phone. After all, most signup and login flows do not currently involve third-party identity verification. Many apps have no reason to know who the person behind the screen actually is. Perhaps they only need to know: “This is the same person, and this person has already been verified.” Would that mean the app does not need a link to the Anchor Credential or to verify it directly? Perhaps what the app needs to check instead is that the Signature VC was actually intended for that application. Could binding it to the session and including the application ID inside the credential be enough?

These are questions I want to test, rather than a finished protocol. If a supermarket took privacy this seriously, I would probably use its app.

Does this reasoning make sense? Am I thinking about it too loosely? I am considering building a prototype on my existing credential exchange platform. If I have missed something, if you have built a similar system, or if you have relevant technical ideas, I would love to hear from you in the comments.