ystems.
-Original Message-
From: Peter Saint-Andre [mailto:stpe...@stpeter.im]
Sent: Monday, March 25, 2013 6:26 PM
To: Mike Jones
Cc: Justin Richer; Manger, James H; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable
names
-BEGIN PGP SIGNED ME
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/25/13 9:11 AM, 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
> http://en.wikipedia.org/wiki/Inter
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
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
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
(not the value). I assume this is
right.
--
James Manger
From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>
[mailto:oauth-boun...@ietf.org] On Behalf Of Justin Richer
Sent: Friday, 22 March 2013 5:15 AM
To: oauth@ietf.org<mailto:oauth@ietf.org> WG
Subject: Re: [OAUTH-WG] Regist
--
James Manger
*From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On
Behalf Of *Justin Richer
*Sent:* Friday, 22 March 2013 5:15 AM
*To:* oauth@ietf.org WG
*Subject:* Re: [OAUTH-WG] Registration: Internationalization of
Human-Readable names
We discussed this issue on the Op
Of
Justin Richer
Sent: Friday, 22 March 2013 5:15 AM
To: oauth@ietf.org 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
: Justin Richer [mailto:jric...@mitre.org]
Sent: Wednesday, March 20, 2013 12:11 PM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable
names
I agree that I'm seeing things from the single-language and single-enc
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable
names
I would say that claims without a language parameter, which I would make
REQUIRED in the presence of other claims, would be treated as UTF8 strings with
no
ipt tags, represented as a BCP47[RFC5646]
>> language tag value. This parameter is REQUIRED if any human-readable
>> values or references to human-readable are provided without
>> language/script tags.
>>
>> -- Mike
>>
>> *From:*oauth-boun...@ietf.org [mailto:
How would you do this instead then?
From: Justin Richer
Sent: 3/20/2013 10:25 AM
To: Mike Jones
Cc: George Fletcher; oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable
names
Personally, I think that this level of
> *From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On
> Behalf Of *Justin Richer
> *Sent:* Thursday, March 14, 2013 8:02 AM
> *To:* George Fletcher
> *Cc:* oauth@ietf.org WG
> *Subject:* Re: [OAUTH-WG] Registration: Internationalization of
> Human-Readable names
&
: George Fletcher
Cc: oauth@ietf.org WG
Subject: Re: [OAUTH-WG] Registration: Internationalization of Human-Readable
names
On the surface this does simplify things, but the issue I forsee with it is
that I want to be able to call "client.getClientName()" and always get
*something* ou
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
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 a
Seems reasonable to me.
On Wed, Mar 13, 2013 at 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 ve
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 f
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.
> It does presume a definition of "claim", which I suppose we could turn to
> "metadata field" for DynR
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 n
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
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 whol
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
+1
2013/3/12 Brian Campbell
> 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
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",
"cl
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,
26 matches
Mail list logo
