Subject: [OAUTH-WG] Registration: Internationalization of Human-Readable names

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 11 Mar 2013 21:15:09 +0000

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

---

From: Brian Campbell <[email-masked]>
Date: Mon, 11 Mar 2013 17:49:35 -0400

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-masked]>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-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 12 Mar 2013 06:54:12 +0900

+1

2013/3/12 Brian Campbell <[email-masked]>

> http://openid.net/specs/openid-connect-registration-1_0-15.html#client-metadataand the examples.
>
>

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: John Bradley <[email-masked]>
Date: Mon, 11 Mar 2013 22:54:14 +0100

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-masked]> 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.
>  
> On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. <[email-masked]> wrote:

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 11 Mar 2013 22:26:30 +0000

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-masked]<mailto:[email-masked]>>
 wrote:

On 2013-03-11, at 10:49 PM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. <[email-masked]<mailto:[email-masked]>> 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?

 -- Justin
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Brian Campbell <[email-masked]>
Date: Mon, 11 Mar 2013 18:35:37 -0400

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-masked]>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:
>
>  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
>
>  On Mar 11, 2013, at 5:54 PM, John Bradley <[email-masked]>
>  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.
>

---

From: "Richer, Justin P." <[email-masked]>
Date: Mon, 11 Mar 2013 22:42:18 +0000

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-masked]<mailto:[email-masked]>>
 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-masked]<mailto:[email-masked]>> 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.

 -- Justin

 -- Justin

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 12 Mar 2013 07:52:39 +0900

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

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

---

From: Justin Richer <[email-masked]>
Date: Wed, 13 Mar 2013 10:22:03 -0400

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:
> 2013/3/12 Richer, Justin P. <[email-masked] <mailto:[email-masked]>>
>
>     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-masked] <mailto:[email-masked]>>
>     wrote:
>
>>     A fair question but what would need to be pulled in is really
>>     probably only a couple sentences (and reference) from
>>     On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P.
>>     <[email-masked] <mailto:[email-masked]>> 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:
>>
>>         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
>>
>>>         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-masked]
>>>         <mailto:[email-masked]>> 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
>>>>         On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P.
>>>>         <[email-masked] <mailto:[email-masked]>> 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
>>>>             [email-masked] <mailto:[email-masked]>
>>>>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Brian Campbell <[email-masked]>
Date: Wed, 13 Mar 2013 14:18:08 -0400

Seems reasonable to me.

On Wed, Mar 13, 2013 at 10:22 AM, Justin Richer <[email-masked]> wrote:

> the proposed webfinger and OIDC drafts for the hash-based localization of
> strings, with the following properties:
>
> * 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
>
>>  It does presume a definition of "claim", which I suppose we could turn
>> to "metadata field" for DynReg and its extensions to be appropriately
>>>  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

---

From: George Fletcher <[email-masked]>
Date: Thu, 14 Mar 2013 10:47:02 -0400

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
> 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
>
>>     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).
>>
>>>            { "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
>>>
>>>>>             "client_name#ja-Jpan-JP":"???????",
>>>>>
>>>>>
>>>>>
>>>>>             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?
>>>>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 14 Mar 2013 11:02:09 -0400

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 
> 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
>
>> * 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)
>>> See: 
>>> http://www.ietf.org/mail-archive/web/webfinger/current/msg00530.html
>>>
>>>     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
>>>     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
>>>
>>>>         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
>>>>         instance uses JSON structures to give language tags to
>>>>         field values, and has a default mechanism:
>>>>
>>>>         single client_id, or should it get a different client_id
>>>>         for each display language set?
>>>>
>>>>          -- Justin
>>>>
>>>>         On Mar 11, 2013, at 5:54 PM, John Bradley
>>>>         <[email-masked] <mailto:[email-masked]>>
>>>>          wrote:
>>>>
>>>>>         While a large number of clients will be native and might
>>>>>         be able to customize themselves for a single user during
>>>>>>             languages, should it have to register itself ten
>>>>>>             times with an AS?
>>>>>>

