Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

From: Mike Jones <[email-masked]>
Date: Thu, 14 Jun 2012 21:14:28 +0000

The more I think about excluding the possibility of using URIs as client IDs, the more uncomfortable I am with it.  I’m increasingly thinking that we should allow the ASCII characters used in URIs (and probably the other visible ones and space as well, as currently proposed) and have special language about “But what if this client_id containing colon characters is to be used with HTTP Basic?”

As one suggestion, mainly to restart discussion (which seems to have stalled), we could suggest (or require) that all colon characters in client_ids be substituted with tab characters (%x09), which are legal in HTTP Basic but not in the proposed definition of client_ids, before use with HTTP Basic, and that the reverse substitution occur when received from HTTP Basic.  Other transformations or encodings are possible.  We could also cop out by saying something like “If characters not legal in HTTP Basic occur in the client_id, a transformation encoding them must be agreed to by both parties”.  I don’t love the tab idea, because it’s admittedly a hack, but I believe it’s better than precluding the use of URIs as client_ids.

Thoughts?

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Wednesday, June 13, 2012 11:40 AM
To: Torsten Lodderstedt
Cc: Julian Reschke; Richard Mortier; [email-masked]
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

That would probably work as well.  That is why I am not particularly concerned about excluding the :

We originally used the URI itself,  mostly for convenience of debugging,  but there are other potential options.

The authorization server needs to compare the client_id and the redirect uri. But it could compare the hash with not much more work.   Also a sha256 hash is probably longer than the uri it is hashing.

I am not super concerned with being able to have : in the client_id

John B.

Sent from my iPhone

On 2012-06-13, at 6:03 PM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:
Hi John,

would it make sense to use a hash of the URI instead of the URI itself in your use case?

regards,
Torsten.

John Bradley <[email-masked]<mailto:[email-masked]>> schrieb:
I think that the issues are getting confused.

There is a use case where the Authorization server may be a embedded app, at least in one openID case.    As it won't have a separate registration or token endpoint,  the client needs to make its own clientID for the request.   A reasonable thing to use is the redirect URI to create a unique value that the user could use for revocation at a later point.

Currently with the no : restriction we would use the host and path to crate the clientid.
There are some scenarios where having the scheme as part of that would be helpful.

This has nothing to do with discovery or the dynamic client registration proposal as far as I know.

A URL as a client_id comes from prototype work for a personal provider that we are doing as part of openID Connect.

John B.
On 2012-06-13, at 7:50 AM, Torsten Lodderstedt wrote:

Hi all,

can anyone please explain the relation between dynamic client registration and URIs as client ids? None of the current drafts (uma or connect) seem to require URIs.

regards,
Torsten.

Jianhua Shao <[email-masked]<mailto:[email-masked]>> schrieb:
Hello,

Dynamic client registration is very useful if client or resource or authorisation server is not permanently available.
A typical case is that is the resource or authorisation server is in mobile platform, the connection is not always available.
Another typical case is that authorisation server do not necessary to have client pre-registered on itself. At moment, industry like facebook would like developer to register a app on its app centre first, and then ask user auth to use the app.

We are researchers from Digital Economy Research Institute. We have this problem When we developing Dataware that could manage the control of access to personal data. We play around our solution base on Oauth2: https://github.com/jianhuashao/dataware.catalog/wiki

We are in the list to receive your mail list, but currently need moderate to post any message. cc my colleague, Richard Mortier
Best
Jian

On 12 Jun 2012, at 21:08, Eran Hammer wrote:

The only distinction I would make is between removing flexibiliy to proactively enabling future extensibility. I would stop short of perscribing encoding in order to fit uri into the Basic auth fields. But if there is a way to allow this to be less restrictive without clean interop issues, that would be nice.

I do agree we need some actual use cases before we spend much more time on this.

EH

