Resumen

  • Steven Mih publicó el 26 de septiembre la primera versión de un Internet-Draft individual sobre cómo pedir evidencia verificable. Ni su publicación supone adopción por la IETF ni demuestra que el modelo ya funcione en producción.
  • Si se mantiene fijo el sujeto, el anclaje de cobertura resuelto y la derivación solicitada, el artefacto debe ser idéntico byte por byte para todos los solicitantes. Un expected_pin conservado por el propio auditor facilita la comparación entre públicos.
  • Una respuesta puede ser una prueba, una negativa firmada o una ausencia registrada tras esperar. La última no es una declaración del responsable ni explica por sí sola el silencio.

Una firma puede dar a dos informes una apariencia de rigor sin responder a la pregunta que más incomoda: ¿se mostró el mismo historial a las dos partes? El borrador de Steven Mih pone el foco en esa diferencia. Su regla no compara argumentos ni resúmenes redactados para cada audiencia. Para una solicitud suficientemente fijada, compara el artefacto en sus bytes. Si una empresa entregara una secuencia distinta al regulador y al cliente para el mismo anclaje, al menos uno de los resultados incumpliría la propiedad propuesta. Es un supuesto ilustrativo, no la denuncia de un caso real.

El Datatracker clasifica draft-mih-agent-evidence-request-00 como texto individual en estado «I-D Exists», con fecha de 26 de septiembre de 2026 y finalidad informativa. No hay aquí consenso de la IETF, obligación legal de exhibir archivos ni prueba de implantación. El documento quiere normalizar la interacción para pedir y contestar evidencia, no diseñar el contenido del archivo probatorio.

La petición nombra un sujeto, que puede ser todo el historial, una serie de puntos de control, un registro, un intervalo, una correlación o un intercambio. Después fija cobertura mediante una, y solo una, de dos opciones. expected_pin aporta un punto de control que el solicitante ya conoce de manera independiente. min_freshness pide un umbral de actualidad, pero deja que quien responde elija un anclaje que lo satisfaga. La segunda opción no equivale a la primera: dos contestaciones apoyadas en anclajes distintos no superan ni suspenden automáticamente la prueba de igualdad. Primero hay que resolver qué punto se utilizó.

La invariancia respecto del solicitante está limitada a la misma combinación de sujeto, anclaje resuelto y derivación. Dentro de ese perímetro, ni la identidad de quien pregunta ni el canal deberían alterar los bytes de la prueba entregada. Fuera de él, el documento permite decisiones de acceso. Alguien puede negar un artefacto a una parte y facilitárselo a otra. Por eso una auditoría que compruebe únicamente la igualdad de las respuestas que logró obtener podría pasar por alto un patrón de negativas selectivas.

También importa la continuidad del registro. Los anclajes servidos para un mismo flujo deben pertenecer a una historia de solo adición compatible entre sí. Si cada público recibe un anclaje diferente, una comparación local de artefactos no descubre por sí sola una bifurcación. Hacen falta copias independientes de los puntos de control y pruebas de consistencia entre ellos, idealmente observadas por más de un actor. Y ni siquiera una historia coherente demuestra que se hayan incorporado todos los hechos ocurridos: una omisión anterior a la firma puede conservar una apariencia matemática impecable.

El borrador ordena las salidas en tres clases finales. La negativa firmada incluye una huella de la solicitud, hora, motivo procesable y firma del respondiente; un motivo genérico puede proteger la existencia misma del sujeto. La ausencia registrada, en cambio, la anota quien preguntó cuando termina la espera sin respuesta final. No hay firma del respondiente en ese silencio. Solo un compromiso de retención firmado y todavía vigente puede convertir ciertos incumplimientos posteriores en algo atribuible con mayor precisión; tampoco promete disponibilidad de la red. Una derivación tipo history_card/1 evita mostrar registros, pero puede dejar ver frecuencia y volumen de puntos de control. Lo verificable tiene, por tanto, fronteras de acceso, integridad y privacidad distintas.

Fuentes