Resumen

  • RFC 3354 exigía que el futuro IOTP v2 permitiera proponer secuencias arbitrarias de pasos comerciales, pero la propuesta no autorizaba un pago ni demostraba que los pasos se hubieran ejecutado.
  • El consentimiento limitado para compras futuras, el aviso de envío, la autorización del sistema de pago, el cargo, la liquidación y el recibo para una disputa seguían siendo hechos separados.

Un mensaje dice que la mercancía salió del almacén. El siguiente bloque del flujo dice «pago». Para una máquina, la proximidad puede parecer una orden; para una transacción real, faltan preguntas esenciales. ¿Quién emitió el aviso? ¿Qué aceptó el cliente? ¿Cuál era el límite? ¿Autorizó el emisor? ¿Hubo captura y liquidación? El orden de dos casillas no contesta nada de eso.

RFC 3354 apareció en agosto de 2002 como documento Informativo de requisitos para una segunda versión prevista del Internet Open Trading Protocol. IOTP v1 ya describía actores, bloques y mensajes para el comercio electrónico. La nueva etapa buscaba conservar esa base y superar una rigidez: las operaciones no debían limitarse a un pago seguido de una entrega. Las partes podrían proponer cualquier secuencia de pasos.

«Proponer» era la palabra exacta. Una propuesta puede colocar una solicitud de oferta al principio, intercalar un protocolo de pago externo o esperar un aviso de envío. Pero no confiere automáticamente autoridad a cada participante. Representa dependencias y expectativas; no es un mandato permanente para gastar dinero.

Además, RFC 3354 no era la especificación de IOTP v2. Separaba funciones que el diseño debía incluir, opciones que podía incluir y asuntos fuera de alcance. La historia del grupo TRADE del IETF muestra concluido el hito de requisitos v2. Eso acredita el trabajo de requisitos, no un protocolo final, una implementación ni un despliegue.

Las funciones obligatorias incluían secuencias dinámicas, un bloque de solicitud de oferta, mejor resolución de problemas, un papel de atención al cliente más claro, protocolos de pago externos a IOTP y monederos de servidor. Un recibo firmado podía presentarse a soporte cuando surgía un problema. Ese recibo aportaba evidencia; no obligaba al agente a conceder un reembolso ni demostraba que tuviera facultades para hacerlo.

Un monedero alojado en un servidor también era una capacidad delegada, no una identidad mágica. Su existencia no autenticaba al usuario actual ni ampliaba un consentimiento anterior. Del mismo modo, admitir un protocolo de pago externo reconocía que el flujo comercial y la ejecución financiera tenían controles distintos. IOTP podía coordinar el salto sin apropiarse de la respuesta de autorización o de la prueba de liquidación.

Los pagos repetidos o continuados figuraban solo entre las posibilidades. El ejemplo era deliberadamente acotado: el cliente podía aprobar un número limitado de compras futuras, con un techo total o un máximo por compra. Una concesión operable debe identificar propósito y beneficiario, importe, moneda, cantidad restante, vencimiento y revocación. La plantilla del flujo no puede inventar esos datos.

Cada solicitud posterior necesita compararse con la concesión. Una compra puede caber en el número permitido y superar el máximo individual. Otra puede ser pequeña y llegar después de la fecha límite. El motor puede programar la evaluación; no puede aprobarla señalando que el bloque de cobro aparece después del bloque de consentimiento.

El aviso de envío muestra la diferencia desde el lado del evento. RFC 3354 decía que un mensaje mejorado entre servidores podría permitir a un Delivery Handler informar al Payment Handler de que la mercancía había sido expedida. Esa noticia podía ser una condición previa para cargar una tarjeta. Ser condición previa no significa ser orden de cobro. El mensaje acredita, como máximo, lo que afirmó el operador identificado dentro del alcance autenticado.

No demuestra entrega física, aceptación del comprador, autorización del emisor, captura o liquidación. Un sistema auditable conserva por separado el aviso, la regla que lo convierte en condición suficiente para una solicitud concreta y la respuesta del sistema de pago. Si se ejecuta el cargo, la captura y la liquidación añaden nuevos recibos. «El envío activó el pago» es un resumen operativo, no una cadena probatoria.

Los RFC cercanos ayudan a fijar las capas. RFC 2801 definía IOTP v1, identificadores y procesamiento idempotente. RFC 2802 hacía que un manifiesto delimitara los componentes cubiertos por una firma. La firma autentica ese material bajo su clave; no aporta consentimiento ausente. RFC 2935 transportaba IOTP por HTTP. RFC 3106 uniformaba nombres de campos comerciales. Transporte y vocabulario mejoran interoperabilidad, no autoridad.

RFC 3275 ofrecía la sintaxis y el procesamiento de XML Signature que IOTP podía reutilizar. RFC 2246 protegía un canal mediante TLS. RFC 3354 advertía que IOTP no ofrecía confidencialidad propia y que la seguridad del pago dependía del sistema elegido. Un canal confidencial, un contenido firmado y un cargo autorizado eran hechos relacionados, pero no intercambiables.

La capacidad opcional de añadir campos y atributos a bloques existentes tampoco elevaba cada dato nuevo a verdad ejecutable. Un atributo «autorizado» sigue siendo una afirmación hasta conocer emisor, alcance, firma, política y vigencia.

Los problemas legales y regulatorios quedaban fuera de alcance. Cumplir el protocolo no probaba exigibilidad contractual, protección del consumidor ni derecho a cobrar en una jurisdicción. La exclusión conservaba una frontera sensata: las reglas locales no podían derivarse de una gramática universal de mensajes.

RFC 3538 añadió contexto SET a IOTP v1. RFC 3867 definió después una interfaz entre el núcleo de una aplicación IOTP y módulos de pago. Esta última separación resulta reveladora: coordinar una operación y ejecutarla en un sistema de pago podían producir estados y recibos diferentes. Ningún documento demuestra que IOTP v2 se completara o desplegara.

El valor de RFC 3354 no está solo en la flexibilidad prometida, sino en la autoridad que no fingió crear. Una secuencia era un plan. El consentimiento para futuras compras era limitado. El aviso de envío era evidencia de un evento. La firma tenía un alcance. TLS protegía el trayecto. El sistema de pago autorizaba y ejecutaba. La liquidación y el remedio venían después.

Los sistemas actuales repiten la misma tensión cuando un evento logístico libera fondos o una agenda de suscripción inicia un débito. Cuanto más componible sea el flujo, más importante es exigir autoridad en el punto irreversible. El protocolo puede proponer cualquier camino; el dinero no debe recorrerlo sin su propia prueba.

Sources