---

From: Mike Jones <[email-masked]>
Date: Thu, 14 Mar 2013 15:42:54 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Thursday, March 14, 2013 8:02 AM
To: George Fletcher
Cc: [email-masked] 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

Paul is proposing the same syntax as Connect.
2013/3/12 Richer, Justin P. <[email-masked]<mailto:[email-masked]>>
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).

 -- Justin

 -- Justin

 -- Justin

OAuth mailing list

---

From: Justin Richer <[email-masked]>
Date: Wed, 20 Mar 2013 13:23:30 -0400

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:[email-masked] [mailto:[email-masked]] *On
> Behalf Of *Justin Richer
> *Sent:* Thursday, March 14, 2013 8:02 AM
> *To:* George Fletcher
> *Cc:* [email-masked] 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.
>
> 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
>
>     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
>
>         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:
>
>         * If a localized version of a field is included, its
>         bare-value (perhaps internationalized) field MUST be included
>         (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
>
>             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
>             <mailto:[email-masked]>>
>
>             wrote:
>
>
>
>             A fair question but what would need to be pulled in is
>             really probably only a couple sentences (and reference)
>             from
>             pull in that whole structure and mechanism for one field
>             in client registration? I really don't think it should be
>             corner case for a single field, but I also doubt we want
>             to normatively point to OIDC Messages for this solution
>             either.
>
>             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 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

---

From: Mike Jones <[email-masked]>
Date: Wed, 20 Mar 2013 17:27:56 +0000

How would you do this instead then?

________________________________
From: Justin Richer
Sent: 3/20/2013 10:25 AM
To: Mike Jones
Cc: George Fletcher; [email-masked] WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

 -- Justin

registration_locale

                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Thursday, March 14, 2013 8:02 AM
To: George Fletcher
Cc: [email-masked]<mailto:[email-masked]> WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

 -- Justin

Thanks,
George

 -- Justin

 -- Justin

 -- Justin

 -- Justin

OAuth mailing list

---

From: Justin Richer <[email-masked]>
Date: Wed, 20 Mar 2013 13:43:16 -0400

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:
> ------------------------------------------------------------------------
> From: Justin Richer
> Sent: 3/20/2013 10:25 AM
> To: Mike Jones
>> 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
>>
>> 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.
>>
>> 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.
>>
>>         So with what little feedback I've gotten, I'm proposing to
>>         add text from the proposed webfinger and OIDC drafts for the
>>             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
>>             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.
>>
>>             [1]
>>             http://tools.ietf.org/html/draft-ietf-appsawg-webfinger-11
>>
>>             determine what language and script to present based on
>>             the user preference.
>>
>>             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?
>>
>>             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

---

From: Mike Jones <[email-masked]>
Date: Wed, 20 Mar 2013 18:30:03 +0000

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:[email-masked]]
Sent: Wednesday, March 20, 2013 10:43 AM
To: Mike Jones
Cc: George Fletcher; [email-masked] 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).

 -- Justin

Cc: George Fletcher; [email-masked]<mailto:[email-masked]> WG

 -- Justin

registration_locale

                                                            -- Mike

 -- Justin

Thanks,
George

 -- Justin

 -- Justin

 -- Justin

 -- Justin

OAuth mailing list

---

