Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER

From: "Clemm, Geoff" <[email-masked]>
Date: Thu, 10 Jan 2002 23:42:49 -0500

From: Daniel Brotsky [mailto:[email-masked]]

   I think there are a variety of client needs here.  These are
   probably a little too fuzzy to be called requirements :^), but it's
   the best I can do right now.

   1. This came up at the first interop, and most servers seemed to be
   compliant by the second interop:

   The <owner> part of a lock is to be completely controlled by the
   client.  The server MUST not alter it (i.e., lock discovery, if it
   returns the <owner> information, must return exactly equivalent XML
   to that in the LOCK request).

   There's a lot of discussion of why this is needed in the archives;
   the gist is that it's the only client-controlled XML that's always
   associated with a LOCK, so clients of a given ilk can use it to
   exchange conventional information with each other about the lock.

I agree.

   2. There's some well-known specification of "principal" in the
   sense of "authenticated user ID whose authorization is being used
   for the current request."  Probably this is a string of some kind,
   and probably there are localization issues so we will want this
   string to be in a known encoding (e.g., UTF-8) or else all
   mechanisms that return this string must be able to return the
   encoding.

In general, the user will not map 1-1 with a "principal", but rather
a user will "match" one or more principals.  Therefore I do not see
that it is feasible or desireable to try to identify a particular
principal for the current user.

   3. Clients need to know/be able to discover which "principal" they
   are.  I don't really know enough about the range of authentication
   schemes to understand whether clients can always know for sure what
   "principal" the server is associating with them based on the
   client-generated authentication header, or whether the client might
   simply have been given some set of opaque credentials and need the
   server to tell it which "principal" those credentials make it.

I believe this is the same as (2), and the same counter-arguments
apply.

   4. Clients need to know/be able to discover which "principal" owns
   a given lock, that is, which principal made the original lock
   request.

We did agree in an earlier thread that a "DAV:can-lock" and a
"DAV:can-unlock" privilege should be supported, so that an ACL
can indicate who can lock or unlock a resource.

But I disagree that it is necessary or useful to identify a principal
that "owns" the lock, since it is the DAV:can-lock and DAV:can-unlock
ACL that matters, and that is not determinable from the "principal"
that created the lock. 

   5. Clients need to know/be able to discover where the "root
   resource" of a lock is; that is, the resource on which the lock
   owner can do an UNLOCK of the right depth and get the lock
   released.

I agree.

So my set of requirements would be:

A) The DAV:owner field of the lock is under client control.

B) A DAV:can-lock and DAV:can-unlock privilege should be defined.

C) The root resource of a lock should be discoverable.

---

From: Daniel Brotsky <[email-masked]>
Date: Thu, 10 Jan 2002 21:49:38 -0800

Geoff,

I think you and I are basically in agreement, but that you are using 
a farily well-refined notion of principal based on the ACL spec while 
I'm talking about the unrefined/undefined notion of "principal" used 
in the DAV spec.  The intuition here, at least for me, is that the 
DAV spec basically says the following:

1. when you obtain a lock, the lock is "identified with" the 
authenticated principal your request is authorized as and the lock 
token.

2. (modulo administrative privileges for some users) only the 
principal who obtained the lock can use it or unlock it, and that 
principal must supply the token in any request that uses/unlocks the 
lock.

It's against that intution that I claim simple DAV clients (not 
necessarily ACL clients) need to be able to find out "who does the 
server think I am" and "who does the server think the principal 
identified with this lock is" so they can compare the two.

Notice that it's really the comparing of the two that is important: I 
agree that many servers will not want to reveal other user identities 
so just having a way of saying "am I the owner of this lock" is 
actually enough.

     dan

-- 
Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:[email-masked]>

---

From: "Stefan Eissing" <[email-masked]>
Date: Fri, 11 Jan 2002 09:08:38 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Daniel Brotsky
> 
> Geoff,
> 

All true, but when you define a principal for locking, this principal
should comply to the definition of principal in the ACL spec.

---

From: "Stefan Eissing" <[email-masked]>
Date: Fri, 11 Jan 2002 09:14:02 +0100

> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> [...]

I do not fully understand. There is always a principal for a request
(and be it {DAV:}anonymous), so it would be easy for a server to keep
this information with an active lock.

When there is a ACL privilege {DAV:}can-unlock and this is granted
to a particular principal on the locked resource, the usualy ACL
matching of principals would apply.

So, I do not see the problem with reporting a locking-principal
as part of an active lock. What am I missing? Servers without ACL?

//Stefan