Personally, I think that this level of specificity is overkill. -- Justin
On 03/14/2013 11:42 AM, Mike Jones wrote: > > I agree that having unadorned values 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 and script 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 are provided without language/script tags. > > -- Mike > > *From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On > Behalf Of *Justin Richer > *Sent:* Thursday, March 14, 2013 8:02 AM > *To:* George Fletcher > *Cc:* oauth@ietf.org WG > *Subject:* Re: [OAUTH-WG] Registration: Internationalization of > Human-Readable names > > On the surface this does simplify things, but the issue I forsee with > it is that I want to be able to call "client.getClientName()" and > always get *something* out of it if there are *any* client_name fields > at all. So in this world if I take a client library that assumes en-us > and it talks to a server that only looks for es-cl, there's a very > real chance of the client name not getting set at all. I think that's > a problem. > > This is why I think the default field name (without the language tag) > really should be required and should be left undefined as to what > language and script it is. Essentially, "It's a UTF8 String, hope for > the best". If you want something more specific and smart about > localization, then you can support the language tags. If you just want > to have a string to store and throw at the user, then you can just use > the bare field name. > > In other words, we take what we have now (which works for a > non-internationalized case where everyone just assumes a common > language/script), and we augment it with features that let it be > smarter if you want it to be smarter. Make the simple case simple, > make the complicated case possible. > > -- Justin > > On 03/14/2013 10:47 AM, George Fletcher wrote: > > As a simplifying option... why not just require human-readable > fields to require a "script-tag". This way it is always explicit > what language/locale the text is for. It then becomes the > responsibility of the AS to return an appropriate response if > there is not a direct match between a request and the data stored > at the AS (and out of scope of the spec). > > Thanks, > George > > On 3/13/13 10:22 AM, Justin Richer wrote: > > So with what little feedback I've gotten, I'm proposing to add > text from the proposed webfinger and OIDC drafts for the > hash-based localization of strings, with the following properties: > > * All localized versions of fields are fully optional on both > client and server > * If a localized version of a field is included, its > bare-value (perhaps internationalized) field MUST be included > * All human-readable fields are eligible for this mechanism > (including any uri's for user-facing web pages, which can be > used to point to language-specific pages) > * Clients and servers can decide to use whatever > language/script they want to for the bare-value field, and no > assumptions can be made on either side about what that is > > I think that with these constraints, we can add functionality > to address Stephen's concerns without getting too complicated > or putting too much burden of support. > > -- Justin > > On 03/11/2013 06:52 PM, Nat Sakimura wrote: > > Similar work is in progress at Webfinger. > > See: > > http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html > > Paul is proposing the same syntax as Connect. > > 2013/3/12 Richer, Justin P. <jric...@mitre.org > <mailto:jric...@mitre.org>> > > It does presume a definition of "claim", which I suppose > we could turn to "metadata field" for DynReg and its > extensions to be appropriately limiting. But we also need > a good definition of what a language-tag-less field means, > and whether or not it's required if the other fields are > present or not (which is something that Connect is trying > to fix at the moment, as I recall from last week). > > So it turns into about a paragraph worth of text. Is that > worth it? I'm not entirely convinced that it is, but I'm > interested to hear what others think, particularly those > who *aren't* tied into the OpenID Connect protocol so > much. (I don't want to pick a solution just because it's > familiar, if we need a solution at all.) > > -- Justin > > On Mar 11, 2013, at 6:35 PM, Brian Campbell > <bcampb...@pingidentity.com > <mailto:bcampb...@pingidentity.com>> > > wrote: > > > > 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 <mailto: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 <mailto: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 > <mailto: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-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. > <jric...@mitre.org <mailto: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 <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > > > > -- > Nat Sakimura (=nat) > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org <mailto:OAuth@ietf.org> > > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
