Resumen
draft-sato-soos-pt-03, anunciado el 5 de septiembre de 2026, es un Internet-Draft individual activo, sin respaldo ni posición formal de la IETF, sin flujo RFC, Area Director responsable ni fecha de teleconferencia.- La revisión 02 situaba
ProgressiveTrustSummaryen el contexto de HEM, pero no cerraba la composición de la firma. La 03 exige que el resumen sea un campo dentro de cada HEM Escalation Request antes de que el GEC la firme. - El texto nuevo prohíbe que la interfaz de la persona receptora trate como autorizado un resumen entregado fuera del sobre firmado de la solicitud.
pt_summary_hashsigue siendo un SHA-256 del JSON canónico y sirve para comprobar el objeto después de extraerlo. La autenticidad ante quien decide procede dekernel_signature, la firma de la solicitud envolvente.- Un recibo conjunto debería guardar
hem_id, la preimagen firmada, firmante y clave, resultado de la verificación, ruta del resumen, hash extraído y transformaciones del transporte. Es una propuesta de Daniel Kade, no una exigencia de la IETF.
La pregunta no es si el número parece correcto
El anuncio del 5 de septiembre describe Progressive Trust como una memoria conductual para agentes de IA: cinco dimensiones extraídas de eventos firmados alimentan recomendaciones sobre su autoridad futura. El Datatracker registra la revisión 03 de Tom Sato como Internet-Draft individual activo. También advierte que no cuenta con respaldo ni posición formal de la IETF. No tiene flujo RFC, Area Director responsable ni cita para teleconferencia. «Standards Track» es el destino pretendido por el autor.
El modelo observa la calibración de la autoevaluación, el criterio para pedir ayuda, la eficacia, la precisión y la adaptación después de un rechazo. ProgressiveTrustSummary reúne las cinco notas, tendencias, recuentos de sesiones, una vista compuesta, recomendaciones pendientes y pt_summary_hash.
Una pantalla puede mostrar todos esos elementos sin que exista un vínculo verificable con la acción sometida a aprobación. Un resumen válido del agente correcto, calculado ayer, puede quedar en caché. Una pasarela puede extraerlo para traducirlo. Un servicio puede devolverlo con retraso y la interfaz emparejarlo con el hem_id que está visible en ese momento. Ningún campo necesita parecer corrupto para que el conjunto sea falso.
La revisión 03 se ocupa de esa unión. No pregunta solo si el resumen se puede verificar aisladamente. Pregunta si el componente que formula la escalada se comprometió criptográficamente con ese resumen dentro de esa solicitud.
De «contexto» a objeto firmado
La revisión 02 decía que el GEC debía incluir ProgressiveTrustSummary en cada HEMContext entregado a una persona. Conservaba la exigencia temporal —calcularlo al invocar HEM— y el hash. Sin embargo, no decía que el resumen entrara en la preimagen antes de crear la firma de la solicitud.
El diff oficial muestra el salto. La revisión 03 convierte el resumen en un campo de cada HEM Escalation Request y ordena componerlo en la solicitud antes de firmar conforme a la sección 18.8 de HEM. Añade una regla de consumo: un resumen fuera del sobre firmado de su solicitud no debe tener autoridad en la interfaz receptora.
El propio borrador atribuye la corrección al hallazgo principal de una revisión de seguridad de WIMSE. La búsqueda pública ordinaria no localizó un artefacto separado de esa revisión. Por eso solo cabe atribuir la frase al borrador; no reconstruir una evaluación que no se ha podido examinar. Lo que sí se puede auditar es la diferencia publicada entre 02 y 03.
La palabra decisiva es «antes». Si el resumen se obtiene después de firmar y se muestra en un panel adyacente, el usuario ve contexto, pero el verificador no puede demostrar que el firmante lo incluyó. Si el resumen forma parte de la preimagen, modificarlo o emparejarlo de nuevo rompe la verificación del objeto completo.
Una huella no identifica quién reunió las piezas
PT-03 mantiene pt_summary_hash como SHA-256 del JSON canónico. La explicación añadida le asigna una función legítima y limitada: una vez extraído el resumen, el auditor puede recalcular la huella y comprobar que no cambió. El hash no es el origen de la autenticidad frente a la persona que recibe la escalada.
El RFC 8785 explica la necesidad general de una representación determinista del JSON para que firma y hash sean repetibles. Esa representación resuelve diferencias de serialización. No añade por sí sola identidad, mandato ni relación con una solicitud. Una huella coincide con unos datos; no declara quién los eligió ni ante qué decisión fueron presentados.
La revisión 07 de HEM define el objeto envolvente. El GEC firma toda la HEM Escalation Request con Ed25519 y kernel_signature cubre la serialización canónica de los demás campos. HEM-07 también describe progressive_trust_summary como campo obligatorio. Así, la comprobación puede abarcar el emparejamiento y no dos piezas sueltas: el firmante vinculó este resumen con esta escalada.
La firma no certifica que la puntuación sea verdadera. Puede haber eventos ausentes, un cálculo erróneo, una clave comprometida o una decisión humana desacertada. La firma hace detectables la alteración y el cambio de pareja bajo las premisas del borrador. La exactitud del mundo representado sigue siendo otra cuestión.
La interfaz no puede adelantar el veredicto
El flujo seguro empieza por el sobre. La aplicación verifica la solicitud completa, la clave pertinente y el resultado de kernel_signature. Después extrae ProgressiveTrustSummary, vuelve a calcular su hash si necesita un registro de auditoría y lo presenta. Si muestra primero una tarjeta verde y comprueba después el objeto envolvente, convierte la latencia de verificación en autoridad visual.
La misma disciplina alcanza a los intermediarios. HEM-07 ordena a los que pueden verificar que no reenvíen una solicitud cuya firma falla. Una pasarela puede transportar, localizar o renderizar. No debería volver a ensamblar componentes y heredar la condición de firmante. Cuando transforma la serialización, necesita conservar la preimagen verificada o un recibo que permita repetir el control.
La persona mantiene la última palabra. PT dice que el resumen es informativo: se puede aprobar con nota baja o terminar con nota alta. Incluirlo en la solicitud firmada no transfiere autoridad a la métrica. Evita que una métrica presentada como evidencia pierda su procedencia mientras conserva su aspecto convincente.
El recibo debe registrar la relación
La unidad mínima de memoria no es «solicitud más resumen» guardados en carpetas distintas. Es un recibo de verificación conjunto. Debería identificar hem_id, versión del objeto, bytes firmados o preimagen canónica, kernel_signature, identidad de firma, clave, momento y resultado de la comprobación. También debería guardar la ruta exacta del resumen, su tiempo de cálculo, la huella recalculada y cualquier transformación efectuada durante el transporte. Este recibo es mi recomendación, no texto normativo de PT o HEM.
Los ensayos útiles intentan romper la unión. El resumen correcto con otro hem_id debe fallar. Un cambio de nota con el hash antiguo debe fallar. Un resumen sustituido con hash nuevo, pero sin firma envolvente válida, debe fallar. Si una interfaz modifica la explicación legible después de verificar, debe demostrar equivalencia o marcarla como elaboración local. Una clave desconocida no debe convertirse en confianza por defecto.
La primacía del código en funcionamiento de Heng Lu sirve como método: publicar la regla no demuestra que una implementación la haga cumplir; hay que poder validarla localmente. Su especificación inicial mínima orienta hacia un núcleo pequeño: un objeto, una firma envolvente y una ruta de comprobación. Son criterios editoriales, no evidencia de adopción.
Corrección verificable, despliegue no demostrado
Ni el registro de PT ni el de HEM aporta una implementación independiente, prueba de interoperabilidad, uso en producción, ataque, incidente o aceptación institucional. Ambos siguen siendo borradores individuales que pueden cambiar o caducar.
La noticia, por tanto, es más concreta que grandiosa. PT-03 ya dice qué objeto debe autenticar el resumen que ve la persona y limita el hash a la verificación posterior a la extracción. Falta comprobar que productos reales rechacen los emparejamientos incorrectos. La próxima prueba importante será código independiente que coincida en los casos negativos y entregue un recibo reproducible.
Fuentes
- Anuncio IETF de
draft-sato-soos-pt-03 - Datatracker — Progressive Trust
- Archivo IETF — PT-03
- Archivo IETF — PT-02
- Comparación oficial PT-02/PT-03
- Archivo IETF — HEM-07
- Datatracker — Human Escalation Mechanism
- RFC 8785 — JSON Canonicalization Scheme
- Heng Lu — Running-Code Primacy
- Heng Lu — especificación inicial mínima
- Heng Lu — realidad, no activismo
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance