authenticatorDisplayName should use a localizable language map

[timcappalli]

Related to #1644

Proposed Change

authenticatorDisplayName is currently a DOMString and does not support localization, specifically language codes and direction.

Change to a map following the String Meta spec: https://www.w3.org/TR/string-meta/#language-maps

"authenticatorDisplayName": {
    "en":    {"value": "This is English"},
    "en-GB": {"value": "This is UK English", "dir": "ltr"},
    "fr":    {"value": "C'est français", "lang": "fr-CA", "dir": "ltr"},
    "ar":    {"value": "هذه عربية", "dir": "rtl"}
}

[emlun]

Are you sure a language map is appropriate for this? My first impression was rather that authenticatorDisplayName is a single-language localizable text field - it's a user-configurable value that should only ever be presented back to the same user.

[emlun]

After the discussion at TPAC I've come around to agreeing that a language map may be a good choice. The ability to specify multiple languages may be most useful if a value is pre-populated by the authenticator vendor without necessarily knowing the user's preferred locale; if the user overwrites with their own configuration the map can simply be collapsed to containing a single key.

The language map type is a superset of what can be expressed by the single-language localizable text field, so the language map is the safer choice for forward compatibility.

[zacknewman]

Presumably the PR that goes along with this will provide a more proper "spec" for what constitutes a language map? The linked "spec" only provides two examples without actually properly defining its structure. Does the following Web IDL define it more properly?

typedef DOMString LanguageTag;

enum LanguageDirection {
    "ltr",
    "rtl",
    "auto"
};

dictionary LanguageMapValue {
    required DOMString value;
    LanguageTag lang;
    LanguageDirection dir;
};

typedef record<LanguageTag, LanguageMapValue> LanguageMap;

where LanguageTag must conform to RFC 5646 § 2.1.

Addendum

Disregard above. I should have exercised more patience and clicked on the embedded hyperlinks which do more properly define the structure.

[emlun]

@aphillips As @zacknewman points out above, it looks like String-Meta §2.1.4 Language Maps doesn't formally define (in WebIDL) the structure of a language map, only by example and later abstractly in language indexing (which is not referenced in §2.1.4). Would it be appropriate for String-Meta to provide a WebIDL definition like:

typedef record<DOMString, Localizable> LocalizableMap;

or should we define this locally in the WebAuthn spec?

[aphillips]

@emlun That's a great callout. I filed a tracking issue and will work on getting that published in String-Meta ASAP

[emlun]

Ironically, this issue is now obsolete with PR #2194 merged.