Résumé

  • La révision 00 de terms.txt décrit des contrôles appliqués par l’origine avant de livrer un contenu : signature, intention, délégation éventuelle et bon de paiement.
  • La déclaration signée reste une déclaration. Le reçu atteste une seule remise ; aucun des deux ne démontre l’utilisation faite après la remise.
  • Daniel Kade propose un registre des obligations d’accès qui sépare décision préalable, audit ultérieur et obligation contractuelle. Il s’agit d’une proposition éditoriale, pas d’une règle de l’IETF.

Le reçu révèle la limite du système

Prenons le reçu en premier. Dans la révision 00, l’origine renvoie un champ Access-Receipt signé lorsqu’une requête satisfait les conditions publiées. Le reçu est lié à la signature d’une requête, à la représentation livrée et aux conditions qui s’appliquaient. Il peut donc répondre à une question précise : quel contenu cette origine a-t-elle remis à cet identifiant d’agent, sous quelle version des règles ?

Il ne répond pas à une autre question : qu’est devenu le contenu après la remise ? Une copie peut être résumée, indexée, incorporée à un jeu d’entraînement ou transmise ailleurs. Le protocole HTTP n’observe pas ces décisions. Le projet le reconnaît explicitement : une intention signée est attribuable et intacte, mais sa véracité ne découle pas de la signature.

Cette granularité explique une règle apparemment technique. Une réponse munie d’un reçu doit porter Cache-Control: no-store, selon le vocabulaire de la mise en cache HTTP. Si un cache partagé servait la même réponse à une deuxième requête, il réutiliserait le reçu de la première. L’origine n’aurait ni signé ni journalisé la seconde livraison. Un reçu par requête n’est pas un certificat collectif attaché au fichier.

Des conditions exécutées avant la sortie

Le mécanisme proposé complète le cadre de robots.txt. RFC 9309 indique que les règles d’exclusion demandent un comportement aux robots, mais ne constituent pas une autorisation d’accès. terms.txt placerait un fichier à l’adresse /.well-known/terms.txt, dans la logique des URI bien connues. Chaque bloc de chemin pourrait autoriser, facturer ou refuser un objectif donné, limiter le niveau de reproduction et imposer une délégation de l’utilisateur.

La requête s’appuierait sur le projet distinct de signature des robots Web et sur les signatures de messages HTTP. Le champ Access-Intent annoncerait une finalité et un niveau d’usage. Une délégation et un bon de paiement pourraient s’y ajouter. La signature doit couvrir ces éléments ainsi que l’URI cible complète.

À ce point de passage, l’origine peut vérifier la clé, la fraîcheur, l’unicité, la portée d’une délégation, la concordance avec la version des conditions et la consommation unique d’un bon. Elle peut refuser avant de livrer. Le projet choisit alors le statut 403 accompagné d’un objet Problem Details. Il n’attribue pas une signification nouvelle au statut 402, réservé par la sémantique HTTP, et n’utilise pas 401 sans mécanisme WWW-Authenticate.

Après la sortie, le pouvoir change de nature. Les journaux peuvent soutenir une enquête. Les conditions peuvent soutenir un contrat. Mais le serveur n’exécute plus le comportement du destinataire.

Identifier une clé n’est pas identifier une société

La signature réduit une autre ambiguïté sans la supprimer. Le mécanisme Web Bot Auth établit que le détenteur d’une clé publiée sous un identifiant d’agent a signé la requête. Il permet à l’origine de reconnaître ce même identifiant, de lui appliquer une limite ou de le bloquer. Il ne prouve pas à lui seul l’identité juridique de l’opérateur.

La délégation connaît une limite comparable. Le jeton serait émis par un fournisseur d’identité auquel l’origine fait confiance, mais la naissance de cette confiance reste hors du champ du projet. Il en va de même pour le rapport entre l’origine et un service de règlement qui émettrait des bons. L’interopérabilité du message ne confère pas automatiquement une légitimité à ces intermédiaires.

Un fichier invalide pose enfin un risque de gouvernance très concret : si terms.txt ne respecte pas la grammaire, le fichier entier est rejeté et le client doit agir comme si aucune condition n’avait été publiée. Une virgule n’est donc pas qu’un détail d’édition ; elle peut changer l’état observable de l’autorité de l’origine.

Une proposition, pas une norme adoptée

La fiche Datatracker présente le texte comme un Internet-Draft individuel, sans flux défini et sans statut formel dans le processus de normalisation. L’historique date la publication manuelle de la révision 00 du 11 septembre 2026. Il n’existe ni adoption par un groupe de travail, ni directeur de zone responsable, ni approbation de l’IESG, ni RFC.

L’en-tête vise la voie « Standards Track », alors que Datatracker ne renseigne encore aucun statut RFC prévu. C’est une intention de trajectoire, pas une décision. Les projets de groupe de travail sur le vocabulaire des préférences IA et son association à HTTP sont des travaux voisins, mais leur état institutionnel ne se transfère pas à terms.txt.

La mise en œuvre citée n’efface pas cette prudence. Le texte annonce 24 vérifications et des mesures de temps, puis précise que la version v0.1 est antérieure au document et s’en écarte sur l’URI signée, les statuts HTTP, les jetons, l’identifiant, le contenu des reçus, les bons, le cache et le nom de la relation de lien. Le code montre une expérience ; il ne prouve pas encore la conformité à cette révision.

Un registre pour ne pas confondre les pouvoirs

Daniel Kade propose un registre des obligations d’accès tenu localement. Une ligne relierait l’origine et le chemin à l’identifiant et au condensat des conditions, à la finalité déclarée, au niveau d’usage, à l’identifiant cryptographique et à sa limite d’assurance, aux autorités de délégation et de règlement, à la décision avant livraison, au condensat du contenu, au reçu, aux observations ultérieures, à l’obligation contractuelle, au responsable du litige, à l’expiration et à la succession des conditions.

Le Policy Mirror de Heng Lu invite à rendre visible la frontière entre preuve et décision. La spécification initiale minimale défend un noyau commun étroit qui laisse les choix futurs au niveau local. Why BTW Media Exists rappelle enfin qu'une proposition mérite d'être décrite avec ses limites. Ici, l'honnêteté tient dans une phrase : le protocole peut constater une remise ; il ne peut pas certifier l'avenir de la copie.

Sources

  1. Fiche Datatracker de terms.txt
  2. Historique de terms.txt
  3. Révision 00 de terms.txt
  4. Projet Web Bot Auth
  5. Vocabulaire des préférences d’usage de l’IA
  6. Association des préférences IA à HTTP
  7. RFC 9309 — Robots Exclusion Protocol
  8. RFC 9421 — HTTP Message Signatures
  9. RFC 9457 — Problem Details
  10. RFC 9110 — Sémantique HTTP
  11. RFC 9111 — Cache HTTP
  12. RFC 8615 — URI bien connues
  13. RFC 8126 — Procédures d’enregistrement IANA
  14. The Policy Mirror
  15. Minimum Initial Specification
  16. Why BTW Media Exists