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


From: Clemm, Geoff <gclemm@rational.com>
Date: Fri, 11 Jan 2002 09:40:43 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B1056E13DB@SUS-MA1IT01>
To: w3c-dist-auth@w3c.org
   From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]

   ...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
      It may nevertheless choose not to do so, due to confidentiality
   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?

Yes, I believe there is agreement that the current DAV:owner field
in the DAV:lockinfo should be used for this purpose (and is client

If you add the definition of appropriate privileges (e.g. DAV:can-lock
and DAV:can-unlock), then I believe we have all we need, while 
supporting servers that fall into those cases you describe above
(i.e. do not want to repot principals for confidentiality reasons,
or have no such principal to report).

Received on Friday, 11 January 2002 09:44:15 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:24 UTC