username and display name should not be mandatory (rp, challange either) and OS UX should be simplified if not present

[r-jo]

Description

PublicKeyCredentialUserEntity has mandatory fields by create(): name and displayName even if there is an anonym user id which is given to the server as "user handle" after a get() and what we can and should use for possibly private-as-possible user identification.

These fields should not be mandatory and OS UX should be much simpler if these fields are not used. For simplicity and privacy it is possible not to use phone numbers, emails or user names. OS should create a ux: Creating passkey for xyz.com web domain (which will be synced to your Apple/Google/Microsoft/Third Party pass manager).

I think there is a username fetish which can be tied to passwords that are going to be replaced with device based security (even if private keys are synced and stored, passkey is rather device based if I understand well). With passwords you could log in from everywhere and though you do not really need usernames if the pass is long enough, it was personal and intuitive and now people seem to think it is a must (which is not the case).

We actually do not need usernames anymore. The new way is to have a personal protected OS account even if the device is common. You protect it with biometrics and PIN. The user is tied to devices (actually OS accounts) that (s)he should own. We can use access tokens and crypto keys to create an implicit account and only if the user wants some more robust recovery, we can give a recovery key (a long password without username) or even better as I recon: a passkey which is synced and stored in the pass manager. For normal people it will be Apple and Google pass manager which is ok because those who dont care, save everything via Apple or Gmail anyways. Those who care (gmx, protonmail, 3rd party pass manager etc), can have the option for a third party pass manager as I see (os api).

Again: the user identity is actually the normally 1-3 personal protected os account (and efforts should be made that people create own os account on common devices). The implicit account can be verified via session management and subtle crypto (netflix pushed it and netflix uses it too), actually the same way as by passkeys: private key in browser indexed db non extractable key, public key on server. Of course clearing the browser is equivavalent to device loss, so at the right point, preferably with passkeys users can create explicit accounts where the private key is stored in a pass manager.

I feel some confusion because I do want the same user id/handle and in the specs you see: "the user handle ought not be a constant value...". Well I do not want a user (=user of 1,2,3 devices/os accounts) to create more than 1 account. I think it is again a perversion from the old times. I need one google account actually and if Google makes it possible, I can create more email adresses inside(!) where I switch easily. Nobody needs more than 1 google account but we create burner accounts because every *** website wants our email adress and it can be personal (our name). It is not private against Google that we create more accounts, it is private against web services who want our email adress.

I do not want to fight the system but I want to point out that actually the normal behavior would be to have private anonym accounts without username, email, phone number and add these information if and only if needed (I would add my phone number to Google for recovery since I might recover with my real identity through the phone company but actually 90% of web domains dont need email, phone or usernames).

I think it would be nice to give websites at least the possibility to offer truly private accounts easily without this complexity. However, with this API I have to write something like: xyz.com user as username and citizen of xyz.com as display name and the whole OS UX is overcomplicated. I will never use username or display name, I will use the anonym user id/handle.

In addition, for simplicity, rp and challenge fields should not be mandatory, either. Perfectly fine to use window.location.hostname and if OS needs a random value, they are more than capable to create for themselves if I do not create any... even better because I have no idea if it is needed and 16 or 32 bytes etc. is better or the whole thing is totally unimportant.

Related Links

https://w3c.github.io/webauthn/#dictdef-publickeycredentialuserentity

[Firstyear]

@r-jo Ultimately this actually comes down to the RP. In https://github.com/kanidm/webauthn-rs we enforce that the userid is a uuid, and the displayname can be any str input - even blank. This is needed so in a discoverable workflow we have to identify which credential matches to which account. We don't even need to store and PII, but we just need to tie it to the account.

The alternate is to have a way to id the user before to know what credential id's to present as valid in the authentication (non-discoverable) where the RP checks the userid/username first.

The displayname is just for the client side in discoverable to allow the user to ID what user account they are about to use to authenticate, but its NOT transmitted as part of that operation.

Finally, RP and challenge are mandatory and have extremely critical security implications for how webauthn works.

Webauthn does have it's complexities and issues, but "privacy" as you are describing is not one - it's simply up to RP's to implement privacy preserving implementations of webauthn that respect users.

[emlun]

Ironically, the only purpose of user.name and user.displayName is actually to enable username-less authentication. They are never conveyed back to the RP, and non-discoverable credentials do not use these fields at all.

I need one google account actually and if Google makes it possible, I can create more email adresses inside(!) where I switch easily. Nobody needs more than 1 google account but we create burner accounts because every *** website wants our email adress and it can be personal (our name). It is not private against Google that we create more accounts, it is private against web services who want our email adress.

This may be your own experience, but it is not up to the RP to decide whether the user gets to have multiple accounts. In fact, it is an explicit design goal of WebAuthn make it difficult for the RP to detect if a user does (see §14.2.). A user with more than one account does need a user.name and/or user.displayName in order to accurately pick an account to sign in as; this is in fact the only function of these fields.

Also notice in the definitions of name and displayName:

name, of type DOMString [...] The Relying Party MAY let the user choose this value. [...]

displayName, of type DOMString [...] The Relying Party SHOULD let the user choose this, and SHOULD NOT restrict the choice more than necessary.

So even if the RP doesn't care about these fields, it's recommended to still allow the user to set them.

That said, it could in principle make sense to make these fields optional and have the client prompt for them if the RP doesn't set them. It would even make sense to me that the user should be allowed to override the values set by the RP. But I'm not sure it's worth the added complexity - UI could become inconsistent between RPs, for example, which might be more confusing than helpful.

In addition, for simplicity, rp and challenge fields should not be mandatory, either.

I agree with @Firstyear, particularly in the case of assertions. It is critical that the RP chooses the challenge and validates its value echoed in clientDataJSON. If you don't need cryptographic proof of key possession, then you don't need WebAuthn - just use a cookie or local storage instead.

