Summary

  • El Internet-Draft individual permite que un emisor evalúe una condición de una cartera contra un estado referenciado y devuelva un booleano firmado verificable sin conexión mediante JWKS.
  • En JSON, la firma cubre id, pass, results y attestedAt; expiresAt, kid, las envolturas y normalmente la cartera quedan fuera de esos bytes firmados.
  • Verificar la firma no demuestra que el bloque siga siendo canónico, que la lectura fuera independiente, que el resultado no sea reproducido ni que la parte usuaria deba autorizar una acción.

Una respuesta correcta para un mundo anterior

Un sistema consulta si una cartera mantiene el saldo exigido. El emisor lee una fuente, selecciona un bloque, evalúa la condición y firma pass: true. La parte usuaria recibe el artefacto pocos segundos después. Puede verificar cada byte y aun así actuar sobre un saldo ya transferido, un indexador rezagado o un bloque desplazado por una reorganización.

La firma no ha fallado: conserva exactamente la declaración que se le pidió conservar. El error aparece cuando la interfaz traduce “el emisor firmó esta evaluación en este ancla” como “la cartera cumple ahora y puedo ejecutar”.

La revisión 01 fue publicada el 27 de septiembre de 2026. Datatracker la ubica entre los envíos individuales, sin stream, con estados Active e I-D Exists. El texto perfila JWT, JWKS y JOSE; no es un nuevo protocolo de cable. Tampoco es un documento adoptado, un RFC, una prueba de interoperabilidad ni evidencia de despliegue.

La firma tiene un perímetro exacto

El objeto JSON firmado contiene cuatro miembros: id, pass, results y attestedAt. Dentro de cada resultado aparecen la condición evaluada, su conditionHash y una referencia específica de la cadena. Esa referencia puede ser número y tiempo de bloque, índice de ledger, slot o altura y hash de la punta.

La modalidad bare reconstruye los bytes en el orden exacto transmitido. La nueva modalidad con separación de dominio añade tipo y versión y usa la canonicalización de RFC 8785. Esta última reduce ambigüedades entre implementaciones. No verifica de dónde obtuvo el emisor el estado ni decide si la referencia era final.

kid selecciona la clave y la modalidad en el JWKS. Si falta o es desconocido, el resultado es unverifiable, no refuted; está prohibido probar otra clave. Durante una rotación, cachés JWKS distintos pueden dividir a los verificadores. Esa diferencia debe aparecer en la telemetría como estado de conocimiento, no como ataque demostrado.

El JSON firmado tampoco nombra necesariamente la cartera. Algunas condiciones incluyen una dirección, pero el receptor de segunda mano no debe inferirla. El formato JWT firma sub y exp; quien lea esos claims debe verificar ese JWT. La firma del JSON que viaja junto a él no lo sustituye.

La frescura necesita una política

La referencia de cadena y attestedAt están protegidos. Lo que no está predefinido es cuánto pueden envejecer. La antigüedad del bloque, la de la firma y la del momento de acción son magnitudes distintas. Un artefacto recién emitido puede partir de una referencia demasiado antigua para una operación de alto valor.

En JSON, expiresAt es un indicio TTL sin firma. La revisión 01 recomienda comprobar que no supere attestedAt más la ventana documentada. En JWT, exp sí está firmado. Aun así, la comprobación de expiración es una recomendación. Un registro serio debe indicar performed, passed, failed o not performed, no asumir que una biblioteca hizo lo correcto.

La prevención de replay también queda en el perfil de integración. id permite una lista de vistos; nonce y audiencia pueden viajar como claims personalizados. La mera cercanía temporal no ata un artefacto a una operación concreta.

La cadena puede corregir su historia

El borrador deja fuera de alcance el enrutamiento RPC, la elección de indexador, los nodos de archivo, la finalidad y la disponibilidad. Reconoce que una reorganización posterior puede volver no canónico el estado observado. Profundidad, fuentes independientes, cadenas con finalidad fuerte y procedimientos de revocación son decisiones operativas.

Recalcular conditionHash detecta que alguien alteró el predicado declarado. No prueba que la fuente de datos fuera correcta ni que el umbral represente la política de la empresa. Una prueba Merkle puede conectar un valor con una raíz; todavía hace falta decidir si esa raíz es aceptable y si el hecho histórico sigue siendo suficiente.

Por eso existen tres relojes: observación, canonicalidad y decisión. Un dashboard que los comprime en un icono concede al emisor una autoridad que el formato no le dio.

Conservar la cadena de recibos

Las capas de realidad de Lu Heng separan representación, observación, cadena canónica, estado actual y resultado. Running-Code Primacy exige mirar la cadena y el servicio reales. Minimum Initial Specification permite compartir un formato pequeño sin ocultar bajo él la política local de finalidad y acceso.

El expediente debe incluir emisor y kid, modalidad y dominio, hash de bytes reconstruidos, veredictos de firma, hash de condición, vínculo de cartera, referencia, contraste independiente, profundidad de finalidad, tiempos, expiración, replay, regla de autorización y resultado de la acción.

Fuentes y límites

Estas fuentes no demuestran consenso IETF, adopción, implementación, despliegue, observación independiente, finalidad, control o consentimiento de la cartera, autorización, liquidación, entrega ni resultado del servicio. Las menciones de adopción informativa del borrador siguen siendo afirmaciones de sus autores.