Partes que confían

Una parte que confía es su cliente, o cualquier otra persona ante quien usted responde, que somete cada versión de su sistema de IA a una evaluación que fijó ella misma. El workspace decide cada versión según su fijación junto a su propio gate, y ella descarga un registro de decisión de cada versión y lo comprueba en su propia máquina. Nunca ve sus casos, etiquetas ni trazas, y nada de lo que usted haga con su propio requisito cambia su fijación.

Un registro es evidencia que una segunda parte puede comprobar, no una certificación.

Invitar a una parte que confía

En un proyecto alojado, abra Relying parties (en el grupo Assurance de la paleta de comandos, o desde Governance). Solo un Owner puede invitar: nombre la organización y luego envíe usted mismo, una sola vez, el enlace que se muestra. Es válido durante siete días.

La parte que confía abre el enlace con la sesión iniciada en una cuenta de su propia organización. Una cuenta que es miembro de su workspace no puede aceptar, y una cuenta que se une más tarde a su workspace pierde las páginas de la parte que confía. Ambos lados ven el correo de la cuenta que aceptó: compruebe que es la que espera.

Lo que hace la parte que confía

1. Verificar un registro que usted envió. Exporte uno desde la página de una ejecución gobernada (Download the decision record) y envíelo. Ella ejecuta:

``bash oloproof record verify record.json --key KEY_ID=PUBLIC_KEY --workspace-keys keys.json ``

con la clave pública de su runner, que el operador de su runner le entrega directamente, y las claves de declaración del workspace publicadas por el despliegue, guardadas desde /api/workspace-statement-key.

Una vez que tenga el id de su parte que confía (en su página), añada --relying-party RP_ID a cada comprobación posterior: un registro que sea de otra parte que confía, o del propio proveedor, entonces falla.

2. Fijar la evaluación. En su página pega evaluation.digest, evaluation.policy_digest y el id de su ejecución decidida del registro. El digest de la evaluación vincula la suite (cada caso y su contenido), los evaluadores por contenido, las especificaciones de métricas y la política, de modo que una suite recortada o una política más laxa da otro digest. La política debe ser una que el workspace haya comprobado. La ejecución es la referencia contra la que se decide cada regla de comparación, mostrada en su página, así que usted no puede elegirla por el orden en que hace push. Una fijación nunca se reemplaza: se añade una nueva y la más reciente es la vigente.

3. Reconocer sus claves de runner. Su página lista cada registro y cada revocación de una clave de runner del proyecto, tal como ocurrieron, desde un registro que nadie puede editar. Una clave cuenta para su fijación solo cuando ella reconoce su registro, así que una clave que usted registre más tarde no decide nada para ella hasta que haya comparado su clave pública con la que su operador le dio. Una ejecución en los workers gestionados de Oloproof no necesita reconocimiento: usted no registra ni rota esa clave.

4. Descargar cada registro. La página lista cada versión del sistema decidida según su fijación, con el estado de cada regla y un enlace Download para su registro. Ella descarga los registros por sí misma, así que no depende de los que usted elija enviar.

Cómo se decide cada versión

El worker toma la ejecución fijada como referencia, una vez que es ejecución verificada firmada por una clave que ella reconoció, y decide cada versión del sistema en su primer inicio de esa evaluación, sea cual sea la clave que lo firmó y lo que fuera de él. Una primera ejecución fallida no puede sustituirse por una repetición con más suerte, y una versión iniciada por primera vez con una clave que ella nunca reconoció queda retenida. Las reglas se deciden con el mismo código que su propio gate, con ejecución verificada.

Una decisión no sobrevive a aquello en lo que se apoya. Si la clave de la referencia se revoca como comprometida, o ella vuelve a fijar, cada gate que la fijación vigente ya no decide queda retenido (MANUAL_REVIEW) con el motivo. Una clave cuenta solo con la clave pública que ella reconoció, y una ejecución en los workers gestionados de Oloproof solo bajo la propia clave del despliegue.

Lo que añade su registro

Un registro exportado para una parte que confía lleva, en la declaración firmada del workspace:

• la parte que confía a la que va destinado, y su fijación como requisito;
• cada inicio de la versión en la evaluación, cada uno con la solicitud firmada del propio runner, que record verify comprueba con las claves que ella proporciona;
• el registro de claves de cada clave que firmó un inicio o una ejecución de la versión: su clave pública, su registro, su reconocimiento y cualquier revocación.

record verify hace fallar el registro si un inicio firmado no se sostiene o nombra otra ejecución, versión, suite, workspace o proyecto, si la clave pública de una clave registrada no es la que ella proporcionó, si un gate que pasa se apoya en una clave que ella no reconoció o en una registrada como comprometida, o, con --relying-party, si el registro no es suyo o su declaración no está firmada por una clave de declaración del workspace que ella proporcionó. Sin --relying-party, una declaración que no está firmada se lee no comprobada, nunca verificada. Sus códigos de salida no cambian: 0 cuando cada comprobación posible pasó, 5 cuando una falló, 2 cuando no se puede leer una clave o un archivo.

Lo que no puede decirle

• Que la cuenta que fijó y reconoció pertenece a la parte que confía: el correo se muestra, no se prueba.
• Que el runner ejecutó solo código que controla su operador, o que la versión evaluada es la que sirve en producción.
• Que la evaluación es la correcta: elegir la suite sigue siendo cosa del proveedor, salvo que la parte que confía aporte la suite o fije una evaluación de tráfico extraída de producción.
• Nada dicho después de la exportación: un registro es la palabra del workspace en el momento de su exportación; descargue uno nuevo en caso de duda.
• Nada después de que el operador ponga fin a la relación. Usted no puede ponerle fin: un proyecto, o su cuenta como último Owner de su workspace, no puede eliminarse mientras haya una parte que confía vinculada. Aun así, descargue cada registro en cuanto se decida.
• Un intervalo PPI: las etiquetas detrás de una muestra humana no están en el registro.