Resumen

  • La revisión 01 del Internet-Draft individual Testimony Record apareció el 5 de septiembre y corrige una frase que excedía los datos de su propio censo.
  • También define cómo calcular el hash, comprueba que un anclaje externo firme ese mismo valor y declara que todavía no hay una implementación independiente conocida.
  • Sus cuatro niveles son acumulativos, pero acts:false permite que un emisor sin acciones alcance TR-4 aunque jamás haya puesto a prueba una barrera de ejecución.
  • El documento separa controles verificables desde el registro de afirmaciones atestiguadas por el emisor, como el origen del riesgo o de la identidad humana.
  • Para tomar decisiones no basta con «TR-4»: hace falta una matriz con alcance, resultado de cada nivel, mezcla de controles, esquema de integridad, validador y momento observado.

La revisión corrigió el expediente, no solo la redacción

El anuncio del archivo de IETF fija la noticia: el 5 de septiembre quedó disponible la revisión 01 de un documento de 18 páginas. La ficha de Datatracker impide agrandar el hecho. Es un Internet-Draft individual activo, sin flujo RFC, sin Area Director responsable, sin posición formal y sin respaldo de IETF. Cualquier persona puede presentar un draft.

La revisión 00 sostenía que ninguno de ocho sistemas examinados registraba quién había aprobado una acción. La revisión 01 explica que esa frase no estaba respaldada. Entre cinco sistemas relevantes escritos por terceros, cuatro fueron evaluados como ausentes y uno quedó indeterminado. Los otros tres incluían el sistema del propio autor, que sí registraba el dato.

No es una sutileza estadística. «No apareció en el código revisado», «no se pudo saber» y «aparece en mi propia implementación» no autorizan una conclusión universal. Un documento dedicado a distinguir creencias, evidencia y contradicciones debía conservar también esa diferencia cuando hablaba de sus comparaciones.

El diff entre versiones expone una segunda falla. El texto anterior pedía un digest, pero no fijaba algoritmo, orden ni serialización. El validador podía aceptar lo escrito sin recalcularlo. Dos implementaciones del autor usaban reglas distintas. El nivel llamado Verifiable no ofrecía al lector una operación común para verificar.

Ahora la regla fija SHA-256, el orden de las entradas cubiertas, JSON compacto, orden de miembros por puntos de código Unicode, omisión de anotaciones con guion bajo, UTF-8, un LF entre objetos y límites para números ambiguos. El validador recalcula. El desacuerdo deja de depender de la confianza en la herramienta del emisor.

Una escalera, tres dimensiones

TR-1 pregunta por la forma: versiones conocidas, tipos admitidos, campos obligatorios, identificadores únicos, tiempos ordenados y consistencia del alcance. TR-2 pregunta por la explicación: cada creencia enumera su evidencia, incluso con una lista vacía que reconoce que no tiene apoyo, y cada conflicto conserva sus lados y la eventual resolución.

TR-3 pregunta por la puerta de acción. La clase de riesgo debe proceder de una fuente fuera del texto generado por el modelo. Una negativa no puede figurar como ejecutada. Una acción de alto riesgo que sí se ejecutó necesita una aprobación humana, una fuente de identidad que no sea salida del modelo y una persona distinta del proponente.

TR-4 pregunta por la integridad del registro. La lista cubierta existe, el hash coincide y un anclaje externo firma la huella declarada. El número más alto acumula, por tanto, sintaxis, explicación, decisión e integridad. No las convierte en una sola propiedad.

La versión 0.2 añadió scope porque el orden producía un resultado absurdo para componentes que no actúan. Un emisor declara acts:false, no incluye decisiones y satisface TR-3 precisamente porque no tiene acciones que filtrar. Puede después alcanzar TR-4. El propio draft aconseja publicar «TR-4, solo registro» y los resultados de cada nivel.

Ese caso es legítimo. Una memoria o un observador puede necesitar una historia inalterable sin enviar una orden al mundo. Lo engañoso sería usar su TR-4 para sugerir que una cadena de efectos fue sometida a aprobación. El alcance decide qué conclusión cabe, no la altura del número.

La máquina también declara su propia frontera

El campo de alcance no está autenticado por el archivo. Si un sistema dice que no actúa y luego contiene una decisión, el conflicto hace fallar TR-1. Si la ejecución ocurre en un conector que el registro omite, los bytes pueden ser perfectos y la descripción incompleta.

