Résumé

  • La RFC 3744 représentait chaque principal comme une ressource Web pouvant avoir plusieurs URL, mais imposait une référence canonique DAV:principal-URL dans les entrées de contrôle d’accès.
  • La recherche par nom et les collections annoncées aidaient à trouver des candidats sans garantir un annuaire exhaustif, une authentification ni un droit d’accès.

Le nom affiché n’était pas la référence de la règle

WebDAV avait rendu possible la création et la modification de documents distants par HTTP. Son extension de contrôle d’accès devait permettre à un client de dire qui peut effectuer quelles opérations sur une ressource. Une liste de noms semblait suffisante pour l’interface. Elle ne l’était pas pour le protocole : le nom aide l’humain à reconnaître une personne, tandis qu’une entrée de contrôle d’accès (ACE) doit désigner un sujet que le serveur saura évaluer.

Publiée en mai 2004, la RFC 3744 définit le principal comme une ressource réseau représentant une personne ou un acteur logiciel. Un même principal pouvait avoir plusieurs URL, par exemple un identifiant technique et une adresse plus lisible. Le client ne pouvait pas déduire de leur seule forme qu’elles désignaient le même sujet. DAV:displayname rendait le choix compréhensible, sans devenir pour autant l’identifiant de référence.

La spécification ajoutait donc une étape de normalisation. Quelle que soit l’URL du principal interrogée, la propriété protégée DAV:principal-URL renvoyait la même URL désignée. Lorsqu’il créait une ACE, le client devait employer une URL de principal conforme à cette règle. Les membres d’un groupe étaient eux aussi désignés par leur URL de principal. Le protocole stabilisait ainsi la référence sans exiger que toutes les adresses visibles soient identiques.

Cette distinction évitait de faire porter aux clients une équivalence qu’ils ne pouvaient pas établir. Une ACE attachée à une URL ne permettait pas, à elle seule, de conclure qu’une autre URL alias recevait les mêmes privilèges. La propriété canonique plaçait cette relation dans un état protégé géré par le serveur plutôt que dans une supposition locale du navigateur ou de l’éditeur.

Une recherche utile, mais non exhaustive

Pour qu’une personne puisse choisir parmi des centaines ou des milliers de principaux, la RFC prévoyait DAV:principal-property-search, une recherche par sous-chaîne sur certaines propriétés, et un rapport distinct indiquant lesquelles étaient interrogeables. Cela évitait d’imposer une navigation rigide dans des collections alphabétiques. Mais ce n’était pas une promesse de recherche sur toutes les données d’identité.

Le serveur pouvait limiter les propriétés recherchables. DAV:principal-collection-set pouvait annoncer certaines collections ou aucune. La RFC n’en faisait donc pas un répertoire complet. Un résultat indiquait qu’une ressource correspondait à la recherche prise en charge par ce serveur ; son absence ne prouvait pas que le principal n’existait pas, et deux résultats ne devenaient pas automatiquement une seule identité.

Le parcours avait ainsi deux questions différentes : « Quelle ressource l’opérateur veut-il sélectionner ? » puis « Quelle URL canonique doit figurer dans l’ACE ? » Ni l’une ni l’autre ne répondait à « Qui envoie réellement la requête ? ». La RFC laissait l’authentification aux mécanismes HTTP. Le serveur devait encore valider le demandeur, examiner l’ACL et déterminer ses privilèges. Un nom affiché, un résultat de recherche, une URL canonique, une preuve d’authentification et une permission effective sont des éléments distincts.

Un raccord, pas un système d’identité complet

La RFC 3744 ne définissait ni la création et la maintenance des ressources de principal et des groupes, ni la façon dont une ACL initiale devait être établie. Elle proposait des références et des rapports interopérables autour de systèmes de gestion d’utilisateurs déjà différents. La complétude de l’annuaire et la gouvernance du cycle de vie restaient à traiter ailleurs.

La contribution historique est donc un contrat précis, pas une preuve d’identité civile : plusieurs alias peuvent exister ; les ACE ont besoin d’une URL canonique ; la découverte dépend des fonctions offertes par le serveur ; authentification et autorisation restent séparées. La norme décrit ce que les clients et serveurs doivent échanger. Elle ne prouve ni l’adoption par un produit donné, ni la couverture d’un annuaire réel, ni le résultat d’un incident.

Sources