W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2002

RE: HOW_TO_IDENTIFY_LOCK_OWNER

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Fri, 11 Jan 2002 15:05:37 +0100
To: "Clemm, Geoff" <gclemm@rational.com>, <w3c-dist-auth@w3c.org>
Message-ID: <NDBBKJABLJNMLJELONBKEEPPDCAA.stefan.eissing@greenbytes.de>
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff
> 
>    From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
> 
>    > 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.

...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
Received on Friday, 11 January 2002 09:06:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:59 GMT