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

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.](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#sctn-non-correlatable-credentials)). 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`](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#dom-publickeycredentialentity-name) and [`displayName`](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#dom-publickeycredentialuserentity-displayname):

>***name***, of type [DOMString](https://heycam.github.io/webidl/#idl-DOMString)
>[...]
>The [Relying Party](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#relying-party) MAY let the user choose this value. [...]
>
>***displayName***, of type [DOMString](https://heycam.github.io/webidl/#idl-DOMString)
>[...]
>The [Relying Party](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#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](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#sctn-public-key-easy), 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.

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


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

Received on Monday, 3 July 2023 09:45:18 UTC