RE: HOW_TO_IDENTIFY_LOCK_OWNER

   From: Daniel Brotsky [mailto:dbrotsky@adobe.com]

   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.

Yes, but we do need a well-refined notion to produce an interoperable
protocol here (i.e. the vague notion in 2518 would not suffice).

   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.

This vague notion of principal does not provide an interoperable
mechanism.  The client presents credentials which may or may not match a
variety of "principals" relevant for access to a given resource.  It is not
the
case that the client *is* exactly one of those principals, but rather
just that its presented credentials "match" one or more of the
principals relevant for ACEs on that resource.

It is true that you can have properties of a resource that identify
special principals (e.g. a DAV:owner property), but that is to provide
a level of indirection in the ACL mechanism, not to persistently
"identify" the client that created the resource.

Thus the vague notion of principal from 2518 has been firmed up in
the context of the ACL spec with the idea that there are DAV:can-lock
and DAV:can-unlock privileges on the locked resource.

   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.

The ACL protocol specifically does not provide a "who am I" mechanism,
because that is an ambiguous question.  In general, all you can
say is which of a set of principals they "match", and the set of
principals can vary depending on what resource you are talking about,
and what operation on that resource you are talking about.  The only well
formed question is "what things can I do to this particular resource".

   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.

Yes, that is another reason why the ACL spec does not depend on
the ability for a client to "match" principal URLs.

Cheers,
Geoff

Received on Friday, 11 January 2002 08:31:43 UTC