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