Resumen

  • El borrador individual del 28 de octubre define un registro con afirmación, resultado, regla y referencias por resumen SHA-256 a las pruebas utilizadas.
  • El comprobador aporta política, anclas de confianza y bytes de prueba propios. Su informe distingue released, held y refused, y evita el rótulo global «verificado».

El expediente tiene dos dueños

La parte que llega a una conclusión puede documentarla con todo cuidado. También puede elegir qué papeles entrega. Darren Wright plantea que el lector no tenga que confiar en el buen orden de esa mesa. Su propuesta en el IETF conserva la declaración del emisor, pero obliga al comprobador a separar el contenido de la declaración de lo que él mismo logró verificar. Es un Internet-Draft individual de destino Experimental, todavía en la fase de propuesta.

El formato se llama «verdict record». Usa JSON canónico y estricto: orden fijo de miembros, límites de profundidad y resúmenes calculados sobre bytes exactos. El emisor figura como writer; el cuerpo contiene la afirmación; la lista de pruebas señala archivos concretos mediante su digest y formato; check nombra la regla y el resultado. La firma y el límite superior de tiempo los aporta el contenedor. Una declaración firmada y un recibo SCITT podrían servir, pero el JSON por sí solo no certifica quién lo escribió.

La prueba de independencia está en los datos de entrada. El comprobador calcula digestos y firmas con los bytes que posee. La política, las anclas de confianza y las especificaciones de reglas son suyas. Ninguna frase del emisor puede convertir en aprobado un paso que, sin ella, no aprobaría. Es una forma bastante tajante de impedir que el fabricante del examen también se otorgue el diploma.

Para cada documento citado, el receptor necesita el documento completo y debe obtener el mismo digest. Comprueba además que el formato está dentro de los que puede verificar. Si falta una pieza o no sabe validar ese formato, marca el paso NOT RUN. Si la regla es mecánica, la vuelve a ejecutar y compara la respuesta. Una diferencia provoca fallo. El caso judgement, sin regla mecánica reproducible, sólo entra para los tipos admitidos por la política del propio comprobador. Retirar una prueba del paquete no crea una aprobación por omisión; deja el expediente retenido.

El informe final no es una bandera binaria. Si pasan todos los pasos, el registro queda released. Si uno falla, refused. Si ninguno falla pero alguno no puede ejecutarse, held. Una política defectuosa del comprobador da no verdict. Deben aparecer los motivos por paso, el límite temporal y los digestos de política y anclas de confianza. La propuesta veta palabras que prometen más para todo el registro: «verificado», «válido», «verdadero», «fiable», «correcto», «probado», «confirmado» u «OK». Hasta el diseño de la pantalla queda sometido a la misma disciplina probatoria.

Released sólo acredita el alcance del expediente: este emisor afirmó este resultado, con estas pruebas y esta regla, antes del límite temporal establecido. La afirmación de fondo puede ser falsa. El mérito de la propuesta está en hacer visible esa distancia donde el receptor toma una decisión.

Fuentes: borrador Wright, estado IETF, RFC 9943, RFC 8259.