Subject: Last Call: Access Control Protocol

From: "Jim Whitehead" <[email-masked]>
Date: Fri, 9 Nov 2001 17:08:32 -0800

** WORKING GROUP LAST CALL FOR COMMENTS ***

From June 21 to August 3, 2001, the WebDAV Working Group held a last call
for comments period on the -06 version of the WebDAV Access Control
Protocol. During the last call period, several working group members
performed detailed reviews of the document. Their feedback has now been
incorporated into the -07 version of the Access Control Protocol.

Additionally, since the submission of the -06 version of the protocol
specification, some early implementation experience indicated the need for a
simple query mechanism to locate principals, since the use of hierarchy to
organize principals was insufficient for large numbers of principals. Hence,
the -07 version contains additional functionality not found in the -06
version that went through last call. Due to this, an additional, shorter
last call period is being held to solicit review of the -07 specification.

From the abstract of the -07 specification:

   This document specifies a set of methods, headers, and
   message bodies that define Access Control extensions to
   the WebDAV Distributed Authoring Protocol. This protocol
   permits a client to read and modify access control lists
   that instruct a server whether to allow or deny operations
   upon a resource (such as HTTP method invocations) by a
   given principal.

I fully expect this to be the absolutely final call for comments from the
WebDAV working group on the WebDAV Access Control Protocol,
draft-ietf-webdav-acl-07, prior to sending it along to the IESG for
approval.  This last call
for comments period begins immediately, and ends December 3, 2001, at
midnight,
US Pacific time.  This allows over three weeks for review of the
specification.

The latest revision of the WebDAV Access Control Protocol was submitted as
an Internet-Draft today, and should appear in the Internet-Drafts directory
in the next few days. In the meanwhile, it can be accessed at:

Text (this is the normative version)
http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.txt

HTML:
http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.htm

PDF:
http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07.pdf

Word (with change tracking active):
http://www.webdav.org/acl/protocol/draft-ietf-webdav-acl-07-tracked.doc

At the end of the last call review period, a new draft may be issued.
Depending on the scope of changes introduced between the -07 and -08
versions, there will either be an immediate call for rough consensus (very
few changes), or a second last call review period (significant changes).
Once the document represents the rough consensus of the working group, I
will submit this document to the Internet Engineering Steering Group (IESG)
for their approval.  IESG review involves a (minimum) two week public last
call for comments period.  This IESG-initiated last call period is in
addition to the working group last call period.

This document is intended to be a "Proposed Standard".  Quoting from RFC
2026, "The Internet Standards Process -- Revision 3":

   The entry-level maturity for the standards track is
   "Proposed Standard". A specific action by the IESG
   is required to move a specification onto the standards
   track at the "Proposed Standard" level.

   A Proposed Standard specification is generally stable,
   has resolved known design choices, is believed to be
   well-understood, has received significant community
   review, and appears to enjoy enough community interest
   to be considered valuable.  However, further experience
   might result in a change or even retraction of the
   specification before it advances.

   Usually, neither implementation nor operational experience
   is required for the designation of a specification as a Proposed
   Standard.  However, such experience is highly desirable, and
   will usually represent a strong argument in favor of a
   Proposed Standard designation.

Many details on the procedures used to develop an IETF standard can be
found in RFC 2026, available at: http://www.ietf.org/rfc/rfc2026.txt

If there are any procedural questions or concerns, please do not hesitate
to contact me, or raise an issue on the list.

Notes:

1) Issues raised during the last call period will be resolved individually,
rather than lumped together and dealt with as a whole.

2) If you've been waiting for a "stable" version of the specification before
performing a review, wait no longer.  This is it.  Please review the
specification NOW in order to ensure your input gets included.

- Jim Whitehead

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 9 Nov 2001 18:45:43 -0800

Some general comments:

 1) Why does every example use xmlns:D="DAV:"?  That seems to be a pointless
    exercise in indirection that will ultimately lead to clients that
    parse on D:whatever instead of the actual spec.  Besides, DAV itself
    is an xmlns that needs to be defined somewhere.  If the goal is to
    simply show that it is possible, then only one or two of the examples
    should use the shorter short name.

 2) This protocol has departed from the Web interface of access control being
    set on a per-method basis.  The effect of this change is that access
    control will now have to be governed by both the Web server and whatever
    handler within the Web server is interpreting WebDAV methods, resulting
    in a pointless duplication of code (and effort, if the resource
    requires both forms be active).  Eventually, someone will have to
    define an HTTP access control protocol.

 3) The protocol does not differentiate between writing to a resource (PUT)
    and appending to a resource (POST), and thus cannot be used to control
    shared access for things like guest-books, log files, or collection-like
    bulletin-board resources.