Registrations are slightly different, though. We already provide shortcuts for RPs not interested in verifying the attestation signature, in which case the challenge is also unnecessary. So in principle, we could make challenge optional when and only when the RP sets attestation: "none". But again, I don't think this very marginal benefit is worth the added complexity.

[Firstyear]

So in principle, we could make challenge optional when and only when the RP sets attestation: "none". But again, I don't think this very marginal benefit is worth the added complexity.

And we just know there are RP's that would make challenge optional when attestation is direct/indirect. Better to do the secure and correct thing by default.

[r-jo]

Hallo, thanks for the replies. I had more time with the standard and I try to formulate some concrete suggestions, then I reply to the replies:

SUGGESTIONS: If I read well, anonym user id came into picture thanks to Google. After having one, it should be considered to redesign the following interfaces as follows, making implicitly optional fields explicitly optional for less RP code and clarity and nudges to OS/pass manager UX implementers:

PKCEntity could be an empty interface if still needed (I do not think it is common practice to say something about inheritance in a base interface like "when inherited by then"... very ugly and a sign that the name field should be a level lower...): dictionary PublicKeyCredentialEntity {};

No apparent need for name to be required. Even Adam Langley in his example sets the name to blank which is a very strong sign if not a proof that the field should be explicitly optional (not just implicitly). dictionary PublicKeyCredentialRpEntity : PublicKeyCredentialEntity { DOMString id; DOMString name; };

No apparent need for name or display name to be required. Setting them to blank is ok and privacy friendly. In fact, for future applications, it should be recommended not to use name or display name if not already in use in the account I guess. dictionary PublicKeyCredentialUserEntity : PublicKeyCredentialEntity { required BufferSource id; DOMString name; DOMString displayName; };

No apparent need for rp or challenge to be required. Per default rp can be nameless, only with the domain name as id. I would say it is even best practice since using discovered domain name is better than self naming (and then error handling). Per default attestation is "none". If challenge is required when there is attestation, attestation parameters should be coupled and while attestation parameters are not required, inside attestation parameters the challenge field for attestation could be required. But I think if you need it later you will be forced to set it anyways...

dictionary PublicKeyCredentialCreationOptions { required PublicKeyCredentialUserEntity user; required sequence pubKeyCredParams; PublicKeyCredentialRpEntity rp; BufferSource challenge; unsigned long timeout; sequence excludeCredentials = []; AuthenticatorSelectionCriteria authenticatorSelection; DOMString attestation = "none"; sequence attestationFormats = []; AuthenticationExtensionsClientInputs extensions; };

I am not very knowledgable yet so take this with a pinch of salt from an amateur who has not very deep ideas about webauthn (and not klugscheissen): the whole API could use a rethink where it does not hurt much (at least notes or required -> not required transitions which is better as the other way round since there are already implementations running): around attestation vs no attestation and platform authenticators vs. roaming authenticators I guess. Especially decoupling attestation would be great for RPs who actually are supposed to implement it. I have the feeling that at least 95% use cases will be with platform authenticators and without attestation.

REPLIES: emlun:

• I think user.name and user.display name have 2 purposes: for accounts that already have username and for users who created 2+ accounts to a domain. Then and only then (!) it is nice to see an account chooser in the pass manager to know which account to use.
• From a business perspective it would be totally ok for the RP to enforce one account for one human per domain. You do not have 2 accounts by real-id-businesses either. So if I know about a user that has a passkey, I will not offer to create one. Having multiple accounts makes no sense (ironically, misused usernames caused this mess that people create burner emails and burner accounts because they do want to stay anonym). Furthermore, in a business sense it is actualy cheating to create mutiple accounts. People often try to get free stuff on multiple accounts and it is not ok even if possible!
• A user is still totally free to create multiple accounts, especially on an anonym-first domain, they just need to fire up a different browser where I do not have access tokens or crypto keys. Then and only then I would offer to create a passkey since it is a new user to me. In the pass manager UX then they can and have to deal with mess they made which is the same mess if I just leave the 2 username fields blank. Thanks to the 2 different user handles they have 2 accounts with blanks for the same domain. They have to create their own fake usernames or account identifiers like A, B, C... (which they can do). I just wanted to clarify: not OK but totally possible to create multiple accounts. All I want is a simplified user experience for my normal not cheating users: no account chooser, no confusion etc. As things are now, I make an effort to create a privacy focused usernamless service and I get punished by the API and the UX and feel pressured to insert usernames in the system.
• My point is: if you try to create anonym usernameless accounts you get punished with a confusing UX instead of rewarded with a more simple(!) UX than with usernames like create your passkey for xyz.com (no more: no account chooser with one account item listed without username which is just horror). Bad UX is implicitly also the responsibility of the API (!) since you cannot/should not write an if-else around blank fields (ugly). However, if the fields are not required, UX programmers have to write if-else around whether there is a user name or display name field and I hope their solution will not be to put blanks, but rather simplify: passkey for xyz.com and thats it. The problem is that it is unusual not to have usernames because it is such a broad (and bad) practice. It became so misused with email adresses that we even have now a user.name and a user.displayName in this independent allegedly privacy focused API, required, alongside with an anonym user handle/id.
• No, if an account is usernameless, it is usernameless and there is NO choice to create a username because it makes no sense and worse: I will not store usernames which then end up being email adresses and personally identifiable data and I get a EU/California fine. I have the RIGHT as RP and service provider to deny storing usernames that MAY be personal. As I see, in the Apple/Google/Microsoft/Chrome UX the users are totally free to name their usernameless accounts on my domain something if it makes sense to them. Actually, here you may be right, it is not up to me if they create 5 accounts (or rather I cannot really do anything unless I make it a real identity account which I wont) and how they name it in their pass manager/on their device (actually I dont care). But it is up to me not to offer creating passkeys for existing accounts, only replacing them.
• Well these 2 fields are so unimportant that you can overwite them as of NOW in android, ios, windows... OS or rather pass manager implementers only care about the user id/handle when identifying accounts.
• I never said anything about challenge in assertion. In fact, that is the only thing I found important to check (and of course create dynamically secure random challenge on server each time by signature verification) apart from the signature which is signed over a lot of funny stuff but also over the challenge I create dynamically. It is another topic but actually I think a signature over a dynamic server challenge would be enough. I am not a security expert but all other stuff including authenticator counter and uv flag can be set from a bad actor as they wish. Maybe the counter is interesting and we could sniff some funny stuff going on but I do not think it is worth the complexity. You may need a more robust underlying signature data by roaming authenticators, it is out of my expertise. It is a bit confusing though.