From: Justin Richer <[email-masked]>
Date: Wed, 20 Mar 2013 15:11:16 -0400

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.
>
> *From:*Justin Richer [mailto:[email-masked]]
> *Sent:* Wednesday, March 20, 2013 10:43 AM
> *To:* Mike Jones
> *Cc:* George Fletcher; [email-masked] WG
> 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
> default locale information in either discovery or service
> documentation, and clients that want to tweak things for specific
> service providers can do that.
>
> 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.
>
>     *From: *Justin Richer
>     *Sent: *3/20/2013 10:25 AM
>     *To: *Mike Jones
>     *Cc: *George Fletcher; [email-masked] <mailto:[email-masked]> WG
>     *Subject: *Re: [OAUTH-WG] Registration: Internationalization of
>     Human-Readable names
>
>         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:[email-masked] <mailto:[email-masked]>
>         [mailto:[email-masked]] *On Behalf Of *Justin Richer
>         *Cc:* [email-masked] <mailto:[email-masked]> 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
>         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.
>
>         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
>
>             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
>
>                 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
>                 * 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)
>                 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
>
>                     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
>
>                     A fair question but what would need to be pulled
>                     in is really probably only a couple sentences (and
>                     reference) from
>                     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:
>
>                     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]
>                     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.
>
>                     registration draft does have some support for
>                     doing this, which could maybe be borrowed. See
>                     client_name in §2 at
>                     It was brought up at the in-person meeting today
>                     that we'll want to consider issues around
>                     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
>                     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

---

From: Mike Jones <[email-masked]>
Date: Wed, 20 Mar 2013 20:02:20 +0000

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:[email-masked]]
Sent: Wednesday, March 20, 2013 12:11 PM
To: Mike Jones
Cc: George Fletcher; [email-masked] 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.

  -- Justin

                                                            Thanks,
                                                            -- Mike

 -- Justin

 -- Justin

registration_locale

                                                            -- Mike

 -- Justin

Thanks,
George

 -- Justin

 -- Justin

 -- Justin

 -- Justin

OAuth mailing list

---

From: Justin Richer <[email-masked]>
Date: Thu, 21 Mar 2013 14:15:04 -0400

We discussed this issue on the OpenID Connect WG call this morning, in a 
conversation that included myself, George Fletcher, Nat Sakimura, Mike 
Jones, and John Bradley (among others) as active participants in this 
thread. After lots of debate, we propose that the OAuth DynReg adopt the 
hashtag-based localization method of OIDC (and it seems, possibly 
webfinger) and explicitly declare that neither the client nor the server 
make any assumptions about the content of the string and treat it as 
just a string. I'm proposing this text to that effect (with the 
references to OIDC-messages removed and replaced with the rule 
description itself in OAuth DynReg):

    Fields with human-readable values or references to human-readable
    values, such as client_name, tos_uri, policy_uri, and client_uri,
    MAY be represented in multiple languages and scripts, specified by
    appending a # character and the RFC5646 language tag. If any such
    human-readable field is sent without a language tag, the server and
    the client MUST NOT make any assumptions about the language,
    character set, or script of the value string, and the value string
    MUST be used as-is wherever it is presented in either the client or
    server UI. To facilitate interoperability, it is RECOMMENDED that
    any fields sent without language tags contain an internationalized
    UTF-8 string suitable for display on a wide variety of systems, and
    it is RECOMMENDED that clients send fields without language tags in
    addition to any more-specifically denominated values.

Plus some examples.

(Anyone whose name I took in vain, please feel free to correct me.)

  -- Justin

