Résumé

  • RFC 3504 réparait trois surfaces exécutables d’IOTP v1 : la DTD, la continuité de la transaction après authentification et la liste des contenus identifiables par une signature IOTP.
  • Appliquer l’errata prouvait l’alignement avec la spécification corrigée, pas le succès de l’authentification, l’autorité du signataire, le débit, le règlement, la livraison ou l’adoption.

Dans une prose ordinaire, remplacer « recommencée » par « continuée » semble relever de l’édition. Dans une machine à états transactionnelle, le choix décide si le logiciel conserve le contexte commercial arrivé devant une étape d’authentification ou se comporte comme si l’échange repartait de son origine.

Publié en mars 2003 avec le statut Informationnel, RFC 3504 rassemblait des erreurs découvertes après les spécifications IOTP version 1, en particulier RFC 2801. IOTP formait un cadre de commerce indépendant du système de paiement : site marchand, gestionnaire de paiement, service de livraison et assistance pouvaient appartenir à des organisations différentes.

Cette distribution des rôles donnait du poids à chaque détail commun. Les composants devaient préserver transaction, acte et rôle lorsque le travail passait d’un système à l’autre. Une divergence de grammaire ou d’état ne restait pas dans un parseur local ; elle pouvait modifier la façon dont une autre organisation interprétait l’échange.

La première correction concernait PackagedContent. La DTD publiée avait inversé les types des attributs Name et Content. L’errata faisait de Name un NMTOKEN et de Content une valeur CDATA. Or cette enveloppe extensible apparaissait dans les défis d’authentification, commandes, marques, données de schéma de paiement, reçus et livraisons.

Un code généré depuis l’ancienne déclaration pouvait imposer la mauvaise contrainte lexicale. Un producteur pouvait émettre une valeur acceptée chez lui et refusée ailleurs. Affirmer « compatible RFC 2801 » ne suffisait donc plus : fallait-il entendre la DTD imprimée ou la DTD réparée ?

La seconde correction tenait à quelques caractères. L’élément nommé Attribute utilisait ( ANY ), forme incorrecte du modèle de contenu. La déclaration corrigée était ANY. Un validateur ne peut deviner de manière normative qu’une grammaire invalide voulait être permissive. Sans errata, chaque équipe pouvait inventer son correctif, abandonner la validation ou ajouter une exception différente.

Passer la DTD corrigée ne constituait toujours qu’un reçu structurel. Cela montrait que noms, classes d’attributs et contenu suivaient le contrat réparé. Cela ne rendait pas vraie une donnée embarquée et ne prouvait ni autorité du partenaire ni mouvement d’argent.

La correction la plus révélatrice touchait l’état. RFC 2801 expliquait comment combiner une transaction d’authentification avec une autre transaction IOTP. Le texte initial disait qu’après une authentification réussie, la transaction IOTP originale était recommencée. RFC 3504 imposait « continuée ».

La transaction gardait ainsi son identité en franchissant une porte. L’authentification était une condition dans un échange plus large ; son succès ne fabriquait pas un nouvel achat et n’effaçait pas les décisions antérieures. Identifiant de transaction, composants accumulés, traces d’idempotence et portée de l’autorisation pouvaient rester attachés au même contexte.

Le mot « continuée » ne disait pas que l’authentification avait effectivement réussi. Il décrivait la conséquence conditionnelle d’un succès obtenu ailleurs. Le système devait encore produire une décision d’authentification reliée à un acteur, une méthode, un défi, une réponse et la bonne transaction. L’identité reconnue n’autorisait pas automatiquement un paiement ou une livraison.

La quatrième réparation élargissait la répartition des signatures. La liste initiale des valeurs de type couvrait réponses d’offre, de paiement et de livraison, requêtes et réponses d’authentification, puis ping. Elle omettait AuthenticationStatus, InquiryRequest et InquiryResponse.

RFC 3504 ajoutait les trois et les rendait utilisables par tout rôle. Un vérificateur strict fondé sur l’ancienne liste pouvait rejeter un type désormais permis ; un vérificateur trop libéral pouvait l’accepter sans règle partagée. L’errata rétablissait le lien commun entre marqueur de type et classe de contenu prétendument signée.

Reconnaître le type n’était pas vérifier la signature. Vérifier la signature ne prouvait pas l’autorité commerciale du signataire. Une réponse d’enquête authentique pouvait rapporter un état de protocole sans démontrer qu’une banque avait réglé, qu’un bien avait été livré ou qu’un client l’avait accepté.

RFC 3504 disait que ces erreurs n’étaient pas particulièrement liées à la sécurité, puis avertissait qu’une mise en œuvre incorrecte issue d’erreurs non corrigées pouvait compromettre la sécurité. La nuance compte : aucun nouvel algorithme cryptographique n’était défini, mais grammaire, transition et table de répartition soutenaient un traitement sensible.

Un errata devient alors une dépendance exécutable. L’inventaire ne doit pas seulement citer RFC 2801 ; il doit nommer le document de base, le jeu de corrections, l’artefact de parseur ou de schéma et les tests du comportement modifié. Deux revendications de conformité sans cette provenance peuvent décrire deux machines différentes.

Même les métadonnées racontent cette difficulté. L’en-tête de RFC 3504 ne déclare pas Updates: 2801. L’erratum 2947 du RFC Editor, conservé pour une mise à jour du document, estime que cette relation devrait être indiquée parce que les changements sont normatifs. La correction avait donc un effet exécutable que la relation documentaire n’exprimait pas pleinement.

La chaîne de preuve honnête commence par l’édition exacte et les errata appliqués. Elle poursuit avec une construction reproductible du parseur, l’acceptation d’un document, la conservation de l’identité transactionnelle, la décision d’authentification, la reconnaissance du type signé, la vérification cryptographique, l’autorisation de l’acte et les reçus externes de règlement ou livraison.

Chaque étage répond à une question différente. La grammaire permet d’interpréter ; la continuité indique quel contexte survit ; le type annonce ce que la signature prétend couvrir. Aucun ne dit à lui seul que l’achat fut payé et exécuté.

Sources