firstyear:

• as far as I can see there are different interfaces for challenge by create() and get() so totally possible to leave challenge optional (as an input from a RP!) by creation where without attestation you as RP never even touch that value again so it is very confusing why a RP who does not make use of attestation should give a random number. If it is not used at all without attestation, why, if it is used for something why the heck should that kind of bug source be allowed where each and every RP has to/will set some random (big enough, random enough, secure enough with subtle crypto, is it a problem that attackers see thanks to js what is used etc). If no attestation and still needed, authenticator or whoever needs it should set it.

• what I am suggesting is the option(!) for explicit usernameless accounts. If you leave a field blank and it is ok, it is implicitly an optional field. I just say: make it explicit. You can still use these fields as you wish. Nobody loses anything by making fields not required if they are in effect not required. If you need them in your flow, feel free to use them.

• making implicitly optional fields explicit means less code and clear api communication to RPs and to OS/pass manager providers too

• I checked Apple, Google and Microsoft implementations and they are way too complicated. In line with required (which are in fact optional) fields they provide a confusing UX with 3x as many texts needed if there is only one account per domain without any usernames.

• what I want is that make optional fields optional and then UX implementations could also make an if-else and not around whether the field is blank or contains only white spaces or so but whether they were used by RP in the RP input

• a usernameless account does not need an account chooser, the whole thing is easy and smooth: -> create your passkey for xyz.com -> use your passkey for xyz.com

• you only need usernames and display names if you have more than one account in your pass manager, and as of now you are even free to set them/change them/delete them

• it is a privacy issue in the sense that the standard should foster usernameless and make this possibility explicit in the API communication so that the UX will be rewarding towards usernamless accounts not punishing like now (not using usernames is confusing on the UX level even if it could be more simple)

[emlun]

What is the privacy issue with name and displayName? These fields are never conveyed back to the RP. The RP does not need to store them. They do not need to represent a unique user identity within the RP's user space.

It may be against some RPs' terms of service for one person to create multiple accounts, but it is not possible for the RP to prevent this using the tools WebAuthn provides. This is by design, because that is a privacy concern. An RP seeking to prevent this must use external tools (cookies, local storage, IP filtering, government ID proofing, etc.) to do so.

You certainly can set name: "Passkey for xyz.com", displayName: "Passkey for xyz.com" for every user if wish to actively sabotage the user experience for users with multiple passkeys on the same authenticator.

(I do not think it is common practice to say something about inheritance in a base interface like "when inherited by then"... very ugly and a sign that the name field should be a level lower...):

I agree, but it is far too late to change this now.

[r-jo]

Hi.

My issue is not really privacy and of course the privacy issue is not explicit since the 2 username fields are implicitly optional. I can skip them by leaving them blank.

If I understand well, the user handle came later on and until then, username was the id too like by practically all accounts with emails as usernames. However, the 2 username fields remain still required in the spec for no good reason, which makes it very ugly for privacy conscious usernameless services to deal with it (leaving it blank? filling with something like "user"? both? just one of them?).

In addition, you always have to fear what the UX implementations will be: will it be only awkward or flat out suspicious if you leave usernames blank? I think the spec has the responsibility to make not required fields not required and guide UX implementers. It should be a totally legal case to use only user id/handle. The api should communicate this.

As I wrote earlier, I do not try to prevent multiple accounts, I know I cannot prevent it, I just pointed out that in my opinion multiple accounts in a domain are not normal. I do not really know what you are talking about since cookies and local storage are

1. totally ok for session tracking (do you want a passkey verification by each request?)
2. you cannot prevent multiple accounts with them even if you wanted to since the user moves to a different browser and that was it. And if I have some privacy monster tools like ip tracking or anything to know that a user is someone that has an account by me I can totally prevent creating a second account. It is not up to webauthn design whether I can identify a user with a cookie or ip.

Either you or me is very wrong (probably me?) because you say things like sabotage something with setting the 2 usernames to the same. Even this implies I should set usernames that make sense? As I can see every pass manager uses the user id/handle for passkey entries. There will be 2 entries even if usernames are the same. And of course by leaving usernames blank they will always be the same. Is that a problem now or not?

Again, if I see in a browser that this user has a passkey I will not offer to create one, why should I. If somebody wants another account (even if they should not) they can just go to a different browser and when they create an account with a passkey they get a new user id/handle. I will not set any usernames but they can in their pass managers, for both of their accounts. I do not sabotage anything.

No, it is not too late to change anything. Tomorrow you could change the specs to what I suggested in my previous post since you only have to make fields not required (fields that are actually not required). Nothing would break.

And I did not get an answer to my real questions. Why not make those fields NOT required? I even published all interfaces how they should look (user.name, user.displayName, rp and challenge).

Problem is they are flat out wrong, ugly, make us RPs (each and every RP) write code that makes no sense like: rp: {name: ''} displayName: '' name: '' challenge: crypto.getRandomValues(new Uint8Array(32))

The API communicates to UX programmers that they do not have to think about usernameless entries. As an effect, now, today all 3 big implementations show account chooser for my domain even if there is only one account and the 2 username fields are blank!

This is all because of this bad API. There is a fundamental misunderstanding what is good and what is bad. Privacy issue is usernames and email adresses, your specs knows about it all, see privacy section. Your specs talk a lot about why user id/handle should have no personally identifiable information. And then reality kicks in and you cannot leave out the 2 hanging username fields and of course the whole UX is bloated.

