currently it is possible for a user that does not own a given lock to delete a resource if he provides the "stolen" locktoken in the If header. e.g. in the following scenario user A LOCK /any/resource user B PROPFIND /any/resource (retrieves the locktoken) user B DELETE /any/resource I think that's a bug. If nobody contradicts, I'll try to fix this ASAP.
Added a testcase under /functional/lock/mix/nonOwnerUsesLocktoken to reproduce. Fixed in LockImpl