`name` and `displayName` validation of empty strings leads to `InvalidUsername about webauthn-rs HOT 6 CLOSED

https://www.w3.org/TR/webauthn-3/#dictionary-makecredentialoptions

"""
user, of type PublicKeyCredentialUserEntity

This member contains names and an identifier for the [user account](https://www.w3.org/TR/webauthn-3/#user-account) performing the [registration](https://www.w3.org/TR/webauthn-3/#registration).

Its value’s [name](https://www.w3.org/TR/webauthn-3/#dom-publickeycredentialentity-name), [displayName](https://www.w3.org/TR/webauthn-3/#dom-publickeycredentialuserentity-displayname) and [id](https://www.w3.org/TR/webauthn-3/#dom-publickeycredentialuserentity-id) members are REQUIRED. 

"""

When used in a make credential, name and displayName are required per the above.

Webauthn in general is a poorly written and confusing specification.

from webauthn-rs.

Accidentally close, sorry.

from webauthn-rs.

I think per the spec we must enforce the name is set.

from webauthn-rs.

I'm with you that they should be set according to spec. Yet any string, even an empty string, SHOULD be a possible value.

from webauthn-rs.

The spec also used to let you strip and disregard UV in a lot of cases until the spec was updated to "strongly advise" people to check that. It wouldn't be the first time we've been stricter then the spec, and then the spec updates to reflect what this library does. So I'd rather be strict here, inspite of the spec. A string must have a non-empty value.

from webauthn-rs.

Fine. I'll keep a change around then. Too many UIs behave wildly different depending on the set name/display name properties and for our use case we have 0 identifiers of a user to put into these fields and don't want to add friction with an additional step.

from webauthn-rs.