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
