RE: HOW_TO_IDENTIFY_LOCK_OWNER

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing
> Sent: Friday, January 11, 2002 3:06 PM
> To: Clemm, Geoff; w3c-dist-auth@w3c.org
> Subject: RE: HOW_TO_IDENTIFY_LOCK_OWNER
>
>
> > 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).

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)?

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

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

Received on Monday, 14 January 2002 05:26:25 UTC