From: William Mills [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Tuesday, June 12, 2012 1:04 PM
To: Eran Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke
Cc: [email-masked]<mailto:[email-masked]>
Subject: Dynamic clients, URI, and stuff Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

I think dynamic client registration is something we have not talked out enough yet.  There's a pretty clear use case for dynamic registration.

Does identifying the client with a URI allow some form of OpenID-ish flow for this?
Is the client ID as a URI a way to allow a trusted site to provide metadata about the client?
Is that URI a way to hit an IDP we trust to validate the client in some way with the provided secret?

I guess what I'm looking for here is a concrete use case/problem to solve, rather then leaving a hook we think is the right thing.

-bill

________________________________
From: Eran Hammer <[email-masked]<mailto:[email-masked]>>
To: Mike Jones <[email-masked]<mailto:[email-masked]>>; William Mills <[email-masked]<mailto:[email-masked]>>; Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; Julian Reschke <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, June 12, 2012 11:39 AM
Subject: RE: [OAUTH-WG] Discussion needed on username and password ABNF definitions

Is the use case of using URI as client ids important? It seems like something that might become useful in the future where clients can use their verifiable servers to bypass client registration and simly use a URI the server can validate via some other means.

I just want to make sure those thinking about more complex use cases involving dynamic registration or distri buted client manamgenet are aware of this potential restriction.

I'm fine either way.

EH

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Mike Jones
Sent: Tuesday, June 12, 2012 11:27 AM
To: William Mills; Hannes Tschofenig; Julian Reschke
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

Not internationalizing fields intended for machine consumption only is already a precedent set and agreed to by the working group, so let me second Bill’s point in that regard.  For instance, neither “scope” nor “error” allow non-ASCII characters.

Julian, if you want different ABNF text than the text I wrote below, I believe it would be most useful if you would provide the exact replace wording that you’d like to see instead of it.  Then there’s no possibility of misunderstanding the intent of suggested changes.

                                                            Thanks all,
                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of William Mills
Sent: Tuesday, June 12, 2012 11:18 AM
To: Hannes Tschofenig; Julian Reschke
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

I agree generally with your assumption about clients, but rather than saying "clients are devices" I think it makes much more sense to say "clients are NOT users, so client_id need not be internationalized".  In practical terms there is very little to argue for anythign beyond ASCII in a client_secret, base64 encoding or the equivalent being a fine way to transport arbitrary bits in a portable/reasonable way.

I argue that client_id need not be internationalized because I assume that any really internationalized application will have an internationalized presentation layer that's presenting a pretty name for the client_id.

-bill

________________________________
From: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
To: Julian Reschke <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, June 12, 2012 11:01 AM
Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF definitions

I had a chat with Julian yesterday and here is my short summary.

Section 2.3 of the core draft defines client authentication based on two mechanisms (and provides room for extensions):http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3

1) HTTP Basic Authentication

2) A custom OAuth authentication mechanism (which uses client_id and client_secret)

With HTTP Basic authentication the problem is that this is a legacy technology and there is no internationalization support.

With our brand new custom OAuth authentication mechanism we have more options.

One possible approach is to say that the clients are devices (and not end users) and therefore internationalization does not matter.

Is it, however, really true that only US-ASCII characters will appear in the client_id and also in the client_secret?

Here we have the possibility to define something better.

In any case we have to restrict the characters that are used in these two authentication mechanisms since they could conflict with the way how we transport the data over the underlying protocol. Julian mentioned this in his previous mails.

Julian, maybe you can provide a detailed text proposal for how to address your comment in case we go for UTF8 (with % encoding) for the custom OAuth client authentication mechanism?

Ciao
Hannes

On Jun 12, 2012, at 11:54 AM, Julian Reschke wrote:

> On 2012-06-12 00:16, Mike Jones wrote:
>> Reviewing the feedback from Julian, John, and James, I'm coming to the conclusion that client_id and client_secret, being for machines and not humans, shou ld be ASCII, whereas username and password should be Unicode, since they are for humans.  Per John's feedback, client_id can not contain a colon and be compatible with HTTP Basic.
>
> I'm not sure that restricting the character repertoire just because one way to send requires this is the right approach. My preference would be not to put this into the ABNF, and just to point out that certain characters will not work over certain transports, and to just advise to avoid them.
>
>> Therefore, I'd like to propose these updated ABNF definitions:
>>
>>    VSCHAR = %20-7E
>>    NOCOLONVSCHAR = %x20-39 / %x3B-7E
>>    UNICODENOCTRLCHAR = <Any Unicode character other than ( %x0-1F / %x7F )>
>>
>>    client-id = *NOCOLONVSCHAR
>>    client_secret = *VSCHAR
>>
>>    username = *UNICODENOCTRLCHAR
>>    password = *UNICODENOCTRLCHAR
>
> In this case you should add an introductory statement pointing out that the ABNF defines the grammar in terms of Unicode code points, not octets (as it is the case most of the time).
>
>> It turns out that non-ASCII characters are OK for username and password because the Core spec only passes them in the form body - not using HTTP Basic - and UTF-8 encoding is specified.
>
> I'll send a separate mail about that, the current text in the spec is way too unspecific.
>
>>                 -- Mike
>>
>> P.S.  If anyone has a better ABNF for UNICODENOCTRLCHAR than "<Any Unicode character other than ( %x0-1F / %x7F )>", please send it to me!
>
> As noted before, here's an example: <http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.5.15.1>
>
> Best regards, Julian
> _______________________________________________
> 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

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

This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation.
_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: William Mills <[email-masked]>
Date: Thu, 14 Jun 2012 14:20:18 -0700 (PDT)

Will BASIC auth be needed for clients with an ID in the form of a URI?

> From: Mike Jones <[email-masked]>
>To: John Bradley <[email-masked]>; Torsten Lodderstedt <[email-masked]> 
>Cc: Julian Reschke <[email-masked]>; Richard Mortier <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Thursday, June 14, 2012 2:14 PM
>From:[email-masked] [mailto:[email-masked]] On Behalf Of John Bradley
>On 2012-06-13, at 6:03 PM, Torsten Lodderstedt <[email-masked]> wrote:
>Hi John,
>>
>>John Bradley <[email-masked]> schrieb:
>>Jianhua Shao <[email-masked]> schrieb:
>>Hello,
>> 
>>From: William Mills [mailto:[email-masked]] 
>>Cc: [email-masked]
>>>From: Eran Hammer <[email-masked]>
>>>To: Mike Jones <[email-masked]>; William Mills <[email-masked]>; Hannes Tschofenig <[email-masked]>; Julian Reschke <[email-masked]> 
>>>Cc: "[email-masked]" <[email-masked]> 
>>>From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
>>>Cc: [email-masked]
>>>From: [email-masked] [mailto:[email-masked]] On Behalf Of William Mills
>>>Cc: [email-masked]
>>>From: Hannes Tschofenig <[email-masked]>
>>>To: Julian Reschke <[email-masked]> 
>>>Cc: "[email-masked]" <[email-masked]> 
>>>>> Reviewing the feedback from Julian, John, and James, I'm coming to the conclusion that client_id and client_secret, being for machines and not humans, shou ld be ASCII, whereas username and password should be Unicode, since they are for humans.  Per John's
 feedback, client_id can not contain a colon and be compatible with HTTP Basic.
>>>> [email-masked]
>>>[email-masked]
>>[email-masked]
>>[email-masked]
>[email-masked]

---

From: Eran Hammer <[email-masked]>
Date: Thu, 14 Jun 2012 21:27:26 +0000

The server must support Basic so if this is not resolved, using a colon will break some implementations. Note that there is an easy way of validating Basic credentials even when the client id includes a colon by not parsing the string on the server and instead building the same string as the client. There is of course a theoretical security issue where a username with colon can match the pair of a username without with colon in the password but that's very unlikely and not really an attack vector if client ids are issued properly.

Either way, If colon is the only issue here, we should either specify encoding for Basic or exclude it and leave it up to others to define encoding of URIs as client ids. A few months ago I would have been more eager to revisit this, but at this point, we made our bed with Basic and are pretty much stuck without colon in the client id.

EH

From: [email-masked] [mailto:[email-masked]] On Behalf Of William Mills
Sent: Thursday, June 14, 2012 2:20 PM
To: Mike Jones; John Bradley; Torsten Lodderstedt
Cc: Julian Reschke; Richard Mortier; [email-masked]
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

________________________________
From: Mike Jones <[email-masked]<mailto:[email-masked]>>
To: John Bradley <[email-masked]<mailto:[email-masked]>>; Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>>
Cc: Julian Reschke <[email-masked]<mailto:[email-masked]>>; Richard Mortier <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, June 14, 2012 2:14 PM
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

Thoughts?

                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of John Bradley
Sent: Wednesday, June 13, 2012 11:40 AM
To: Torsten Lodderstedt
Cc: Julian Reschke; Richard Mortier; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: Discussion needed on username and password ABNF definitions

John B.

Sent from my iPhone

regards,
Torsten.

John B.

Hi all,

regards,
Torsten.

EH

-bill

I'm fine either way.

EH

                                                            Thanks all,
                                                            -- Mike

-bill

Ciao
Hannes

---

From: Justin Richer <[email-masked]>
Date: Fri, 15 Jun 2012 09:53:15 -0400

I'm in favor of allowing all characters in the string and leaving a note 
that if someone wants to have a character in there that they can't use 
elsewhere, they need to use an encoding (percent encoding? mime 
encoding? we should just pick one that other people use) to get that 
extra character into Basic.

  -- Justin

On 06/14/2012 05:27 PM, Eran Hammer wrote:
>
> The server must support Basic so if this is not resolved, using a 
> colon will break some implementations. Note that there is an easy way 
> of validating Basic credentials even when the client id includes a 
> colon by not parsing the string on the server and instead building the 
> same string as the client. There is of course a theoretical security 
> issue where a username with colon can match the pair of a username 
> without with colon in the password but that's very unlikely and not 
> really an attack vector if client ids are issued properly.
>
> Either way, If colon is the only issue here, we should either specify 
> encoding for Basic or exclude it and leave it up to others to define 
> encoding of URIs as client ids. A few months ago I would have been 
> more eager to revisit this, but at this point, we made our bed with 
> Basic and are pretty much stuck without colon in the client id.
>
> EH
>
> *From:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *William Mills
> *Sent:* Thursday, June 14, 2012 2:20 PM
> *To:* Mike Jones; John Bradley; Torsten Lodderstedt
> *Cc:* Julian Reschke; Richard Mortier; [email-masked]
> *Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re: 
> Discussion needed on username and password ABNF definitions
>
>     ------------------------------------------------------------------------
>
>     *From:*Mike Jones <[email-masked]
>     <mailto:[email-masked]>>
>     *To:* John Bradley <[email-masked] <mailto:[email-masked]>>;
>     Torsten Lodderstedt <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* Julian Reschke <[email-masked]
>     <mailto:[email-masked]>>; Richard Mortier
>     <[email-masked]
>     <mailto:[email-masked]>>; "[email-masked]
>     <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
>     *Sent:* Thursday, June 14, 2012 2:14 PM
>     *Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re:
>     Discussion needed on username and password ABNF definitions
>
>     The more I think about excluding the possibility of using URIs as
>     client IDs, the more uncomfortable I am with it.  I'm increasingly
>     thinking that we should allow the ASCII characters used in URIs
>     (and probably the other visible ones and space as well, as
>     currently proposed) and have special language about "But what if
>     this client_id containing colon characters is to be used with HTTP
>     Basic?"
>
>     As one suggestion, mainly to restart discussion (which seems to
>     have stalled), we could suggest (or require) that all colon
>     characters in client_ids be substituted with tab characters
>     (%x09), which are legal in HTTP Basic but not in the proposed
>     definition of client_ids, before use with HTTP Basic, and that the
>     reverse substitution occur when received from HTTP Basic.  Other
>     transformations or encodings are possible.  We could also cop out
>     by saying something like "If characters not legal in HTTP Basic
>     occur in the client_id, a transformation encoding them must be
>     agreed to by both parties".  I don't love the tab idea, because
>     it's admittedly a hack, but I believe it's better than precluding
>     the use of URIs as client_ids.
>
>     Thoughts?
>
>                                                                 -- Mike
>
>     *From:[email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]]
>     <mailto:[mailto:[email-masked]]> *On Behalf Of *John Bradley
>     *Sent:* Wednesday, June 13, 2012 11:40 AM
>     *To:* Torsten Lodderstedt
>     *Cc:* Julian Reschke; Richard Mortier; [email-masked]
>     <mailto:[email-masked]>
>     *Subject:* Re: [OAUTH-WG] Dynamic clients, URI, and stuff Re:
>     Discussion needed on username and password ABNF definitions
>
>     That would probably work as well.  That is why I am not
>     particularly concerned about excluding the :
>
>     We originally used the URI itself,  mostly for convenience of
>     debugging,  but there are other potential options.
>
>     The authorization server needs to compare the client_id and the
>     redirect uri. But it could compare the hash with not much more
>     work.   Also a sha256 hash is probably longer than the uri it is
>     hashing.
>
>     On 2012-06-13, at 6:03 PM, Torsten Lodderstedt
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hi John,
>
>         John Bradley <[email-masked] <mailto:[email-masked]>>
>         schrieb:
>
>         There is a use case where the Authorization server may be a
>         embedded app, at least in one openID case.    As it won't have
>         a separate registration or token endpoint,  the client needs
>         to make its own clientID for the request.   A reasonable thing
>         to use is the redirect URI to create a unique value that the
>         user could use for revocation at a later point.
>
>         A URL as a client_id comes from prototype work for a personal
>         provider that we are doing as part of openID Connect.
>
>         John B.
>
>         can anyone please explain the relation between dynamic client
>         registration and URIs as client ids? None of the current
>         drafts (uma or connect) seem to require URIs.
>
>         regards,
>         Torsten.
>
>
>
>         Jianhua Shao <[email-masked]
>         <mailto:[email-masked]>> schrieb:
>
>         Hello,
>
>         Dynamic client registration is very useful if client or
>         resource or authorisation server is not permanently available.
>
>         A typical case is that is the resource or authorisation server
>         is in mobile platform, the connection is not always available.
>
>         Another typical case is that authorisation server do not
>         necessary to have client pre-registered on itself. At moment,
>         industry like facebook would like developer to register a app
>         on its app centre first, and then ask user auth to use the app.
>
>         We are researchers from Digital Economy Research Institute. We
>         have this problem When we developing Dataware that could
>         manage the control of access to personal data. We play around
>         our solution base on Oauth2:
>         https://github.com/jianhuashao/dataware.catalog/wiki
>
>         We are in the list to receive your mail list, but currently
>         need moderate to post any message. cc my colleague, Richard
>         Mortier
>
>         Best
>
>         Jian
>
>         The only distinction I would make is between removing
>         flexibiliy to proactively enabling future extensibility. I
>         would stop short of perscribing encoding in order to fit uri
>         into the Basic auth fields. But if there is a way to allow
>         this to be less restrictive without clean interop issues, that
>         would be nice.
>
>         *From:*William Mills [mailto:[email-masked]]
>         <mailto:[mailto:[email-masked]]>
>         *Sent:*Tuesday, June 12, 2012 1:04 PM
>         *To:*Eran Hammer; Mike Jones; Hannes Tschofenig; Julian Reschke
>         *Cc:[email-masked] <mailto:[email-masked]>
>         *Subject:*Dynamic clients, URI, and stuff Re: [OAUTH-WG]
>         Discussion needed on username and password ABNF definitions
>
>         I think dynamic client registration is something we have not
>         talked out enough yet.  There's a pretty clear use case for
>         dynamic registration.
>
>         Is that URI a way to hit an IDP we trust to validate the
>         client in some way with the provided secret?
>
>         I guess what I'm looking for here is a concrete use
>         case/problem to solve, rather then leaving a hook we think is
>         the right thing.
>
>         -bill
>
>             ------------------------------------------------------------------------
>
>             *From:*Eran Hammer <[email-masked]
>             <mailto:[email-masked]>>
>             *To:*Mike Jones <[email-masked]
>             <mailto:[email-masked]>>; William Mills
>             <[email-masked] <mailto:[email-masked]>>;
>             Hannes Tschofenig <[email-masked]
>             <mailto:[email-masked]>>; Julian Reschke
>             <[email-masked] <mailto:[email-masked]>>
>             *Cc:*"[email-masked] <mailto:[email-masked]>"
>             <[email-masked] <mailto:[email-masked]>>
>             *Sent:*Tuesday, June 12, 2012 11:39 AM
>             *Subject:*RE: [OAUTH-WG] Discussion needed on username and
>             password ABNF definitions
>
>             Is the use case of using URI as client ids important? It
>             seems like something that might become useful in the
>             future where clients can use their verifiable servers to
>             bypass client registration and simly use a URI the server
>             can validate via some other means.
>
>             I just want to make sure those thinking about more complex
>             use cases involving dynamic registration or distri buted
>             client manamgenet are aware of this potential restriction.
>
>             I'm fine either way.
>
>             EH
>
>             *From:[email-masked]
>             <mailto:[email-masked]>[mailto:[email-masked]]
>             <mailto:[mailto:[email-masked]]>*On Behalf Of*Mike
>             Jones
>             *Sent:*Tuesday, June 12, 2012 11:27 AM
>             *To:*William Mills; Hannes Tschofenig; Julian Reschke
>             *Cc:[email-masked] <mailto:[email-masked]>
>             *Subject:*Re: [OAUTH-WG] Discussion needed on username and
>             password ABNF definitions
>
>             Not internationalizing fields intended for machine
>             consumption only is already a precedent set and agreed to
>             by the working group, so let me second Bill's point in
>             that regard.  For instance, neither "scope" nor "error"
>             allow non-ASCII characters.
>
>             Julian, if you want different ABNF text than the text I
>             wrote below, I believe it would be most useful if you
>             would provide the exact replace wording that you'd like to
>             see instead of it.  Then there's no possibility of
>             misunderstanding the intent of suggested changes.
>
>                                                                         Thanks
>             all,
>
>                                                                         --
>             Mike
>
>             *From:[email-masked]
>             <mailto:[email-masked]>[mailto:[email-masked]]
>             <mailto:[mailto:[email-masked]]>*On Behalf
>             Of*William Mills
>             *Sent:*Tuesday, June 12, 2012 11:18 AM
>             *To:*Hannes Tschofenig; Julian Reschke
>             *Cc:[email-masked] <mailto:[email-masked]>
>             *Subject:*Re: [OAUTH-WG] Discussion needed on username and
>             password ABNF definitions
>
>             I agree generally with your assumption about clients, but
>             rather than saying "clients are devices" I think it makes
>             much more sense to say "clients are NOT users, so
>             client_id need not be internationalized".  In practical
>             terms there is very little to argue for anythign beyond
>             ASCII in a client_secret, base64 encoding or the
>             equivalent being a fine way to transport arbitrary bits in
>             a portable/reasonable way.
>
>             I argue that client_id need not be internationalized
>             because I assume that any really internationalized
>             application will have an internationalized presentation
>             layer that's presenting a pretty name for the client_id.
>
>             -bill
>
>             ------------------------------------------------------------------------
>
>             *From:*Hannes Tschofenig <[email-masked]
>             <mailto:[email-masked]>>
>             *To:*Julian Reschke <[email-masked]
>             <mailto:[email-masked]>>
>             *Cc:*"[email-masked] <mailto:[email-masked]>"
>             <[email-masked] <mailto:[email-masked]>>
>             *Sent:*Tuesday, June 12, 2012 11:01 AM
>             *Subject:*Re: [OAUTH-WG] Discussion needed on username and
>             password ABNF definitions
>
>
>             Section 2.3 of the core draft defines client
>             authentication based on two mechanisms (and provides room
>             for
>             extensions):http://tools.ietf.org/html/draft-ietf-oauth-v2-27#section-2.3
>
>             With HTTP Basic authentication the problem is that this is
>             a legacy technology and there is no internationalization
>             support.
>
>             One possible approach is to say that the clients are
>             devices (and not end users) and therefore
>             internationalization does not matter.
>
>             Is it, however, really true that only US-ASCII characters
>             will appear in the client_id and also in the client_secret?
>
>             In any case we have to restrict the characters that are
>             used in these two authentication mechanisms since they
>             could conflict with the way how we transport the data over
>             the underlying protocol. Julian mentioned this in his
>             previous mails.
>
>             Julian, maybe you can provide a detailed text proposal for
>             how to address your comment in case we go for UTF8 (with %
>             encoding) for the custom OAuth client authentication
>             mechanism?
>
>             Ciao
>             Hannes
>
>             >> Reviewing the feedback from Julian, John, and James, I'm
>             coming to the conclusion that client_id and client_secret,
>             being for machines and not humans, shou ld be ASCII,
>             whereas username and password should be Unicode, since
>             they are for humans.  Per John's feedback, client_id can
>             not contain a colon and be compatible with HTTP Basic.
>             >
>             > I'm not sure that restricting the character repertoire
>             just because one way to send requires this is the right
>             approach. My preference would be not to put this into the
>             ABNF, and just to point out that certain characters will
>             not work over certain transports, and to just advise to
>             avoid them.
>             >
>             > In this case you should add an introductory statement
>             pointing out that the ABNF defines the grammar in terms of
>             Unicode code points, not octets (as it is the case most of
>             the time).
>             >
>             >> It turns out that non-ASCII characters are OK for
>             username and password because the Core spec only passes
>             them in the form body - not using HTTP Basic - and UTF-8
>             encoding is specified.
>             >
>             >> P.S.  If anyone has a better ABNF for UNICODENOCTRLCHAR
>             than "<Any Unicode character other than ( %x0-1F / %x7F
>             )>", please send it to me!
>             >
>             > As noted before, here's an example:
>             <http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.5.15.1>
>             >
>             > Best regards, Julian
>             >[email-masked] <mailto:[email-masked]>
>             [email-masked] <mailto:[email-masked]>
>         [email-masked] <mailto:[email-masked]>
>         This message and any attachment are intended solely for the
>         addressee and may contain confidential information. If you
>         have received this message in error, please send it back to
>         me, and immediately delete it. Please do not use, copy or
>         disclose the information contained in this message or in any
>         attachment. Any views or opinions expressed by the author of
>         this email do not necessarily reflect the views of the
>         University of Nottingham.
>
>         This message has been checked for viruses but the contents of
>         an attachment may still contain software viruses which could
>         damage your computer system: you are advised to perform your
>         own checks. Email communications with the University of
>         Nottingham may be monitored as permitted by UK legislation.
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>