Re: [webauthn] username and display name should not be mandatory (rp, challange either) and OS UX should be simplified if not present (#1915)

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.











-- 
GitHub Notification of comment by r-jo
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1915#issuecomment-1625728442 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 7 July 2023 17:34:52 UTC