- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Thu, 27 Jan 2000 15:13:43 -0800
- To: w3c-dist-auth@w3.org
Geoff Clemm writes: > Yes, authentication is mentioned in various places in the > protocol, but there is no mention of an "authentication > header" (neither a definition of its value nor how it is > to be used). The "Authorization" header is defined in RFC 2617, "HTTP Authentication: Basic and Digest Access Authentication" <http://www.ics.uci.edu/pub/ietf/http/rfc2617.txt>. This is the Draft Standard version of the Basic authentication information from RFC 2068, and the Digest authentication information from RFC 2069. Both of these documents (RFC 2068 and RFC 2069) are normatively referenced from RFC 2518 (see especially section 17.1). Furthermore, the locking examples in section 8.10.8, 8.10.9, and 8.10.10 use the Authorization header in the request message to highlight the fact that authentication credentials must be supplied. There is no reference to a header named "authentication" in RFC 2518. Greg Stein writes: > That mechanism may or may not be a header, but the RFC > is quite clear (in my mind) that simply holding a token > is not enough. You must have the token and you must have > the same authentication as that used when the lock was > created. Given these two pieces of state, you are allowed > to operate on the target resource. This is correct. Geoff Clemm writes: > I agree that this is made stated in the protocol, but > this is of limited value to a client since no interoperable > mechanism for doing so is specified. Section 17.1 states that, at minimum, Digest authentication must be supported by all WebDAV applications, thus ensuring there exists at least one interoperable mechanism for authentication. Geoff Clemm writes: > In addition, no authentication is required if no > authentication was performed when the lock was > created, so a client cannot count on any authentication > taking place. Well, at present RFC 2518 is silent on whether a server is allowed to create a lock if no authentication credentials were presented during the lock request. There are good arguments either way: requiring them would make locking more consistent, but allowing "anonymous" locking would enable WebDAV clients to interact anonymously with a service, which could be a plus for publically writeable pages. But, if the server grants a lock to a specific authenticated principal, the fact that it might also allow anonymous locking on that resource is irrelevant. Other principals will not be able to modify the resource while the lock is being held by authenticated principal. Any other behavior is an error. - Jim
Received on Thursday, 27 January 2000 18:17:53 UTC