Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER

From: "Clemm, Geoff" <[email-masked]>
Date: Mon, 14 Jan 2002 14:01:16 -0500

The client should never automatically reuse a lock taken out
by another client (irrespective of whether or not it was another
client with the same authentication credentials), but should only
steal another client's lock on explicit request by the user.
So the client should present to the user the information stored
in the DAV:owner field of the lock, and the user will use that
information to decide whether he/she really wants to steal that lock.

So I agree that information about the user that took out the lock
is required, but this info is available in the DAV:owner field.
The only reason this information needs to be supplemented, is to
let the client know whether or not the user will in fact be allowed
to steal the lock (assuming that he/she wants to), and that is the
info provided by the DAV:can-lock and DAV:can-unlock privileges.

Cheers,
Geoff

-----Original Message-----
From: Daniel Brotsky [mailto:[email-masked]]
Sent: Monday, January 14, 2002 1:16 PM
To: Stefan Eissing
Cc: Clemm, Geoff; [email-masked]
Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER

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:[email-masked]>

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 14 Jan 2002 11:25:55 -0800

> steal another client's lock on explicit request by the user.

Not even that liberal: the client should only *remove* another client's lock
on explicit request by the user.  The client should never reuse another
client's lock.  Ever.  (The ambiguity may just be in the word steal - I'm
not sure what you intend here Geoff)

> is required, but this info is available in the DAV:owner field.

No, this info is not necessarily available in the DAV:owner field.  Because
the client can submit this field, the client can submit bogus information,
and it's not necessarily possible for the server to decide if the
information is bogus.

> info provided by the DAV:can-lock and DAV:can-unlock privileges.

It's not necessarily an issue of privilege, it may be an issue of system
policy.  I'm not sure if using can-lock and can-unlock privileges addresses
that.

lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 14 Jan 2002 21:07:45 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Monday, January 14, 2002 8:26 PM
> To: Clemm, Geoff; [email-masked]
> ...

Furthermore, there is no standard format for this information, but this
would be needed for a interoperability.

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 14 Jan 2002 21:08:46 +0100

> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Monday, January 14, 2002 8:01 PM
> To: [email-masked]

*How* would a client present this information if the contents of DAV.owner
is not specified at all?