Registration - Add registration_locale metadata parameter

[Michael Jones]

Having metadata values without language tags likely simplifies things in many cases, but if we do this, we should let the Client say what language/script it’s using when providing human-readable strings or references to them as registration parameters. For this purpose, I’d propose that we have a parameter something like this one:

registration_locale OPTIONAL or REQURED. Language tag used for human-readable values or references to human-readable values that are supplied without language/script tags, represented as a BCP47[RFC5646] language tag value. This parameter is REQUIRED if any human-readable values or references to human-readable text are provided without language/script tags.

This was also discussed for OAuth Registration.

[Michael Jones]

Having thought about it for a few days, I’d change the proposed field name from registration_locale to default_registration_locale, so the meaning is clearer.

[Michael Jones]

Instead, we'll say that if registration parameters are sent without language tag values, the parties can not make any assumptions about what language and script they use.

[Former user]

Suggested text (in its own paragraph or section at the end of the Client Metadata section):

Fields with human-readable values or references to human-readable values, such as client_name, tos_uri, policy_uri, and client_uri, MAY be sent with language tags by applying the rules set forth in Section 2.1.1.1.3 ("claims" member) of OpenID Connect Messages 1.0 [OpenID.Messages]. If such a human-readable field is sent without a language tag, the server and the client MUST NOT make any assumptions about the language, character set, or script of the value string, and the value string MUST be used as-is wherever it is presented in either the client or server UI. To facilitate interoperability, it is RECOMMENDED that any fields sent without language tags contain an internationalized UTF-8 string suitable for display on a wide variety of systems.

[Michael Jones]

The draft now includes the following paragraphs, which I believe resolve this issue.

Human-readable Client Metadata values and Client Metadata values that reference human-readable values MAY be represented in multiple languages and scripts. For example, values such as client_name, tos_uri, policy_uri, logo_uri, and client_uri might have multiple locale-specific values in some Client registrations.

If such a human-readable field is sent without a language tag, parties using it MUST NOT make any assumptions about the language, character set, or script of the string value, and the string value MUST be used as-is wherever it is presented in a user interface. To facilitate interoperability, it is RECOMMENDED that any human-readable fields sent without language tags contain values suitable for display on a wide variety of systems.