Seems reasonable to me.
On Wed, Mar 13, 2013 at 10:22 AM, Justin Richer <jric...@mitre.org> 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> > >> 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> >> 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>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 >> >> > > > -- > Nat Sakimura (=nat) > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
