5.4.1. Public Key Entity Description (dictionary PublicKeyCredentialEntity)
https://w3c.github.io/webauthn/#dictionary-pkcredentialentity
name, of type DOMString
A human-palatable name for the entity. Its function depends on what the PublicKeyCredentialEntity represents:
The name attribute of the entity description is subjected to RFC8266 content requirements (aka PRECIS), but there is no provision for base direction metadata or language metadata (see our document String-Meta). It is therefore possible that the name will not be displayed correctly to end users due to spillover or font-selection (or other language-specific operations).
See also 5.4.3:
A human-palatable name for the user account, intended only for display. For example, "Alex P. Müller" or "ç”°ä¸ å€«". The Relying Party SHOULD let the user choose this, and SHOULD NOT restrict the choice more than necessary.
This field ends up transmitted to the security key hardware, which is fixed-function, practically un-updatable, and which only accepts a single field. So, while changes in future devices could be imagined, any solution that adds fields will not function with any of the millions of devices already in existance.
Thus, while they are discouraged in the document, the systems for embedding this information in the string (1 2) seem the most promising. Their downside here is the encoding size: 24 bytes for many languages.
Encoding in the string is the only viable option in the short term.
On the other hand that will probably break authenticators with built-in displays.
I don't know that that can be avoided however if direction and script are needed.
Most helpful comment
Encoding in the string is the only viable option in the short term.
On the other hand that will probably break authenticators with built-in displays.
I don't know that that can be avoided however if direction and script are needed.