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
<[email protected]<mailto:[email protected]>>
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
<[email protected]<mailto:[email protected]>> 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-metadata
and the examples.
"client_name": "My Example",
"client_name#ja-Jpan-JP":"クライアント名",
On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P.
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
