Resumen

  • RFC 3744 modeló a un principal como un recurso web con posibles URL múltiples, pero exigió una referencia canónica DAV:principal-URL para nombrarlo en una entrada de control de acceso.
  • La búsqueda por nombre y las colecciones anunciadas facilitaban encontrar candidatos; no garantizaban un directorio completo, autenticaban a nadie ni concedían acceso.

El nombre visible no era el sujeto de la regla

WebDAV permitió editar documentos y colecciones remotos mediante HTTP. Su extensión de control de acceso tenía que expresar quién podía ejecutar qué operación sobre un recurso. Una lista de nombres parecía una interfaz natural. El protocolo necesitaba algo distinto: el nombre ayuda a una persona a reconocer, mientras que una entrada de control de acceso (ACE) debe apuntar a un principal que el servidor pueda evaluar.

La RFC 3744, publicada en mayo de 2004, representó a cada principal —una persona o agente computacional— como un recurso de red. Un mismo principal podía aparecer con varias URL, una técnica y otra más legible. El cliente no podía deducir solo por su aspecto que ambas identificaban al mismo actor. DAV:displayname ofrecía una etiqueta humana, no una clave de identidad.

Por eso la norma incorporó una referencia canónica. Al consultar DAV:principal-URL desde cualquiera de las URL del principal, el cliente recibía la misma URL designada. Para crear una ACE debía usar una URL del principal conforme a esa regla. La lista de integrantes de un grupo aplicaba el mismo criterio: cada miembro se representaba mediante su URL de principal. Se estabilizaba la referencia sin exigir que todos los alias desaparecieran.

La diferencia era importante porque una ACL asociaba privilegios a recursos y las ACE nombraban principales. Si una regla mencionaba un alias, otro cliente no tenía una forma general de saber si una URL distinta era equivalente. RFC 3744 trasladó esa relación a una propiedad protegida mantenida por el servidor, en vez de pedir a cada cliente que la adivinara.

Buscar no significaba enumerar

Para que un operador pudiera elegir entre cientos o miles de principales, la norma definió DAV:principal-property-search, una búsqueda por subcadena en ciertas propiedades, y otro informe para indicar qué propiedades podían buscarse. El mecanismo evitaba obligar al usuario a recorrer una jerarquía alfabética fija. No prometía consultar todos los atributos de identidad.

El servidor podía limitar las propiedades disponibles. DAV:principal-collection-set podía anunciar algunas colecciones o ninguna. Por tanto, no era una garantía de directorio exhaustivo. Un resultado significaba que una coincidencia estaba disponible a través de la interfaz soportada por ese servidor. No encontrar a alguien no demostraba su inexistencia; dos resultados tampoco probaban que fueran la misma persona.

El proceso contestaba primero «¿qué recurso quiere seleccionar el operador?» y luego «¿qué URL canónica debe usar la ACE?». Ninguna pregunta respondía «¿quién envía realmente la solicitud?». RFC 3744 dejó la autenticación a los mecanismos HTTP. Al evaluar una ACE, el servidor aún debía validar al solicitante y aplicar la ACL. Nombre visible, resultado de búsqueda, referencia canónica, credencial y privilegio efectivo son comprobantes diferentes.

Un contrato de interoperabilidad, no un sistema de identidad

La RFC no especificó cómo crear y mantener recursos de principal o grupos, ni cómo inicializar la ACL de un recurso. Ofreció referencias y búsquedas interoperables que podían integrarse con repositorios de usuarios diversos. La integridad del directorio y el gobierno de su ciclo de vida quedaban fuera.

Su aporte histórico fue un contrato acotado: pueden existir alias; los clientes necesitan una URL canónica para las ACE; la búsqueda depende de las capacidades anunciadas por cada servidor; y la autenticación y la autorización siguen siendo controles separados. El texto normativo prueba ese diseño, no su adopción por un producto, la exhaustividad de un directorio real ni el resultado de un incidente.

Fuentes