The value of the explicit locale field is that it provides locale information
to servers that want to use it without having to use any explicit language tags
in the single-locale case. I guess I don’t see the complication here. With
this solution, in the single-locale case, all fields would be passed without
language tags (simple for both client and server), and a locale would be
provided by the client (simple). The server would store the locale but
otherwise could ignore it if it knew that it was in a single-locale deployment.
I just don’t see it as being very hard for a registration request to include
“default_registration_locale”:“en” and for the server to store it and return
that value, but otherwise ignore it, if that reflects the realities of your
particular deployment. :)
--
Mike
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Wednesday, March 20, 2013 12:11 PM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable
names
I agree that I'm seeing things from the single-language and single-encoding
perspective here, and that's the use case I'm currently solving for with my
development. I want to see this one remain simple, and I think we can do that
without breaking other use cases.
I would argue that multi-script languages (such as Chinese, Japanese, and
others) are all cases where you're going to assume multiple languages, and the
tags would be necessary for real use. So client and AS would both need to know
how to deal with the multiple different tags, and smart ones would be able to
effectively ignore the default field. The default, scriptless field could be
for any one of the supported languages at the AS or Client, and it'd
effectively be a backup, internationalized version, the one that you use when
there's nothing else more specific to use.
I guess what's getting me stuck on the explicit locale field is that I'm not
seeing much value in requiring it over George's proposal of always using
language tags on everything (which I also don't like, but for different
reasons). Having the information doesn't mean that you can do anything
intelligent with it, either, but I can see the argument that it makes doing
something smart possible. But on the other hand, we already have a mechanism
for doing something smart: using the explicit language tags directly.
Also, note that the AS doesn't need to render any characters for tos_uri,
policy_uri, and other _uri options, just for client_name. That's why I was
making the distinction in my explanation below. You might want to give the user
the right option, sure, but a served webpage has a much better chance of
getting the locale right dynamically than an included string would have
(approaches like user preferences, browser settings, etc. -- everything that's
used today on web pages, in other words). This is why I think that the _uri
claims are in a different category and we're talking almost exclusively about
client_name here.
I think, ultimately, that I need to think about this more.
-- Justin
On 03/20/2013 02:30 PM, Mike Jones wrote:
I suspect you only feel that leaving the locale information out is OK because
you (and I) live in a culture where it’s not needed to adequately render
characters. I’d actually defer on this decision to Nat and others from Japan
and China (and I think Korea?) where I believe that this information is
essential.
For what it’s worth, it’s more than just client_name. It’s also tos_uri and
policy_uri and potentially client_uri.
Also, having thought about it for a few days, I’d change the proposed field
name from registration_locale to default_registration_locale, so the meaning is
clearer.
Nat and others from Eastern cultures, what is your opinion on this?
Thanks,
-- Mike
From: Justin Richer [mailto:jric...@mitre.org]
Sent: Wednesday, March 20, 2013 10:43 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org<mailto:oauth@ietf.org> WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable
names
I would say that claims without a language parameter, which I would make
REQUIRED in the presence of other claims, would be treated as UTF8 strings with
no guarantee of what language, script, or other locale-specific information
would be in there. It's a default string, and it's the best the client can give
if nothing more specific is useful. And servers would have to accept this
default string and do their best with it. A service provider can publish their
expected default locale information in either discovery or service
documentation, and clients that want to tweak things for specific service
providers can do that.
The server can display it (because it's a string that'll always be there, if
any version is there), but a server that doesn't do internationalized strings
very well might not get its display correct. Since displayable text this is
likely to be dumped into the middle of a webpage that has its own character
encoding and other considerations anyway, so it's not guaranteed that
specifying a locale will always help here anyway. This is just for the
displayable text, which right now is only the client_name field in OAuth and
OIDC: for URLs (the other "human-readable" field), it's a moot point, because
the server's just going to spit out the URL itself into an href of some flavor.
The server doesn't have to deal with any kind of encoding or text/script issues
here.
As a server developer, it's just another thing that I *have* to track and deal
with on the client model, even if I don't want to support the rest of the
multi-language tags in my service. As a client developer, it's one more thing
that I *have* to specify when I send things to the server. I don't see how
requiring its specification is going to really help interoperability, and I can
almost guarantee that implementations will just leave it off even if marked
REQUIRED (like how many, many documents in the wild that are supposed to have a
character-encoding field of some type just leave it off).
I think that it's a lot of work on both sides for just client_name.
-- Justin
On 03/20/2013 01:27 PM, Mike Jones wrote:
How would you do this instead then?
________________________________
From: Justin Richer
Sent: 3/20/2013 10:25 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org<mailto:oauth@ietf.org> WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable
names
Personally, I think that this level of specificity is overkill.
-- Justin
On 03/14/2013 11:42 AM, Mike Jones wrote:
I agree that having unadorned values likely simplifies things in many cases,
but if we do this, we should let the Client say what language/script it’s using
when providing human-readable strings or references to them as registration
parameters. For this purpose, I’d propose that we have a parameter something
like this one:
registration_locale
OPTIONAL or REQURED. Language and script used for human-readable values or
references to human-readable values that are supplied without language/script
tags, represented as a BCP47[RFC5646] language tag value. This parameter is
REQUIRED if any human-readable values or references to human-readable are
provided without language/script tags.
-- Mike
From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>
[mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Thursday, March 14, 2013 8:02 AM
To: George Fletcher
Cc: oauth@ietf.org<mailto:oauth@ietf.org> WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable
names
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<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
