Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

A fair question but what would need to be pulled in is really probably only
a couple sentences (and reference) from
http://openid.net/specs/openid-connect-messages-1_0-16.html#ClaimsLanguagesAndScripts(note
the reference to 2.1.1.1.3 inside
http://openid.net/specs/openid-connect-registration-1_0-15.html is broken)


On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. <jricher@mitre.org>wrote:

>  My concern with this is that OIDC can get away with defining this
> multi-language structure because it defines the mechanism once (in
> Messages) and applies it to all user-readable strings throughout the whole
> application protocol, of which there are several. Do we really want to pull
> in that whole structure and mechanism for one field in client registration?
> I really don't think it should be something that's defined completely
> inside of DynReg for a corner case for a single field, but I also doubt we
> want to normatively point to OIDC Messages for this solution either.
>
>  There are also other ways to do this: Webfinger [1] for instance uses
> JSON structures to give language tags to field values, and has a default
> mechanism:
>
>     { "en_us": "my client", … }
>
>  The fundamental question is  this: should a client be able to register
> multiple names (in different locales) with a single client_id, or should it
> get a different client_id for each display language set?
>
>   -- Justin
>
>  [1] http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11
>
>  On Mar 11, 2013, at 5:54 PM, John Bradley <ve7jtb@ve7jtb.com>
>  wrote:
>
>  That is what I was thinking.   It would be up to the AS to determine
> what language and script to present based on the user preference.
>
>  While a large number of clients will be native and might be able to
> customize themselves for a single user during registration , we don't want
> to forget the web server clients that are multi user.
>
>  On 2013-03-11, at 10:49 PM, Brian Campbell <bcampbell@pingidentity.com>
> wrote:
>
>  FWIW, the closely related OpenID Connect client registration draft does
> have some support for doing this, which could maybe be borrowed. See
> client_name in §2 at
> http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadataand the examples.
>
>
>    "client_name": "My Example",
>    "client_name#ja-Jpan-JP":"クライアント名",
>
>
>
>
> On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. <jricher@mitre.org>wrote:
>
>> It was brought up at the in-person meeting today that we'll want to
>> consider issues around internationalization and localization of
>> human-readable fields like client_name in the client registration. Which is
>> to say: if a client supports ten languages and wants to present itself in
>> ten languages, should it have to register itself ten times with an AS?
>>
>> At the moment, I'm of the opinion a client with ten languages could
>> register itself ten times, or do something with the context in which it
>> runs to determine which human-facing language to use. Keep in mind that in
>> some cases (such as native clients), you'll be dynamically registering a
>> client for each user, in effect. In other words, I personally think that
>> this is a rathole that will cause more harm than good.
>>
>>  -- Justin
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
>  _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>