Summary

  • RFC 3744 treated a principal as a Web resource that could have multiple URLs, but required clients to use one canonical DAV:principal-URL when referring to that principal in an ACE.
  • Human-name search and advertised principal collections helped users find candidates; neither promised an exhaustive directory, authenticated anyone, or granted access.

The name on screen was not the thing in the rule

By 2004, WebDAV had made remote documents and collections editable over HTTP. Its access-control extension had to let clients express who could perform which operations on a resource. The tempting interface was a list of names. The protocol problem was harder: a name is for recognition, while an access-control entry (ACE) needs a reference that the server can evaluate.

RFC 3744, published in May 2004, represented a principal—a human or computational actor—as a network resource. The same principal might be reachable at /u/256432 and /people/Greg.Stein. Both URLs could be valid. A client could not infer merely from their appearance that they referred to the same actor. The human-readable DAV:displayname helped a person choose, but it was not the identity key.

RFC 3744 therefore established a canonicalization step. A client could retrieve DAV:principal-URL through any of a principal’s URLs; the property returned the same designated URL. When creating an ACE, the client had to use one of the principal’s URLs rather than treating every alias as a separate authority. Group membership followed the same reference rule: a group’s member set used each member’s principal URL. This gave the protocol a stable reference without requiring every user-facing URL to look alike.

The distinction mattered because the ACL was attached to a resource and its ACEs named principals plus privileges to grant or deny. If a client wrote an ACE against one alias and another client later encountered a different alias, the client had no general alias-equivalence oracle. Canonicalization moved that ambiguity into a protected server-maintained property instead of asking each client to guess.

Search was deliberately narrower than a directory

The protocol also needed a way for a human operator to find a principal among potentially thousands. RFC 3744 defined DAV:principal-property-search, a substring search over selected properties, and a separate report that told clients which properties were searchable. This was more flexible than forcing users through a fixed collection hierarchy, but it was not a promise that every useful identity attribute could be queried.

The boundary is explicit. A server may limit the properties available for search. Its DAV:principal-collection-set may identify some collections or none; the property does not guarantee a complete universe of principals. A search result is therefore a candidate surfaced by one server’s supported discovery interface, not proof that no other principal exists and not proof that two results are the same person.

That limitation was a design choice with practical consequences. A client could present a searchable picker and then normalize the selected resource to its principal URL. It could not truthfully label the picker a complete corporate directory unless some separate system supplied that guarantee. Discovery answered “which resource might the operator mean?” Canonicalization answered “which principal URL should the ACL name?”

Neither step answered “who is making this request?” RFC 3744 left authentication to HTTP mechanisms. When the server evaluated an ACE, it still had to validate the requesting principal and apply the ACL. A display name, search result, canonical URL, authentication credential and granted privilege are different records in the control path.

A boundary, not a complete identity system

RFC 3744 did not specify how principal resources or groups were created and maintained, nor how a resource’s initial ACL was established. It supplied interoperable references and discovery reports around those systems. That modest scope helped it integrate with different user-management repositories, but it also meant that directory completeness and lifecycle governance remained outside this protocol.

The specification’s historical contribution is not that a URL proved a person’s real-world identity. It made a narrower contract: aliases may exist; clients need a canonical principal URL for ACL references; discovery is bounded by server support; and authentication and authorization remain separate checks. The operator-facing search could help choose a subject without becoming the authority that defined the subject or granted it permission.

The source record establishes a standards design, not adoption by a named product, a current deployment census or a real access incident. The useful lesson is architectural: a discoverable label, a stable reference, an authenticated requester and an effective privilege are not interchangeable just because one interface displays them together.

Sources