[webauthn] make username fields optional (do not delete them, but do not force their usage, either, which is hostile against usernameless services) (#1942)

r-jo has just created a new issue for https://github.com/w3c/webauthn:

== make username fields optional (do not delete them, but do not force their usage, either, which is hostile against usernameless services) ==
## Proposed Change

Regarding name and displayName in the spec I request **OPTION 2** here, an example spec change is in the APPENDIX:

1. keep these 2 username fields required
2. **make these 2 username fields optional**
3. delete these 2 required username fields
4. replace the 2 required username fields with an optional note field

My opinion is that actually option 3 would be best, but also radical, making it super clear that **webauthn has usernameless logic** and punishing the sins of the past, which made the abnormal case of multiple (burner) accounts per human per web domain a kind of accepted way of thinking. Website owners hijack personal information like emails or phone numbers and try to make money from it. As a consequence, users create burner accounts, and services like apple or proton start to provide "services" to create burner emails. However, **EU-DMA** is coming and starting from 2024 soon (2-5 years) it may be a MUST to create usernameless accounts and an opt-in flow for providing personal information like email accounts (if a passkey-like authentication system succeeds, recovery will be through trusted devices or in case all devices lost, through pass manager or a recovery code not through email).

An optimal compromising solution would be option 4, since it is very confusing to have 2 username fields and the thinking that is clear from webauthn examples is based on some real name + email address, which are 2 pieces of personal information and plenty of websites do not have both. It is actually rude from Apple, Google, Microsoft to think that every web service has names and emails and that is the way to go. This logic replicates an edge case and actually not a future proof one... If an RP wishes to provide some kind of help or hint to create a label in the pass manager of the user, one simple optional note field would suffice. Now **each and every RP is forced to deal with these fields**, some of us have no usernames at all, some of us have usernames, others only emails. We have **no idea or assurances** how pass managers handle if one of the fields are left blank or other hacky ways.

Making these **fields optional is minimum** if we do not want to force usernameless RPs to come up with some hacky solutions (each with their own) like blanks, timestamps, enumerations etc. It is absolute **horrible and hostile** towards those RPs that are actually doing the right thing: usernameless.

I have not heard any argument against making these fields optinal, only some arguments against complete deletion: option 3
Please see the forcefully very quickly closed discussion here:
https://github.com/w3c/webauthn/issues/1915

Also, the specs **should GUIDE pass manager implementors**:
- in case of the RP does not define the optional fields, an internal timestamp or so should be created for the entry, and the pass manager may want to **use a very neat and nice and simple UX** like "create a passkey for xyz.com" and "use your passkey for xyz.com"
- ONLY IN CASE a RP uses one of the optinal username fields or a user creates **multiple accounts** per domain (the abnormal case of burner accounts... side note: if it is desirable for some RP, the website owner could just create a logic for different selves INSIDE the one and only domain account) should a pass manager create a **complex UX logi**c where the suggested label is shown or an **account chooser with labels** is shown

Also, the spec would ideally GUIDE THINKING that in case a RP omits username fields and a user creates a burner account, it is the **responsibility of the user** to change 1-timestamp or 2-timestamp or whatever fields are shown in the pass manager since the RP intention is that a user should have one account, but if the user still thinks it makes sense to create more, the user must totally be able to label the entries **according to the same logic he created it** (pro-amateur account, main-burner, personal email - burner email etc.) Again, with option 2 no RP would be forced to provide or omit these fields, each and every RP could do what he thinks is best for them. But it should be made clear that even if an RP provides username fields, the ultimate power and responsibility to manage these fields is by th user. It is not my opinion, it **follows from webauthn internal usernameless logic**.

I would really love to **continue the discussion in this thread** at least 6 months before closing, if nobody can really argue against option 2. Again, nobody is forced when making fields optional, all RP that wish to help its users with usernames because they have this kind of logic in their account can do so (and then it is their responsibility to deal with things like changing usernames/emails and with this long run maintenance hell).
https://stackoverflow.com/questions/76330306/user-name-and-displayname-change-for-existing-passkey/76663224#76663224

However, **as of now, an open web spec is hostile towards websites** that have or wish to have usernameless logic and try to do the right thing: not collecting personally identifyable information from users. Yes, the highly praised **privacy comes with some user effort**: no email recovery or if they want burner accounts for whatever reason, they have to take responsibility and manage their own pass manager labels for their own multiple accounts.

I am looking forward to a healthy discussion but please write only in favor of denying my suggestion **if you really have some arguments** against making fields optional and please **let us not go down the rabbit hole of discussing option 3 or 4 now**. It is too late for that and I am not suggesting them here.

Also, if a website owner (RP) is reading this and agrees that these fields should be optional and pass manager UX could be more simple, **please join the discussion at least with a thumbs up or so**.

Thanks!


APPENDIX:

An example of how the change could be implemented.
It would have the very positive side effect that by creation we should not add this RP name field, either:
rp: {
name: ''"
}
No better relying party ID than the **automatically obtained domain name**, I would say it is somewhat a security risk if a web domain can push a made up name to the user facing UX and MAY fake another service. But again plenty of questions: how will the UX be if I add a blank string, will my domain name shown twice if I add here the domain name? The bad design that makes this field required is coming out of under the rug again...



A POSSIBLE SOLUTION TO HONOR THE REQUESTED CHANGE:
dictionary PublicKeyCredentialEntity {
};

dictionary PublicKeyCredentialUserEntity : PublicKeyCredentialEntity {
    required BufferSource   id;
    DOMString      name;
    DOMString      displayName;
};

dictionary PublicKeyCredentialRpEntity : PublicKeyCredentialEntity {
    DOMString    id;
    DOMString    name;
};



PRESENT SPECS:
dictionary PublicKeyCredentialEntity {
    **required** DOMString    name;
};

dictionary PublicKeyCredentialUserEntity : PublicKeyCredentialEntity {
    required BufferSource   id;
    **required** DOMString      displayName;
};

dictionary PublicKeyCredentialRpEntity : PublicKeyCredentialEntity {
    DOMString      id;
};

Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1942 using your GitHub account


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

Received on Saturday, 19 August 2023 08:06:57 UTC