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, 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. > > 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 protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
