Vertrauende Parteien

Eine vertrauende Partei ist Ihr Kunde oder jemand anderes, dem Sie Rechenschaft schulden, und misst jede Version Ihres KI-Systems an einer Evaluation, die sie selbst festgelegt hat. Der Workspace entscheidet jede Version gegen ihre Festlegung neben Ihrem eigenen Gate, und sie holt sich einen Entscheidungsnachweis jeder Version und prüft ihn auf ihrem eigenen Rechner. Sie sieht nie Ihre Fälle, Labels oder Traces, und nichts, was Sie an Ihrer eigenen Anforderung ändern, ändert ihre Festlegung.

Ein Nachweis ist Evidenz, die eine zweite Partei prüfen kann, keine Zertifizierung.

Eine vertrauende Partei einladen

Öffnen Sie in einem gehosteten Projekt Relying parties (in der Gruppe Assurance der Befehlspalette oder über Governance). Nur ein Owner kann einladen: Nennen Sie die Organisation und senden Sie dann den angezeigten Link einmal selbst. Er gilt sieben Tage.

Die vertrauende Partei öffnet den Link, angemeldet mit einem Konto ihrer eigenen Organisation. Ein Konto, das Mitglied Ihres Workspace ist, kann nicht annehmen, und ein Konto, das Ihrem Workspace später beitritt, verliert die Seiten der vertrauenden Partei. Beide Seiten sehen die E-Mail des Kontos, das angenommen hat: Prüfen Sie, dass es das erwartete ist.

Was die vertrauende Partei tut

1. Einen gesendeten Nachweis prüfen. Exportieren Sie einen von der Seite eines gesteuerten Laufs (Download the decision record) und senden Sie ihn. Sie führt aus:

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

mit dem öffentlichen Schlüssel Ihres Runners, den ihr der Betreiber Ihres Runners direkt gibt, und den veröffentlichten Workspace-Statement-Schlüsseln des Deployments, gespeichert von /api/workspace-statement-key.

Sobald Sie die ID Ihrer vertrauenden Partei haben (auf Ihrer Seite), fügen Sie jeder späteren Prüfung --relying-party RP_ID hinzu: Ein Nachweis, der einer anderen vertrauenden Partei oder dem Anbieter selbst gehört, scheitert dann.

2. Die Evaluation festlegen. Auf ihrer Seite fügt sie evaluation.digest, evaluation.policy_digest und die ID des entschiedenen Laufs des Nachweises ein. Der Evaluations-Digest bindet die Suite (jeden Fall und seinen Inhalt), die Evaluatoren nach Inhalt, die Metrikspezifikationen und die Policy, sodass eine gekürzte Suite oder eine laxere Policy einen anderen Digest ergibt. Die Policy muss eine sein, die der Workspace geprüft hat. Der Lauf ist die Baseline, gegen die jede Vergleichsregel entschieden wird, angezeigt auf ihrer Seite, sodass Sie ihn nicht durch die Reihenfolge Ihrer Pushes wählen können. Eine Festlegung wird nie ersetzt: Eine neue wird hinzugefügt, und die neueste gilt.

3. Ihre Runner-Schlüssel bestätigen. Ihre Seite listet jede Registrierung und jeden Widerruf eines Runner-Schlüssels des Projekts so auf, wie er geschah, aus einem Protokoll, das niemand bearbeiten kann. Ein Schlüssel zählt für ihre Festlegung erst, wenn sie seine Registrierung bestätigt, sodass ein später registrierter Schlüssel für sie nichts entscheidet, bis sie seinen öffentlichen Schlüssel mit dem verglichen hat, den Ihr Betreiber ihr gab. Ein Lauf auf den verwalteten Workern von Oloproof braucht keine Bestätigung: Diesen Schlüssel registrieren und rotieren Sie nicht.

4. Jeden Nachweis holen. Die Seite listet jede gegen ihre Festlegung entschiedene Systemversion mit dem Zustand jeder Regel und einem Download-Link für ihren Nachweis. Sie holt die Nachweise selbst und hängt daher nicht von denen ab, die Sie zu senden wählen.

