W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2000

Re: RFC-2518 LOCK-TOKEN: header

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Thu, 27 Jan 2000 08:38:23 -0500
Message-Id: <10001271338.AA29281@tantalum>
To: w3c-dist-auth@w3.org
   From: Greg Stein <gstein@lyra.org>

   > I have found no reference to an "authentication header" in rfc2518,
   > neither in terms of defining it, nor in terms of using it.

   Section 6.3, last paragraph. It mentions that the use of the lock token
   must also be enforced through the server's authentication mechanism.

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).

   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.

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.  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.

There are different to address this current problem in the protocol.
One would be to beef up the authentication associated with locks.  I
believe this is the wrong approach, since I believe that token-based
namespace-protecting "locks" are only appropriate as a merge avoidance
mechanism, while long-term access control should be neither
token-based, nor should it involve any URL protection.

Another approach is to provide a principal-based access control mechanism,
to complement the locking mechanism.  Whether or not locks require some
level of authentication for use would be controlled by the client, based
on ACL's of the locked resource.  That is an approach I would support.

   > For the purposes of the user deciding whether to cancel an
   > existing lock, the DAV:owner information should be sufficient.

   Many clients may not set that field. I don't think that you can
   necessarily depend upon it. But: I tend to agree that there is nothing
   better, and that field *is* intended for human consumption (and,
   therefore, for asking whether a lock should be cancelled).

Yes, if a client decides to store no information there, then that is
the clients choice.  But I believe the DAV:owner field is a good
interoperable mechanism for addressing the problem of how to let a
client present information to its user about the principal that
requested the lock.

Received on Thursday, 27 January 2000 08:38:26 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:21 UTC