Resumen

  • RFC 3506 representó cada vale como <emisor, promesa, titular> dentro del conjunto lógico VVS; transferir significaba cambiar el titular válido, no duplicar un objeto.
  • Los componentes XML y la API posterior describían promesas y solicitaban operaciones, pero la titularidad, el consumo y la prestación final requerían comprobantes separados.

Un usuario envía un vale a otro. El mensaje sale, llega y deja copias en dos buzones. Si borrar el archivo original fuera la única defensa contra el doble uso, la transferencia dependería de una cortesía imposible de auditar. RFC 3506 escogió otra base: los archivos podían persistir; el derecho válido tenía que moverse mediante una transición controlada.

El RFC apareció en marzo de 2003 con categoría Informativa. Reunía bajo una misma abstracción puntos de fidelidad, cupones, certificados de regalo, billetes, tarjetas telefónicas y notas de entrega. No decía que todos fueran dinero. Decía que todos representaban algún derecho a reclamar bienes o servicios.

La definición usó tres elementos. I era el emisor, P la promesa y H el titular. El vale era <I,P,H>. La promesa podía ser un descuento, un asiento reservado o acceso temporal. El texto admitía lenguaje natural o pares de atributos XML. Ninguna sintaxis, sin embargo, convertía por sí sola una descripción en una instancia vigente.

Los participantes tenían autoridad limitada. El emisor creaba el vale y garantizaba el contenido. El titular lo poseía, transfería y canjeaba. El recolector examinaba el vale y ejecutaba la promesa. El proveedor VTS garantizaba que una instancia no quedara asignada a varios titulares ni se utilizara más veces de las permitidas.

El VTS administraba lógicamente el Valid Voucher Set, VVS. El conjunto empezaba vacío y contenía las ternas reconocidas como válidas. La palabra “lógicamente” evitaba fijar la arquitectura: podía haber una base central, servidores repartidos entre emisores o tarjetas inteligentes en manos de los usuarios. La topología era una decisión de confianza e implementación.

Emitir agregaba <I,P,H> al VVS con intención del emisor. Transferir reemplazaba H por H' con intención del titular original. No había dos derechos porque dos documentos siguieran accesibles. Había un derecho cuyo punto válido dentro del sistema había cambiado.

El canje tenía dos formas. La presentación mostraba el vale y conservaba su titularidad; servía para credenciales reutilizables. El consumo eliminaba la terna, anulaba el derecho o reducía sus usos restantes; servía para entradas y tarjetas de saldo. Mezclar ambos actos habría hecho imposible saber si una comprobación agotaba el valor.

La seguridad no se reducía a verificar firmas. Sólo el emisor podía crear una instancia válida. Sólo el titular actual podía iniciar transferencia o canje. El vale no debía alterarse salvo por el cambio autorizado de titular. Una instancia consumida no podía volver a canjearse y no debía existir más de un titular válido a la vez.

El propio RFC explicó la limitación criptográfica. Para un vale no transferible, una firma del emisor sobre I, P y H podía funcionar. Al transferir, H cambiaba y la firma se rompía. Además, evitar el doble canje exigía consultar estado en línea o usar un dispositivo resistente a manipulaciones. Una declaración auténtica no era todavía un estado exclusivo y actual.

También había que conciliar privacidad y trazabilidad. El poseedor posterior no debía aprender necesariamente toda la cadena de titulares. A la vez, el sistema tenía que distinguir emisores confiables y detectar falsificaciones. Guardar suficiente evidencia para negar una reproducción no autorizaba a publicar la biografía completa del derecho.

RFC 3506 desconfiaba de un intermediario único para todos los vales. Un punto central universal sería frágil. Sin embargo, no convirtió esa observación en una obligación de cadena de bloques ni en una receta única. Los sistemas fuera de línea y en línea tenían necesidades distintas, por lo que un protocolo universal de transferencia parecía prematuro.

Esa decisión dejó tres piezas posibles: protocolo de transferencia, interfaz de aplicación y lenguaje genérico. El mínimo compartido fue el significado del estado y sus cambios. La elección tecnológica podía evolucionar sin alterar qué prueba cada operación.

RFC 4153 desarrolló en 2005 el Voucher Component en XML. El componente definía promesa, valor, restricciones, emisor y proveedor. Aclaraba de manera terminante que el componente no era un vale: muchas instancias podían usar el mismo componente. Una copia adicional del XML era otra descripción, no otro derecho.

Proteger el componente seguía siendo esencial. Si alguien lo alteraba, una promesa falsa podía parecer válida. Transporte seguro o firma de objeto protegían esa raíz. Pero la pertenencia de una instancia al VVS, el titular presente y el historial de consumo quedaban fuera de esa evidencia descriptiva.

RFC 4154 añadió una API uniforme. Una aplicación podía emitir, transferir, consumir o presentar sin depender de una implementación concreta. La semántica seguía el modelo original: agregar, mover, retirar o mostrar sin retirar. Una interfaz común coordinaba llamadas; no fabricaba autoridad ni resultados.

La nota del IESG señaló una dependencia crítica. La API asumía que el complemento VTS era confiable, pero no especificaba autenticación de la aplicación. Necesitaba un mecanismo adicional. Por eso una llamada bien formada no demostraba quién la autorizó, y una respuesta no demostraba que el recolector hubiera entregado el producto.

La escalera probatoria debe conservar cada peldaño: existe una descripción; el emisor y el proveedor son confiables; una instancia vive en VVS; el titular fue autenticado; la operación fue autorizada; el cambio quedó confirmado; el recolector aceptó; el bien se entregó. Ningún peldaño inferior hereda automáticamente el significado del superior.

Los vouchers de incorporación de dispositivos aparecieron mucho después en otra familia técnica. Compartir un nombre con RFC 3506 no comparte actores, promesas ni transiciones. Confundirlos sería deducir parentesco por una etiqueta.

Tampoco la existencia del RFC acredita despliegue. Un documento Informativo puede fijar una idea rigurosa sin mostrar interoperabilidad comercial, aceptación de usuarios ni cumplimiento de recolectores. Esas conclusiones exigen registros de código, operación y resultados.

La lección histórica es concreta. El dato puede viajar y copiarse; el derecho necesita una autoridad limitada, un estado actual y una transición verificable. RFC 3506 no intentó hacer incopiables los bytes. Hizo que copiarlos fuera insuficiente para multiplicar el valor.

Sources