Replace in-field string metadata with resource-level default fields

[emlun]

This addresses #1643:

We request that you do the following:

• Remove the in-field encoding of language metadata using Unicode tag characters
• Remove the in-field encoding of string direction using strongly directional marks
• Add a document-level field for the document language and a document-level field for default direction; such fields would be optional, since you have an installed base

New language and direction attributes on PublicKeyCredentialUserEntity seems like the most appropriate implementation of a "document-level field", since these are the only natural language string parameters we have. The new attributes won't work with currently existing CTAP authenticators, but their processing is specified as "best-effort" (at least that's the intent) so RPs should be aware that they might not work.

---

The following tasks have been completed:

• [ ] Modified Web platform tests (link)

Implementation commitment:

• [ ] WebKit (link to issue)
• [ ] Chromium (link to issue)
• [ ] Gecko (link to issue)

Documentation and checks

• N/A ~~Affects privacy~~
• N/A ~~Affects security~~
• N/A ~~Updated explainer~~

---

Preview | Diff

[emlun]

From 2025-04-11 face-to-face WG meeting:

• It's unclear what clients would do differently for different language values, especially considering these values (user.name and user.displayName) are likely chosen by the user in some way. Is the language field needed here?

[nadalin]

@selfissued can you review to make sure your issues have been resolved

[MasterKale]

From WG meeting @ May 28: We'll wait till next week's meeting when we can have a more direct discussion on the "best" path forward

[dwaite]

Question since I don't quite understand from conversation - is there a reason the UserEntity fields (language, direction and value) can't be encoded by the client into a single string behind the API using STRINGPREP, and decoded by the client when read? (theoretically read - I don't believe we expose displayName back into the API today)

This would mean that we are using STRINGPREP internally only, otherwise banning its use on the web-facing API. This allows for improvements on a more arbitrary schedule to the backing CTAP and platform specifications.

[emlun]

Closing in favour of #2308, per https://github.com/w3c/webauthn/issues/1643#issuecomment-2985299304.