RE: HOW_TO_IDENTIFY_LOCK_OWNER

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Daniel Brotsky
> 
> 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 

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

> 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 03:09:17 UTC