Subject: Re: RFC-2518 LOCK-TOKEN: header

From: [email-masked]
Date: Wed, 26 Jan 2000 12:42:33 -0500

But Geoff, the semantics you describe below would make locks useless (maybe
your intent?!). If only the lock token was used to protect from overwrite
conflicts, then any user could just do a PROPFIND, get the lock token from
the DAV:lockdiscovery element, and then have at the resource! The spec
indicates that the user agent owning the lock, the one taking out the lock
in the LOCK request, must be specified along with the lock token. It does
not however say exactly what the user agent is. That's because ACLs weren't
done yet, and the working group didn't want to define principal. So they
just punted and left if up to the server implementation with
server-specific ACL mechanisms until the ACL spec was done. This is why the
principal element wasn't included in the DAV:activelock element. However, I
think we've made enough progress in defining ACLs and principals that we
can now safely include this information in DAV:activelock in which case all
problems are resolved.

"Geoffrey M. Clemm" <[email-masked]>@w3.org on 01/25/2000
04:24:54 PM

Sent by:  [email-masked]

To:   [email-masked]
cc:

Subject:  Re: RFC-2518 LOCK-TOKEN: header

   From: [email-masked] (WJCarpenter)

   gmc> Section 6.3 of RFC-2518 states that you can get the lock token
   gmc> through the lock discovery property:

   Yeah, that's what I was thinking (especially as the lock discovery
   property is the prescribed payload returned after a successful LOCK
   request).  But Jim Amsden is right that that's not sufficient.
   ...  The DAV:owner
   property is just so much commentary by the LOCK requester.  It
   explicitly has no bearing on the out-of-band authentication.  In
   short, it can be a complete lie or completely irrelevant.  I think the
   idea of DAV:owner was for human consumption, in case you want to track
   down the LOCK owner and beat him/her with a stick until s/he releases
   the LOCK.  It is by design not at all helpful to the server in
   deciding whether the principal attempting a change is the LOCK holder
   or not.

There seem to be two issues here.  The first is whether a server
should authenticate that the principal specifying the lock token in an
IF header is the same principal that created the lock token in a lock
request.  This is not required by WebDAV, since it is pretty pointless
to carefully guard a lock token when as soon as you UNLOCK the
resource, anyone can come in and trash the resource.  Lock tokens are
for avoiding merges, not for security.

So if you want interoperable security, you should become active in the
WebDAV ACL's effort.  If you try to get it from WebDAV locking and
lock tokens, you will be doomed to disappointment.  But that's not
because WebDAV locking is broken (it in fact does a great job
of avoiding merges), but rather that it doesn't do what it wasn't
designed to do.

The second issue is whether a client other than the lock requesting
client should be able to use the lock token to get access to a
resource.  Doing so would violate the whole design of the lock token
scheme, which is to have a protocol for reliably deciding whether a
*particular* client has the authority granted by the lock token.  The
protocol only works if only the client that made the LOCK request uses
the generated lock token.  The fact that the lock token was issued to
a particular principal is irrelevant.

So a client should always get its own lock token, not appropriate
an existing one.  If a resource is already exclusively locked,
it first will need to UNLOCK the resource.  This then guarantees
that if the other client (that issued the LOCK request) is still
around, it will notice the "cancellation" by the failure of its next
update request.

   For exclusive LOCKs, you can assume from the lock discovery part of a
   successful response that you got the applicable token mentioned.  For
   shared LOCKs, you need the LOCK-TOKEN: header or some additional goop
   in lock discovery conveying "authenticated" ownership.

There is even less point in authenticating shared lock ownership
(which I guess makes it a negative number, since I argue above
that there is no point in authenticating exclusive lock ownership :-).
If you are a principal that has the right to take out a shared
lock, you can just get one - you don't need to use some existing shared
lock.

   For the
   problem you mention, of multiple clients being run by the same
   principal, there is no sanctioned, unambiguous way to do lock
   discovery.

There is a sanctioned unambiguous way to do lock discovery ... there
just is (by design) no sanctioned way to do lock appropriation (:-).

Cheers,
Geoff

P.S. I may be all wrong about this, since my livelihood is versioning,
not locking, but I don't think so (:-).

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Wed, 26 Jan 2000 23:39:26 -0500

From: [email-masked]

   your intent?!).

I believe locks are very useful for avoiding merge conflicts between
cooperating clients.  By "cooperating clients", I mean clients that
whenever they want to update a resource:

 - get an exclusive lock on the resource (LOCK)
 - get the body/properties of the resource (GET, PROPFIND)
 - update the body/properties of the resource (PUT, PROPPATCH)
 - unlock the resource (UNLOCK)

If a locking unaware client tries to update the resource, the locking
protocol prevents the update while the resource is locked, but has no
way of preventing the locking unaware client from getting the state of
the resource before or during the lock, and then unknowingly
overwriting updates from a locking client because it issues its update
after the locking client performed an UNLOCK.

This point is made in section 6.7 of rfc2518.

Now if rfc2518 stopped there, we'd be fine.  But unfortunately, it
doesn't, but tries to present locks as also providing authenticated
access control (e.g. "the right to update a resource").  The reason
this is unfortunate is that "merge avoidance between cooperating
clients" and "authenticated access control" require radically
different support and semantics.

In particular, for merge avoidance, a lock token is required, and
which principal is issuing the request is irrelevant.  On the other
hand, for authenticated access control, the principal is required, and
a "lock-token" is irrelevant.  Thus all the confusion in the working
group about when/where a principal is required and when/where a lock
token is required.

Furthermore, for merge avoidance, you want to protect the URL, because
the URL is what the client is holding as the "key" to identify the
resource being authored.  On the other hand, for authenticated access
control, it is the *resource* that is being controlled, not the URL.
Thus all the confusion in the working group about whether a resource
is being protected or whether a URL is being protected.

So whatever was intended by WebDAV locks, the protocol that is
specified in rfc2518 does a fine job of preventing merge conflicts
for cooperating clients, and is totally inadequate for providing
authenticated access control.  So I propose that anyone that cares
about authenticated access control become active in the WebDAV ACL
specification effort, and just use WebDAV locks for what they can
do, namely prevent merge conflicts for cooperating clients.

   If only the lock token was used to protect from overwrite
   conflicts, then any user could just do a PROPFIND, get the lock token from
   the DAV:lockdiscovery element, and then have at the resource!

Exactly.  Which is precisely what that user can do as soon as you UNLOCK
the resource.  If you intend on keeping the resource permanently
"writable only by a certain principal" (i.e. never issuing an UNLOCK),
then requiring a lock token is pointless, since it is the principal
that matters, and the lock token is irrelevant.  Furthermore, it is
the resource you want to control, and that control should survive
a MOVE, unlike a LOCK.

   The spec
   indicates that the user agent owning the lock, the one taking out the lock
   in the LOCK request, must be specified along with the lock token.

I see no protocol header or XML element in rfc2518 for this purpose.
As you've pointed out, the DAV:owner element does not provide this,
and as you have also pointed out, saying that something should be the
case without providing protocol elements for doing so is useless.

   It does

I've been basing my statements on what is in rfc2518, not on some
ACL functionality that might (and hopefully will!) appear in some
successor to rfc2518.

But I believe the ACL functionality should be orthogonal to the
locking functionality, and in particular, the ACL's should have no
notion of an "ACL token that must be included in an IF header", nor
should an ACL on a resource imply any "protection" of any URL to that
resource.  When this is done, I expect to see a DAV:acl-discovery
element defined, and with appropriate DAV:principal sub-elements.

Cheers,
Geoff