Partes confiantes

Uma parte confiante é seu cliente, ou qualquer outra pessoa a quem você presta contas, que submete cada versão do seu sistema de IA a uma avaliação que ela mesma fixou. O workspace decide cada versão contra essa fixação ao lado do seu próprio gate, e ela baixa um registro de decisão de cada versão e o verifica na própria máquina. Ela nunca vê seus casos, rótulos ou traces, e nada do que você faz com o seu próprio requisito altera a fixação dela.

Um registro é uma evidência que uma segunda parte pode verificar, não uma certificação.

Convidar uma parte confiante

Em um projeto hospedado, abra Relying parties (no grupo Assurance da paleta de comandos, ou a partir de Governance). Apenas um Owner pode convidar: dê o nome da organização e envie você mesmo, uma única vez, o link exibido. Ele funciona por sete dias.

A parte confiante abre o link conectada com uma conta da sua própria organização. Uma conta que é membro do seu workspace não pode aceitar, e uma conta que depois entra no seu workspace perde as páginas da parte confiante. Os dois lados veem o email da conta que aceitou: confira se é a que você espera.

O que a parte confiante faz

1. Verificar um registro que você enviou. Exporte um a partir da página de uma execução governada (Download the decision record) e envie-o. Ela executa:

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

com a chave pública do seu runner, que o operador do seu runner entrega diretamente a ela, e as chaves publicadas de declaração do workspace da implantação, salvas a partir de /api/workspace-statement-key.

Assim que tiver o id da sua parte confiante (na sua página), acrescente --relying-party RP_ID a cada verificação posterior: um registro que pertence a outra parte confiante, ou ao próprio provedor, então falha.

2. Fixar a avaliação. Na página dela, ela cola o evaluation.digest, o evaluation.policy_digest do registro e o id da execução decidida dele. O digest da avaliação vincula a suíte (cada caso e seu conteúdo), os avaliadores pelo conteúdo, as especificações de métricas e a política, então uma suíte reduzida ou uma política mais branda é outro digest. A política deve ser uma que o workspace verificou. A execução é a linha de base contra a qual toda regra de comparação é decidida, exibida na página dela, então você não pode escolhê-la pela ordem em que envia. Uma fixação nunca é substituída: uma nova é adicionada e a mais recente está em vigor.

3. Reconhecer as chaves do seu runner. A página dela lista cada registro e revogação de uma chave de runner do projeto, como aconteceu, a partir de um log que ninguém pode editar. Uma chave só conta para a fixação dela depois que ela reconhece seu registro, então uma chave que você registra depois não decide nada para ela até que tenha comparado a chave pública com a que seu operador lhe deu. Uma execução nos workers gerenciados do Oloproof não precisa de reconhecimento: você não registra nem rotaciona essa chave.

4. Baixar todos os registros. A página lista cada versão do sistema decidida contra a fixação dela, com o estado de cada regra e um link Download para o seu registro. Ela mesma baixa os registros, então não depende dos que você escolhe enviar.

Como cada versão é decidida

O worker toma a execução fixada como linha de base, desde que seja execução verificada assinada por uma chave que ela reconheceu, e decide cada versão do sistema no seu primeiro início dessa avaliação, qualquer que seja a chave que o assinou e o que quer que tenha acontecido com ele. Uma primeira execução reprovada não pode ser substituída por uma reexecução com mais sorte, e uma versão iniciada pela primeira vez sob uma chave que ela nunca reconheceu permanece retida. As regras são decididas pelo mesmo código do seu próprio gate, em execução verificada.

Uma decisão não sobrevive àquilo em que se apoia. Se a chave da linha de base for revogada como comprometida, ou se ela fixar de novo, todo gate que a fixação em vigor não decide mais fica retido (MANUAL_REVIEW) com o motivo. Uma chave só conta com a chave pública que ela reconheceu, e uma execução nos workers gerenciados do Oloproof só sob a própria chave da implantação.

O que o registro dela acrescenta

Um registro exportado para uma parte confiante traz, na declaração assinada do workspace:

• a parte confiante a que se destina, e a fixação dela como requisito;
• cada início da versão na avaliação, cada um com a própria solicitação assinada do runner, que record verify verifica contra as chaves que ela fornece;
• o log de cada chave que assinou um início ou uma execução da versão: sua chave pública, registro, reconhecimento e qualquer revogação.

record verify reprova o registro se um início assinado não se sustenta ou nomeia outra execução, versão, suíte, workspace ou projeto, se a chave pública de uma chave registrada no log não é a que ela forneceu, se um gate aprovado se apoia em uma chave que ela não reconheceu ou em uma registrada no log como comprometida, ou, com --relying-party, se o registro não é dela ou se sua declaração não está assinada por uma chave de declaração do workspace que ela forneceu. Sem --relying-party, uma declaração que não está assinada aparece como não verificada, nunca como verificada. Seus códigos de saída não mudam: 0 quando toda verificação que pôde ser feita passou, 5 quando uma falhou, 2 quando uma chave ou arquivo não pode ser lido.

O que ele não pode dizer

• Que a conta que fixou e reconheceu pertence à parte confiante: o email é exibido, não comprovado.
• Que o runner executou apenas código que seu operador controla, ou que a versão avaliada é a que está servindo em produção.
• Que a avaliação é a certa: escolher a suíte ainda cabe ao provedor, a menos que a parte confiante forneça a suíte ou fixe uma avaliação de tráfego extraída da produção.
• Nada dito após a exportação: um registro é a palavra do workspace no momento da exportação; baixe um novo em caso de dúvida.
• Nada depois que o operador encerra a relação. Você não pode encerrá-la: um projeto, ou sua conta como último Owner do workspace dele, não pode ser excluído enquanto houver uma parte confiante vinculada. Ainda assim, baixe cada registro assim que for decidido.
• Um intervalo PPI: os rótulos por trás de uma amostra humana não estão no registro.