Résumé

  • draft-jacobs-web4-federation-policy-00 propose une annonce lisible par machine qui nomme la politique, sa version, son autorité, son statut, ses recours, sa conservation et sa révocation.
  • Le texte précise qu’une publication ne prouve pas la conduite de l’opérateur et qu’un engagement cryptographique ne prouve ni vérité, ni complétude, ni légalité, ni aptitude à l’usage.
  • La révision 00 est un Internet-Draft individuel visant le statut Experimental, et non un RFC, un travail adopté par un groupe IETF ou un certificat.

Le scénario le plus trompeur est aussi le plus propre techniquement. Un logiciel récupère la bonne politique, vérifie l’émetteur, contrôle la preuve, constate que la date d’effet est atteinte et reçoit du service d’état la réponse « active ». Tout est exact dans cette chaîne. Rien n’indique encore si l’opérateur a réellement accordé le recours annoncé ou effacé les données au terme prévu.

La proposition publiée le 12 septembre 2026 ne cache pas cette limite. Elle indique qu’une fédération conforme publie des déclarations véridiques, versionnées et protégées en intégrité, puis ajoute que la publication seule ne prouve pas le comportement de l’opérateur. L’annonce devient ainsi une pièce de preuve sur ce qui a été déclaré, pas une attestation sur ce qui a été fait.

Le noyau de l’objet comprend l’identifiant de politique, la version, l’autorité responsable, la date d’effet, les profils pris en charge, les formats reconnus, le mécanisme d’état et la preuve d’intégrité. La politique doit en outre exposer les catégories de critères d’admission, les profils d’assurance, la conservation des preuves, les procédures de contestation et d’appel, la suspension et la révocation, la divulgation et la minimisation, la juridiction applicable et les versions prises en charge.

Cette normalisation a une valeur concrète. Le participant sait quelle autorité revendique la règle. L’auditeur peut identifier la version associée à une ancienne décision. Le système client peut reconnaître qu’une politique est remplacée ou retirée. Aucun de ces usages ne nécessite de déduire l’autorité depuis un logo ou de capturer une page web changeante.

Authentifier, appliquer, observer

Trois questions doivent rester séparées. L’authenticité demande si l’émetteur nommé a produit cet objet exact et si les octets ont été modifiés. L’applicabilité demande quelle version était en vigueur au moment de la décision et quel est son état présent. La conduite demande si l’opérateur a suivi les règles annoncées.

La preuve d’intégrité traite la première question. La découverte stable, les dates, l’état et l’historique traitent la deuxième. La troisième exige des observations, des dossiers de décision ou un contrôle extérieur. Une signature valide authentifie une déclaration ; elle ne transforme pas la déclaration en constat.

Le projet demande au vérificateur d’authentifier l’émetteur, de contrôler l’intégrité et la finalité de la preuve, d’appliquer la validité temporelle, de résoudre l’état courant et de lier sa décision à l’identifiant et à la version exacts. Il mentionne notamment la répétition, l’état périmé, la substitution non autorisée, la confusion d’identifiants, le compromis de clé, la rétrogradation d’algorithme et le comportement permissif en cas d’indétermination.

La version est donc une composante de la preuve. Une modification sémantique matérielle doit produire une nouvelle version. L’historique doit rester assez riche pour déterminer la politique qui gouvernait une décision passée. Remplacer silencieusement le fichier préserverait la simplicité du point d’accès, mais détruirait la possibilité de reconstruire le droit déclaré au moment pertinent.

Une frontière pour les informations internes

L’annonce minimale n’ouvre pas tout le fonctionnement de la fédération. Les scores d’éligibilité, classements d’admission, vecteurs de risque privés, relations de graphe internes, optimisations, délibérations, données de routage et de plan de contrôle ne sont pas requis. Le projet cherche une politique inspectable sans imposer la publication du moteur qui l’exécute.

Cette limite protège la sécurité, la vie privée et les secrets d’exploitation. Elle empêche également une lecture trop ambitieuse : puisque le public ne voit pas tous les intrants ni toutes les décisions, le format ne peut être présenté comme audit complet. Il fixe ce qui doit être déclaré à la frontière, non ce qui se passe derrière elle.

Les objets de preuve peuvent eux-mêmes tracer les personnes. Identifiants persistants, consultations d’état et reçus reliés créent des possibilités de corrélation. Le texte exige la minimisation et recommande des identifiants non corrélables ou par paire lorsqu’ils conviennent. Une preuve privée peut rester cachée derrière un engagement, mais la conservation et l’effacement demeurent des obligations de politique.

Un lien d’appel ne démontre enfin ni indépendance ni efficacité. La procédure peut dépendre du décideur initial, arriver trop tard ou ne proposer aucun maintien de la situation contestée. La proposition oblige à décrire la voie ; elle ne publie aucun résultat montrant qu’une fédération l’applique équitablement.

Le statut exact de la proposition

La révision 00 est un Internet-Draft individuel de cinq pages signé Tim Jacobs. Elle vise une publication Experimental, se trouve à l’état I-D Exists et expire le 16 mars 2027 si elle n’est pas remplacée. Aucun groupe de travail IETF ne l’a adoptée. Ce n’est ni un RFC, ni une approbation d’une couche Internet appelée « Web4 », ni une demande d’action à l’IANA.

Les autres textes Web4 cités ou voisins donnent un contexte architectural et terminologique. Ils ne confèrent pas d’autorité institutionnelle à cette annonce. De même, les mots obligatoires de la BCP 14 expriment les exigences proposées par l’auteur ; leurs majuscules ne prouvent pas un consensus IETF.

Sources