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]> > 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]> > 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]>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]> >> 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]> >> 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. <[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] >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/oauth >> >> >> >> > > > _______________________________________________ > OAuth mailing list > [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
