Guides

Parties de confiance

Une partie de confiance est votre client, ou toute autre personne envers qui vous êtes responsable, qui soumet chaque version de votre système d'IA à une évaluation qu'elle a épinglée elle-même. Le workspace décide chaque version selon son épinglage à côté de votre propre gate, et elle récupère un enregistrement de décision de chaque version et le vérifie sur sa propre machine. Elle ne voit jamais vos cas, labels ou traces, et rien de ce que vous faites à votre propre exigence ne change son épinglage.

Un enregistrement est une preuve qu'une seconde partie peut vérifier, pas une certification.

Inviter une partie de confiance

Sur un projet hébergé, ouvrez Relying parties (dans le groupe Assurance de la palette de commandes, ou depuis Governance). Seul un Owner peut inviter : nommez l'organisation, puis envoyez vous-même, une seule fois, le lien qui s'affiche. Il est valable sept jours.

La partie de confiance ouvre le lien connectée avec un compte de sa propre organisation. Un compte membre de votre workspace ne peut pas accepter, et un compte qui rejoint plus tard votre workspace perd les pages de la partie de confiance. Les deux côtés voient l'e-mail du compte qui a accepté : vérifiez que c'est celui que vous attendez.

Ce que fait la partie de confiance

1. Vérifier un enregistrement que vous avez envoyé. Exportez-en un depuis la page d'une exécution gouvernée (Download the decision record) et envoyez-le. Elle lance :

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

avec la clé publique de votre runner, que l'opérateur de votre runner lui remet directement, et les clés de déclaration de workspace publiées par le déploiement, enregistrées depuis /api/workspace-statement-key.

Une fois que vous avez l'identifiant de votre partie de confiance (sur votre page), ajoutez --relying-party RP_ID à chaque vérification ultérieure : un enregistrement qui appartient à une autre partie de confiance, ou au fournisseur lui-même, échoue alors.

2. Épingler l'évaluation. Sur sa page, elle colle les champs evaluation.digest et evaluation.policy_digest de l'enregistrement, ainsi que l'identifiant de son exécution décidée. Le digest d'évaluation lie la suite (chaque cas et son contenu), les évaluateurs par contenu, les spécifications de métriques et la politique, si bien qu'une suite réduite ou une politique plus laxiste donne un autre digest. La politique doit être une politique que le workspace a vérifiée. L'exécution est la référence par rapport à laquelle chaque règle de comparaison est décidée, affichée sur sa page, si bien que vous ne pouvez pas la choisir par l'ordre dans lequel vous poussez. Un épinglage n'est jamais remplacé : un nouveau est ajouté et le plus récent est en vigueur.

3. Reconnaître vos clés de runner. Sa page liste chaque enregistrement et chaque révocation d'une clé de runner du projet, tels qu'ils ont eu lieu, depuis un journal que personne ne peut modifier. Une clé ne compte pour son épinglage qu'une fois son enregistrement reconnu, si bien qu'une clé que vous enregistrez plus tard ne décide rien pour elle tant qu'elle n'a pas comparé sa clé publique à celle que votre opérateur lui a remise. Une exécution sur les workers gérés d'Oloproof ne demande aucune reconnaissance : vous n'enregistrez ni ne renouvelez cette clé.

4. Récupérer chaque enregistrement. La page liste chaque version de système décidée selon son épinglage, avec l'état de chaque règle et un lien Download pour son enregistrement. Elle récupère les enregistrements elle-même, et ne dépend donc pas de ceux que vous choisissez d'envoyer.

Comment chaque version est décidée

Le worker prend l'exécution épinglée comme référence, une fois qu'elle est une exécution vérifiée signée par une clé qu'elle a reconnue, et décide chaque version de système sur son tout premier démarrage de cette évaluation, quelle que soit la clé qui l'a signé et quel qu'en ait été le sort. Une première exécution échouée ne peut pas être remplacée par une relance plus chanceuse, et une version démarrée pour la première fois sous une clé qu'elle n'a jamais reconnue reste retenue. Les règles sont décidées par le même code que votre propre gate, en exécution vérifiée.

Une décision ne survit pas à ce sur quoi elle repose. Si la clé de la référence est révoquée comme compromise, ou si elle épingle à nouveau, chaque gate que l'épinglage en vigueur ne décide plus est retenu (MANUAL_REVIEW) avec la raison. Une clé ne compte qu'avec la clé publique qu'elle a reconnue, et une exécution sur les workers gérés d'Oloproof seulement sous la propre clé du déploiement.

Ce qu'ajoute son enregistrement

Un enregistrement exporté pour une partie de confiance porte, dans la déclaration signée du workspace :

la partie de confiance à laquelle il est destiné, et son épinglage comme exigence ;
chaque démarrage de la version sur l'évaluation, chacun avec la requête signée du runner lui-même, que record verify vérifie avec les clés qu'elle fournit ;
le journal de chaque clé qui a signé un démarrage ou une exécution de la version : sa clé publique, son enregistrement, sa reconnaissance et toute révocation.

record verify fait échouer l'enregistrement si un démarrage signé ne tient pas ou nomme une autre exécution, version, suite, workspace ou projet, si la clé publique d'une clé journalisée n'est pas celle qu'elle a fournie, si un gate qui passe repose sur une clé qu'elle n'a pas reconnue ou sur une clé journalisée comme compromise, ou, avec --relying-party, si l'enregistrement n'est pas le sien ou si sa déclaration n'est pas signée par une clé de déclaration de workspace qu'elle a fournie. Sans --relying-party, une déclaration qui n'est pas signée se lit non vérifiée, jamais vérifiée. Ses codes de sortie sont inchangés : 0 quand chaque vérification possible a réussi, 5 quand l'une a échoué, 2 quand une clé ou un fichier ne peut pas être lu.

Ce qu'il ne peut pas vous dire

Que le compte qui a épinglé et reconnu appartient à la partie de confiance : l'e-mail est affiché, pas prouvé.
Que le runner n'a exécuté que du code contrôlé par son opérateur, ou que la version évaluée est celle qui sert en production.
Que l'évaluation est la bonne : le choix de la suite reste celui du fournisseur, sauf si la partie de confiance fournit la suite ou épingle une évaluation de trafic tirée de la production.
Quoi que ce soit dit après l'export : un enregistrement est la parole du workspace à la date de son export ; récupérez-en un nouveau en cas de doute.
Rien après que l'opérateur a mis fin à la relation. Vous ne pouvez pas y mettre fin : un projet, ou votre compte en tant que dernier Owner de son workspace, ne peut pas être supprimé tant qu'une partie de confiance y est rattachée. Récupérez tout de même chaque enregistrement dès qu'il est décidé.
Un intervalle PPI : les labels derrière un échantillon humain ne sont pas dans l'enregistrement.