RE: [ACL] Where are we here?

Geoff:

Thanks for the update.  I now propose:

1) that ACLs are not needed to ADMINISTER (isn't this what you mean by
authoring?) access.
<jra>
Interoperability for getting and setting ACLs will improve the ability of
many client applications to interact with many repository managers through
WebDAV. I think we do need interoperable administration, but this does not
mean that this is the only thing WebDAV ACLs could do.
</jra>

2) that relying on the "handslap" approach (the server refuses to perform
the requested operation) as the main approach to authoring operations is
wrong.
<jra>
WebDAV is extensions to HTTP which already uses a challenge/response
paradigm. Changing this will significantly delay acceptance of the WebDAV
spec. However, this does not mean that challenge/response cannot be
augmented by proactive access management by clients based on available ACL
information. What it means is that no matter what the client might think at
the moment, the server will always use challenge/response. That is, a
client might discover (doesn't matter how) the current permissions on a
resource, adjust its UI accordingly, subsequently attempt to access the
resource, and have the request refused because the ACLs on the resource
have changed since the client did the discovery.
</jra>

3) we bring the permission scheme forward.
<jra>
I'm not against additional methods to provide more proactive access
management in clients, but 1)I don't think it is necessary, ACL queries
provide the capability although not in the most convenient manner, 2)
proactive ACL management with additional methods or using ACL discovery
cannot eliminate the challenge/response behavior of the server as this is
fundamental to a distributed environment where information is cached and
can become stale, 3) I don't think it is advisable to hold up the ACL spec
to resolve these non-fundamental issues.
</jra>


============================================================================


1) I suggest that administration of access can be performed by a write-only
operation.  This means that I request to set the access level/rights for a
principal, and get only a set/refused response.  This hides who has what
rights to the document (otherwise a security breach).  If you like the
image
of writing an ACL as the way to model this operation, I can live with that.

It also removes the need for a client app. to decode the list.  Reading the
ACL may be supported (or not) if the server wishes to permit the client to
display the information, but is not required, and has no connection to
setting access.  This permits incomplete ACLs to be returned as well.
<jra>
This is an interesting idea and does resolve some important issues.
</jra>

I believe that the meaning of the principal identifier (group, individual,
network service, ...) should be tied to directory and authentication
standards.  Once again, a client would not be required or expected to see
any or all principle identifiers.
<jra>
I agree with this.
</jra>

2) A WEBDAV client must handle rejection but does not expect it as the
common case.  I look to applications setting appropriate expectations,
within the validity of asynchronous changes (after I look, someone else
changes the state).
<jra>
Agreed
</jra>

3) Since business demands forced me to miss the last 2 calls, I would just
like to know that permissions are not optional, and will be addressed
before
we submit a draft.

Thanks folks
Bernard Chester

-----Original Message-----
From: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On Behalf Of
Geoffrey M. Clemm
Sent: Friday, April 14, 2000 8:48 AM
To: acl@webdav.org
Subject: Re: [ACL] Where are we here?



   From: "Bernard Chester" <bernard.chester@capeview.com>

   I thought we had a majority agreed on a "Train 1" approach which does
not
   require ACLs, but does require describing the Boolean data and/or
functions
   to set/get rights on the resource.   The general philosophy was for the
   server to tell us what was possible (or not) and not to compute it on
the
   client.

   I still see comments about expanding group ACEs.  What's up?

Train #1 did not remove ACL's.  It just said that the purpose of reading
an ACL was only for "ACL authoring", i.e. for clients that want to modify
the ACL of a resource.

This is in contrast to Train#2 which said that ACL's were also to be
read/understandable by clients that wanted to know "what am I allowed
to do with this resource.

So we appear to be agreed that we will focus initially on authoring
ACL's, and leave it up to the server for applying the ACL's
appropriately, and conveying information back to the user when an ACL
is violated.  So reading ACL's (and understanding owners and
principals) are of interest to the extent that they support authoring
of the ACL's.

As for a client finding out what it can do, I believe we agreed to
defer that.  The main use cases are:

- client wants to modify an ACL (and may need to read the ACL to figure
  out how to set it).
- client does some operation and the ACL's are enforced by the server.

Cheers,
Geoff


_______________________________________________
acl mailing list
acl@webdav.org
http://mailman.webdav.org/mailman/listinfo/acl


_______________________________________________
acl mailing list
acl@webdav.org
http://mailman.webdav.org/mailman/listinfo/acl

Received on Friday, 14 April 2000 14:34:50 UTC