On 2015-02-05 23:49, Bjoern Hoehrmann wrote:
* The IESG wrote:
Abstract
This document defines the "Basic" Hypertext Transfer Protocol (HTTP)
Authentication Scheme, which transmits credentials as userid/password
pairs, obfuscated by the use of Base64 encoding.
I do not think the use of Base64 is intended as obfuscation and it seems
misleading to me to describe it as such. (The Introduction has the same
problem).
I think it was.
In the Introduction:
The "Basic" scheme previously was defined in Section 2 of [RFC2617].
This document updates the definition, and also addresses
internationalization issues by introducing the "charset"
authentication parameter (Section 2.1).
I think "updates" is the wrong word considering the document is intended
to "obsolete" RFC 2617.
It does update the definition, no? Also: "Other documents updating RFC
2617 are "Hypertext Transfer Protocol (HTTP/1.1): Authentication"
([RFC7235], defining the authentication framework) and "HTTP Digest
Access Authentication" ([DIGEST], updating the definition of the
'"Digest" authentication scheme). Taken together, these three documents
obsolete RFC 2617."
In section 2:
The "Basic" authentication scheme is based on the model that the
client needs to authenticate itself with a user-ID [...]
The document switches between "user name", "username", "userid", and
"user-ID". I think the "user-ID" forms should be replaced by one of the
"name" forms.
Good point. I'll have a look.
The realm value is an opaque string
which can only be compared for equality with other realms on that
server.
RFC 7235 says "The realm value is a string, generally assigned by the
origin server, that can have additional semantics specific to the
authentication scheme." This seems contradictory (perhaps the intent is
to say that for the particular case of Basic, the realm value is opaque
in contrast to other schemes where it might not be opaque, but that is
It *is* the definition of the "Basic" scheme.
not clear from the text) and misleading (users make decisions based on
the string, which often contains human readable text, so it's not really
opaque to them).
That is true.
The original definition of this authentication scheme failed to
specify the character encoding scheme used to convert the user-pass
into an octet sequence.
I think it would be more appropriate to say that it did not do so. That
wasn't a particular "failure", sending unlabeled 8bit (and 7bit) content
was normal at the time, in part because other system parts also did not
know or care about character encodings.
It's a defect in that specification, no matter when it was written.
There should be an example for "no other authentication parameters are
defined -- unknown parameters MUST be ignored by recipients", otherwise
such extension points are too easily missed by implementers.
<http://greenbytes.de/tech/tc/httpauth/#simplebasicnewparam2> shows that
UAs seem to get at least this correct. I'll think about it.
Best regards, Julian