Résumé

  • RFC 3354 exigeait qu’un futur IOTP v2 puisse proposer une suite quelconque d’étapes commerciales ; cette proposition ne constituait ni un consentement au paiement ni la preuve qu’une étape avait eu lieu.
  • L’accord plafonné pour des achats futurs, l’avis d’expédition, l’autorisation du système de paiement, le débit, le règlement et le recours auprès du service client restaient des faits distincts.

Un entrepôt annonce l’expédition d’un colis. Quelques millisecondes plus tard, un système demande un débit. Entre les deux événements, un schéma pourrait tracer une simple flèche. Or cette flèche ne dit pas si le client avait accepté ce montant, si l’avis provenait du bon opérateur, si la banque avait autorisé l’opération ou si les fonds avaient été réglés. Elle décrit un enchaînement ; elle ne fabrique pas l’autorité commerciale.

Publié en août 2002 comme document d’information, RFC 3354 énonçait les exigences d’une deuxième version envisagée de l’Internet Open Trading Protocol. IOTP v1 organisait déjà un échange autour de rôles, de blocs et de messages. Le nouveau programme voulait préserver l’existant tout en supprimant un cadre trop étroit : un paiement unique suivi d’une livraison unique. Les parties devaient pouvoir proposer une séquence arbitraire d’étapes.

Le verbe « proposer » est la charnière du texte. Une offre peut précéder une demande d’information ; un protocole de paiement externe peut s’insérer entre deux messages ; l’expédition peut devenir une condition avant débit. Mais décrire cet ordre n’accorde pas à chaque acteur le droit d’exécuter l’étape suivante. La séquence est une carte des dépendances possibles, pas une procuration permanente.

RFC 3354 n’était pas la spécification achevée d’IOTP v2. Il distinguait les fonctions obligatoires, celles que la version pourrait inclure et les sujets hors périmètre. L’historique du groupe IETF TRADE marque l’étape des exigences v2 comme terminée. Ce jalon prouve que les exigences ont été documentées ; il ne prouve ni protocole v2 final, ni implantation, ni adoption.

Parmi les fonctions requises figuraient la définition dynamique des séquences, un bloc de demande d’offre, une meilleure résolution des problèmes, un rôle Customer Care mieux défini, la prise en charge de protocoles de paiement non encapsulés dans IOTP et des portefeuilles côté serveur. Présenter un reçu signé au service client pouvait soutenir une contestation. Cela n’obligeait pas le service à accepter le dossier ni à rembourser.

Le portefeuille serveur illustre la même prudence. Il pouvait héberger une fonction déléguée, mais sa seule existence n’authentifiait pas l’utilisateur présent et n’élargissait pas son accord. Le paiement externe conservait ses propres contrôles, réponses et preuves de règlement. IOTP coordonnait une action sans absorber l’autorité du système qui l’exécutait.

Les paiements répétés ou continus n’étaient qu’une option. L’exemple portait sur une autorisation bornée : un nombre limité d’achats futurs, avec un plafond total ou un maximum par achat. Une telle permission doit identifier son bénéficiaire, son objet, le nombre restant, les montants, l’échéance et l’état de révocation. Aucune de ces limites ne se déduit correctement de la seule position d’un bloc dans un scénario.

Chaque demande ultérieure appelle donc une évaluation. Une opération peut respecter le nombre prévu mais dépasser le plafond unitaire ; une autre peut être faible mais arriver après expiration. La séquence peut ordonner le test. Elle ne peut pas déclarer que le test est réussi parce que la flèche mène au bloc « paiement ».

L’exemple de l’expédition sépare encore plus clairement l’événement de l’autorité. Un message serveur à serveur pouvait permettre à un Delivery Handler d’informer un Payment Handler que les marchandises avaient été expédiées. Cette information pouvait devenir une condition préalable à un débit sur carte. Une condition n’est pas un ordre : elle rapporte l’assertion d’un acteur identifié. Elle ne prouve ni réception physique, ni consentement, ni autorisation de l’émetteur, ni capture, ni règlement.

Il faut donc conserver l’avis authentifié, la règle qui explique comment il satisfait une condition, puis la réponse propre au système de paiement. Un débit et son règlement ajoutent encore des reçus. Résumer cette chaîne par « l’expédition a déclenché le paiement » détruit précisément les preuves nécessaires en cas de doublon, d’annulation ou de litige.

Les textes voisins éclairent ces limites. RFC 2801 définissait les transactions IOTP v1, leurs identifiants et le traitement idempotent. RFC 2802 utilisait un manifeste pour préciser les composants couverts par une signature. Une signature valable authentifie ce périmètre ; elle ne crée pas un consentement absent. RFC 2935 transportait IOTP sur HTTP, tandis que RFC 3106 normalisait des noms de champs commerciaux. Acheminer des octets ou partager un vocabulaire ne valide pas l’autorité du contenu.

RFC 3275 fournissait le mécanisme de signature XML que le projet voulait réutiliser. RFC 2246 protégeait le canal TLS. RFC 3354 précisait néanmoins qu’IOTP ne fournissait pas lui-même la confidentialité et que la sécurité du paiement dépendait du système de paiement choisi. Canal chiffré, contenu signé, accord du client et débit autorisé appartenaient à des couches différentes.

Même l’extension de blocs par de nouveaux champs et attributs n’accordait aucune force automatique à ces données. Un champ nommé « approuvé » reste une assertion tant que son émetteur, son périmètre, sa signature, sa base de décision et sa validité n’ont pas été établis.

Le droit et la réglementation étaient hors périmètre. La conformité technique ne démontrait donc ni validité contractuelle, ni respect du droit de la consommation, ni pouvoir de débiter dans une juridiction. Cette limite reconnaissait qu’un langage universel de messages ne peut pas concentrer toutes les institutions qui rendent une action légitime.

RFC 3538, consacré à un supplément SET pour IOTP v1, et RFC 3867, interface ultérieure entre le cœur IOTP et des modules de paiement, offrent un contexte utile. L’interface confirme que l’orchestration et l’exécution par un système de paiement peuvent rester séparées. Aucun des deux documents ne prouve la réalisation d’IOTP v2.

La valeur historique de RFC 3354 tient ainsi à une discipline de séparation. La séquence proposée est un plan. L’accord est une délégation limitée. L’avis d’expédition est une preuve d’événement. La signature authentifie un contenu déterminé. TLS protège un trajet. Le système de paiement autorise, exécute et règle. Le service client traite ensuite un recours selon ses propres pouvoirs.

Les automatismes actuels reproduisent ce problème lorsqu’un statut logistique libère des fonds ou qu’un calendrier d’abonnement lance un prélèvement. Plus le scénario est souple, plus il faut rendre l’autorité explicite au point irréversible. RFC 3354 n’autorisait pas moins d’innovation ; il empêchait l’ordre des opérations de se déguiser en consentement.

Sources