On 03/20/2013 03:11 PM, Justin Richer wrote:
> 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.
>
> 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.
>
> 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.
>
>> 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 
>> For what it's worth, it's more than just client_name.  It's also 
>> 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.
>>
>> 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.
>>
>> 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).
>>
>>         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
>>
>>         that are supplied without language/script tags, represented
>>         as a BCP47[RFC5646] language tag value.  This parameter is
>>         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.
>>
>>         "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.
>>
>>             match between a request and the data stored at the AS
>>             (and out of scope of the spec).
>>
>>             Thanks,
>>             George
>>
>>                 pages, which can be used to point to
>>                 language-specific pages)
>>                 language/script they want to for the bare-value
>>                 field, and no assumptions can be made on either side
>>                 about what that is
>>
>>                     present or not (which is something that Connect
>>                     is trying to fix at the moment, as I recall from
>>                     last week).
>>
>>                     the OpenID Connect protocol so much. (I don't
>>                     want to pick a solution just because it's
>>                     in is really probably only a couple sentences
>>                     (and reference) from
>>                     On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin
>>                     P. <[email-masked] <mailto:[email-masked]>>
>>                     wrote:
>>
>>                     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.
>>
>>                     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]
>>                     That is what I was thinking.   It would be up to
>>                     the AS to determine what language and script to
>>                     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
>>                     On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin
>>                     P. <[email-masked] <mailto:[email-masked]>>
>>                     wrote:
>>
>>                     supports ten languages and wants to present
>>                     itself in ten languages, should it have to
>>                     register itself ten times with an AS?
>>
>>                     determine which human-facing language to use.
>>                     Keep in mind that in some cases (such as native
>>                     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

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 22 Mar 2013 09:35:22 +0900

Can we tighten it a bit as to the encoding is concerned?
I believe all the fields value MUST be UTF-8, so it propagates here as
well.
Saying that it must not make any assumption on character set (e.g., UTF-8)
is a bit too much.
Proposed text:

Fields with human-readable values or references to human-readable values,
such as client_name, tos_uri, policy_uri, and client_uri, MAY be
represented in multiple languages and scripts, specified by appending a #
character and the RFC5646 language tag. If any such human-readable field is
sent without a language tag, the server and the client MUST NOT make any
assumptions about the language, script, and country of the value string,
and the value string MUST be used as-is wherever it is presented in either
the client or server UI. To facilitate interoperability, it is RECOMMENDED
that any fields sent without language tags contain an internationalized
UTF-8 string suitable for display on a wide variety of systems, and it is
RECOMMENDED that clients send fields without language tags in addition to
any more-specifically denominated values.

2013/3/22 Justin Richer <[email-masked]>

> make any assumptions about the content of the string and treat it as just a
> string. I'm proposing this text to that effect (with the references to
> OIDC-messages removed and replaced with the rule description itself in
> OAuth DynReg):
>
> Fields with human-readable values or references to human-readable values,
> such as client_name, tos_uri, policy_uri, and client_uri, MAY be
> represented in multiple languages and scripts, specified by appending a #
> character and the RFC5646 language tag. If any such human-readable field is
> sent without a language tag, the server and the client MUST NOT make any
> assumptions about the language, character set, or script of the value
> string, and the value string MUST be used as-is wherever it is presented in
> either the client or server UI. To facilitate interoperability, it is
> RECOMMENDED that any fields sent without language tags contain an
> internationalized UTF-8 string suitable for display on a wide variety of
> systems, and it is RECOMMENDED that clients send fields without language
> tags in addition to any more-specifically denominated values.
>
>
> Plus some examples.
>
> 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.
>
> 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.
>
> 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.****
>
> ** **
>
> 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:[email-masked] <[email-masked]>]
> Human-Readable names****
> ** **
> 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).
>
> ****
> On 03/20/2013 01:27 PM, Mike Jones wrote:****
>
>  How would you do this instead then?****
>   ------------------------------
>
> *From: *Justin Richer
> *Cc: *George Fletcher; [email-masked] WG
> Human-Readable names****
> ****
> On 03/14/2013 11:42 AM, Mike Jones wrote:****
>
> 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:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Justin Richer
> Human-Readable names****
>  ****
> 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.
>
> 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.
>
> 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
>  ****
> On 03/14/2013 10:47 AM, George Fletcher wrote:****
>
> 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:****
>
>  -- 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. <[email-masked]>****
>
> moment, as I recall from last week).  ****
>
>  ****
>
> familiar, if we need a solution at all.)****
>
>  ****
>
>  -- Justin****
>
>  ****
>
> On Mar 11, 2013, at 6:35 PM, Brian Campbell <[email-masked]>**
> **
>
>  wrote:****
>
> ** **
>
> ****
>  ****
> On Mon, Mar 11, 2013 at 6:26 PM, Richer, Justin P. <[email-masked]>
> wrote:****
>
> 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", … }****
>
>  ****
>
> 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-masked]>****
>
>  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. ****
>
>  ****
>
> to forget the web server clients that are multi user.****
>
>  ****
>
> On 2013-03-11, at 10:49 PM, Brian Campbell <[email-masked]>
> wrote:****
>
> ** **
>
>  ****
>    "client_name": "My Example",****
>
>    "client_name#ja-Jpan-JP":"クライアント名",****
>
>  ****
>
>  ****
>
> On Mon, Mar 11, 2013 at 5:15 PM, Richer, Justin P. <[email-masked]>
> wrote:****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>  ****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>
>
> ****
>
>  ****
>
> --
> Nat Sakimura (=nat) ****
>
> @_nat_en****
> ****
> _______________________________________________****
>
> OAuth mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>   ****
>
>  ****
>
> ** **
>
> ** **
>
>
>
>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 22 Mar 2013 09:44:27 +0900

