This documents highlights the current WebDAV ACL specification and
should start to identify how Subversion can implement the requisite
functionality to become compliant.  Note that some of these items may
require work in Apache HTTP Server and/or its included mod_dav to succeed.

Current WebDAV ACL draft:

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

===Open questions===

* Are WebDAV ACLs version independent, version dependent, or up to impl?
Justin: Seems up to impl.  I'd believe that ACLs are properties of the
        resource and should be versioned.

* What inheritance model should Subversion support?  If so, how?
Justin: WebDAV ACLs indicate inheritance via DAV:inherited property and
        DAV:inherited-acl property (for ACE and ACLs, respectively).  So, the
        inheritance is directly known and explicit (i.e. X inherits from Y).
        I believe a similar model would work fine within Subversion.

* Should ACLs themselves be versioned?
Justin: See above, yes, I think they should.  (Those that aren't derived.)

* What sub/superset of WebDAV privileges should Subversion have, and how
  should they map to WebDAV's privilege model?

* What other types of access control mechanisms are we going to require?
Justin: Bill has mentioned that we might want to control who can change
        the log.  Indeed, there seems to be a separate class of repository
        specific attributes.  Could we key them off of the Subversion root?
        These would seem to be an extension of the WebDAV ACL model, but
        necessary ones for uses.

* What are the real semantics of DAV:owner?  Could it be the person who
  create this file?  The site admin?  What?

* What to do about inherited and protected ACEs on MOVEs? (up to impl.)

* What ACLs would be required for deletion?  (up to impl.)

* Can the repository structure be itself unchanged with only modifications
  contained within ra_dav and mod_dav_svn?
Justin says: Just might be possible.  If Subversion implemented the ACLs
             and related items as simple properties on the file, this
             approach may work as mod_dav/mod_dav_svn handles enforcement.

===Answered questions===

* Can Subversion handle the principal data model?  That is, can it enumerate
  what users it recognizes.  Similarly, can we represent the groups in a
  controlled fashion?
Justin: Isn't the concept of a user foreign to Subversion?  Indeed, Greg says
        it is.  So, mod_dav would have to introduce a model to map backend
        authentication models and present a unified principal model.  Still,
        work would have to be done in Apache httpd to achieve this.  But,
        storage of users doesn't occur with SVN.  All SVN would receive is an
        authenticated username.

* Given Subversion does not know about users, what sorts of ACLs could be
  placed on other non-DAV access to the repository (say ra_local)? 
Justin: Greg hints that ra_local doesn't use ACLs as it would be possible
        to just bypass SVN and edit the BDB backend directly.  ACLs are
        therefore only desired for ra_dav access.

===Required to-do items===

- Contemplate the nature of ACLs

- Construct a mapping of WebDAV ACL properties and values to potential SVN
  counterparts.

- Define extensions to the mod_dav provider API that allows ACLs to be
  implemented in a provider-neutral fashion.  mod_dav should be able to
  handle most of the protocol logic, but it will have to retrieve certain
  items from the provider to achieve this.

- Allow mod_dav to handle principal URLs via authentication rewrite.
  - mod_dav can be written to use these backends and expose provider URLs and
    handle the DAV methods on them.

===Completed items===

- Apache httpd authentication switched to a provider model for post-2.0.42
  releases.

===30,000ft summary of WebDAV ACL draft===
****
Note: You are encouraged to read the draft in its entirety, but this is
      just a rough sketch so that I can remember what is in it.
****

Principal:
  - Single URL which identifies a person
  - Certain DAV methods must be implemented on these URLs

Privileges:

- DAV:read
  - Controls: GET/PROPFIND
  - MAY control: OPTIONS
- DAV:write
  - Controls: PUT/PROPPATCH
  - Locking interacts with it
  - Includes DAV:write-properties and DAV:write-content (3.10)
- DAV:write-properties
  - Controls: PROPPATCH.
  - Modify dead properties, but (optionally) live ones
- DAV:write-content
  - Controls: PUT/DELETE
- DAV:unlock
  - Controls: UNLOCK
- DAV:read-acl
  - Controls: PROPFIND (on DAV:acl)
- DAV:read-current-user-privilege-set
  - Controls: PROPFIND (on DAV:current-user-privilege-set)
- DAV:write-acl
  - Modify ACLs
- DAV:all
  - Everything

Principal properties:
- DAV:alternate-URI-set
  - Required
  - HREF
  - More knowledge about principal
- DAV:principal-URL
  - Required
  - Definitive singular URL
- DAV:group-member-set (group principals)
  - Direct members of group
- DAV:group-membership
  - Required
  - What groups a principal belongs to

ACL properties:
- DAV:owner
  - Protected
- DAV:supported-privilege-set
  - Protected
  - What properties are allowed
- DAV:current-user-privilege-set
  - Protected
  - Computed effective access for current principal
- DAV:acl
  - Collection of ACEs (see below)
- DAV:acl-semantics
  - Protected
  - Describes current behavior of implementing access checks
- DAV:inherited-acl-set
  - Indicates which entities that this ACL inherits from
- DAV:principal-collection-set
  - Collection of principals for this server

ACE properties:
- DAV:ace
  - Invert
  - DAV:principal
    - href to a principal URL
    - DAV:All
      - All users
    - DAV:Authenticated
    - DAV:Unauthenticated
    - DAV:Property
      - If specified property value matches what we know, success.
        - DAV:Owner matching (?)
    - DAV:Self
      - Only for principal URLs if authenticated as that principal
  - grant or deny privilege:
    - See above for ACE privileges
  - DAV:protected
    - Any attempt to remove this MUST fail
  - DAV:inherited
    - This ACE comes from resource in href
 
ACE combinations:
- Describes how ACEs are evaluated
- DAV:first-match
- DAV:all-grant-before-any-deny
- DAV:specific-deny-overrides-grant
  
ACE ordering:
- DAV:deny-before-grant

Allowed ACE:
- DAV:principal-only-one-ace
  - A principal may only appearing in one ACE per ACL
- DAV:grant-only
- DAV:no-invert

Required principals
- DAV:required-principal
  - Defines that a principal must be defined for this property ACE
    - Usually for DAV:owner (?)

DAV methods changes:
- OPTIONS
  - Must return literal "access-control"
- MOVE
  - Must move non-inherited and non-protected ACEs from DAV:acl
- COPY
  - Permissions must not be copied.  Default ACL may apply.
  - If wish to preserve ACL, retrieve before COPY, then reapply ACLs.
- DELETE
- LOCK
  - Only lock owner may modify ACEs

Access control methods:
- ACL
  - Allows updating of ACLs

Reporting:
- REPORT
  - Must support DAV:expand-property
- DAV:acl-principal-prop-set 
  - Required
  - Returns property requested for all principals
    - Client access?
- DAV:principal-match
  - Required
  - Lists which ACEs you are the principal on
- DAV:principal-property-search
  - Required
  - Does a search for principals who match the criteria
- DAV:principal-search-property-set
  - Required
  - Returns what properties may be searched on DAV:principal-property-search