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 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