La comprobación de una compra o auditoría debe comenzar fuera del registro. ¿Qué proceso propone la acción? ¿Quién la autoriza? ¿Dónde se despacha? ¿Qué salida externa confirma el efecto? ¿Existe un camino alternativo que no atraviesa el emisor? Sin ese mapa, acts:false es una frase de la parte interesada.

El repositorio Machine Testimony publica especificación, validadores, adaptadores y casos de conformidad. Permite observación y prueba local. La nueva sección de implementación dice, sin embargo, que todas las implementaciones conocidas son del autor. Dos validadores escritos por la misma persona pueden detectar una regla ambigua; no prueban interpretación independiente ni interoperabilidad.

El directorio del censo fija commits, exige evidencia al declarar una ausencia y publica el conflicto de interés. Incluso registra defectos de la referencia. Es una práctica más auditable, pero sigue siendo una evaluación construida y ejecutada por quien creó el formato. No debe citarse como auditoría independiente.

El mismo nivel puede descansar en pruebas distintas

Un control verificado es resoluble con el propio registro: existe la evidencia citada; se conservaron ambos lados del conflicto; una negativa no se marcó ejecutada; el hash recalculado coincide; la huella firmada por el anclaje es la correcta.

Un control atestiguado es una afirmación específica que el lector no puede confirmar allí. El emisor dice que una tabla externa asignó el riesgo. Dice que el nombre del aprobador vino de una sesión autenticada. Dice que un motor de replay reproduce el estado. Anotar esas fuentes ayuda, porque una afirmación precisa puede refutarse después. No equivale a presentar la fuente.

Así, dos archivos TR-4 pueden tener perfiles opuestos. Uno resuelve casi todo con cálculos sobre bytes disponibles. Otro depende de declaraciones para los hechos centrales. El rótulo oculta la proporción.

Tampoco todos los esquemas de integridad ofrecen la misma resistencia. Un hash del emisor detecta cambios de terceros, pero el emisor puede rehacer historia y hash. Una firma añade una identidad y una política de confianza. RFC 3161 permite que una autoridad externa selle una huella temporal. El sello demuestra que esa huella existía bajo esa política y en ese momento; no lee la historia ni descarta otra versión omitida.

RFC 8785 aporta el contexto de canonicalización JSON. RFC 9162 y el borrador de arquitectura SCITT muestran mecanismos para colocar evidencia más allá del emisor. Ninguno verifica retroactivamente que el alcance declarado incluyera todos los efectos o que una creencia fuera cierta.

Qué debe contener la matriz

Una afirmación de conformidad útil debe incluir la versión exacta y hash de la especificación; la identidad del emisor y de la frontera ejecutable; el alcance declarado y su respaldo externo; el resultado separado de TR-1, TR-2, TR-3 y TR-4; los identificadores y recuentos de controles verificados y atestiguados; el esquema de integridad y entradas cubiertas; la autoridad, política y veredicto del anclaje; la versión del validador y corpus; y la hora limitada de la observación.

La matriz permite decir verdades parciales sin transformarlas en autoridad total. La integridad puede estar demostrada mientras el origen de una aprobación sigue declarado. Una barrera puede funcionar aunque todavía no haya anclaje durable. El lector ve ambas cosas.

Hay una frontera adicional que el draft no resuelve: la tensión entre historia append-only y borrado. Recomienda no duplicar material sensible, guardar identificadores y hashes, y hacer visible la redacción. Pero reescribir destruye continuidad y conservar lo borrado niega la supresión. Una etiqueta técnica no decide ese conflicto.

El texto también menciona la Ley de IA europea y niega expresamente que el formato la implemente. La obligación jurídica no nace del nombre de un nivel ni del registro de una aprobación. La decide la aplicación concreta y la autoridad competente.

La revisión 01 ha mejorado porque deja a la vista sus límites, sus correcciones y la ausencia de implementación independiente. La mejor manera de respetar ese avance es impedir que el mercado vuelva a comprimirlo en una cifra que dice más de lo que los datos pueden demostrar.

Fuentes

  1. Anuncio IETF de Testimony Record 01
  2. Estado en IETF Datatracker
  3. Testimony Record, revisión 01
  4. Testimony Record, revisión 00
  5. Comparación oficial 00–01
  6. Repositorio Machine Testimony
  7. Directorio del censo de conformidad
  8. RFC 3161 — protocolo de sello de tiempo
  9. RFC 8785 — canonicalización JSON
  10. RFC 9162 — Certificate Transparency 2.0
  11. Arquitectura SCITT, revisión 22
  12. Heng Lu sobre la primacía del código operativo