As of now, the UX is sabotaged by a very bad specs. Since optional fields are marked as required, leaving out optional fields by blanking them leads to an awkward UX in reality instead of just: create your passkey for xyz.com or use your passkey for xyz.com

And please do not say that the specs says nothing about UX implementations because you should have take more responsibility. Make these fields truly optional and lets see if it has a positive effect on UX in the future. No way somebody by Apple/Google/Microsoft will write a code that: if a required field string contains only white spaces then... It is NOT the way. If a field can truly be blank, the field is optional and must not be required.

[r-jo]

My real questions. Please do not talk about privacy or something else other than my real question was/still is. My real questions are:

• Why not make those 4 fields NOT required? What would break, what speaks for leaving them required? I really see no argument there but I told you plenty of arguments why optinal fields should not be marked required.
• What is the actual solution for usernameless services? What should I do with these 2 username fields? Is it bad for some reason to leave them blank? If yes, why, if no, why are they required fields?

Thanks a lot.

[emlun]

• Why not make those fields NOT required?
• What would break, what speaks for leaving them required?
• Is it bad for some reason to leave them blank?

This:

That's what you get if you create two passkeys with name: "", displayName: "" with Chrome's virtual authenticator. And similarly, if you create two passkeys with name: "Passkey for demo.yubico.com", displayName: "Passkey for demo.yubico.com" on a YubiKey, this is what you'll see in Firefox:

How do you propose that "UX programmers [...] think about usernameless entries" when there's more than one? Remember, the browser cannot assume that the user will have only one credential per domain.

in my opinion multiple accounts in a domain are not normal

Nevertheless, there are many valid reasons a user may have them. When they do, the UI needs to be equipped to help the user distinguish which passkey goes to which account. That is why these fields are required.

• What is the actual solution for usernameless services? What should I do with these 2 username fields?

Ask the user for a value, maybe describe it as a "passkey label". You do not need to store that value; it will never be conveyed back to you. Or set all three to the same user ID, if you have one suitable for human consumption. Or generate a random name for the account and its passkeys. As long as there's something the user can use to distinguish passkeys for different accounts.

[emlun]

2023-08-16 WG call: There seems to be nothing more to discuss here; closing.

[r-jo]

Hi, of course there may be multiple accounts, I said it should not be the default thinking. The default should be one account and then the UX would be very nice and simple. In case the user creates more accounts, the user has to set appropriate labels in the pass manager. It is not possible to control the pass manager label from the server side. Thinking more about it, my opinion became just stronger: the username fields should NOT exist. It should be a minimum to make them optional instead of required.

The internal logic of webauthn is usernameless and it will be extremely confusing if this thing is not cleared. I would make them optional because deleting them is not backward compatible. Actually implemetors should also be warned to handle absence of this fields if made optional. I know it is a mess, but it will be a bigger mess if you leave it as it is.

For more details and the first website people struggling with this check out: https://stackoverflow.com/questions/76330306/user-name-and-displayname-change-for-existing-passkey/76663224#76663224 https://stackoverflow.com/questions/73562080/webauthn-how-to-get-rid-of-the-username-requirement/76920460#76920460 I provided answers too if somebody is interested.

I do not have time for this anymore. But I am 100% convinced, more than when I created this thread some time ago that this is a crucial mess up. It is not just simply logiacally awful to force usernames in an otherwise usernameless logic but messes up people who try to implement passkeys in their web service.

Moreover, the BAD pass manager UX is also because of this mess up. Even if only one account (which should be NORMAL) there is a lot of unnecessary text in the pass manager, an account choser as extra step blaahhh... instead of "use the passkey for xyz.com"

Simply put: you cannot and should not micromanage the pass manager labels from the server side. And in the webauthn logic, the 2 username fields are nothing more than labels. They can be changed by the user anytime in the pass manager without the "relying party" knowing about it. They are in the power of the user and the responibility of the user.

Even accounts with usernames would learn in absence of username fields at least the true nature of passkey authentication. But if any, an optional note field would be much better instead of 2 username fields. You want to sell passkeys as very easy but it would be better to be clear from the very beginning what is whose responsibility and pass manager labels management is not the webservice providers responsibility.

Again, it is a self-discussion about deleting username fields from the spec vs. 1 or 2 optional fields. MAking the fields required is 100% wrong.

[emlun]

Yes, WebAuthn doesn't need the usernames internally, but human-comprehensible labels are still needed for human end-users to understand and what each passkey is for.

Also, it occurred to me just now that your original ask is based on a false premise:

These fields should not be mandatory and OS UX should be much simpler if these fields are not used.

But the reality is that if they were optional, then the client UI would have to have more steps than if they were set, not fewer. As established above, it's not feasible to leave passkeys without a user-comprehensible label, so the client would have to ask the user for one if the RP doesn't.

Then if the user chooses to create another passkey for the same account on an additional authenticator, they'll probably want the same label on both passkeys. The RP is better equipped than the client to choose and remember a suitable "account label" for any future passkeys the user may choose to create for the account.

I fully agree that choosing suitable values for user.name and user.displayName in a username-less application is difficult - I'm experiencing this firsthand right now in a project I'm working on - but making the fields optional is not an appropriate solution. At its core, this is an inherent challenge in the very concept of username-less accounts.

[r-jo]

I did not answer your questions because I think I did them before but again:

If it is optional, not required, others who fear those screenshots you published can set the starting username or note fields in the pass manager. Your reply was an argument against deleting the fields not against making them optional.

If it is optional, I can decide that I dont give a shit about users who create more than one accounts. It is not normal and I do not support multiple accounts and I do not use usernames or personal identifiers!

For such websites if a user creates multiple accounts, which it can, then it is of course his/her responsibility to manage in his/her pass manager labels... in my service, in a usernameless account, there are no such labels because it makes no sense to have more than one account.

Your thinking is very tied to the fact that everybody uses burner accounts and multiple accounts but it does not make it normal. Do you have more accounts by your bank? Do you have more real digital identity account in your country?

