Why not email/username as user.id / user handle?

[dagnelies]

The specs says:

The user handle MUST NOT contain personally identifying information about the user, such as a username or e-mail address

Or here:

the Relying Party MUST NOT include personally identifying information, e.g., e-mail addresses or usernames, in the user handle

However, I fail to understand the reasoning behind it since:

1. the authenticators store the user.name / user.displayName anyway (that's also what they display when you let it pick)
2. the user id/handle is neither transmitted nor necessary during authentication (what you need is the "real" identifier like email/username)
3. ...what's the privacy issue anyway?!

[Firstyear]

Because these become baked into the credential in a way that may never change, this can have impacts on individuals when they need to change their name (think divorce, leaving domestic violence). Additionally it may also have privacy disclosure impacts on individuals as well.

The user id and handle ARE transmitted during authentication for discoverable credentials (usernameless flows).

However the displayName field can be changed post credential creation which is why these can contain info that the client side can update, and this displayname is NOT tranmitted during auth.

[dagnelies]

it was probably poorly phrased from me. Indeed the user id is transmitted into the authentication payload. What I meant is that it is of no practical use. What you store in your database as a RP is typically "username/email -> list of public key credentials". So basically, you have to either transmit the "username/email" directly or map the user id to username/email on the server side.

Regarding the user "name", from the specs:

it is a human-palatable identifier for a user account. It is intended only for display, i.e., aiding the user in determining the difference between user accounts with similar displayNames. For example, "alexm", "alex.mueller@example.com" or "+14255551234".

So basically, it is just an identifier. I don't really see the problem with things like "divorce, leaving domestic violence, ...". More like when changing one's username/email/phone. But in that case, the solution looks simple to me: create new credentials. Done.

[emlun]

The text in question was added in PR #1041 which was motivated by issue #578. It's more to do with not revealing the identity of an authenticator's owner without authentication, for example if a security key is stolen or dropped on the street. Authenticators are required to keep name and displayName secret unless they've authenticated the user, but may reveal the user handle without authentication.

As a concrete example, CTAP 2.0 reveals user handles without authentication when called with empty allowCredentials. This is also the default in CTAP 2.1, but many client platforms now set the credProtect extension to keep credential existence secret unless the user passes user verification or the caller already knows the credential ID.

[dagnelies]

Actually, when calling credentials.get with an empty allowCredentials list, it shows to me the list of users with name and displayName but without id/handle! At least, that is how it is on my system:

After all, listing a bunch of cryptic user id/handles would be quite useless. In such a case, the user would not be able to identify which one to pick.

So, to conclude:

• current browser implementations do expose private information like name/displayName
• the user id/handle is not shown (and would be useless to show users since cryptic)

...so I'm kind of puzzled that there are privacy issues for an internal id that's never shown while name/displayName are easely listed without requiring user verification.

[emlun]

Yes, but platform authenticators are presumably protected by the local login on the device. For external security keys the opposite is true: they may reveal user handles without authentication but not names and displayNames.

[dagnelies]

Ok. Thanks for the answers. So to summarize, because the users can freely be listed on external security keys, they require some cryptic handle to ensure usernames are not leaked. I understand that.

Nevertheless, from an outsider's POV, I find the property names could have been chosen much better, like:

user.id => the username/email instead
user.displayName => should be optional IMHO
user.securityKeyHandle => the anonymized thingy listed by security keys

... Or alternatively "anonymizedId" or something like that.

This would have been much more intuitive IMHO.

[dagnelies]

But well, that's how things are. Thanks for the explanations.

[Firstyear]

I don't really see the problem with things like "divorce, leaving domestic violence, ...". More like when changing one's username/email/phone

I want to address this specifically. Because these things are very related.

I used to work at a company that made your username "first letter of given name, and lastname". So for me, wbrown. Now imagine you married someone, and took their lastname. Lets say in my case I married Alice Green (exampple name). And I changed my name to William Green. I join this company and that's my username. wgreen.

Now something happens between Alice and I. Something that hurts deep inside, and causes huge pain. Every day at work I login with wgreen. A reminder of the person who inflicted so much harm.

It's not just a "change of username/email". It's a change of identity, and allowing someone to not have to have reminders of horrors. That's why it's so important that these values are not used as primary keys and identifiers anywhere because developers get into these weird "oh we can never change it" positions.