Résumé

  • RFC 3341 ordonnait plusieurs entrées owner/actor correspondantes par spécificité; effacer l’entrée exacte pouvait faire gagner une autorisation générique.
  • La révocation complète exigeait alors une entrée exacte all:none; disparition de la ligne, succès de mutation, notification, décision effective et blocage réel restaient des reçus distincts.

L’exemple du texte combine deux entrées. La première, destinée à un acteur nommé, autorise l’envoi de données, l’abonnement de présence et l’observation. La seconde autorise tous les acteurs du même domaine à envoyer des données. Si l’on supprime la première, l’acteur perd ses droits de présence mais conserve l’envoi de données grâce à la seconde.

L’opération administrative a pourtant réussi. La ligne visée n’existe plus. Ce qui subsiste n’est pas la ligne, mais la permission calculée après recomposition de l’ensemble des correspondances. La règle large devient le meilleur candidat. RFC 3341 propose donc de transformer l’entrée exacte en all:none lorsqu’il faut refuser toute action. Le refus reste présent et continue de battre la règle générique.

Une décision issue d’un classement

Chaque entrée contenait un owner, un actor, des actions permises et une date lastUpdate attribuée par le service. L’owner désignait l’extrémité ou la sous-adresse protégée. L’actor désignait une entité ou un groupe d’entités. Une action associait service et opération; core:data correspondait par exemple au droit d’utiliser le maillage pour envoyer des données à l’owner.

Les parties locale et domaine de l’actor acceptaient certains jokers. Plusieurs entrées pouvaient donc correspondre à la même adresse concrète. Le service retenait d’abord les entrées du bon owner et les acteurs compatibles. Il classait ensuite selon l’exactitude du domaine, puis celle de la partie locale. Une égalité exacte l’emportait; entre jokers, la correspondance la plus courte, donc la plus précise, avait priorité.

Le droit effectif n’appartenait ainsi à aucune ligne isolée. Il résultait de l’ensemble candidat, du classement et de l’action demandée. La preuve qu’une ligne a été supprimée décrit le stockage. Elle ne décrit pas encore le verdict de la prochaine évaluation.

Des entrées par défaut complétaient les lignes enregistrées. L’owner et les services APEX de son domaine recevaient des droits étendus; les services APEX de tout domaine recevaient core:data; les autres acteurs globaux recevaient all:none. Une entrée explicite ne remplaçait qu’un défaut ayant exactement la même valeur actor. L’état réel comprenait donc aussi les règles implicites.

Pourquoi le refus devait rester

Pour supprimer une entrée existante, une application envoyait un set contenant owner, actor et version courante, mais sans attribut actions. Le service supprimait l’entrée, envoyait une réponse de succès à l’auteur du changement et adressait séparément à l’owner un set sans actions pour annoncer la suppression.

La spécification prévient ensuite que les jokers peuvent faire de la suppression une modification de permission. all:none signifie qu’aucune opération n’est autorisée. Conservé sur l’actor exact, il reste plus spécifique que la règle large et transforme le résultat effectif en refus.

Cette entrée négative ressemble à une absence, mais elle transporte une information que l’absence ne possède pas. Elle dit que cet acteur précis ne doit pas hériter. Si une procédure de nettoyage la traite comme un simple tombeau obsolète, l’accès peut revenir sans création d’une nouvelle règle d’autorisation.

La version protégeait l’écriture

Avant remplacement ou suppression, l’application récupérait normalement l’entrée. La réponse fournissait lastUpdate, valeur nécessaire dans le set suivant. Si une mise à jour versionnée ne trouvait plus l’entrée exacte, ou si la date fournie n’était pas sémantiquement identique à la version actuelle, le service renvoyait le code 555. Une création omettait cette date.

Ce mécanisme empêchait d’écraser silencieusement une modification intervenue après la lecture. Le service produisait une nouvelle date après création ou mise à jour, différente de la précédente.

Mais une comparaison réussie ne prouvait pas la propagation. Elle n’attestait ni la réception de la notification par l’owner, ni l’observation du nouvel ensemble par chaque relais, ni le refus d’une opération ultérieure. Il faut relier lecture et version, mutation, réponse, nouvel état, notification émise, notification reçue, décision recalculée, point d’application mis à jour et test réel.

Le droit de poser la question

Le service protégeait aussi les requêtes de politique. Il vérifiait que le sujet appartenait au domaine et représentait une adresse valide. Puis il cherchait l’entrée du sujet correspondant à l’origine de la requête et exigeait access:query. Seulement ensuite sélectionnait-il l’entrée correspondant à l’actor étudié et vérifiait-il que toutes les actions demandées y figuraient.

L’acteur qui interroge et celui dont on mesure les droits sont donc différents. Le pouvoir d’interroger ne confère pas le pouvoir d’exécuter. De même, allow signifie que toutes les actions apparaissaient dans l’entrée retenue lors de cette évaluation; il ne garantit pas qu’une opération ultérieure utilisera la même version ni qu’elle aboutira.

RFC 3341 imposait enfin un stockage persistant des entrées, même quand l’adresse owner n’était pas rattachée au maillage. La déconnexion n’effaçait pas la politique. La persistance n’était pourtant ni un reçu de réplication, ni une preuve de fraîcheur, ni une observation de l’exécution.

Une mécanique devenue Historic

Publié sur la voie de normalisation en juillet 2002, RFC 3341 appartenait à la famille APEX avec le cœur, les options et la présence. L’historique IETF du 29 juillet 2012 explique le passage de RFC 3340 à RFC 3343 au statut Historic : à la connaissance de l’IETF, aucune implémentation n’avait été déployée et les fonctions étaient assurées par XMPP, largement déployé sous RFC 6120 et RFC 6121.

Cette phrase ne relie pas le non-déploiement au classement des règles et ne décrit aucun incident. Elle fixe une limite historique d’adoption. La limite de preuve reste cependant utile : supprimer un objet de politique, retirer un droit effectif et faire appliquer le refus sont trois événements.

Un audit moderne peut reprendre cette discipline sans prétendre que son système est APEX. Il conserve l’ensemble candidat et l’algorithme, protège les refus dont la présence a un sens, relit le verdict après mutation et teste le point d’application. La réponse de changement dit ce que le service a accepté. La révocation doit montrer ce que l’acteur ne peut plus faire.

Sources