[OAUTH-WG] Discussion needed on username and password ABNF definitions

[Mike Jones <[e-mail]>]

Hi Julian,

The current draft restricts username and password to ASCII was because RFC 2616 says this about the TEXT fields used by HTTP Basic in RFC 2617:
   "Words of *TEXT MAY contain characters from character sets other than
    ISO-8859-1 [22] only when encoded according to the rules of
   RFC 2047 [14]."

Given that RFC 2047 MIME encodings aren't possible in this context, that you wrote that "If you define new protocol elements, either restrict them to US-ASCII, or find a way to encode all of Unicode", and you and Peter St. Andre wrote that using ISO-8859-1 is a non-starter, that seemed to leave ASCII as the only available choice.

If you have an alternative proposal for encoding all of Unicode for username and password, I'd appreciate if you could propose specific text changes to -27 to accomplish them.  I'd be fine with doing that, but didn't know how to satisfy all the constraints above for Unicode characters.  Draft -27 is now available at http://tools.ietf.org/html/draft-ietf-oauth-v2-27.

The working group should also discuss whether client_id and client_secret should use the same character set restrictions as username and password or whether they should be different for some reason.  In the case of one character, they need to be different:  The client_id field already allows colon (":") for reasons identified by Nat Sakimura, among others, whereas username can't because of HTTP Basic restrictions.

				Best wishes,
				-- Mike

-----Original Message-----
From: Julian Reschke [mailto:[e-mail]] 
Sent: Friday, June 08, 2012 2:52 AM
To: Mike Jones
Cc: [e-mail]
Subject: Re: [OAUTH-WG] Draft OAuth Core spec changes updating proposed ABNF

On 2012-06-08 09:56, Mike Jones wrote:
> The attached proposed edits to the Core spec update the ABNF to remove 
> the character set restrictions that working group participants had 
> objected to, and to define common syntax elements, where appropriate.
> After working group review, I believe that these changes are ready to 
> be checked in for draft 27 after being merged with whatever other 
> changes Eran has made.
> ...

As far as I can tell, you have chosen to restrict everything to US-ASCII. That definitively makes the ABNF and the wire representation simpler, but it does break I18N big time.

And please don't tell me that people do not use non-ASCII characters in credentials (-> <https://bugzilla.mozilla.org/show_bug.cgi?id=41489>).

Focusing on username and password... If this relates to the use in Basic and Digest, it's fine that it has their current limitations; but in that case the ABNF shouldn't invent new productions and claim that they match 2617's when they do not.

If this relates to uses of usernames and passwords outside Basic and Digest (thus new uses), then I believe the proposed solution is not acceptable.

Best regards, Julian