And no, I do not want to prohibit it, I cannot prohibit it but it is not my responsibility if a user creates 2 usernameless accounts in a web domain and doesnt have any idea which is which.

Hint: enter both accounts, know why you created them and why you need them how you want to distinguish them (you are on pro level in one account and the opponents are too strong and you want to create a new one where you seem to be an amateur and enjoy being super dominant, then call them pro and amateur in your pass manager, or call them 1 and 2 I dont care).

And I suggested for example

• until only one account, which should be the normal case, keep it simple, no labels, use your passkey UX etc.
• if multiple accounts and no help from the website (blanks now or in a well designed API not using optional fields) then the pass manager could label them 1,2 or creation time and the user can name them as he wishes

Another example, a usernamless account with the option(!) of email recovery could let the user manage the labels which could be the email adresses (if the user has no idea, enter account with label 1, check email, then replace label in the pass manager to email adress)

A nicer website could suggest the email adress as label. But actually, I would not do this because it makes usually no sense to have real users create multiple accounts.

The users are not babys. Websites should not micromanage things that they actually have no power or responsibility over.

[r-jo]

I really dont have time for this but you simply state logically false statements!

You do not even realize there are 3 possibilities for the 2 username fields or whatever pass manager labels you want relying parties to micro manage or suggest:

1. required in the specs as of now
2. optional
3. deleted

You repeatedly argue against 3. (and even if 3 was possible and desirable with a radical rethink, please note that I ACTUALLY SUGGESTED 2. and do not argue against 3 like you would argue against me and my suggestion because you falsely imply I want 3... I realize that 3. is too late now, also it is a more difficult thing to argue against. In addition, 3. is very radical since it goes against some typical wrong pattern of existing multiple accounts, correctly labeled with different emails or such. And I never said those websites should not set these email fields for the users in the pass manager for simplicity, even if the pass manager label is actually the responsibility of the user).

Let us see your last answer block, statement by statement: A: "WebAuthn doesn't need the usernames internally"

• thank God we agree, check

B: "human-comprehensible labels are still needed for human end-users to understand and what each passkey is for"

• no, ONLY IF there are multiple accounts to the same web domain... if you have one car, you dont label your car keys, if you have one identity card, you dont label them either, if you have one passkey for each domain in you pass manager (for simplicity, lets say you use apple that sync to your ipad and mac from your iphone in keychain and we consider apple pass manager) than the label is not needed since you have one entry for xyz.com
• I said 5x that we should consider one account per domain the NORMAL case, it is just a kind of a mental attitude, we still have to think about multiple accounts, of course
• if there are multiple accounts, you are right it is better to label them but the question is, in this ABNORMAL state, WHO should label them... last time I checked you can change these labels in the Google Pass Manager as user as you wish and happily overwrite any inital labels that were provided by the relying party with these discussed 2 username fields... the relying party will have no notification or whatsoever, which is totally ok because these labels in the pass manager are actually not the website owners responsibility to manage
• so yes, in the abnormal case of multiple accounts THE USER (!) better do some labeling... it MAY be convenient at first sight for both the website owner and the user if there is some kind of username/email in the system (which is not always the case and I think it should not be the case and the EU DMA may force website owners to provide usernameless accounts in the future per defaul with email and such opt ins...) but I would say it is just postponing the "problem" or responibility that actually the user has to manage these labels and it may suggest wrongly to website owners that they have to carry on with username-management in the passkey system too, even if it is logically usernameless... but it is a discussion between 1 and 2 not 2 and 3! I just say in my OPINION actually 3 would be best BUT I happily COMPROMISE to 2 (!)... I am not the API designer so let us see how web site owners and users manage with these fields but those website owners who want to OPT OUT of this should be allowed to WITHOUT a hacky way of setting fields to blank or current time millis or whatever...

C: "your original ask is based on a false premise" , "if they were optional, then the client UI would have to have more steps than if they were set" , "the client would have to ask the user for one if the RP doesn't"

• simply NOT true
• for the normals case of one account, the UX would be "use your passkey for xyz.com", easier cannot be
• for the abnormal case of multiple accounts, the UX would be more complicated but NOT more complicated than it is now, we need in this case and in this case only an account chooser with labels
• what you are referring to is some user labeling effort in the pass manager in the abnormal case of multiple accounts and secondary label management is not part of webauthn process UX (!!!)... and again, you are arguing against 3. not 2. which is very annoying, really! with 2. each and every relying party who wishes to label the pass manager through these fields CAN, and those who do not wish, they can do that too... again, I just silently say that 3. is the best design since it forces website owners and everybody to think the logically correct way but we discuss 2. here and your arguments are against 3
• so this extra step you mention is not part of the whole process, it occurs if a relying party decides not to label the pass manager fields with some username or email (because they may not have any) and the user is not happy with 1,2 or timestamps... in this case a user can and should re-label them but it is outside of the webauthn process and it is possible even now... and you cannot sweep this case under the rug since it MUST happen by websites who simply do not have usernames, moreover, we may encounter more and more such websites... it will be very messy if each and every website HAS TO come up with some own labeling logic instead of a well established pass manager behavior of labeling them 1-timestamp, 2-timestamp or such...

D: "The RP is better equipped than the client to choose and remember a suitable "account label""

• not true, it may seem to be in the case of usernames/emails but the user is as equipped as the RP to label multiple accounts and it is better if they do what their responsibility is... with usernameless accounts ONLY the user is well equipped to label the accounts
• messing with more platforms instead of getting syncing right is another problem I see that will bury this kind of passkey webauthn in the end, so you bring up another bad design that there will be no single pass manager... but in this case too, having the normal case of one account per domain avoids problems, and again, you argue against 3 and not 2... please let it be my problem to decide if I want to micromanage those users who create multiple accounts in my domain. But with number 2 optional fields: all relying party who think your way can happily micromanage their users... with number 2, NEITHER those are forced who think it is better (or in case of usernameless only possible) to let/make users manage their labels, NOR those who want to set these fields initally for them to mimic their old logic. I simply do not care and CANNOT care for users that create multiple accounts on multiple platforms for a usernameless website how they label their multiple pass managers... even if I had emails and such, I would not care to use the optional fields and the users should label their multiple accounts in their multiple pass managers... but again, please argue against 2 not 3

