Parti affidatarie

Una parte affidataria è un vostro cliente, o chiunque altro a cui rispondete, che sottopone ogni versione del vostro sistema di IA a una valutazione fissata da lei stessa. Il workspace decide ogni versione rispetto al suo pin accanto al vostro gate, e la parte affidataria scarica un record di decisione di ogni versione e lo verifica sulla propria macchina. Non vede mai i vostri casi, le vostre etichette o le vostre tracce, e nulla di ciò che fate al vostro requisito cambia il suo pin.

Un record è un'evidenza che una seconda parte può verificare, non una certificazione.

Invitare una parte affidataria

In un progetto ospitato, aprite Relying parties (nel gruppo Assurance della palette dei comandi, oppure da Governance). Solo un Owner può invitare: indicate il nome dell'organizzazione, poi inviate voi stessi, una volta sola, il link che vi viene mostrato. Vale sette giorni.

La parte affidataria apre il link dopo aver effettuato l'accesso con un account della propria organizzazione. Un account membro del vostro workspace non può accettare, e un account che in seguito entra nel vostro workspace perde le pagine della parte affidataria. Entrambe le parti vedono l'email dell'account che ha accettato: verificate che sia quella che vi aspettate.

Che cosa fa la parte affidataria

1. Verifica un record che avete inviato. Esportatene uno dalla pagina di un'esecuzione governata (Download the decision record) e inviatelo. La parte affidataria esegue:

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

con la chiave pubblica del vostro runner, che l'operatore del runner le consegna direttamente, e le chiavi pubblicate dal deployment per le dichiarazioni del workspace, salvate da /api/workspace-statement-key.

Una volta che avete l'id della vostra parte affidataria (nella vostra pagina), aggiungete --relying-party RP_ID a ogni controllo successivo: un record che appartiene a un'altra parte affidataria, o al fornitore stesso, allora fallisce.

2. Fissa la valutazione. Nella sua pagina incolla evaluation.digest, evaluation.policy_digest e l'id dell'esecuzione decisa del record. Il digest della valutazione vincola la suite (ogni caso e il suo contenuto), i valutatori per contenuto, le specifiche delle metriche e la policy, quindi una suite ridotta o una policy più permissiva producono un altro digest. La policy deve essere una che il workspace ha verificato. L'esecuzione è la baseline rispetto a cui è decisa ogni regola di confronto, mostrata nella sua pagina, quindi non potete sceglierla con l'ordine in cui fate push. Un pin non viene mai sostituito: se ne aggiunge uno nuovo e vale il più recente.

3. Riconosce le chiavi del vostro runner. La sua pagina elenca ogni registrazione e revoca di una chiave di runner del progetto, così come è avvenuta, da un registro che nessuno può modificare. Una chiave conta per il suo pin solo dopo che ne ha riconosciuto la registrazione, quindi una chiave che registrate in seguito non decide nulla per lei finché non ne ha confrontato la chiave pubblica con quella che le ha dato il vostro operatore. Un'esecuzione sui worker gestiti di Oloproof non richiede riconoscimento: quella chiave non la registrate né la ruotate voi.

4. Scarica ogni record. La pagina elenca ogni versione del sistema decisa rispetto al suo pin, con lo stato di ogni regola e un link Download per il suo record. La parte affidataria scarica i record da sé, così non dipende da quelli che scegliete di inviarle.

Come viene decisa ogni versione

Il worker prende l'esecuzione fissata come baseline, una volta che è un'esecuzione verificata firmata da una chiave riconosciuta, e decide ogni versione del sistema sul suo primo avvio di quella valutazione, qualunque chiave l'abbia firmato e qualunque sia stato il suo esito. Una prima esecuzione fallita non può essere sostituita da una ripetizione più fortunata, e una versione avviata per la prima volta con una chiave mai riconosciuta resta trattenuta. Le regole sono decise dallo stesso codice del vostro gate, con esecuzione verificata.

Una decisione non sopravvive a ciò su cui si basa. Se la chiave della baseline viene revocata come compromessa, o la parte affidataria fissa di nuovo, ogni gate che il pin in vigore non decide più viene trattenuto (MANUAL_REVIEW) con il motivo. Una chiave conta solo con la chiave pubblica che ha riconosciuto, e un'esecuzione sui worker gestiti di Oloproof solo con la chiave propria del deployment.

Che cosa aggiunge il suo record

Un record esportato per una parte affidataria contiene, nella dichiarazione firmata del workspace:

• la parte affidataria a cui è destinato, e il suo pin come requisito;
• ogni avvio della versione sulla valutazione, ciascuno con la richiesta firmata del runner stesso, che record verify controlla rispetto alle chiavi fornite;
• il registro di ogni chiave che ha firmato un avvio o un'esecuzione della versione: la sua chiave pubblica, la registrazione, il riconoscimento ed eventuale revoca.

record verify fa fallire il record se un avvio firmato non regge o indica un'altra esecuzione, versione, suite, workspace o progetto, se la chiave pubblica di una chiave registrata non è quella fornita, se un gate superato si basa su una chiave non riconosciuta o registrata come compromessa, o, con --relying-party, se il record non è suo o se la sua dichiarazione non è firmata da una chiave per le dichiarazioni del workspace da lei fornita. Senza --relying-party, una dichiarazione non firmata risulta non verificata (not checked), mai verificata. I suoi codici di uscita non cambiano: 0 quando ogni controllo che si è potuto fare è passato, 5 quando uno è fallito, 2 quando una chiave o un file non si possono leggere.

Che cosa non può dirvi

• Che l'account che ha fissato il pin e riconosciuto le chiavi appartenga alla parte affidataria: l'email è mostrata, non dimostrata.
• Che il runner abbia eseguito solo codice controllato dal suo operatore, o che la versione valutata sia quella in produzione.
• Che la valutazione sia quella giusta: la scelta della suite resta del fornitore, a meno che la parte affidataria fornisca la suite o fissi una valutazione del traffico tratta dalla produzione.
• Qualunque cosa detta dopo l'esportazione: un record è la parola del workspace al momento dell'esportazione; in caso di dubbio scaricatene uno nuovo.
• Nulla dopo che l'operatore pone fine al rapporto. Voi non potete porvi fine: un progetto, o il vostro account come ultimo Owner del suo workspace, non può essere eliminato mentre è collegata una parte affidataria. Tuttavia, scaricate ogni record appena viene deciso.
• Un intervallo PPI: le etichette dietro un campione umano non sono nel record.