Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER

From: "Clemm, Geoff" <[email-masked]>
Date: Fri, 11 Jan 2002 08:30:39 -0500

From: Stefan Eissing [mailto:[email-masked]]

   > From: Clemm, Geoff
   > 
   > 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.

   I do not fully understand. There is always a principal for a request
   (and be it {DAV:}anonymous), so it would be easy for a server to keep
   this information with an active lock.

No, there are credentials for a request, but those credentials
can match a variety of principals in a variety of different
principal spaces relevant to the ACL on a resource.

   When there is a ACL privilege {DAV:}can-unlock and this is granted
   to a particular principal on the locked resource, the usualy ACL
   matching of principals would apply.

It is not matching of principals that takes place, but rather the
matching of the client credentials against the principals identified
in the ACE of an ACL.

   So, I do not see the problem with reporting a locking-principal
   as part of an active lock. What am I missing? Servers without ACL?

I think the only thing being missed is that a client has credentials,
and that these credentials match a variety of principals, as opposed
to identifying the client as *being* a particular principal.

Cheers,
Geoff

---

From: "Stefan Eissing" <[email-masked]>
Date: Fri, 11 Jan 2002 15:05:37 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> 

...scanning acl spec...done.
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.

That leaves possible lock-owner information up to the client. Either it
provides something meaningful to others (e.g. mailto:) or it is silent.
Would that be a feasible way forward?

//Stefan

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 14 Jan 2002 11:25:53 +0100

> [mailto:[email-masked]]On Behalf Of Stefan Eissing
> Sent: Friday, January 11, 2002 3:06 PM
> To: Clemm, Geoff; [email-masked]
> Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER
>
>

Well, if the set of principals with the ability to unlock the resource is
bigger than one, why not report all of them (or a subset whicht the server
thinks makes sense)?

> Would that be a feasible way forward?

That would still require that we define a format for this information (and
we would have to deice whether to put it into the lockowner or into a new
element).

Julian

---

From: Daniel Brotsky <[email-masked]>
Date: Mon, 14 Jan 2002 10:16:21 -0800

>    It only can tell if your credentials are sufficient to lock/unlock

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]>