Resumen

  • Douglas Cameron Borthwick publicó la versión -01 de su borrador individual sobre atestación del estado de carteras el 27 de septiembre. No es una RFC ni una propuesta adoptada por un grupo de trabajo.
  • En JSON se firman id, pass, results y attestedAt. Una condición concreta puede incluir la dirección, pero el objeto firmado no identifica necesariamente la cartera consultada.
  • expiresAt queda fuera de los bytes firmados en JSON. El JWT opcional sí firma sub y exp, pero requiere una verificación propia y, si llega junto con JSON, una comprobación de concordancia.

Dos equipos y un «sí» auténtico

La revisión -01 plantea una operación de lectura. Un emisor observa datos públicos de la cadena, evalúa condiciones definidas por el operador para una dirección y firma un resultado booleano. El verificador puede comprobarlo sin volver a consultar al emisor, usando su conjunto publicado de claves. La respuesta ordinaria comunica si se cumplió una condición, no el saldo exacto. No se trata de una credencial de identidad que el titular presente.

Ese diseño hace especialmente importante el traspaso entre sistemas. Imaginemos que un componente pide comprobar una cartera y otro concede el acceso. El primero conoce la dirección incluida en la solicitud. El segundo quizá reciba solo el JSON. El texto revisado especifica cuatro miembros principales en los bytes firmados: id, pass, results y attestedAt. No hay un campo general que nombre la cartera en ese conjunto. Algunas condiciones llevan la dirección dentro de evaluatedCondition; en esos casos queda protegida como parte de results. Pero el formato no obliga a que toda condición la lleve. Por eso la validez de la firma no resuelve por sí sola la relación entre resultado y sujeto cuando se ha perdido la solicitud.

No hace falta imaginar un atacante para comprender el coste. Un identificador de correlación equivocado, dos solicitudes simultáneas o una entrega incompleta pueden adjuntar un resultado genuino a la cuenta equivocada. Son escenarios de control, no fallos observados ni incidentes atribuidos a un producto. El error sería preguntar solo si se verificó la firma y omitir quién conservó el vínculo con la cartera que originó el cálculo.

La condición intacta no rellena un dato ausente

La versión nueva exige volver a calcular conditionHash a partir de evaluatedCondition y rechazar una discrepancia. Protege la integridad de lo evaluado y evita que se cambie silenciosamente una condición. Pero una condición íntegra que no contenga la dirección no constituye una prueba general sobre cuál fue la cartera. La firma cubre también la marca attestedAt y referencias a bloques en cada resultado. Con ello es posible razonar sobre el momento de observación; no implica que cualquier aplicación lo haga.

La fecha expiresAt viaja junto a la respuesta JSON, pero fuera de sus bytes firmados. El documento sugiere cotejarla con la hora firmada y con el plazo de validez que publique el emisor. Una parte que necesite una garantía más estricta puede rechazar resultados demasiado antiguos según su propia política de edad máxima para el bloque o attestedAt. En el procedimiento de siete pasos, las comprobaciones de clave, bytes, firma y hash son requisitos de la propuesta; las de frescura y caducidad se recomiendan. No se puede convertir esa recomendación en una promesa de que todos los verificadores la aplicarán.

La clave tampoco se puede adivinar. kid, transmitido al lado del objeto JSON firmado, selecciona una entrada de JWKS y el esquema de firma correspondiente. Si falta o es desconocido, el estado es «no verificable», distinto de una firma refutada bajo la clave seleccionada. Ninguno permite aceptar la respuesta. Refrescar una copia antigua de JWKS puede ser razonable; sustituir la clave por la primera de la lista no lo es según el borrador.

El token adicional cambia el perímetro

Si se solicita JWT, el emisor entrega además un token firmado por separado. En él, sub designa la cartera realmente evaluada, exp queda cubierto por la firma y kid aparece en la cabecera protegida. Un destinatario que use esos datos tiene que verificar el token mismo. Cuando se reciben JSON y JWT juntos, la revisión exige revisar su correspondencia; un JWT fallido o incongruente obliga a rechazar el conjunto. No basta con mostrar el token en pantalla mientras se verifica únicamente la firma JSON. Tampoco se puede afirmar que el JSON incluya ahora sub: cada artefacto conserva su perímetro.

Una prueba de Merkle opcional permitiría comprobar algunos valores frente a una referencia de bloque sin aceptar sin más la evaluación del emisor. La propuesta advierte que no todas las condiciones o cadenas la admiten. Además, esa modalidad puede revelar el valor bruto —por ejemplo, un saldo— que el resultado booleano evitaba divulgar. Es una elección de verificación y privacidad, no una solución automática al vínculo entre respuesta y cartera.

La versión -01 añadió un esquema JSON con separación de dominio, una posible firma acompañante y ramas de verificación más explícitas. El propio historial dice que las firmas emitidas bajo la versión -00 siguen siendo verificables. El límite de cobertura se explica ahora con más precisión; no se inventó en septiembre. El registro de Datatracker indica que es un Internet-Draft individual activo, sin flujo RFC y con estado I-D Exists; el alojamiento no constituye aval del IETF. Las afirmaciones del autor sobre usos de producción no son prueba independiente de despliegue para este artículo.

Fuentes