Resumo

  • A RFC 3744 tratou o principal como um recurso Web que podia ter várias URLs, mas exigiu a referência canônica DAV:principal-URL nas entradas de controle de acesso.
  • A busca por nomes e as coleções anunciadas ajudavam a localizar candidatos; não prometiam um diretório completo, autenticação nem concessão de acesso.

O nome exibido não era a referência da regra

O WebDAV permitiu editar documentos e coleções remotos por HTTP. Sua extensão de controle de acesso precisava expressar quem podia executar quais operações sobre um recurso. Uma lista de nomes parecia natural para a interface, mas o protocolo exigia algo diferente: o nome ajuda a pessoa a reconhecer; uma entrada de controle de acesso (ACE) precisa apontar para um principal que o servidor consiga avaliar.

Publicada em maio de 2004, a RFC 3744 representou o principal — uma pessoa ou agente computacional — como um recurso de rede. O mesmo principal podia ter mais de uma URL, uma técnica e outra mais fácil de ler. Um cliente não podia inferir pela aparência que ambas identificavam o mesmo ator. DAV:displayname oferecia uma etiqueta humana, não uma chave de identidade.

A especificação criou uma etapa de normalização. Ao consultar DAV:principal-URL por qualquer endereço do principal, o cliente recebia a mesma URL designada. Para criar uma ACE, precisava usar a URL do principal conforme essa regra. A lista de membros de um grupo também usava a URL de principal de cada membro. Assim, o protocolo estabilizou a referência sem exigir que os endereços visíveis fossem iguais.

Isso importava porque uma ACL pertence a um recurso e suas ACEs associam principais a privilégios. Se uma regra nomeasse um alias, outro cliente não teria um mecanismo geral para concluir que uma URL diferente era equivalente. A RFC 3744 colocou essa relação em uma propriedade protegida mantida pelo servidor, em vez de pedir que cada cliente adivinhasse.

Buscar não era enumerar

Para ajudar alguém a escolher entre centenas ou milhares de principais, a RFC definiu DAV:principal-property-search, uma busca por trecho em certas propriedades, e um relatório separado que informa quais propriedades são pesquisáveis. Era mais flexível que obrigar o operador a percorrer uma hierarquia fixa, mas não prometia consultar todos os atributos de identidade.

O servidor podia limitar as propriedades disponíveis para busca. DAV:principal-collection-set podia anunciar algumas coleções ou nenhuma. Portanto, não garantia um diretório completo. Um resultado indicava que uma pesquisa compatível com aquele servidor encontrou um candidato. A ausência de resultado não provava que o principal não existia; dois resultados tampouco provavam que eram a mesma pessoa.

O fluxo respondia a duas perguntas: “qual recurso o operador quer selecionar?” e “qual URL canônica a ACE deve usar?”. Nenhuma respondia “quem está enviando a requisição?”. A RFC deixou a autenticação para mecanismos HTTP. Ao avaliar uma ACE, o servidor ainda precisava validar quem solicitava e aplicar a ACL. Nome exibido, resultado de busca, referência canônica, credencial e privilégio efetivo são registros distintos.

Um contrato de interoperabilidade, não um sistema de identidade

A RFC não definiu como criar e manter recursos de principal ou grupos, nem como estabelecer a ACL inicial de um recurso. Ela forneceu referências e relatórios de descoberta interoperáveis para integrar repositórios de usuários diferentes. A completude do diretório e a governança do ciclo de vida ficaram fora do escopo.

Sua contribuição histórica foi um contrato delimitado: aliases podem coexistir; ACEs precisam de uma URL canônica; a descoberta depende do que cada servidor oferece; autenticação e autorização seguem como verificações separadas. O texto normativo comprova esse desenho, não a adoção por um produto específico, a completude de um diretório real ou o resultado de um incidente.

Fontes