Resumen

  • RFC 3504 reparó tres superficies ejecutables de IOTP v1: la gramática DTD, la continuidad de la operación después de autenticar y la lista de contenidos identificables por firmas IOTP.
  • Aplicar la errata acreditaba alineación con la especificación corregida, no éxito de autenticación, autoridad del firmante, autorización de cobro, liquidación, entrega, despliegue o adopción.

En prosa común, sustituir “reiniciada” por “continuada” parece una edición menor. En una máquina de estados, decide si el software conserva el contexto comercial que llegó a una puerta de autenticación o actúa como si el intercambio comenzara de nuevo.

RFC 3504 apareció en marzo de 2003 como documento Informativo. Reunía errores encontrados después de las especificaciones de IOTP versión 1, sobre todo en la enorme RFC 2801. IOTP era un marco comercial independiente del sistema de pago: tienda, procesador, entrega y atención podían estar en organizaciones distintas.

Esa separación hacía importante cada acuerdo técnico. Cuando una operación atravesaba límites empresariales, mensajes y componentes debían conservar qué transacción y qué acto representaban. Una diferencia de gramática o transición podía convertirse en diferencia de comportamiento entre partes que decían implementar la misma RFC.

La primera reparación afectaba a PackagedContent. La DTD original había intercambiado los tipos de Name y Content. La corrección convertía Name en NMTOKEN y Content en CDATA. Este contenedor aparecía en retos de autenticación, pedidos, marcas, datos del esquema de pago, recibos y material de entrega.

El código generado desde la declaración antigua podía aplicar restricciones léxicas equivocadas. Un emisor podía producir algo válido para su herramienta y rechazado por otra. La frase “compatible con RFC 2801” ocultaba entonces una pregunta: ¿con la DTD impresa o con la corregida?

La segunda modificación era diminuta: el elemento Attribute tenía ( ANY ), una forma incorrecta; debía decir ANY. Un validador no tiene autoridad para adivinar la intención. Sin una corrección común, cada equipo podía parchear distinto, desactivar validación o crear excepciones incompatibles.

Superar la DTD corregida seguía siendo una prueba estrecha. Confirmaba estructura, nombres y clases de atributos. No demostraba que un dato fuese verdadero, que el interlocutor tuviera autoridad ni que un sistema externo hubiese movido dinero.

La tercera corrección tocaba el estado. RFC 2801 explicaba cómo combinar una transacción de autenticación con otra transacción IOTP. El texto original decía que, tras autenticar con éxito, la transacción IOTP original se reiniciaba. RFC 3504 cambió el verbo por continuaba.

La identidad atravesaba así la puerta. La autenticación era una condición dentro del intercambio mayor, no una fábrica de otra compra. Identificador, componentes acumulados, registro de idempotencia y alcance de permisos podían permanecer unidos al contexto original.

“Continuaba” tampoco decía que la autenticación hubiese sucedido. Sólo definía qué hacer si tenía éxito. El sistema aún necesitaba una decisión vinculada con actor, método, reto, respuesta y transacción. Incluso una identidad autenticada no autorizaba automáticamente pago o entrega.

La cuarta reparación ampliaba la tabla de tipos firmados. La lista inicial incluía respuestas de oferta, pago y entrega, solicitudes y respuestas de autenticación y mensajes ping. Omitía AuthenticationStatus, InquiryRequest e InquiryResponse.

RFC 3504 añadió los tres y permitió que cualquier rol los utilizara. Un verificador estricto basado en la lista vieja podía rechazar contenido permitido; uno permisivo podía aceptarlo sin una regla de despacho. La errata restauró un mapa compartido entre el marcador y la clase de contenido que la firma pretendía representar.

Reconocer el tipo no verificaba la firma. Verificarla no probaba autoridad comercial. Una respuesta de consulta auténtica informaba de cierto estado de protocolo, pero no demostraba liquidación bancaria, entrega material o aceptación del cliente.

La RFC dijo que los errores no eran particularmente de seguridad y, a la vez, advirtió que una implementación incorrecta provocada por errores sin corregir podía comprometerla. No había un algoritmo criptográfico nuevo; había gramática, transición y despacho que sostenían decisiones sensibles.

Por eso una errata puede ser dependencia ejecutable. El inventario debe registrar documento base, conjunto de correcciones, artefacto del parser o schema y pruebas de las conductas cambiadas. Citar sólo “RFC 2801” permite que dos máquinas distintas reclamen la misma conformidad.

La historia de metadatos refuerza la idea. La cabecera de RFC 3504 no declara Updates: 2801. La errata 2947 del RFC Editor, retenida para actualizar el documento, afirma que debería hacerlo porque introduce cambios normativos. El texto corregía la ejecución aunque la relación documental no reflejara toda su fuerza.

La cadena honesta empieza con edición y erratas exactas, y sigue con construcción reproducible, documento aceptado, identidad transaccional conservada, decisión de autenticación, tipo firmado reconocido, firma comprobada, acto comercial autorizado y recibos externos de pago o entrega.

La gramática dice que el mensaje puede interpretarse. La continuidad dice qué contexto sobrevive. El tipo dice qué contenido pretende cubrir una firma. Ninguno de esos recibos equivale a una compra pagada y cumplida.

Fuentes