Resumen

  • RFC 3505 fijó requisitos para nombres y jerarquías comunes con los que carteras, formularios y sistemas internos pudieran intercambiar datos comerciales.
  • ECML no sustituía el cifrado, la autenticación, el consentimiento, la autorización de pago o la liquidación; entender un campo sólo probaba semántica compartida.

Antes de automatizar el pago había que resolver una dificultad básica: cada comercio nombraba de manera distinta el apellido, la dirección, la moneda o la tarjeta. Una persona podía interpretar etiquetas y teclear. Una cartera necesitaba una correspondencia previsible para no confundir conceptos.

RFC 3505, publicado como Informativo en marzo de 2003, convirtió ese problema en requisitos para ECML versión 2. Quería cubrir operaciones entre consumidor y comercio y entre empresas, ampliar la versión 1.1 a cheques electrónicos, ACH, pagos móviles y otros vehículos, y conectar formularios con sistemas internos.

La lista incluía coste, recibo, moneda, tarjeta, pago y datos bancarios o telefónicos. Una jerarquía común permitía preguntar o afirmar un valor sin diseñar una traducción nueva para cada sitio. Era una ganancia real de interoperabilidad, pero no verificaba el contenido.

El RFC fue explícito: ECML v2 no reemplazaba TLS, SET, EMV, XML ni IOTP. Aquellos mecanismos ofrecían confidencialidad, no repudio, selección de esquema, soporte de tarjeta inteligente o flujo comercial. ECML nombraba piezas de información. No heredaba las garantías de las capas vecinas.

La separación importaba porque los campos eran privados. Su seguridad dependía del canal y de las aplicaciones que almacenaban o liberaban los datos. ECML no tenía que inventar protección propia, pero la especificación debía advertir y orientar. Normalizar una dirección hacía más fácil rellenarla; también podía hacer más eficiente una divulgación indebida.

Una DTD bien formada y ejemplos XML válidos ofrecían otro recibo limitado. Demostraban gramática. No demostraban que el número perteneciera al usuario, que el importe fuera legítimo, que el comercio fuera auténtico o que el procesador hubiera autorizado un cargo.

Entre las mejoras se propuso un campo de traducción oculto para mapear nombres ECML a campos existentes sin cambiar código antiguo. Reducía costes de adopción, pero ocultaba la ruta por la que los datos pasaban de una semántica a otra. La compatibilidad invisible no constituía consentimiento visible.

RFC 4112 llevó los requisitos a una especificación en 2005. Definió nombres jerárquicos y XML opcional, manteniendo abiertas otras sintaxis y transportes. La norma se aplicaba a nombres transmitidos, no a la etiqueta humana. Diferentes idiomas podían mostrar textos naturales y conservar la misma referencia para software.

Los tamaños mínimos indicaban capacidad de entrada, no validez de identidad. Un comercio debía admitir al menos cierta longitud, aunque valores más cortos o largos podían ser correctos. Usar MIN como prueba habría convertido una obligación de interfaz en una regla falsa sobre personas.

Los modos de consulta y afirmación expresaban qué hacía un mensaje. No autenticaban al solicitante ni volvían verdadera la afirmación. La cartera todavía necesitaba saber quién pedía, con qué propósito y si el usuario autorizaba responder.

En la Web, Ecom_SchemaVersion marcaba la versión del vocabulario. Permitía escoger interpretación; no autenticaba el dominio. Reconocer un esquema no era confiar en el extremo.

Ecom_TransactionComplete atendía un riesgo de formularios multipágina. Era una pista para que el llenado automático se detuviera hasta recibir nueva autorización. Su nombre no probaba que la compra hubiera sido autorizada, capturada, liquidada o entregada. Marcaba el fin de una ventana de automatización, no el éxito económico.

RFC 4112 dejó las protecciones fuera de la sintaxis. Firma XML, CMS, TLS o IPsec podían aportar integridad, autenticidad o confidencialidad según el caso. El control del usuario seguía siendo necesario. Terminales públicos debían poder olvidar datos, y valores ocultos o predeterminados podían sufrir cambios maliciosos antes de volver.

La escalera correcta separa campo reconocido, estructura válida, contraparte autenticada, liberación consentida, transporte protegido, aceptación de la aplicación, autorización de pago, liquidación y entrega. Un indicador que salta de los dos primeros a “pagado” convierte legibilidad en ficción.

Tampoco publicar una norma demuestra uso. RFC 3505 registra requisitos y RFC 4112 una especificación Standards Track; ninguno mide adopción en navegadores, comercios o carteras ni pagos exitosos.

El logro histórico fue mantener delgada la capa común. Un nombre compartido redujo traducciones y errores. No volvió buena a la contraparte, cierta a la información ni completa a la compra. ECML abrió una vía semántica; cada autoridad posterior todavía tenía que emitir su propio comprobante.

Sources