Résumé

  • RFC 8259 recommande l'unicité des noms d'un objet, car les récepteurs divergent devant un doublon : certains gardent la dernière paire, d'autres échouent, d'autres encore exposent toutes les occurrences.
  • Lorsqu'un parseur a réduit ces occurrences à une table ne contenant qu'une valeur, la validation, la journalisation ou la canonicalisation ultérieure ne peut plus restituer ce qui a été supprimé.
  • La frontière défendable se situe à l'entrée : conserver une preuve du message reçu, comparer les noms après traitement des échappements et refuser l'ambiguïté avant tout usage métier.

Avant la table, il existe une séquence

Sur le réseau, un objet JSON est une suite ordonnée de membres. Dans le programme, il devient le plus souvent une table associative où chaque clé ne possède qu'une valeur. Tant que les noms sont uniques, la différence reste invisible. Dès qu'un nom revient, la conversion exige une décision : première occurrence, dernière occurrence, liste complète ou erreur.

Le développeur de l'application ne voit pas toujours cette décision. Le serveur HTTP, la passerelle ou un middleware peut avoir déjà construit l'objet avant d'appeler son code. Le contrôle d'accès lit alors une valeur, la logique métier une autre projection, et le journal réencode l'objet normalisé. Chacun peut « fonctionner comme prévu » tout en traitant un message différent.

Dire que le JSON a été correctement parsé ne prouve donc pas qu'il avait une signification unique. Cela prouve qu'un parseur a produit un résultat.

La prudence précise de RFC 8259

RFC 8259 dit que les noms d'un objet DEVRAIENT être uniques. Il ne les interdit pas par une obligation grammaticale absolue. Cette nuance explique pourquoi un texte comportant un doublon peut franchir un outil conforme à la syntaxe de base.

Le document décrit ensuite le coût d'interopérabilité. Avec des noms uniques, les implémentations réceptrices s'accordent sur les associations entre noms et valeurs. Sans cette propriété, leur comportement devient imprévisible : beaucoup ne rapportent que la dernière paire, certaines signalent une erreur ou refusent le texte, et d'autres livrent toutes les paires. Les bibliothèques ne s'accordent même pas toujours sur l'exposition de l'ordre des membres.

La faille de contrôle apparaît lorsqu'une décision en amont dépend de la première occurrence alors que l'exécution en aval conserve la dernière. Le journal, produit après la réduction, peut n'en montrer qu'une. Il n'est pas nécessaire d'inventer un incident : l'architecture a déjà perdu la capacité de démontrer que ses composants ont raisonné sur les mêmes faits.

I-JSON fait de l'unicité une condition d'admission

RFC 7493 adopte une position plus stricte pour le profil I-JSON : un objet NE DOIT PAS comporter de membres aux noms dupliqués. Le mot « dupliqué » s'évalue après le traitement des caractères échappés. Deux écritures différentes dans le texte peuvent donc devenir la même suite de caractères Unicode.

Cette précision disqualifie un filtre superficiel placé devant le vrai décodeur. Il faut observer les noms décodés, sans perdre les occurrences. Le profil autorise ensuite un récepteur à rejeter ou ignorer un message non conforme ; un protocole de sécurité peut exiger qu'il ne soit pas considéré comme digne de confiance.

La vérification doit précéder la construction de la table ordinaire. Si elle reçoit une table où le parseur a déjà appliqué « la dernière valeur gagne », elle ne trouvera plus aucun doublon. Le contrôle appartient donc à un mode de parseur qui signale les répétitions, ou à une étape lexicale capable de parcourir tous les noms décodés avant leur réduction.

Le premier parseur exerce un pouvoir de politique

Faute de règle explicite, une option de bibliothèque choisit le fait qui survivra. Elle devient ainsi une autorité de politique sans avoir été conçue comme telle.

Une chaîne d'entrée robuste rend ce pouvoir visible. Elle limite taille et profondeur, décode les noms de manière constante, recherche les collisions après échappement et refuse l'objet avant que tarification, routage, autorisation ou persistance ne s'en servent. Elle conserve séparément les octets reçus, ou au minimum leur empreinte cryptographique selon une politique de rétention adaptée.

Réencoder la table après coup ne constitue pas une preuve équivalente. Cette copie décrit le choix du parseur ; elle ne décrit pas nécessairement tout ce qui est arrivé.

L'exception JWS reste dans son périmètre

RFC 7515 fournit une règle particulière pour les en-têtes JOSE. Leurs paramètres doivent avoir des noms uniques. Un parseur JWS doit soit rejeter les doublons, soit utiliser un parseur JSON qui rend seulement le dernier membre dupliqué dans l'ordre lexical.

Cette disposition explicite ne transforme pas l'ensemble de JSON en protocole « dernière valeur gagnante ». Elle concerne les paramètres d'en-tête JOSE, pas n'importe quel corps d'API, fichier de configuration ou charge utile. La vérification d'une signature JWS établit en outre une propriété cryptographique du message protégé ; elle ne décide pas à elle seule si l'opération représentée doit être autorisée.

Une exception n'est exploitable avec sûreté que si la passerelle, la bibliothèque, le vérificateur et les outils d'observation suivent tous la même règle. Dans le cas contraire, la spécification locale ne répare pas la divergence entre composants.

La canonicalisation travaille après l'admission

RFC 8785 définit JCS, un schéma de canonicalisation de JSON. Son ordre est révélateur : les données doivent respecter I-JSON, les objets ne doivent pas présenter de propriétés dupliquées, les primitives suivent des règles de sérialisation définies et les propriétés sont triées de façon déterministe.

La canonicalisation réussit parce que le modèle admis est déjà sans ambiguïté. Si un parseur généraliste élimine d'abord une occurrence, puis JCS canonicalise la table obtenue, les octets seront déterministes — mais seulement pour cette projection. Ils ne prouvent pas que le message initial ne contenait qu'un membre de ce nom.

Pour un schéma de signature, JCS ordonne trois contrôles : parser et vérifier la conformité I-JSON, vérifier les conventions propres à l'écosystème, puis vérifier la signature. Tout échec impose l'abandon. Syntaxe admissible, sens métier et preuve cryptographique demeurent ainsi trois questions distinctes.

Concevoir les passages entre représentations

Le contrat technique doit nommer ses états : octets reçus, suite de jetons décodés, objet admis sans doublon, modèle métier validé, puis éventuelle forme canonique ou enveloppe signée. Chaque passage possède un responsable et un résultat d'échec.

Les essais doivent placer des doublons à plusieurs profondeurs et employer des noms qui ne deviennent identiques qu'après décodage des échappements. Ils doivent traverser la vraie passerelle, les middlewares, le chemin de signature et la journalisation. Le bon résultat n'est pas seulement un code d'erreur : aucune action en aval ne s'est produite, la cause est classée et la preuve retenue correspond au message original.

Une mise à niveau de parseur, de moteur d'exécution ou de passerelle peut modifier la règle de collision sans toucher au schéma métier. Des corpus de conformité partagés entre composants permettent de détecter cette dérive avant la production.

Sources