This seems to have been dropped on the floor of the Issues list,
so I've added it.
In any case, there has been no comment since Sept. 09 on this issue;
consider this the last call on the proposed wording.
- Jim Gettys
Forwarded message 1
I can't see this on the issues list, but it was discussed on the
mailing list (with no objections).
....Roy
------- Forwarded Message
Date: Tue, 09 Sep 1997 12:12:52 -0500 (EST)
From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Subject: Re: Basic Authentication behavior
To: fielding@kiwi.ics.uci.edu
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <01INFSEQ12BM000NRI@SCI.WFBR.EDU>
Resent-From: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4378
"Roy T. Fielding" <fielding@kiwi.ics.uci.edu> wrote:
>IETF WGs do not generate specifications; authors do. If someone can
>author up a chunk of text for the Authentication section that describes
>how the "http" URL space is treated hierarchically for predetermining
>the reusability of credentials within a given realm, and can do so in
>a manner less complicated than this sentence, then I am sure Jim can
>add it to the Issues list and the matter can be resolved.
Appended is the current text of Section 11.1 in the -08 draft,
with a proposed insertion to make explicit the behavior expected for
paths in Request-URIs as originally implemented for Basic Access
Authentication and recently reviewed in the HTTP-WG by Ari Luotonen,
<URL: http://www.ics.uci.edu/pub/ietf/http/hypermail/1997q3/0766.html>.
Because neither RFC 1945 nor RFC 2068 addressed the issue of
paths and implied protection spaces for Basic Access Authentication,
the insertion uses SHOULD and MAY rather than MUST for this behavior.
Fote
=========================================================================
Foteos Macrides Worcester Foundation for Biomedical Research
MACRIDES@SCI.WFBR.EDU 222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
[CURRENT TEXT:]
11.1 Basic Authentication Scheme
The "basic" authentication scheme is based on the model that
the client must authenticate itself with a user-ID and a
password for each realm. The realm value should be
considered an opaque string which can only be compared for
equality with other realms on that server. The server will
service the request only if it can validate the user-ID and
password for the protection space of the Request-URI. There
are no optional authentication parameters.
Upon receipt of an unauthorized request for a URI within the
protection space, the origin server MAY respond with a
challenge like the following:
WWW-Authenticate: Basic realm="WallyWorld"
where "WallyWorld" is the string assigned by the server to
identify the protection space of the Request-URI. A proxy
may respond with the same challenge using the Proxy-
Authenticate header field.
To receive authorization, the client sends the userid and
password, separated by a single colon (":") character,
within a base64 [7] encoded string in the credentials.
basic-credentials = "Basic" SP base64-user-pass
base64-user-pass = <base64 [7] encoding of user-pass,
except not limited to 76 char/line>
user-pass = userid ":" password
userid = *<TEXT excluding ":">
password = *TEXT
Userids might be case sensitive.
If the user agent wishes to send the userid "Aladdin" and
password "open sesame", it would use the following header
field:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
[START INSERT]---------------------------------------------------------
A user agent SHOULD assume that all paths at or deeper than
the depth of the last symbolic element in the path field
of the Request-URI also are within the protection space
specified by the Basic realm value of the current challenge,
and MAY send the corresponding Authorization header with
requests for resources in that space without receipt of
another challenge from the server.
[END INSERT]-----------------------------------------------------------
If a client wishes to send the same userid and password to a
proxy, it would use the Proxy-Authorization header field.
See section 15 for security considerations associated with
Basic authentication.
------- End of Forwarded Message