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. <jric...@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 <ve7...@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 <bcampb...@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. <jric...@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
>
>
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
