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

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 PublicKeyCredential**_Creation_**Options {
 required PublicKeyCredentialUserEntity user;
 required sequence<PublicKeyCredentialParameters> pubKeyCredParams;
      **_PublicKeyCredentialRpEntity rp; 
      BufferSource challenge;_**
      unsigned long timeout;
      sequence<PublicKeyCredentialDescriptor> excludeCredentials = [];
      AuthenticatorSelectionCriteria authenticatorSelection;
      DOMString attestation = "none";
      sequence<DOMString> 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](http://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](http://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](http://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](http://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](http://xyz.com/)
-> use your passkey for [xyz.com](http://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)

-- 
GitHub Notification of comment by r-jo
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1915#issuecomment-1625293277 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 11:47:03 UTC