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

From: [email-masked]
Date: Tue, 25 Jan 2000 12:25:28 -0500

Bill,
If the lock token isn't returned in the header, there's no way for you to
get the lock token of the lock you just created. That's because the active
lock element of the lock discovery property does not contain the
authentication id of the principal owning the lock. The lock  tokens are in
the lock discovery, but you can't figure out which ones you own.

I continue to believe this is an open issue that requires clients to
persist their lock  tokens outside the WebDAV repository. Lock tokens are a
pain enough for the rare case where they are actually useful. Not having
the principal owning the lock in the lock discovery makes them even worse.
I proposed a fix to this over a year ago, but was  told at that time that
it was too late and would have too much effect on the spec which was about
to become an accepted draft. But now we are looking at some pretty
significant changes to locking semantics. Can we please get this simple
issue resolved. WebDAV clients will appreciate it.

[email-masked] (WJCarpenter)@w3.org on 01/20/2000 06:31:11 PM

Sent by:  [email-masked]

To:   [email-masked]
cc:

Subject:  RFC-2518 LOCK-TOKEN: header

Examples in RFC-2518, section 8.10.8 et seq, don't show a LOCK-TOKEN:
response header.  This contradicts other places in RFC-2518 which say
that the header is required in the response.

It would suit me if the requirement were changed and the examples left
as is.
--
[email-masked]   (WJCarpenter)           PGP
[email-masked]                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Tue, 25 Jan 2000 13:10:24 -0500

From: [email-masked]

   If the lock token isn't returned in the header, there's no way for you to
   get the lock token of the lock you just created.

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

"A lock token is a type of state token, represented as a URI, which
identifies a particular lock.  A lock token ... can also be found
through lock discovery on a resource."

   That's because the active
   lock element of the lock discovery property does not contain the
   authentication id of the principal owning the lock.

I can find no authentication id defined or required by RFC-2518.

In fact, RFC-2518  explicitly states that an authentication id is not
part of the WebDAV protocol:

"Locks MUST be enforced based upon whatever authentication mechanism
is used by the server, not based on the secrecy of the token values."

and:

"User agent authentication has previously occurred via a mechanism
outside the scope of the HTTP protocol, in an underlying transport
layer."

   The lock tokens are in

This information is provided by the DAV:owner element in the
lockdiscovery property.

   I continue to believe this is an open issue that requires clients to
   persist their lock  tokens outside the WebDAV repository. Lock tokens are a
   pain enough for the rare case where they are actually useful.

How else do you handle the situation where the same principal has
several clients acting against the same resource?  I believe this will
be a common scenario.

Cheers,
Geoff

---

From: [email-masked] (WJCarpenter)
Date: Tue, 25 Jan 2000 11:04:33 -0800

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.

ja> That's because the active lock element of the lock discovery
ja> property does not contain the authentication id of the principal
ja> owning the lock.

gmc> I can find no authentication id defined or required by RFC-2518.

Yeah, you're right, too, and that's the problem.  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.

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.  For the
problem you mention, of multiple clients being run by the same
principal, there is no sanctioned, unambiguous way to do lock
discovery.

I agree that that is an issue needing a solution.
-- 
[email-masked]   (WJCarpenter)           PGP
[email-masked]                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Tue, 25 Jan 2000 16:24:54 -0500

From: [email-masked] (WJCarpenter)

   ...  The DAV:owner

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

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: [email-masked] (WJCarpenter)
Date: Tue, 25 Jan 2000 14:58:57 -0800

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

This doesn't address other reasons for doing unambiguous lock
discovery.  It leaves aside such rainy day scenarios as "oops, my
application just crashed (et seq :-))" and "I guess I'll go home for
the night and work on this".

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

This technique also opens a (probably very small) window wherein
someone else could grab the lock.  (Such events are not always a
matter of competition.  You could be under the impression that your
co-author was going to release the LOCK when s/he was done and it was
your turn.)
-- 
[email-masked]   (WJCarpenter)           PGP
[email-masked]                    0x91865119
38 95 1B 69 C9 C6 3D 25  73 46 32 04 69 D6 ED F3

---

From: Jim Whitehead <[email-masked]>
Date: Tue, 25 Jan 2000 15:34:20 -0800

> the night and work on this".

When dealing with exclusive locks, the lack of owner information is more an
inconvenience than a   problem in the situations you mention. A client can
retrieve the lock token by performing lock discovery, and then assume it
belongs to that client.  The server will let the client know if this isn't
the case.  To prevent a user from doing too much work before they discover
the lock token doesn't belong to them, the application should pop up a
dialog letting the user know what happened, and then try to write a dummy
property using PROPPATCH (or some other simple, easy-to-undo write
operation), and see if the method succeeds.

> co-author was going to release the LOCK when s/he was done and it was

So, I'm not as opposed to grabbing an existing lock token as Geoff is.  If a
client does seize a lock token, the application should inform the user of
this.

- Jim

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Tue, 25 Jan 2000 18:58:54 -0500

If you are using shared locks, neither of these scenarios are
a problem: you just take out another shared lock and let the
orphan locks time out or be eventually cancelled by routine
lock administration.

If you are using exclusive locks, then your second client must first
UNLOCK (i.e. delete the lock from the first client).  If the first
client is still alive after all, this might leave it with changes that
must be "merged", but your client can (and should) make it clear to
you that you are taking that risk when you UNLOCK a resource you
didn't LOCK.

In either case, if you want to make sure that you are taking back
your own lock, and not somebody else's, then the DAV:owner element
should contain exactly the information the client needs to give
to the user in order for the user to decide whether to "cancel"
the lock.  Note that this can *never* be an automatic operation
based on "unambiguous" principal identification.  Just because the
second client has the same principal as the first provides no
guarantee that the first client is no longer alive and active.

   This technique also opens a (probably very small) window wherein
   someone else could grab the lock.(Such events are not always a
   matter of competition.  

There are a variety of situations where you want to specify
relationships between a resource and a principal (or set of
principals), such as: "this principal is the only one that can lock
this resource".  But holding and maintaining a lock token is pointless
for this ...  this are relationships between a resource and a principal,
and passing around a (publically available) lock token is of no
relevance.

So I agree we want to be able to associate with a resource
the access rights for specific principals, but the lock tokens
are irrelevant for this association.

   You could be under the impression that your
   co-author was going to release the LOCK when s/he was done and it was
   your turn.)

I'm not sure what point this scenario illustrates, but I predict my
answer will be to look at the DAV:owner element of the lock (:-).

Cheers,
Geoff

---

From: "Geoffrey M. Clemm" <[email-masked]>
Date: Tue, 25 Jan 2000 19:27:36 -0500

Ah, good, we've flushed out an author (:-).

   From: Jim Whitehead <[email-masked]>

The whole point of having a lock token is so that you can handle the
case where multiple clients are active for a single principal.  If you
are going to encourage a clients to use a lock token it did not obtain
with a LOCK, the lock token is totally pointless, and should be
removed from the protocol.

And would this message be something like "as your client, I decided
overwrite protection is not needed, so I'm just going to use some
other client's lock token"? (:-)

On the other hand, you can UNLOCK the resource and get your own lock,
ensuring that any still alive clients will know that this happened when
they next try to do an update.  The only benefit of the former approach
is that it removes a miniscule window for some other client to come in
and get a lock (where that client has just as much a right to author that
resource as you do).  Seems like you are throwing away the only value
of token based locking in return for a very unlikely and even arguably
"unfair" benefit.

I still may be missing something, but I still don't think so (:-).

Cheers,
Geoff