Isn't the nuance that Basic and Digest should be able to be passed through OAuth? Or is there a secondary requirement that uid/passwords forms in OAuth be re-encodable to Basic?
So while "UTF-8 may not work with Basic and Digest" is that a valid concern? I think our concern should be limited to "Basic and Digest working within OAuth". Am I missing something? Phil @independentid www.independentid.com [email protected] On 2012-06-10, at 11:50 AM, Mike Jones wrote: > Thanks for your reply, Julian. > > Given that, as you confirmed, UTF-8 "doesn't work with Basic and Digest", and > they're required to be used with Basic, I believe that that confirms that > username and password must either be ASCII or ISO-8859-1, and given that > several people have written that ISO-8859-1 is a "non-starter", that > effectively confirms the current syntax in -27 that username and password > must be ASCII. Do you agree or am I missing a nuance here? > > Julian, there was one aspect of the open issue that you didn't reply to: Do > you have an opinion on whether client_id and client_secret should be > restricted to the same characters as username and password? This seems > logical to me, as they are objects of the same kind as username and password, > but I also sympathize with your sentiment that "we shouldn't extend this > problem to anything new we define". On the other hand, given that client_id > and client_secret are for machine (and not for human) consumption, I don't > see any more need for internationalization of these fields than there was for > scope (which the working group decided to limit to ASCII). > > Julian, what do you think? Working group, what do you think? > > Thanks, > -- Mike > > -----Original Message----- > From: Julian Reschke [mailto:[email protected]] > Sent: Sunday, June 10, 2012 11:39 AM > To: Mike Jones > Cc: [email protected] > Subject: Re: Discussion needed on username and password ABNF definitions > > On 2012-06-08 20:09, Mike Jones wrote: >> 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. > > The other choice was "find a way to encode all of Unicode". The way to do > this usually is to use UTF-8. That doesn't work with Basic and Digest, but we > shouldn't extend this problem to anything new we define. > >> 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. >> ... > > I haven't looked at the core OAuth spec. The right answer depends on where > you use these protocol elements. > > Changing this into a question to the WG: is it acceptable to restrict all of > these protocol elements to US-ASCII? > > Best regards, Julian > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