E: "I fully agree that choosing suitable values for user.name and user.displayName in a username-less application is difficult"

• no, it is not difficult, it is something a RP should not do, and if you force us to do with BAD API design, then users will see blanks, timestamps, 1,2,3 and A,B,C and domain names and whatever popping up instead of some unified way of their pass manager handling this actually abnormal case
• the pass manager should choose how to handle this and so the users will have a unified way across web domains who CANNOT or WILL NOT care about the abnormal case of multiple accounts. For example, they will always see 1-timestamp, 2-timestamp for ALL of the web domains where the users(!) create extra burner accounts and the RP opts out of setting username fields because even if RP cared for burner accounts and helping users labeling them, usernameless accounts simply cannot be parenting users. And users will and must learn to label burner accounts themselves.

Please RE-THINK, I still have some hopes:

• do not argue against 3, 3 vs 2 is another discussion, we discuss 2 vs 1
• usernameless RPs cannot handle username fields properly, it is not a challenge for them but it is where the problems of the BAD design pops up and will keep popping up... you cannot smooth away or talk away bad design, it will show itself in the end somewhere. Usernameless accounts or changing usernames are two example where it comes up. If a user changes the email address and it was used as label because the user uses burner account, it takes some effort from the user to re-label on all platforms... fortunately, NORMALLY with one account per web domain the server changes the username and that was it because the passkey system is thanks god logically usernameless: https://stackoverflow.com/questions/76330306/user-name-and-displayname-change-for-existing-passkey/76663224#76663224
• it is possible (and for some usernameless websites a MUST "thanks" to the bad design) to handle these required fields with blanks, timestamps etc. (but for example not possible to use enumeration since users can delete pass manager entries so only a pass manager can realyl handle enumerations) but it is UGLY and HORRIBLE and a DESIGN SMELL
• moreover, pass manager implementations will be ugly too... there is an EXTRA step (account chooser) in the pass managers now because of this DESIGN HORROR... should pass managers supress these fields until there is only one account per domain? should they suppress them when the REQUIRED field comes with a blank or should they suppress them when it is a timestamp? No wonder they just use them and show them even if blank. They SHOULD definitely suppress them when the RP wants to omit these fields which the RP as of now CANNOT communicate to them... they should internally label them with 1-timestamp etc. and show 1-timestamp and 2-timestamp or so ONLY IF there is another passkey created later on with different anonymous id to the same domain... but as of now the pass manager implementors always get these 2 text fields and they just build in extra texts and extra account choosing steps instead of "create your passkey for xyz.com" and "use your passkey for xyz.com".

[r-jo]

And I am not happy that this thread was closed! It is very hostile towards open discussions. Forcing username fields will cause problems whether you close discussions about it or not. Let us close it after some time like 6 months so that other people may discover this topic better and tell their opinions. RPs just start to implement things.

[ryanshahine]

@r-jo

Your points are valid, but it's essential to recognize diverse user behaviors and needs. People often manage multiple accounts for various reasons: personal, work, testing, and more. While single accounts might work for some, many users appreciate the flexibility of managing different accounts efficiently. Comparisons to bank accounts or digital identity accounts don't fully reflect the web service context, where varying roles and purposes call for multiple accounts.

Do you have more accounts by your bank?

I do have multiple accounts at one bank.

The core issue you've raised seems to be more about the UX design around the passkey management process, rather than the necessity of name labels themselves. Instead of focusing solely on the name labels, perhaps a better approach would be to consider streamlining the user interface. For instance, if there's only one account associated with a passkey, the name selector could be skipped, and the user could be directly prompted to enter their passkey. On the other hand, if multiple accounts are detected, the interface could show the account selector to help users choose the appropriate account.

By shifting the emphasis to refining the user interface and experience, we can address your concerns while still maintaining the necessary labeling for passkey differentiation. This approach could potentially lead to a more intuitive and user-friendly interaction, catering to both the single-account and multi-account scenarios.

[ragnarbull]

@r-jo while some of your points are valid you could have gone about this way better. Posting huge amounts of text, downvoting people who respond (literally the very people who are the WebAuthn spec members) and yourself being somewhat disrespectful (even hostile as you call it) never ever works to persuade anyone who is in a position to back your ideas.

Also as others said the security implications of some of what you're proposing (eg. not having a challenge) are high and show a lack of understanding (on your part) of the spec. Further, users should be allowed to create multiple accounts - imagine if you could only have one Google account with your security key and you need to delete it (and your account?) to make another. It's up to you as a RP to work through multiple accounts not the spec.

