Re: [http-auth] Normalization forms in draft-ietf-httpauth-basicauth-enc

[Bjoern Hoehrmann <[e-mail]>]

* Yoav Nir wrote:
>The group can decide to mandate one behavior (entirely server-side) for 
>basicauth, and something else for others (like maybe negotiate the kind 
>of normalization to perform). But I'd rather we use the same kind of 
>processing for all methods unless there's a good reason to do so. 

The specification in question cannot really require server-side normali-
sation. It is entirely up to the server whether to authorize a client to
access its resources. The server might treat user names case-sensitively
or might reject passwords that are not in NFC form or do whatever else
it feels like. You cannot make a black box test that would demonstrate
non-compliance to such a requirement. This would rather note that use of
certain combinations of characters can result in unexpected failures and
various forms of normalisation and tolerances can be used to mitigate.

I think it would be out of scope of the document to do much more and it
would very likely delay and complicate deployment without a clear gain.

There is of course the option to make sure the draft defines that user
agents must treat certain unrecognized values for the charset parameter
or multiple `WWW-Authenticate` headers for the same Basic realm such
that servers have an option to opt into client-side normalization later,
if the group decides on some common options. So,

  WWW-Authenticate: Basic realm="example", charset="UTF-8/NFCv6+"

or

  WWW-Authenticate: Basic realm="example", charset="UTF-8", x="precis"
  WWW-Authenticate: Basic realm="example", charset="UTF-8"

for instance.
-- 
Björn Höhrmann · mailto:[e-mail] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: [phone] · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/