Re: RFC-2518 LOCK-TOKEN: header

   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.

Cheers,
Geoff

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