Wie jede Version entschieden wird

Der Worker nimmt den festgelegten Lauf als Baseline, sobald er verifizierte Ausführung ist, signiert mit einem von ihr bestätigten Schlüssel, und entscheidet jede Systemversion an ihrem frühesten Start dieser Evaluation, gleich welcher Schlüssel ihn signierte und was aus ihm wurde. Ein gescheiterter erster Lauf kann nicht durch eine glücklichere Wiederholung ersetzt werden, und eine Version, die zuerst unter einem nie bestätigten Schlüssel gestartet wurde, bleibt zurückgehalten. Die Regeln werden mit demselben Code wie Ihr eigenes Gate entschieden, bei verifizierter Ausführung.

Eine Entscheidung überdauert nicht, worauf sie beruht. Wird der Schlüssel der Baseline als kompromittiert widerrufen oder legt sie erneut fest, wird jedes Gate, das die geltende Festlegung nicht mehr entscheidet, mit Begründung zurückgehalten (MANUAL_REVIEW). Ein Schlüssel zählt nur mit dem öffentlichen Schlüssel, den sie bestätigt hat, und ein Lauf auf den verwalteten Workern von Oloproof nur unter dem eigenen Schlüssel des Deployments.

Was ihr Nachweis hinzufügt

Ein für eine vertrauende Partei exportierter Nachweis enthält im signierten Statement des Workspace:

• die vertrauende Partei, für die er bestimmt ist, und ihre Festlegung als Anforderung;
• jeden Start der Version auf der Evaluation, jeweils mit der eigenen signierten Anfrage des Runners, die record verify gegen die von ihr angegebenen Schlüssel prüft;
• das Schlüsselprotokoll jedes Schlüssels, der einen Start oder einen Lauf der Version signierte: sein öffentlicher Schlüssel, seine Registrierung, Bestätigung und ein etwaiger Widerruf.

record verify lässt den Nachweis scheitern, wenn ein signierter Start nicht standhält oder einen anderen Lauf, eine andere Version, Suite, einen anderen Workspace oder ein anderes Projekt nennt, wenn der öffentliche Schlüssel eines protokollierten Schlüssels nicht der von ihr angegebene ist, wenn ein bestehendes Gate auf einem Schlüssel beruht, den sie nicht bestätigt hat oder der als kompromittiert protokolliert ist, oder, mit --relying-party, wenn der Nachweis nicht ihrer ist oder sein Statement nicht mit einem von ihr angegebenen Workspace-Statement-Schlüssel signiert ist. Ohne --relying-party liest sich ein nicht signiertes Statement als nicht geprüft, nie als verifiziert. Seine Exit-Codes sind unverändert: 0, wenn jede mögliche Prüfung bestanden wurde, 5, wenn eine scheiterte, 2, wenn ein Schlüssel oder eine Datei nicht gelesen werden kann.

Was er Ihnen nicht sagen kann

• Dass das Konto, das festgelegt und bestätigt hat, zur vertrauenden Partei gehört: Die E-Mail wird angezeigt, nicht bewiesen.
• Dass der Runner nur Code ausführte, den sein Betreiber kontrolliert, oder dass die evaluierte Version die ist, die in Produktion läuft.
• Dass die Evaluation die richtige ist: Die Wahl der Suite liegt weiterhin beim Anbieter, es sei denn, die vertrauende Partei liefert die Suite oder legt eine aus der Produktion gezogene Traffic-Evaluation fest.
• Alles, was nach dem Export gesagt wurde: Ein Nachweis ist das Wort des Workspace zum Zeitpunkt seines Exports; holen Sie im Zweifel einen frischen.
• Nichts, nachdem der Betreiber die Beziehung beendet hat. Sie können sie nicht beenden: Ein Projekt, oder Ihr Konto als letzter Owner seines Workspace, kann nicht gelöscht werden, solange eine vertrauende Partei angebunden ist. Holen Sie dennoch jeden Nachweis, sobald er entschieden ist.
• Ein PPI-Intervall: Die Labels hinter einer menschlichen Stichprobe sind nicht im Nachweis.