RE: HOW_TO_IDENTIFY_LOCK_OWNER

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

At 11:42 PM -0500 1/10/02, Clemm, Geoff wrote:
>    From: Daniel Brotsky [mailto:dbrotsky@adobe.com]
>
>    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.


-- 
Daniel Brotsky, Adobe Systems
tel 408-536-4150, pager 877-704-4062
2-way pager email: <mailto:page-dbrotsky@adobe.com>

Received on Friday, 11 January 2002 00:49:52 UTC