Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol
Extracted elements (36)
Abstract privileges allow server implementations that cannot separate certain access capabilities (e.g., DAV:read from DAV:read-acl) to still present the standard privilege model by wrapping both under a non-abstract aggregate, making the standard privileges abstract on that resource.
ACE inheritance (dynamic sharing of an ACE from a parent resource) is explicitly distinguished from ACL initialization (the default ACL assigned when a resource is created). The mechanism for either is intentionally left unspecified to give implementations flexibility.
DAV:read-current-user-privilege-set is a separate privilege from DAV:read-acl because most users need to see their own effective permissions (for UI rendering) while the full ACL may reveal information inappropriate for general users. This keeps the set of users who can read the full ACL much smaller.
Principals are represented as http(s) WebDAV resources rather than opaque identifiers so that clients can use PROPFIND to discover human-readable display names and alternate URIs without requiring a separate directory protocol. The DAV:principal-URL property provides a single canonical URL to avoid ambiguity across multiple aliases.
Access control properties (DAV:acl, DAV:supported-privilege-set, DAV:current-user-privilege-set, etc.) SHOULD NOT be returned by a PROPFIND allprop request because retrieving ACL information is expensive on many servers. Clients must request these properties explicitly by name.
DAV:acl-restrictions lets clients discover server ACL constraints before submitting an ACL request, avoiding predictable rejection. Servers may still return additional implementation-specific errors (e.g., DAV:ace-conflict) that DAV:acl-restrictions cannot fully capture.
The DAV:group-member-set property on a group principal MUST reference principals by their DAV:principal-URL values, not arbitrary alternate URLs. Clients populating ACEs from group listings must resolve principal-URL first.
A principal MUST have a non-empty DAV:displayname property and a DAV:resourcetype property that includes the DAV:principal XML element.
A privilege MUST NOT contain itself; privilege containment loops are not allowed. For example, DAV:read cannot contain DAV:read.
An ACL request body MUST contain exactly one DAV:acl XML element, and MUST fail if the non-inherited, non-protected ACEs cannot be updated to exactly match the submitted set. Multiple precondition violations (no-ace-conflict, no-abstract, not-supported-privilege, missing-required-principal, recognized-principal, etc.) each require a specific DAV error element in the 403/409 response.
DAV:write MUST contain DAV:bind, DAV:unbind, DAV:write-properties, and DAV:write-content. Forbidden cross-containment rules prohibit DAV:read-acl from containing DAV:read or DAV:write, and vice-versa, to preserve fine-grained privilege separation.
Each element in DAV:current-user-privilege-set MUST identify a non-abstract privilege from the resource's DAV:supported-privilege-set. Abstract privileges MUST NOT appear in the current-user-privilege-set.
If a server supports access control, it MUST return "access-control" as a token in the DAV response header for OPTIONS on any resource it implements. Presence of this token MUST indicate full compliance with all MUST-level requirements in this document.
If an ACL contains an ACE with a DAV:protected element, any attempt to remove that ACE from the ACL MUST fail.
Server-defined privileges MUST NOT use the DAV: namespace; implementations must use a namespace they control such as an http scheme URL.
Servers implementing this specification MUST expose principal resources at an http(s) scheme URL. A URI of any scheme MAY identify a principal, but at least one of its URIs must be http(s).
Servers MUST report a 403 Forbidden error when access is denied due to insufficient privileges, except where the privilege restricts knowledge of the resource's existence, in which case 404 Not Found MAY be returned.
The DAV:acl property on the destination resource of a COPY MUST be the same as if the resource had been newly created (e.g., via MKCOL or PUT). Clients wishing to preserve the original ACL must read it before the COPY and restore it via a subsequent ACL request.
The DAV:read privilege MUST control the OPTIONS method in addition to GET and PROPFIND. Implementation-defined privileges controlling GET and PROPFIND MUST be aggregated under DAV:read.
When a resource is moved via MOVE, the non-inherited and non-protected ACEs in the DAV:acl property MUST NOT be modified, or the MOVE request MUST fail. Handling of inherited and protected ACEs is intentionally left to implementations.
When an HTTP method returns 403 Forbidden due to insufficient privileges, the response body MUST contain a DAV:error element enclosing a DAV:need-privileges element, which contains DAV:resource elements identifying which resource lacked which specific privilege.
A DAV:ace element has the structure: ((principal | invert), (grant|deny), protected?, inherited?). It either grants or denies a set of non-abstract privileges to a single principal, and may carry DAV:protected or DAV:inherited markers.
DAV:acl is a protected property containing an ordered list of access control entries (ACEs). Each ACE specifies a principal and a set of privileges to be granted or denied. If the DAV:acl property is empty, no principal is granted any privilege.
DAV:acl-restrictions is a protected property advertising the constraints a client must observe when submitting an ACL request: DAV:grant-only (no deny ACEs), DAV:no-invert (no inverted ACEs), DAV:deny-before-grant, and DAV:required-principal (mandatory ACE principals).
DAV:current-user-privilege-set is a protected property containing the exact set of non-abstract privileges granted by the server to the currently authenticated user, including all privileges expanded from aggregate privileges. Clients use this to adapt their UI without issuing speculative requests.
DAV:inherited-acl-set is a protected property containing URLs of resources whose ACLs also control access to this resource. Effective privilege is the AND of privileges granted by the local ACL and each inherited ACL.
DAV:principal-collection-set is a protected property on each resource identifying the root collections containing principals available on the server. Its scope defines where the DAV:principal-property-search REPORT operates. Servers MAY report only a subset of known collections.
DAV:principal-URL is a required protected property on every principal resource that returns the single canonical URL clients MUST use when constructing ACEs for that principal. It resolves the problem of a principal having multiple URLs.
DAV:principal within an ACE may be one of: DAV:href (a specific authenticated principal URL), DAV:all (every user), DAV:authenticated, DAV:unauthenticated, DAV:property (value of a resource property), or DAV:self (the resource itself as a principal). Servers may also support DAV:invert to negate a principal match.
DAV:supported-privilege-set is a protected property exposing the tree of privileges defined for a resource. Abstract privileges are flagged with DAV:abstract and MUST NOT be set in an ACE. The tree maps well-known DAV privileges to implementation-specific ones and guides administrative UIs.
Four REPORT types are defined: DAV:acl-principal-prop-set (retrieve properties of principals named in a resource's ACL), DAV:principal-match (find resources matching the current principal), DAV:principal-property-search (substring search on principal properties), and DAV:principal-search-property-set (list searchable properties).
The ACL method modifies only the non-inherited, non-protected ACEs in a resource's DAV:acl property, replacing them entirely with the ACEs in the request body. The request body MUST contain exactly one DAV:acl XML element.
Because access control is enforced per-principal, a compromised user account gains all privileges granted to that principal. Administrators should apply the principle of least privilege when constructing ACLs, and authentication mechanisms must be strong (Digest or better).
Clients have no foreknowledge of the initial ACL assigned to a newly created resource. Clients requiring specific initial permissions must read and, if necessary, update the ACL immediately after resource creation, accepting a race window where the default ACL applies.
The DAV:read-acl privilege exposes the full ACL including all principal URLs, enabling enumeration of users and groups. The DAV:current-user-privilege-set privilege, while less sensitive, reveals the effective permission set of the requesting user and can aid in privilege escalation attempts.
ACL evaluation iterates ordered ACEs until all required privileges are granted (access allowed) or a deny ACE is encountered for a not-yet-granted privilege (access denied). Evaluation halts as soon as the outcome is determined; failure to grant all required privileges also results in denial.