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