Résumé

  • Les variantes Base64 sloppy de RFC 9741 dispensent d’un contrôle précis sur les bits inutilisés. Le contrôle .json, lui, porte sur la valeur décodée et non sur une sérialisation unique.
  • Une différence de libellé ne produit un problème d’autorisation ou de facturation que si les clés et les liaisons du service lui donnent cet effet. Elle ne démontre à elle seule ni contournement ni surfacturation.
  • Il faut distinguer les représentations admises, l’identité métier et les données couvertes par une signature, puis attribuer le coût de leur rapprochement au bon responsable.

Le désaccord commence au rapprochement

Imaginons une équipe financière qui cherche à rapprocher deux lignes de consommation. Les libellés diffèrent, mais le service technique affirme qu’ils désignent le même contenu. Faut-il supprimer une ligne, conserver deux demandes ou rechercher deux opérations distinctes ? Sans unité de facturation explicite, aucune de ces réponses ne découle du décodage.

Ce cas est hypothétique. Il ne décrit ni un fournisseur identifié ni un incident observé. Il met en scène un service de références de contenu dont l’accueil, les autorisations, le cache et les comptes sont gérés séparément. Chaque équipe peut avoir une bonne raison d’utiliser son propre identifiant. Le risque naît lorsque l’on suppose, sans l’avoir établi, que ces identifiants donnent le même sens au mot « identique ».

Une demande reçue, une ressource conservée et une opération autorisée ne sont pas la même chose. Deux demandes peuvent coûter du travail même si elles aboutissent à une seule ressource. Deux clients peuvent soumettre la même donnée sans partager une autorisation. Le rapprochement n’est donc pas un exercice consistant à éliminer tous les doublons : il doit préserver les distinctions que le contrat et l’autorité d’exécution exigent.

RFC 9741 aide à formuler le premier étage de cette question, celui du texte et de la valeur. Il n’installe pas un service commun d’arbitrage entre les équipes. La compatibilité gagnée à l’entrée reste incomplète tant que personne ne sait ce qu’elle implique pour les identités en aval.

Une tolérance étroite, pas une réparation générale

Publié en mars 2025 sur la voie des standards de l’IETF, RFC 9741, de Carsten Bormann, ajoute des opérateurs CDDL de conversion et de traitement du texte. Les opérateurs .b64u et .b64u-sloppy concernent Base64url sans remplissage ; .b64c et .b64c-sloppy concernent le Base64 classique avec remplissage. Les variantes sloppy omettent la vérification imposant des bits supplémentaires inutilisés à zéro. Les autres règles ne sont pas effacées. Le statut du RFC ne prouve pas qu’un outil donné les applique.

Prenons Zg et Zh. Dans ces deux graphies, les huit premiers bits valent 01100110, soit l’octet 0x66. Les quatre bits restants du second groupe de six bits sont respectivement 0000 et 0001. Ce calcul manuel illustre la distinction ; il ne constitue pas un test de conformité exécuté sur un validateur CDDL. Pour une même valeur de contrôle autorisant cet octet, la différence pertinente entre le contrôle strict et sa variante sloppy se situe dans ces bits inutilisés. En Base64 classique, les graphies correspondantes sont Zg== et Zh==.

RFC 4648, section 3.5, impose aux encodeurs conformes de mettre ces bits à zéro et traite du choix de rejet par les décodeurs selon la spécification qui les utilise. Quatre bits variables donnent seize graphies pour cette disposition d’un seul octet. Ce nombre ne doit pas être attribué automatiquement à toutes les références, quelle que soit leur longueur.

Un accueil strict peut ainsi refuser la graphie non canonique ; une entrée de compatibilité peut admettre l’alias dans les limites définies. En revanche, interpréter sloppy comme une permission de tolérer des caractères étrangers, n’importe quel espace ou une troncature inventerait une autre politique. La portée de la tolérance doit être lisible pour les autres équipes.

Le formulaire et son empreinte ne répondent pas à la même question

Les mêmes difficultés sont possibles avec des textes JSON plus ordinaires :

{"account":"team-a","units":1}

{ "units": 1, "account": "team-a" }

Les membres ont les mêmes valeurs, avec un petit entier et une chaîne fixe ; seuls leur ordre et les espaces non significatifs changent. Il n’y a pas de nom dupliqué. RFC 8259 fournit le cadre syntaxique ; RFC 7493 sur I-JSON écarte notamment les membres dupliqués et précise que leur ordre ne change pas le sens du message.