I withdraw the comment.

Somehow, for a moment, charset and encoding was flipped in my head.
Maybe I need a vacation.

Sorry.

Nat

2013/3/22 Nat Sakimura <[email-masked]>

>> OPTIONAL or REQURED. Language and script used for human-readable values
>> or references to human-readable values that are supplied without
>> want to for the bare-value field, and no assumptions can be made on either
>> side about what that is
>>
>> On Mar 11, 2013, at 6:35 PM, Brian Campbell <[email-masked]>*
>> ***
>>
>>  wrote:****
>>
>> ** **
>>
>> http://openid.net/specs/openid-connect-registration-1_0-15.html is
>> broken)****
>>
>>  ****
>>

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 22 Mar 2013 12:43:28 +1100

What is an “internationalized UTF-8 string”?

P.S. It would be worth explicitly stating that the # character and RFC5646 language tag are appended *to the field name* (not the value). I assume this is right.

--
James Manger

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Friday, 22 March 2013 5:15 AM
To: [email-masked] WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

We discussed this issue on the OpenID Connect WG call this morning, in a conversation that included myself, George Fletcher, Nat Sakimura, Mike Jones, and John Bradley (among others) as active participants in this thread. After lots of debate, we propose that the OAuth DynReg adopt the hashtag-based localization method of OIDC (and it seems, possibly webfinger) and explicitly declare that neither the client nor the server make any assumptions about the content of the string and treat it as just a string. I'm proposing this text to that effect (with the references to OIDC-messages removed and replaced with the rule description itself in OAuth DynReg):
Fields with human-readable values or references to human-readable values, such as client_name, tos_uri, policy_uri, and client_uri, MAY be represented in multiple languages and scripts, specified by appending a # character and the RFC5646 language tag. If any such human-readable field is sent without a language tag, the server and the client MUST NOT make any assumptions about the language, character set, or script of the value string, and the value string MUST be used as-is wherever it is presented in either the client or server UI. To facilitate interoperability, it is RECOMMENDED that any fields sent without language tags contain an internationalized UTF-8 string suitable for display on a wide variety of systems, and it is RECOMMENDED that clients send fields without language tags in addition to any more-specifically denominated values.

Plus some examples.

 -- Justin

---

From: Justin Richer <[email-masked]>
Date: Mon, 25 Mar 2013 11:11:48 -0400

"Internationalization is the process of designing a software application 
so that it can be adapted to various languages and regions without 
engineering changes." (From 
http://en.wikipedia.org/wiki/Internationalization_and_localization)

What this means in our case is that you'd want a string that would be 
usable on the widest variety of systems that you care about without them 
having to do something special to handle it. For some, that's going to 
mean ASCII. For others, it's going to mean some common local script.

And yes, the # character is appended to the field name, good catch.

  -- Justin

