Résumé

  • La version -04 du projet individuel CAID, datée du 28 septembre 2026, conserve la forme canonique et le condensat des objets que -03 et -04 acceptent toutes deux.
  • Elle refuse pourtant certains objets qui possédaient un identifiant valable selon -03. L'identifiant seul ne suffit donc pas à rejouer loyalement une décision ancienne.

Un auditeur examine une opération approuvée la veille. Il soumet l'objet archivé au logiciel actualisé et obtient un refus. L'écran lui propose une conclusion commode : l'ancien dossier était invalide. Cette conclusion est peut-être fausse. Le contenu n'a pas nécessairement été altéré, et le calcul du condensat n'a pas nécessairement changé. Le logiciel peut appliquer un ensemble plus étroit d'entrées admissibles. Le bon compte rendu comporte alors deux observations, non une correction rétrospective : « admis selon la règle précédente » et « refusé selon la nouvelle ».

Cette différence est au cœur de la révision -04 de The Canonical Action Identifier, soumise par Iman Schrock. CAID propose de représenter une action par un objet typé, de fixer la manière de le canoniser et de lui attribuer un identifiant compact. L'objectif est de comparer des actions mentionnées dans des pièces d'autorisation, de délégation, d'exécution ou d'audit dont les formats locaux ne retiennent pas les mêmes champs. Ce n'est, à ce stade, qu'un Internet-Draft individuel. Le Datatracker indique qu'il n'a pas de statut formel dans le processus de normalisation de l'IETF ; aucun déploiement ou incident n'est établi par sa publication.

L'auteur a pris soin de limiter la portée de la continuité annoncée. La section 14 précise que, pour les objets admis par les deux révisions, les suites, le condensat et la forme canonique restent inchangés. Elle qualifie néanmoins -04 de révision substantielle du modèle de traitement. Il ne faut donc ni annoncer une migration générale des hachages, ni prétendre que toute ancienne action sera encore acceptée. La liste des nouvelles exclusions comprend notamment une imbrication de plus de 64 niveaux, un encodage canonique dépassant 16 777 216 octets, des caractères Unicode non conformes et certains horodatages que la description antérieure laissait passer, comme un t ou un z minuscule ou une seconde égale à 60. Le texte dit expressément que plusieurs de ces objets avaient un CAID valable sous -03.

Le condensat et la validation ne portent pas la même promesse. Le premier lie des octets canoniques à une suite donnée ; la seconde décide si l'objet entre dans le domaine où ce calcul peut faire foi. Si ce domaine rétrécit, le même dossier peut changer de verdict sans que l'identifiant des cas communs ne soit modifié. Un refus nouveau n'accuse pas automatiquement l'émetteur d'avoir falsifié une action. Il indique d'abord que le nouveau vérificateur n'accepte plus cette forme ou cette définition. Pour établir davantage, il faudrait des preuves propres au cas étudié.

La définition du type d'action devient elle aussi une pièce vérifiable. -04 ajoute definition_sha256, qui désigne la projection de validation d'une définition, et permet de comparer la définition utilisée à celle attendue. Une divergence peut produire definition_mismatch. Un simple nom de type ne suffit donc plus à présumer que deux équipes vérifient les mêmes champs matériels. Le registre de référence de l'auteur passe à la version 5 tout en conservant le fichier de la version 4 octet pour octet comme historique. Ce registre appartient aux matériaux du projet : les sept registres demandés dans le texte ne sont pas, par cette seule demande, des registres IANA créés et utilisés partout.

La nouvelle version précise aussi le traitement d'un texte JSON, l'ordre des motifs de refus et la résolution de définitions non conformes. Le cas de deux noms de membre JSON identiques, y compris après décodage d'échappements, figure parmi les entrées refusées. Il montre pourquoi une première lecture ambiguë ne peut être réparée par un hachage ultérieur. Mais réduire l'actualité de -04 aux doublons JSON manquerait le changement principal : le périmètre de validité d'une même identité d'action est désormais plus explicite et plus strict.

CAID ne donne aucune autorité à l'action qu'il nomme. Son résumé exclut explicitement l'identité de l'acteur, son pouvoir d'autoriser, l'exécution, la sûreté et la valeur juridique. La question nouvelle se situe en amont de ces choix : deux participants peuvent-ils seulement dire qu'ils ont validé le même objet selon les mêmes règles ? S'ils ne gardent que la chaîne compacte, la réponse devient impossible à contrôler après une mise à jour. Il leur faut aussi le jeu de règles, la définition du type et le résultat de chaque tentative de vérification.

La mesure proposée ici par Daniel Kade est un reçu de validation versionné : objet source ou référence vérifiable, CAID et suite, version du parseur et du projet ou de l'implémentation, empreinte de la définition, instantané du registre, verdict et raison du refus, puis décision explicite en cas de migration. Ce reçu n'est pas un champ normalisé par le projet. Il vise à empêcher qu'un tableau de bord remplace l'histoire de l'ancienne décision par le résultat d'un nouveau test.

Sources