On 2010/05/11 12:49, Robert Sayre wrote: > Basic leaves the input character encoding unspecified, so it doesn't > handle anything but ASCII in an interoperable way. OAuth > implementations will certainly screw this up too, but I suspect it > will be somewhat less buggy, since most people will probably just > guess it's supposed to be UTF-8.
For the purpose of using Basic auth internally for OAuth, we could specify that it should be treated as UTF-8 under OAuth's context. However, if we go that way please make it an explicit rule in addition to RFC2617, not just as a people's guess. In Japan there is a long, non-ignorable history of using MS-Windows/MS-DOS local encoding (Shift_JIS) for Basic auth. And there is still many major implementations not using UTF-8 for this purpose. I afraid that, if Basic is used with no explicit charset rule, clients may use the core libraries of those and thus they will not assume UTF-8. At least under my short experiment, IE7 (ja) still assumes Shift_JIS for all of realm, user-name and password. This may be depending on the locale of either the browser or the operating system (I do not know which). # "Authorization: Basic k/qWe4zqOpP6lnuM6g==", # where both user/pass are the 3-char word "nihon-go" in Japanese characters. FF3.5.9 (Windows, ja) assumes ISO-8859-1(?) for realm, and sends some meaningless data for Japanese user-name/password (possibly each character truncated to single-octet forcibly). # "Authorization: Basic 5SyeOuUsng==". You can see there is only # 7 octets (for 6 Japanese characters + a colon) after decoding BASE64. -- Yutaka OIWA, Ph.D. Research Scientist Research Center for Information Security (RCIS) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: <y.o...@aist.go.jp>, <yut...@oiwa.jp> OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth