Resumen

  • El borrador individual draft-schrock-ep-authorization-evidence-chain-07 divide el antiguo resultado VERIFIED de -06 en comprobación nativa VERIFIED y aceptación local ACCEPTED.
  • No hallar una clave referenciada impide evaluar la firma; no demuestra que sea falsa. Hallarla tampoco obliga a confiar en ella para ese papel.
  • La comparación con la acción, la suficiencia de la evidencia, la autorización del ejecutor y el resultado material son juicios posteriores y diferentes.

El problema aparece cuando un agente trae un paquete de aprobaciones y pide a un servicio que ejecute una operación costosa. Un servicio dispone de una clave con la que puede comprobar una firma; otro, que recibe el mismo paquete, también puede comprobarla. Sin embargo, sus listas de emisores y clases de clave autorizadas para ese uso son distintas. Un informe que conserve solo «firma correcta» borra la razón por la que uno acepta el documento y el otro lo descarta. Peor aún: si esa etiqueta se transforma en «acción aprobada», elimina una decisión que corresponde al ejecutor.

Ian Schrock ha dado forma explícita a esa frontera en la revisión del 28 de septiembre de Authorization Evidence Chains: Composing Heterogeneous Agent-Action Evidence. La copia -07 consta en el archivo oficial. Es un Internet-Draft individual con la intención Informational declarada por su autor: no es un RFC, ni una especificación adoptada por un grupo de trabajo, ni prueba de que exista una instalación operativa. La versión -06 ya describía cómo componer artefactos de identidad, delegación, aprobación y otros tipos. La lista de cambios de -07 identifica una corrección más estrecha: antes el resultado VERIFIED incluía la decisión de confianza del tercero que iba a depender de la prueba; ahora se informa por separado de VERIFIED y ACCEPTED.

El primer término exige que el verificador nativo supere sus controles criptográficos y estructurales. El segundo solo puede ser positivo después del primero y conforme a los parámetros fijados por quien se apoya en el artefacto. Entre ellos figuran el directorio de claves y su estado, los emisores admitidos, la clase de clave, el papel o destinatario esperado, la política propia del formato y su revisión. La parte que presenta el paquete no puede designar sus propias anclas de confianza como si fueran las del receptor. Si el formato remite a una clave externa, la resolución de esa referencia es un paso anterior: si falla, la comprobación queda NOT_EVALUATED, no FAILED. Si tiene éxito, la clave permite examinar los bytes, pero puede seguir sin ser aceptable para aprobar esta clase de acción.

Hay una sutileza adicional. No siempre puede trasladarse de un receptor a otro ni siquiera el veredicto de verificación, porque dos directorios de resolución podrían asociar la misma referencia a claves distintas. El borrador exige guardar el contexto y no anunciar una propiedad absoluta de la cadena de bytes. Asimismo rechaza que el agente entregue un indicador de «verificado», un hecho normalizado o una relación de confianza preconstruida para sustituir el examen propio.

Un resultado previo dentro de la misma frontera protegida solo se reutiliza si queda ligado de manera íntegra al resumen exacto de la evidencia, al perfil del verificador, a la instantánea de confianza y al momento de la comprobación. Un resultado serializado que llega desde fuera requiere a su vez verificación.

Después viene otra pregunta: ¿es esta prueba para la operación que el ejecutor tiene realmente preparada? El texto permite MATCH únicamente después de VERIFIED y ACCEPTED. Un permiso auténtico y admitido que habla de otra acción no fracasa porque el firmante deje de ser fiable; fracasa porque no corresponde a la acción congelada. La vigencia, el estado autenticado, los vínculos entre piezas y la expresión de requisitos determinan entonces SATISFIED o UNSATISFIED. SATISFIED no significa que el servicio haya autorizado la operación. La decisión AUTHORIZED, la invocación y el efecto permanecen en el sistema local que puede causar el cambio.

La revisión incluye una salida reproducible con revisión del algoritmo, huellas de cadena y acción, hora de verificación, resumen de la instantánea de confianza y ambos resultados por componente. Los motivos diferenciados sirven para no confundir un fallo matemático, una verificación imposible, un rechazo de confianza o una acción ajena. La propuesta no crea un registro universal ni pide acciones a IANA. Tampoco el informe de evaluación convierte por sí solo una prueba en autoridad sobre una red ajena.

Fuentes