On 03/21/2013 09:43 PM, Manger, James H wrote:
> P.S. It would be worth explicitly stating that the # character and 
> RFC5646 language tag are appended **to the field name** (not the 
> value). I assume this is right.
>
> --
>
> James Manger
>
> *Sent:* Friday, 22 March 2013 5:15 AM
> *To:* [email-masked] WG
> We discussed this issue on the OpenID Connect WG call this morning, in 
> a conversation that included myself, George Fletcher, Nat Sakimura, 
> Mike Jones, and John Bradley (among others) as active participants in 
> this thread. After lots of debate, we propose that the OAuth DynReg 
> adopt the hashtag-based localization method of OIDC (and it seems, 
> possibly webfinger) and explicitly declare that neither the client nor 
> the server make any assumptions about the content of the string and 
> treat it as just a string. I'm proposing this text to that effect 
> (with the references to OIDC-messages removed and replaced with the 
> rule description itself in OAuth DynReg):
>
> values, such as client_name, tos_uri, policy_uri, and client_uri, MAY 
> be represented in multiple languages and scripts, specified by 
> the client MUST NOT make any assumptions about the language, character 
> set, or script of the value string, and the value string MUST be used 
> as-is wherever it is presented in either the client or server UI. To 
> facilitate interoperability, it is RECOMMENDED that any fields sent 
> without language tags contain an internationalized UTF-8 string 
> suitable for display on a wide variety of systems, and it is 
> RECOMMENDED that clients send fields without language tags in addition 
> to any more-specifically denominated values.
>
>
> Plus some examples.
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 25 Mar 2013 11:14:28 -0400

No problem, it's important that we be very precise about this bit of
text. There are many terms in this space with subtle differences between
them, so I'm glad to have others with more experience reading over it.

-- Justin

On 03/21/2013 08:44 PM, Nat Sakimura wrote:
> 2013/3/22 Nat Sakimura <[email-masked] <mailto:[email-masked]>>
>
>     I believe all the fields value MUST be UTF-8, so it propagates
>     here as well.
>     Saying that it must not make any assumption on character set
>     (e.g., UTF-8) is a bit too much.
>     Proposed text:
>
>         Fields with human-readable values or references to
>         human-readable values, such as client_name, tos_uri,
>         policy_uri, and client_uri, MAY be represented in multiple
>         languages and scripts, specified by appending a # character
>         and the RFC5646 language tag. If any such human-readable field
>         is sent without a language tag, the server and the client MUST
>         NOT make any assumptions about the language, script, and
>         country of the value string, and the value string MUST be used
>         as-is wherever it is presented in either the client or server
>         UI. To facilitate interoperability, it is RECOMMENDED that any
>         fields sent without language tags contain an internationalized
>         UTF-8 string suitable for display on a wide variety of
>         systems, and it is RECOMMENDED that clients send fields
>         without language tags in addition to any more-specifically
>         denominated values.
>
>
>     2013/3/22 Justin Richer <[email-masked] <mailto:[email-masked]>>
>
>         We discussed this issue on the OpenID Connect WG call this
>         morning, in a conversation that included myself, George
>         Fletcher, Nat Sakimura, Mike Jones, and John Bradley (among
>         others) as active participants in this thread. After lots of
>         debate, we propose that the OAuth DynReg adopt the
>         hashtag-based localization method of OIDC (and it seems,
>         possibly webfinger) and explicitly declare that neither the
>         client nor the server make any assumptions about the content
>         of the string and treat it as just a string. I'm proposing
>         this text to that effect (with the references to OIDC-messages
>         removed and replaced with the rule description itself in OAuth
>         DynReg):
>
>             Fields with human-readable values or references to
>             human-readable values, such as client_name, tos_uri,
>             policy_uri, and client_uri, MAY be represented in multiple
>             languages and scripts, specified by appending a #
>             character and the RFC5646 language tag. If any such
>             human-readable field is sent without a language tag, the
>             server and the client MUST NOT make any assumptions about
>             the language, character set, or script of the value
>             string, and the value string MUST be used as-is wherever
>             it is presented in either the client or server UI. To
>             facilitate interoperability, it is RECOMMENDED that any
>             fields sent without language tags contain an
>             internationalized UTF-8 string suitable for display on a
>             wide variety of systems, and it is RECOMMENDED that
>             clients send fields without language tags in addition to
>>         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:
>>         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 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.
>>>
>>>         *Cc:* George Fletcher; [email-masked] <mailto:[email-masked]> WG
>>>         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
>>>         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).
>>>
>>>             *Subject: *Re: [OAUTH-WG] Registration:
>>>             Internationalization of Human-Readable names
>>>
>>>                 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
>>>
>>>                 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
>>>
>>>                 *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
>>>
>>>                     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
>>>
>>>                         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
>>>                         * All human-readable fields are eligible for
>>>                         this mechanism (including any uri's for
>>>                         user-facing web pages, which can be used to
>>>                         * 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
>>>
>>>                             2013/3/12 Richer, Justin P.
>>>                             <[email-masked]
>>>                             <mailto:[email-masked]>>
>>>
>>>                             "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-masked]
>>>                             A fair question but what would need to
>>>                             be pulled in is really probably only a
>>>                             couple sentences (and reference) from
>>>                             On Mon, Mar 11, 2013 at 6:26 PM, Richer,
>>>                             Justin P. <[email-masked]
>>>                             <mailto:[email-masked]>> wrote:
>>>
>>>                             multi-language structure because it
>>>                             defines the mechanism once (in Messages)
>>>                             and applies it to all user-readable
>>>                             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.
>>>
>>>                             structures to give language tags to
>>>                             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]
>>>                             On Mar 11, 2013, at 5:54 PM, John
>>>                             Bradley <[email-masked]
>>>                             <mailto:[email-masked]>>
>>>
>>>                             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
>>>                             On 2013-03-11, at 10:49 PM, Brian
>>>                             Campbell <[email-masked]
>>>                             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
>>>                             On Mon, Mar 11, 2013 at 5:15 PM, Richer,
>>>                             Justin P. <[email-masked]
>>>                             <mailto:[email-masked]>> wrote:
>>>
>>>                             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
>>>                             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