The first is a matter of editorial choice.  The second prevents this protocol
from being generally useful outside webdav.  The third leads from the second.
I don't think any of them would necessarily prevent it from becoming a
proposed standard for WebDAV, but I wouldn't call it access control for
the Web.

....Roy

---

From: "Eric Sedlar" <[email-masked]>
Date: Fri, 9 Nov 2001 19:21:11 -0800

1)  I agree that the xmlns:D="DAV:" is kind of off-putting.  "DAV:" is a URL
with the "DAV:" protocol identifier, which is never used anywhere else, not
another namespace.  This is the way RFC2518 is defined, and I guess the goal
was to define the shortest possible namespace URL
for the "D" namespace prefix.  You get used to it.

2)  Are you complaining about the lack of mapping between the ACL privileges
and HTTP methods?  Would you be happier if it were specified that the "GET"
method for example must be restricted by "DAV:read" and the "PUT" method
must be restricted by "DAV:write"?  This issue has come up
before, and while I remember that there was some reason not to do so
(because I think some HTTP methods may be restricted by different privileges
depending on other context, e.g. POST), I'm not sure that's not a good
reason to specify things for the methods that we do map.

3)  POST is not necessarily appending to a resource.  I consider it more of
an "execute" command than anything else.

I think access control in the scenarios you describe may well be constrained
by server-defined privileges, and the general intent of the protocol is that
this is what would be done.  I can define privileges like "Sign GuestBook"
for a particular resource if I want to restrict that.

--Eric

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Roy T. Fielding
> Sent: Friday, November 09, 2001 6:46 PM
> To: Jim Whitehead
> Cc: WebDAV
> Subject: Re: Last Call: Access Control Protocol
>
>
> Some general comments:
>

---

From: "Julian Reschke" <[email-masked]>
Date: Sat, 10 Nov 2001 11:01:39 +0100

> Sent: Saturday, November 10, 2001 3:46 AM
> To: Jim Whitehead
> Cc: WebDAV

I agree with the criticism to invent a new URI scheme in the first place.
But this happened three years ago (RFC2518), not for ACL.

It's true that

	<D:elementname xmlns:D="DAV:" />

is just one of many representations, but the fact that RFC2518 (as well)
always uses the same format doesn't seem to have produced non-interoperable
clients. The requirement is to parse requests and responses using a
namespace-aware XML processor. If you don't, you have a problem. If you do,
you won't care at all about the XML serialisation format.

Julian

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 12 Nov 2001 10:26:33 -0800

>  2) This protocol has departed from the Web interface of access
>     control being set on a per-method basis.  The effect of this
>     change is that access control will now have to be governed
>     by both the Web server and whatever handler within the Web
>     server is interpreting WebDAV methods, resulting in a
>     pointless duplication of code (and effort, if the resource

In a file-based Apache installation, reading a particular resource requires
that GET is enabled, and that read permissions are set on a specific file.
So, in stock Apache, the read operation is governed by both the "Web server"
and the code interpreting the GET method. The DAV ACL protocol is the same.

Our goal was to create an access control protocol for remote collaborative
authoring of Web resources, not a remote Web server configuration protocol.
There was room for consensus on the former, not on the latter.

>  3) The protocol does not differentiate between writing to a
>     resource (PUT) and appending to a resource (POST), and
>     thus cannot be used to control shared access for things
>     like guest-books, log files, or collection-like bulletin
>     board resources.

If you can identify a single DAV client that uses POST to append to a
resource, I might consider this a valid case that should be accommodated by
the protocol.

At present, POST is almost exclusively used for forms submission and
HTTP-tunneled RPCs of various types.  We felt that each individual use of
POST (i.e., each RPC scheme) would require one or more privileges to be
defined for them. We didn't want to guess, a priori, as to which privileges
they might need.

- Jim