I would say that claims without a language parameter, which I would make REQUIRED in the presence of other claims, would be treated as UTF8 strings with no guarantee of what language, script, or other locale-specific information would be in there. It's a default string, and it's the best the client can give if nothing more specific is useful. And servers would have to accept this default string and do their best with it. A service provider can publish their expected default locale information in either discovery or service documentation, and clients that want to tweak things for specific service providers can do that.
The server can display it (because it's a string that'll always be there, if any version is there), but a server that doesn't do internationalized strings very well might not get its display correct. Since displayable text this is likely to be dumped into the middle of a webpage that has its own character encoding and other considerations anyway, so it's not guaranteed that specifying a locale will always help here anyway. This is just for the displayable text, which right now is only the client_name field in OAuth and OIDC: for URLs (the other "human-readable" field), it's a moot point, because the server's just going to spit out the URL itself into an href of some flavor. The server doesn't have to deal with any kind of encoding or text/script issues here. As a server developer, it's just another thing that I *have* to track and deal with on the client model, even if I don't want to support the rest of the multi-language tags in my service. As a client developer, it's one more thing that I *have* to specify when I send things to the server. I don't see how requiring its specification is going to really help interoperability, and I can almost guarantee that implementations will just leave it off even if marked REQUIRED (like how many, many documents in the wild that are supposed to have a character-encoding field of some type just leave it off). I think that it's a lot of work on both sides for just client_name. -- Justin On 03/20/2013 01:27 PM, Mike Jones wrote: > How would you do this instead then? > > ------------------------------------------------------------------------ > From: Justin Richer > Sent: 3/20/2013 10:25 AM > To: Mike Jones > Cc: George Fletcher; oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Registration: Internationalization of > Human-Readable names > > 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
