Messages – Proposal to reuse locales member for specifying per-claim locales, rather than claim#BCP47 syntax

[Michael Jones]

Rather than using the "family_name#ja-Kana-JP" request form, it would be cleaner and more parallel to also allow a list of locales on a per-claim basis, just like we did for entire request set. For example, the "family_name" claim request could contain a member which is "locales":"ja-Kana-JP ja-Hani-JP".

[Nat Sakimura]

This has been discussed several times in the past. We should not reopen it.

[Michael Jones]

I do not remember ever discussing this specific proposal during a working group call. If we did, can you provide me the date of the call and the notes taken about it?

Parallelism and reuse is a clear sign of good spec design. In contrast, doing the same thing indifferent ways under different circumstances is a sign of muddled and inconsistent design.

The fact that the JSON member "locales":"ja-Kana-JP ja-Hani-JP" can occur in the top-level OpenID Request object to request locales for all claims, but that a different syntax is used to request locales for particular claims is a case of doing the same thing in different ways under different circumstances. It would be far more parallel for a claims request of the form: "claims": { "family_name": {"locales":"ja-Kana-JP ja-Hani-JP"} } to be specified than one of the form: "claims": { "family_name#ja-Kana-JP": null, "family_name#ja-Hani-JP": null }

(One could even make the case for allowing a "locales" member with the same syntax individually beneath the "userinfo" and/or "id_token" OpenID Request object members as well, allowing locales to be specified separately for the userinfo and/or id_token return values. The most local "locales" member would be the one used for each claim.)

None of this would change the format of the returned claims when multiple locales are employed, which would still be family_name#ja-Kana-JP and family_name#ja-Hani-JP. It just makes the request syntax more uniform.

[Michael Jones]

We decided on the 21-Nov-11 call to change the top-level "locale" member to "preferred_locales". Nat will discuss whether to make the syntax change to the requests with implementers in Japan and will report back to us.

Nat should also clarify the behavior of the top-level preferred_locales member in terms of whether and when #script tags get added to responses.

One issue is how to allow some locales to be required and some optional on a per-claim basis.

[Nat Sakimura]

In addition, in the call, following points came up.

In the top level or id_token or user_info claim level, language preference makes sense. E.g., ja > en > es, etc.

For individual claims level, it is not the preference but requirement.

So, using the top level "preference" syntax:

"claims": {
  "family_name": {
    "locales":"ja-Kana-JP ja-Hani-JP"
  }
 } 

introduces more confusion.

From the consistency, pattern of using

"claim_name":null

to show the required claim should be kept. Thus, the current syntax

"family_name#ja-Hani-JP":null

is better unless we change the claim request syntax to something like:

"claims":"family_name given_name address email"

etc. which defeats the purpose of using JSON for request.

[Nat Sakimura]

Re #338 changed top level locale to preferred_locale

→ 9d93650699b9

[Michael Jones]

Withdrawn, based on the difficulty of applying different parameters such as optional/requred to different locales in the proposed syntax.