---

From: Mike Jones <[email-masked]>
Date: Mon, 25 Mar 2013 18:08:05 +0000

FYI, the following version of this wording was incorporated into the OpenID Connect Registration spec.  I also found the phrase “internationalized UTF-8 string” ambiguous and so revised it.  Also, UTF-8 is just plain wrong, as once you’re in JSON you’re just dealing with Unicode strings, whether they were originally encoded in UTF-8, UTF-16, or another encoding before parsing.

Human-readable Client Metadata values and Client Metadata values that reference human-readable values MAY be represented in multiple languages and scripts. For example, values such as client_name, tos_uri, policy_uri, logo_uri, and client_uri might have multiple locale-specific values in some Client registrations.

…

If such a human-readable field is sent without a language tag, parties using it MUST NOT make any assumptions about the language, character set, or script of the string value, and the string value MUST be used as-is wherever it is presented in a user interface. To facilitate interoperability, it is RECOMMENDED that any human-readable fields sent without language tags contain values suitable for display on a wide variety of systems.

                                                            Best wishes,
                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Monday, March 25, 2013 8:12 AM
To: Manger, James H
Cc: [email-masked] WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

"Internationalization is the process of designing a software application so that it can be adapted to various languages and regions without engineering changes." (From http://en.wikipedia.org/wiki/Internationalization_and_localization)

What this means in our case is that you'd want a string that would be usable on the widest variety of systems that you care about without them having to do something special to handle it. For some, that's going to mean ASCII. For others, it's going to mean some common local script.

 -- Justin

--
James Manger

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Friday, 22 March 2013 5:15 AM
To: [email-masked]<mailto:[email-masked]> WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

Plus some examples.

 -- Justin

---

From: SM <[email-masked]>
Date: Mon, 25 Mar 2013 12:06:57 -0700

Hi Justin,
At 08:11 25-03-2013, Justin Richer wrote:
>"Internationalization is the process of designing a software 
>application so that it can be adapted to various languages and 
>regions without engineering changes." (From

There is some discussion about internationalization in RFC 6365.

Regards,
-sm

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 25 Mar 2013 19:25:47 -0600

On 3/25/13 12:08 PM, Mike Jones wrote:
> FYI, the following version of this wording was incorporated into
> the OpenID Connect Registration spec.  I also found the phrase 
> “internationalized UTF-8 string” ambiguous and so revised it.
> Also, UTF-8 is just plain wrong, as once you’re in JSON you’re just
> dealing with Unicode strings, whether they were originally encoded
> in UTF-8, UTF-16, or another encoding before parsing.

Mike and others, please read RFC 6365 at the very least to get some of
the terminology right here. For example, a Unicode code point is
simply a numbered point in a coded character set, say, U+03C0 (pi).
That code point is the same thing no matter whether it is written on a
piece of paper, mentioned in spoken text, etc. In an electronic
representation on the wire or in a file, the code point MUST be
encoded using something like UTF-8 (which we prefer in IETF protocols)
or UTF-16 or whatever. So it is incorrect to say that "UTF-8 is just
plain wrong, as once you’re in JSON you’re just dealing with Unicode
strings". It doesn't work that way!

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 25 Mar 2013 19:30:45 -0600

On 3/25/13 9:11 AM, Justin Richer wrote:
>  What this means in our case is that you'd want a string that would
> be usable on the widest variety of systems that you care about
> without them having to do something special to handle it. For some,
> that's going to mean ASCII. For others, it's going to mean some
> common local script.

Again, please read RFC 6365. ASCII means several things (is it a
character encoding scheme, a coded character set, etc.?), but in these
days of Unicode and UTF-8 it's least confusing to refer to it only as
the ASCII range of characters within the Unicode coded character set
since the characters in the ASCII range are represented using the same
bytes under UTF-8 as they were back in the old days of the ASCII
character encoding scheme.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 25 Mar 2013 19:32:32 -0600

On 3/25/13 9:14 AM, Justin Richer wrote:
> No problem, it's important that we be very precise about this bit
> of text. There are many terms in this space with subtle differences
> between them, so I'm glad to have others with more experience
> reading over it.

RFC 6365 is your friend. :-)

