Résumé

  • DAV:current-user-principal renvoie, pour la requête courante, une seule URL HTTP(S) vers une ressource de principal, ou le pseudo-principal non authentifié.
  • Plusieurs URL peuvent désigner une même ressource et plusieurs ressources peuvent correspondre à un même principal; l’URL choisie est un amorçage, pas une identité universelle.
  • Authentification, localisation du principal, stabilité de sa représentation, découverte des collections, calcul des privilèges et effet final exigent des preuves distinctes.

La variation n’était pas forcément un changement de personne

RFC 3744 avait déjà donné à WebDAV un modèle de contrôle d’accès. Les utilisateurs et les groupes pouvaient être représentés par des ressources de principal. Une propriété protégée indiquait les privilèges du compte authentifié sur une ressource donnée. Mais un client ne disposait pas d’un moyen direct recommandé pour trouver la ressource représentant l’utilisateur courant.

La recherche DAV:principal-match ne supprimait pas l’ambiguïté. Elle pouvait retourner le principal individuel ainsi que tous les groupes auxquels il appartenait. Le résultat était utile pour explorer des relations; il ne répondait pas proprement à la question initiale: par quelle ressource commencer?

RFC 5397 ajoute ce point de départ. La propriété DAV:current-user-principal, protégée et calculée à chaque requête, porte un DAV:href unique ou DAV:unauthenticated. L’URL doit utiliser HTTP ou HTTPS et appartenir aux URL déclarées sur la ressource de principal. Le client peut ensuite interroger cette ressource pour découvrir d’autres propriétés.

Ce contrat explique le mot «amorce». Il n’offre pas la liste complète des identifiants, ne garantit pas que la ressource suivante sera accessible et ne décide pas qu’une écriture est autorisée.

Une URL sélectionnée n’est pas une clé éternelle

Le RFC reconnaît deux multiplicités. Une ressource de principal peut avoir plusieurs URL. Un seul principal authentifié peut aussi correspondre à plusieurs ressources de principal. Si plusieurs ressources conviennent, le serveur peut en choisir une, mais il devrait conserver un choix cohérent pour le même principal.

Cette latitude protège des architectures différentes. Elle devient risquée lorsque le client transforme l’URL observée en clé humaine universelle. Une migration, une nouvelle collection de principaux ou un changement de frontal peut modifier la représentation sans modifier la personne. À l’inverse, deux autorités différentes peuvent employer des chemins identiques sans désigner la même identité.

Le journal utile conserve donc l’autorité du service, l’instant, le compte authentifié, l’URL retournée, les redirections et les propriétés obtenues ensuite. Pour fusionner deux représentations, il faut une preuve produite par l’autorité compétente. La ressemblance des chaînes n’est pas suffisante.

La cohérence demandée par RFC 5397 n’est pas l’immobilité absolue. C’est une promesse opérationnelle: éviter les variations arbitraires et rendre les changements explicables. Un tableau de bord peut surveiller les changements, mais il ne doit ni créer automatiquement un nouvel utilisateur ni fusionner silencieusement deux historiques.

Une propriété de requête ne voyage pas avec un document

DAV:current-user-principal est calculée à partir de l’état d’authentification de la requête. Elle est protégée, et les opérations COPY ou MOVE ne la copient jamais. Le principal courant appartient au contexte qui observe la ressource, pas au fichier observé.

Cette règle devient importante pendant les exports et les migrations. Sérialiser la propriété comme une métadonnée durable figerait l’identité d’un ancien demandeur dans un objet vu plus tard par un autre compte. La réponse correcte doit être recalculée dans le nouveau contexte.

La mise en cache reste possible. RFC 6764 recommande de conserver les paramètres de découverte qui ont réussi, dont l’URL du principal, afin de les réutiliser. Mais une panne persistante de connexion ou d’authentification doit relancer la découverte SRV et celle du compte. Le cache accélère un contrat qui reste révocable; il ne remplace pas la source.

Le pseudo-principal ferme une branche dangereuse

Lorsque l’authentification n’a pas eu lieu ou a échoué, la propriété doit contenir DAV:unauthenticated. Ce résultat négatif empêche le client de confondre «aucun principal authentifié» avec «champ temporairement vide».

Réutiliser la dernière URL connue après un échec produirait une continuité visuelle au prix d’une fausse attribution. Fabriquer une URL à partir du nom de connexion aurait le même défaut. Le serveur est l’autorité qui associe la requête au principal; le client ne doit pas compléter ce fait par intuition.

Dans la découverte CalDAV ou CardDAV décrite par RFC 6764, le fournisseur doit imposer l’authentification aux PROPFIND qui demandent cette propriété. Si elle manque, le client peut devoir demander le chemin à l’utilisateur. L’absence déclenche un autre parcours de configuration, pas une permission de deviner.

Identifier n’accorde aucun droit supplémentaire

Le principal donne un sujet aux règles d’accès. Le droit reste calculé sur la ressource visée. DAV:current-user-privilege-set peut annoncer les opérations accordées au compte courant sur cette cible. Le simple fait d’avoir trouvé la ressource de principal ne remplit pas cet ensemble.

Un compte peut lire sa fiche, voir un carnet d’adresses, appartenir à plusieurs groupes et pourtant ne pas modifier une collection précise. Une réponse 200 au premier PROPFIND ne prédit donc ni le statut du second ni l’effet métier final.

Les applications CalDAV et CardDAV illustrent la chaîne. Le client trouve le service, négocie TLS, s’authentifie, reçoit une ressource de principal, découvre une collection d’accueil, évalue l’accès à une collection, soumet une opération puis vérifie l’état. Un seul voyant «connecté» efface six responsabilités.

La bonne télémétrie garde les transitions. Elle permet de dire si la panne vient du service, de l’authentification, du choix de représentation, de la ressource de principal, de la collection d’accueil, des droits ou du résultat applicatif.