Résumé

  • RFC 3505 fixait les exigences d’un vocabulaire hiérarchique commun afin que portefeuilles, formulaires et systèmes de paiement échangent des données sans réinventer chaque correspondance.
  • Il distinguait explicitement cette interopérabilité de la confidentialité, de l’authentification, du consentement, de l’autorisation et du règlement, qui dépendaient d’autres mécanismes.

Le même nom de famille pouvait se cacher derrière trois libellés et quatre structures. Un acheteur humain comprenait le contexte et retapait la valeur. Un portefeuille électronique risquait de remplir la mauvaise case ou d’abandonner. La première promesse d’ECML n’était donc pas de sécuriser l’argent, mais de rendre les champs compréhensibles par plusieurs logiciels.

Publié en mars 2003 avec le statut Informationnel, RFC 3505 énonçait les exigences d’ECML version 2. Le modèle devait couvrir consommateurs, marchands et échanges interentreprises, ajouter cartes, chèques électroniques, ACH, paiements mobiles et portefeuilles, tout en restant compatible avec la version 1.1 et des systèmes de gestion existants.

Les données visées comprenaient coût, reçu, devise, carte, paiement et informations bancaires ou télécoms. Leur hiérarchie devait permettre requête et assertion. Un nom partagé réduisait l’ambiguïté : un logiciel savait quel concept était demandé ou fourni. Il ne savait pas encore si la demande était légitime ni la valeur vraie.

Le texte conservait une limite nette. ECML v2 ne remplaçait ni TLS, ni SET, ni EMV, ni XML, ni IOTP. Ces technologies apportaient confidentialité, non-répudiation, choix de mécanisme de paiement, carte à puce ou déroulement commercial. ECML organisait les données ; il n’absorbait pas les pouvoirs des autres couches.

Cette modestie était indispensable parce que les champs contenaient des informations privées. Le RFC rendait ECML dépendant de la sécurité du transport et des applications qui stockaient ou libéraient les valeurs. Le langage n’avait pas à inventer son propre chiffrement, mais sa spécification devait avertir et proposer des protections.

La conformité XML restait un reçu étroit. Une DTD bien formée et des exemples testés prouvaient une structure correcte. Ils ne prouvaient ni l’identité du marchand, ni l’appartenance d’une carte, ni l’honnêteté du prix, ni l’autorisation du processeur.

Une demande détaillée proposait un champ de traduction caché reliant les noms ECML aux champs déjà utilisés par un site. L’avantage était économique : adopter le vocabulaire sans réécrire l’application. Le risque était tout aussi clair : un mappage invisible pouvait déplacer des données sensibles sans que l’interface humaine rende ce mouvement compréhensible. Compatibilité ne signifiait pas consentement.

RFC 4112 publia la spécification en 2005. Il définit des noms hiérarchiques et un exemple XML, tout en permettant d’autres syntaxes et protocoles. La conformité portait sur les noms transmis, non sur les libellés visibles. Une page française et une page japonaise pouvaient afficher des mots différents tout en conservant la même sémantique machine.

Les tailles minimales du tableau indiquaient la capacité qu’un champ devait accepter, pas la longueur d’une identité valide. Un nom plus court ou une adresse plus longue pouvait être légitime. Transformer MIN en règle de vérité aurait converti une garantie d’interopérabilité en filtre erroné.

Les modes requête et assertion exprimaient l’intention du message. Ils n’authentifiaient pas l’auteur d’une requête et ne rendaient pas une assertion exacte. Avant de répondre, le portefeuille devait toujours décider si ce partenaire, cette finalité et cet instant autorisaient la communication.

Sur le Web, Ecom_SchemaVersion identifiait la version du vocabulaire. Le marqueur aidait le logiciel à interpréter les champs ; il n’authentifiait ni domaine ni marchand. Reconnaître une version ne revenait pas à reconnaître une autorité.

Les transactions multipages posaient un autre problème. L’automate pouvait continuer à libérer des données après la fin logique de l’échange. Ecom_TransactionComplete servait d’indice d’arrêt jusqu’à une nouvelle autorisation. Malgré son nom, il ne prouvait pas qu’un paiement avait été accepté, capturé, réglé ou livré.

RFC 4112 rappelait que confidentialité, intégrité et authenticité pouvaient utiliser signature XML, CMS, TLS ou IPsec selon le contexte. Il ne les intégrait pas à la grammaire. Le contrôle par l’utilisateur restait requis, la mémoire des terminaux publics devait pouvoir être désactivée, et les valeurs cachées ou par défaut pouvaient être modifiées malicieusement.

La chaîne de preuves commence donc par « champ reconnu », puis structure acceptable, destinataire authentifié, libération autorisée, transport protégé, acceptation applicative, autorisation de paiement, règlement et livraison. Aucune étape ne reçoit automatiquement le sens de la suivante.

La publication ne prouve pas davantage l’adoption. RFC 3505 documente des exigences et RFC 4112 une spécification Standards Track ; ils ne constituent pas un recensement de navigateurs, de marchands ou de paiements réussis.

L’apport historique d’ECML est celui d’une couche commune mince. Elle rend les logiciels capables de se comprendre. Cette capacité peut réduire les erreurs, mais elle peut aussi accélérer une divulgation mal autorisée. Le champ normalisé ouvre un passage ; les acteurs de sécurité, de paiement et de livraison doivent encore décider s’il peut être franchi.

Sources