- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Thu, 27 Jan 2000 08:38:23 -0500
- 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. Cheers, Geoff
Received on Thursday, 27 January 2000 08:38:26 UTC