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. <[email protected] <mailto:[email protected]>> > > 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 > <[email protected] <mailto:[email protected]>> > 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. >> <[email protected] <mailto:[email protected]>> 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 <[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] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/oauth > > > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