And no, I have not read the entire thread on the topic here, but if
pressed into service I will review the proposed text. This i18n stuff
can be tricky. ;-)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Mike Jones <[email-masked]>
Date: Tue, 26 Mar 2013 01:37:34 +0000

Hi Peter,

Fair enough.  I'll take an action item to read RFC 6365 and review the related text accordingly.

The main point of my commentary was that the processing of the parsed JSON would be the same no matter what the original encoding used was.

For what it's worth, I think that the two paragraphs quoted from the recent OpenID Connect Registration draft use the terminology correctly (but again, I'll read RFC 6365 in a bit and try to check for myself).  If they don't (since you're volunteering to read , brave man that you are :-) ), suggested corrections would be appreciated.  They're repeated below...

				Thanks again,
				-- Mike

…

-----Original Message-----
From: Peter Saint-Andre [mailto:[email-masked]] 
Sent: Monday, March 25, 2013 6:26 PM
To: Mike Jones
Cc: Justin Richer; Manger, James H; [email-masked] WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable names

On 3/25/13 12:08 PM, Mike Jones wrote:
> FYI, the following version of this wording was incorporated into the 
> OpenID Connect Registration spec.  I also found the phrase 
> dealing with Unicode strings, whether they were originally encoded in 
> UTF-8, UTF-16, or another encoding before parsing.

Mike and others, please read RFC 6365 at the very least to get some of the terminology right here. For example, a Unicode code point is simply a numbered point in a coded character set, say, U+03C0 (pi).
That code point is the same thing no matter whether it is written on a piece of paper, mentioned in spoken text, etc. In an electronic representation on the wire or in a file, the code point MUST be encoded using something like UTF-8 (which we prefer in IETF protocols) or UTF-16 or whatever. So it is incorrect to say that "UTF-8 is just plain wrong, as once you’re in JSON you’re just dealing with Unicode strings". It doesn't work that way!

Peter

- --
Peter Saint-Andre
https://stpeter.im/