- From: Daniel Brotsky <dbrotsky@adobe.com>
- Date: Mon, 14 Jan 2002 10:16:21 -0800
- To: "Stefan Eissing" <stefan.eissing@greenbytes.de>
- Cc: "Clemm, Geoff" <gclemm@rational.com>, <w3c-dist-auth@w3c.org>
At 3:05 PM +0100 1/11/02, Stefan Eissing wrote: >I see what you mean. There could be an ACL server which just has >"group" principals and no principals with one-one relation to users >(well it could even skip user credentials and just have credentials >matching groups). > >As for identifying the owner of a lock this means one of the following: >a) the server has a "primary" principal and could report it as lock owner. > It may nevertheless choose not to do so, due to confidentiality reasons. >b) the server has no such thing and thus cannot report who owns a lock. > It only can tell if your credentials are sufficient to lock/unlock > a resource. But (b) misses the point of my requirement, which is that a client needs to be able to issue a request that says "am I the <credentialed id> that obtained this lock"? The client is *not* asking an ACL question: can I unlock this resource; the client is asking a workflow question: would I be unlocking someone else's lock if I did unlock the resource? It's the workflow question that's at the heart of the requirement. So, Geoff, given ACL's (desirable) vagueness about "principals", and building on your language about "request credentials", can we alter the DAV spec language so that servers can return info about "is this request authorized with the same credentials as the lock request" and still be compatible with ACL? dan P.S. Another way of looking at this is to say: the ACL info provides a way of distinguishing between principals (i.e., they have different capabilities), but that way of distinguishing is not required to be fine-grained enough to support what I claim is the "workflow intuition" behind DAV locking: locks are held by a particular <workflow user identity> and are only allowed to be used (in the absence of ACL or other server admin magic) by that <workflow user identity> regardless of token. My requirement is that users be able to determine whether they are currently authenticating requests as the same <workflow user identity> as the request that locked the resource was. -d. -- Daniel Brotsky, Adobe Systems tel 408-536-4150, pager 877-704-4062 2-way pager email: <mailto:page-dbrotsky@adobe.com>
Received on Monday, 14 January 2002 13:31:06 UTC