RE: RFC-2518 LOCK-TOKEN: header

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