Le contrôle .json de RFC 9741 décrit la valeur obtenue selon la conversion JSON vers CBOR par défaut de RFC 8949, section 6.2. Il ne fixe ni les espaces non significatifs ni l’ordre de sérialisation des entrées d’une table. Un formulaire peut donc satisfaire la contrainte sans posséder une représentation textuelle unique utilisable comme clé.

Ce raisonnement a une limite importante. Les choix de représentation numérique, la précision et les modèles applicatifs utilisant des nombres sous forme de chaînes doivent être examinés séparément. Un tableau réordonné ou des clés répétées ne sont pas des exemples interchangeables avec celui-ci. Le contrôle doit refléter les contraintes de l’application ; le décodage ne les complète pas à sa place.

Si l’autorisation est recherchée par le texte intégral, tandis que le cache sélectionne une ressource par la valeur décodée, la réussite de la validation n’assure pas leur liaison. Il faut connaître la clé de rapprochement, sa portée et le moment où elle est vérifiée. Le problème ne réside pas dans l’existence de deux représentations, mais dans l’absence d’une décision explicite sur leur usage.

Le contrat choisit ce qui compte comme une unité

Une facturation par demande peut distinguer deux soumissions identiques : l’admission, le décodage et la traçabilité ont pu être mobilisés deux fois. Une facturation par ressource logique peut au contraire promettre qu’un second alias n’augmente pas le nombre de ressources. Une facturation par opération doit suivre l’identité de l’acte et son changement d’état.

Ces modèles peuvent se combiner. La déduplication du stockage ne supprime pas nécessairement le coût des demandes ; l’identité du contenu ne fusionne pas les droits des clients. Le rapprochement financier doit garder ces différences au lieu de chercher un identifiant universel censé tout résoudre.

La preuve d’une erreur nécessite donc plus que deux textes de même valeur. Elle exige le contrat applicable, la portée du compteur, la liaison aux demandes ou opérations et le résultat comptable. De même, un contournement d’autorisation demande de montrer la règle qui aurait dû empêcher l’acte et la manière dont l’alias a modifié sa décision. Une possibilité décrite par un RFC ne tient pas lieu de constat d’incident.

Il existe aussi une asymétrie de coût. L’accueil permissif peut éviter un changement au client, mais ajouter des exceptions au rapprochement interne. L’équipe qui présente un meilleur taux d’acceptation ne paie pas forcément les heures nécessaires pour expliquer les comptes. Ce déplacement est une question d’organisation, pas un défaut que le décodeur saura corriger seul.

Une signature peut tenir à la graphie d’origine

Le cache peut ignorer une différence textuelle que le mécanisme d’authentification doit conserver. Dans le JWS ordinaire à charge utile encodée en Base64url, RFC 7515 construit l’entrée de signature à partir de l’en-tête protégé encodé et de la charge utile encodée, séparés par un point. L’égalité après analyse JSON n’autorise pas à remplacer cette entrée par une sérialisation nouvelle.

Une application peut choisir explicitement de signer une représentation canonique de son modèle. JCS, RFC 8785, fournit une représentation déterministe dans son domaine d’entrée ; ce RFC informatif, issu de la voie indépendante, n’est pas une obligation implicite de .json. Ses contraintes font partie du choix. Les extensions à charge utile non encodée et les autres enveloppes ne sont pas traitées ici.

« Normaliser avant usage » ne suffit donc pas. Avant quelle utilisation, selon quelle règle et après préservation de quelle preuve ? Le responsable du cache ne peut prêter sa définition de l’égalité à celui de la signature. La graphie peut faire partie de ce que l’émetteur a authentifié, même si elle n’intéresse pas le stockage.

Séparer les règles partagées de l’arbitrage métier

Lu Heng, dans sa réflexion sur une spécification commune minimale, distingue les invariants déterministes des arrangements métier et des choix ultérieurs des opérateurs. Cette perspective éclaire le cas présent : une règle d’admission vérifiable ne doit pas devenir par défaut une autorité sur les comptes. Ce n’est ni un avis de Lu Heng sur RFC 9741 ni une exigence de l’IETF pour la facturation.

Sa réflexion sur la primauté du code en fonctionnement invite à vérifier les clés effectivement employées, plutôt qu’une simple déclaration de conformité. Sa discussion des couches de réalité et du pouvoir symbolique sert ici de grille de lecture : une attestation de validation représente un contrôle, pas l’ensemble de la transaction.

RFC 8610, section 5, avertit déjà que la correction d’une spécification CDDL et de son moteur de correspondance ne remplace pas les autres défenses. La bonne frontière n’est pas celle qui prétend décider de tout. C’est celle qui dit précisément ce qu’elle établit et ce qu’un autre responsable doit encore établir.