Closed aphillips closed 3 years ago
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.
The i18n WG regards this issue as closed. Thank you.
5.4.1. Public Key Entity Description (dictionary PublicKeyCredentialEntity) https://w3c.github.io/webauthn/#dictionary-pkcredentialentity
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: