> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Mike Jones
> Sent: Tuesday, June 12, 2012 6:17 AM
> To: [email protected]
> Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF
> definitions
> 
> 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,
> should 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.
> 

As a person in the non-English half of the world, this sounds like a
reasonable solution.

> 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
> 
> 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.
> 
>                               -- 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!
> 
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Manger, James H
> Sent: Monday, June 11, 2012 8:37 AM
> To: [email protected]
> Subject: Re: [OAUTH-WG] Discussion needed on username and password ABNF
> definitions
> 
> Are we so sure the non-english "half" of the world only use ASCII
characters in
> passwords? Sounds highly unlikely to me.
> 
> > Given that, as you confirmed, UTF-8 "doesn't work with Basic and
Digest"...
> 
> It can work. It is just underspecified. So things can get messy.
> draft-reschke-basicauth-enc-05 is a current draft (March 2012) attempting
to
> fix this as much as possible.
> 
> Forcing ASCII password for people feels unacceptable. Better would be to
say
> OAuth servers accepting HTTP BASIC MUST accept UTF-8 encoded usernames
> and passwords. A warning about interop problems with non-ASCII password is
> ok.
> 
> ASCII-only for usernames is almost as bad. I thought internationalized
email
> addresses were just standardized, and email addresses are often used as
> usernames.
> 
> For client id & password ASCII-only is less of an issue. These are values
> configured into apps, not remembered by human brains.
> 
> 
> --
> James Manger
> 
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
> 
> 
> _______________________________________________
> OAuth mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to