Fields name and given_name have unclear usage

[aphillips]

3.3. Accounts endpoint
https://w3c-fedid.github.io/FedCM/#idp-api-accounts-endpoint

name, of type USVString
The user’s full name.
given_name, of type USVString
The user’s given name.

The fields name and given_name appear designed to store user-friendly display names of the user. The example given shows both fields set to the string "Johnny". It is unclear if name is meant to be the full user name or is meant to be composed with given_name to form the full name. The example suggests it is meant to be the long name, but not spec guidance is given.

Usage of these fields probably should be clarified.

In addition, because personal names are natural language strings, these fields should be associated with language and direction metadata, to ensure correct display by the user agent or RP.

[TallTed]

Keep these in mind along with the rest of that page!

[cbiesinger]

In addition, because personal names are natural language strings, these fields should be associated with language and direction metadata, to ensure correct display by the user agent or RP

This is a person's name. Names don't have a language, right? https://www.w3.org/TR/string-meta/#single-linguistic-field says that localizable strings should have these properties, but names are not localizable. I don't think the concept makes sense for a name though. I am called "Christian Biesinger", what language is that in? How is an IDP supposed to determine the name? Same for the direction.

[aphillips]

Names do have a language (and are culturally affected in various ways)! See this long section of International-specs for details, including "example" names for use in specs (notice that some names are in other scripts or have more than one--or even two--representations, even in this curated list.

Many personal names are not translated or transliterated when shown in other language contexts, so "Christian Biesinger" might be your displayed name in most or even all localized contexts. And there is no requirement that an IDP perform any transformations to accomplish e.g. transliteration or otherwise localized presentation. It's fine for the value to just be a string--in fact, we want to avoid having to "know stuff about names" in this context.

However, language and base direction metadata greatly assists in processing and displaying such information and can often be computed or known from the user's setup. Providing slots for the metadata allows the appearance of a Japanese person's name, for example, to work better by selecting the correct font, or for the pronunciation to be correct in assistive technology. Or the display of a person's name in Arabic may be greatly improved if the base direction is set to right-to-left, usw.

Note that the term "localizable text" in String-Meta uses the I18N Glossary definition:

String content intended as human-readable text and not to any of the surrounding or embedded syntactic content that form part of the document structure. Note that syntactic content can have localizable text embedded in it, such as when an HTML img element has an alt attribute containing a description of the image.

This definition does not necessarily mean that the text requires translation or that it would or should be translated or localized. It simply means that the text is natural language (meant, at least sometimes, for human eyes), rather than being strictly a program-internal identifier or being syntax.

[aphillips]

I should probably add: a lot of applications (and FedCM might be one of them) are deliberately avoiding complexity in personal names, providing (as here) simple string slots to store whatever the user chooses to use as personal identity. As long as the application does not care (or provides only extremely minimal checking) of the content of the value, things work without additional data or effort.

However, beyond a certain point, applications have to deal with what turns out to be a fairly complex topic. CLDR has recently add locale data to assist with the parsing and presentation of personal names, for example. See here. Our group has a nice intro in this article which can also help.

Non-trivial applications that deal with personal naming often have a variety of hidden internal fields, including language metadata, to address this complexity (which includes a many-to-many presentation problem).

With that preamble, I don't think FedCM needs to be a "non-trivial application". I would suggest that you make it clear that name and given_name are separate fields, unrelated to one another. You might even rename them as full_name and nickname to better distinguish their usage (these are only intended as suggestions, please note).

The usage of these fields is probably application specific and you probably don't want to wade into providing anything normative at all, except to clarify what the original issue is remarking on: the given_name should probably not be composed with the name.