I agree some of the UX is not the best yet (eg. Sign-in when you the user hasn't set a key with that device) and many users are definitely confused by passkeys - it would better to have a single issue for these.

[r-jo]

hi i dont have time for this now, but i read your reply in 5 seconds in my email so i must add my part

• i was frustrated because the tech is good but it is messed up, i spent plenty of time implementing it, studying it (only profis will do it, not small websites so it cannot be this way a success just saying...) and in the end I will not use this (but ECDSA in the browser instead)... so yes, please take our frustration, there were easy years you had, you present a product and we "RP"s are the users actually and if I think it is sh** I want to say it out loud... you never had a boss to say it? I think if he is right, sometimes it is good to say it... churchill said: I did not have time to write a short speech, now I did not have time to write a nice and short comment, it was long and rude maybe
• it was long also because the problem is complex... I think if googlers and microsoft people etc. cannot get it, it must be complex... I am specialised to solve complex problems and I am an RP and I took the time to implement this sh** so you could take the useful infos from what I wrote and be happy, your welcome! really. I mean it. without thinking high of myself (you can take 0 or 100% of it, you can analyse what I wrote etc. it is actually valuable)
• well I dont play the persuasion game, I play the truth game... you will never be successful if something is too complex, not clear for the users (RP) etc. I tried to help how to improve it... and some points are really extreme like these usernames, flat out logically wrong, bad interfaces etc.
• not having a challenge? I do not have time to check it out but I think somebody wrote that I wrote this and you took it from him/her, the only thing I find important and that I actually implemented is the challenge... the whole thing is nothing else than ECDSA with server challenge and I think the other parts are of no use for normal RPs but maybe for nobody (counter maybe but comeon)
• well Google ux just moves in the way like I say, accounts are collected and represented together... imagine just have one google account and email aliases.. vow... the logic should be inside if they want it... more google accounts is cheating with 15gb of drive space etc...and email aliases for anonymity not provided in the first place... of course you are allowed to have multiple accounts, nobody can stop you (without real id checks etc) but this SHOULD not be the default thinking and IF somebody has multiple accounts it is NOT a problem to sweat a little bit like managing the multiple passkeys in their pass manager...
• again, I spent a lot of time with this, thats why I remember after months what the main problem is:
  1. passkeys are pass manager related and plenty of people will never use pass managers, and implicitly making them use pass managers will be a mess, you should be transparent about it, solve pass managers first... be transparent about it... and again, a passkey has actually some but much less advantage against passwords in a pass manager... I would say I actually prefer a scheme like bitcoin: they changed to complex backupable english words (I would just use 25 character string like a widows recovery key) and derive ecdsa private key... so you have a paper or otherways backupable secret but you actually use ecdsa with pass manager all the time... passkey will have the problem even if well implemented/specsed that some people just want to have more control (not my father but like my mother) and for these people RP must have a different auth method than passkeys... or passkeys have to become backupable (again, then you have to face it just became again fishing inresistent... trade offs... on windows I enter google per default with fingerprint now and if people get used to this, it will be very rare to use backup keys/recovery keys/passes etc. but I think if you want to be overly successful you have to make it backupable better, on paper too... main thing that 99% of time trusted device+biometrics (or strong device pass which is now the weak point)
  2. too complex because of ubikey people and device based original design... it sounds laughable but you really just should start again fresh without yubikeys and get rid of anything else than ECDSA, actually what apple did and google and forced it...
  3. and really this username thing is actually complex, I wrote about this in stackoverflow but I dont check my account because I have to work hard and I get nothing out of this as it seems... just frustration... but the problem is the LOGIC with anonym user IDs which you do have and which renders the 2 username fields disturbing and pointless, it is in the power of the user/pass manager to manage this, still it is there for RPs to give a default value... you actually did the right thing to implement anonym user IDs (google I guess and appple) but then some other guys came who wanted to stick to usernames and emails because traditionally this is the thing (WRONG) and you wanted both the right thing and keep the username thing to make the transition to passkeys smooth... but it is a LIE to RPs because it is another model and everybody should learn this new model: managing usernames and stuff is for the users and pass managers to distinguish between multiple accounts IF they have them which they should not! one account per web domain with backupable secret key and ecdsa private key should be derived from it (would be even more NSA resistent :) there may be US politics behind this, not wanting to get away from emails and usernames and some crackable ECDSA :) but I am not good enough to understand this part but I had a feeling that it might be even crackable as of now... and not really clear whether apple, google, microsoft or pass managers create the passkeys...

so the RPs should write one-account logic without usernames and yes it would be great to have this by google etc... do you have more apple IDs? it is just like email is not always anonym and you want anonym accounts etc... or cheat with drive space... then you need an alias email for the same account and google may give you 3x15gb... not more

[ragnarbull]

I'm going to mostly ignore the end of 3. for obvious reasons except to say that of course there are benefits in pushing WebAuthn for all of the players you mention; but there are huge benefits for users too both in security and in ease of use (the UX needs work as we all point out). Also what's not clear about how discoverable creds are created? It's not some conspiracy... you can create your own authenicator and get it FIDO certified.

If you also want something more secure for your app and that still uses WebAuthn then derive keys using the PRF extension (unfortunately not available on all OS/client/authenticator combos) and hold the final login until these have been derived, set and the data decrypted (ie. E2EE). More than happy to share code if you're interested. And yep some of it is defintely "hacky" when trying to go usernameless and anon but ironically this actually gives your users greater privacy. Also I'm sure you've heard of the Signal Protocol - that's probably what you're looking for but it is very complex and probably easy to make a mistake.

Like I said, some of what you're saying is great albeit mashed up with some topics that no-one wants to discuss, at least on GitHub. PS. you have "...not be mandatory (rp, CHALLENGE either) ..." in the issue title and also mentioned it.

[r-jo]

hey, thanks for the reply, I am not looking for anything else than a great way to provide my users a simple and secure authentication solution: trusted device + biometrics (device code)

of course webauthn can be implemented great, I enter my google account on a windows machine with my fingerprint, vow (on my linux pc hmmm...)

the question is the broader design and whether it will be (should be) widespread, will 50%+ web domains implement it?

of course not, because it has the flaws I discussed... the biggest problem is that a ruling solution requires the secret to be backupable (like bitcoin BIP39 or something)... or else the whole thing is federated again (apple, google, pass manager) and nobody wants to (and nobody should want to) be dependent of the pass manager completely... the secrets must be exportable... that is my opinion and if only 10% of people think so, no web domain or service will implement only passkeys in this form... and what is actually the big advantage of passkeys IF there is a backupable secret key anyways? you should have understood that there always be some backupable secret key because why should I add passkeys if I already use a recovery key (if the user wants it, on paper, if the user wants it easy in pass manager with some local disk encrypted backup etc...) and the browser can do ECDSA too, just like passkeys? the only thing is missing is biometrics. I would have never implemented passkeys if there is a better way for biometrics on the web.

the trade off is you DO have a readable backup but you hopefully rarely or never really use it... if you create passkeys this way, there will be other solutions and why would I complicate my life with passkeys? I can do it in the browser (now without biometrics because webauthn has monopoly)

but my REAL SMALL problem is that you do not even consider minimal changes like making username fields NOT required... you do not even discuss what is right what is not right... you do not even seem to understan that the whole webauthn logic is usernameless, you did it this way and then required 2 username fields...? come on!

I do not want to circumvent it, I do not want to hack it, I want to write 5-10 lines in js with the really important fields, I want to know from the interface and specs which fields are really important... and that is it... the UX cannot improve on BAD LOGIC! what should a UX writer do if a fied is REQUIRED? then they have to do something with the string inside, even if it is ""... the fact that people want to put "" is a proof that something is smelly (should not be required field.... if the field is not required, the UX implementer HAS to create an if-else... if it is not there, vow, then no field... then they think about it, vow, if it is not there, one account, no multiple account, we do not need 80% of UX stuff here... just sign in to xyz.com with your passkey, that is it!

if a second account is created with a different id, then we prompt the user to manage the username labels because logically it is NOT authentication logic by passkeys but pass manager multi-account labeling logic... I can change this label on android now and I can sign in...

PS: I do not have the time but at one point challenge is crucial (the random server challenge that is signed over) at another point there is some challenge we never do anything with, as far as I can remember it has something to do with attestation that is not happening 99,9999% so we have to generate a random something that has no use... it may only be bad if an RP gives a non-random something... if we do not need it, we should not be made to create it, it is obvious... again, if someone needs it, it can be optional and if there is no challenge, the party that actually does something with it and has more security knowledge than an average RP creates a random something... PS2: did anyone by webauthn really implemented as an RP the stuff? because it is a great practice to face your monster... I did it, it is horrible, one can do it, full with not needed required fields, you questions yourself the whole time why they are required and then after some time and work you realize the whole thing is messed up: overcomplicated reality-fern start if you ose all your devices you are out... then apple, google etc. wants something commercially, and they do it their way, especialyl apple cares nothing about windows, linux, android... buy all apple and then everything works great, synced etc... or use your iphone to log in... come on! and somebody (google) makes it usernameless but the username fields stay there etc... the whole thing is a big mess up instead of a nice design with super math like ECDSA, preferably deriving ECDSA keys from a backupable secure key that is readable to humans... the logic should be trusted device + biometrics and start again, not this historically grown monster that fido2-apple-google-microsoft-webauthn sh... is

[r-jo]

some questions:

• "no one wants to discuss" I mean, who are you to know this? and where to discuss, I mean actual RPs?
• did you make a working example? I created back then an actually working implementation without any libraries, pure js, pure java, pure math, worked on apple, android, windows (with face id and fingerprint)
• there are 2 challenges in create options and get options, I talked about create options of course which should not be required because nobody uses it: https://www.w3.org/TR/webauthn-2/#dom-publickeycredentialcreationoptions-challenge

so tell me, why do we need to create in js a random number for this, if there is practically no attestation logic we want or even if we want, apple simply does not implement it? why is it REQUIRED? I mean all you actually need are the code below, and PLENTY of other stuff you must include with blanks or default values that 99,9999% will use but are not default in the specs... the real deal is generating the PID on server, giving by creation, choosing algo, then by get give a random challenge and check the signature later on server with the public key... it would also be nice if someone who actually wants to be this widespread provided the MOST simple code needed, without libraries... I mean I even had to write derToRaw() functions etc... getting info out of signature is a nightmare... it could be EXTREMELY SIMPLE code on client and server... it is not that complicated, I did it in js and java, but I can tell you now that an avergae RP will not want this and even if wanted, not capable, and not because it is that complicated but because the very simple stuff was made overly complicated with design horrors... I mean next time a good test: gather 10 RPs and if they cannot do this in a day and have a joyful face at the end of the day and practically no questions, THEN it is simply NOT OK yet... I mean you can write NOTEs in the specs... I could make this working in 2 weeks alone, with wonderful understandable specs for the 99,9999% of RPs... but actually I think even if usernames and other shit disappeared and good notes and good example codes, this is the SMALLER part where I wanted to help you with my actual RP implementer experience... the BIGGER problem is backup... I think you should find a backupable format and derive ECDSA keys from them, there is an RFC for it and of course you just have to check out parts of bitcoin stuff: https://www.rfc-editor.org/rfc/rfc6979.html the whole model is bad because if it wants to win, it has to be backupable... I mean passkey is not really secure if you have another system where you recover with gmail... then it is just hokus-pokus [I call the private key passkey]

function getPkcCreateOptions(pid) {
    return {
        //user is passkey holder (no names required)
        user: {
            //passkey id (PID) created on server, should not have personally identifying information
            id: _base64UrlToArrayBuffer(pid),
        },

        //only ecdsa 256 (rsa option means much more complex code)
        pubKeyCredParams: [{type: 'public-key', alg: -7}],
    }
}

function getPkcRequestOptions(challengeArrayBuffer) {
    return {
         //the random dynamic server challenge that will be signed over with the passkey and returned to server along with the PID and signature
        challenge: challengeArrayBuffer,
    };
}

[Firstyear]

so tell me, why do we need to create in js a random number for this, if there is practically no attestation logic we want or even if we want, apple simply does not implement it? why is it REQUIRED?

If you don't make it required people won't do it.

It allows a registration to enforce that the registration we are being sent is genuine and related to the caller that initiated the registration call. It prevents replays.

if it wants to win, it has to be backupable...

This is why RP's allow you to register multiple credentials.

You aren't backing up a single private key. You enroll multiple keys, and can individually revoke them in the case of loss.

I can tell you now that an avergae RP will not want this and even if wanted,

This is why you use libraries like https://docs.rs/webauthn-rs/0.4.8/webauthn_rs/ which does everything for you and has been through security audits to ensure properly handling of credentials.

There are genuine issues in the Webauthn space, but they are not the ones you are raising here.

I think this conversation has gone far enough though.

[arianvp]

You can see the challenge check in the registration even if it's not signed by an attester as a mandatory CSRF token. It still has its use even-though it's not signed!