Vertrouwende partijen

Een vertrouwende partij is je klant, of iemand anders aan wie je verantwoording aflegt, die elke versie van je AI-systeem toetst aan een evaluatie die ze zelf heeft vastgezet. De workspace beslist elke versie tegen haar pin naast je eigen gate, en zij haalt van elke versie een beslissingsrecord op en controleert die op haar eigen machine. Ze ziet nooit je cases, labels of traces, en niets wat je aan je eigen eis verandert, wijzigt haar pin.

Een record is bewijs dat een tweede partij kan controleren, geen certificering.

Een vertrouwende partij uitnodigen

Open in een gehost project Relying parties (in de groep Assurance van het opdrachtenpalet, of vanuit Governance). Alleen een Owner kan uitnodigen: geef de naam van de organisatie op en stuur dan zelf, één keer, de link die je te zien krijgt. Hij werkt zeven dagen.

De vertrouwende partij opent de link terwijl ze is aangemeld met een account van haar eigen organisatie. Een account dat lid is van je workspace kan niet accepteren, en een account dat later lid wordt van je workspace verliest de pagina's van de vertrouwende partij. Beide kanten zien het e-mailadres van het account dat heeft geaccepteerd: controleer of het het verwachte is.

Wat de vertrouwende partij doet

1. Een record verifiëren dat je stuurde. Exporteer er een vanaf de pagina van een gereguleerde run (Download the decision record) en stuur het. Zij voert uit:

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

met de publieke sleutel van je runner, die de operator van je runner haar rechtstreeks geeft, en de gepubliceerde sleutels voor workspaceverklaringen van de deployment, opgeslagen van /api/workspace-statement-key.

Zodra je de id van je vertrouwende partij hebt (op je pagina), voeg je --relying-party RP_ID toe aan elke latere controle: een record van een andere vertrouwende partij, of van de aanbieder zelf, wordt dan afgekeurd.

2. De evaluatie vastzetten. Op haar pagina plakt ze de evaluation.digest, de evaluation.policy_digest en de id van de besliste run van het record. De evaluatiedigest bindt de suite (elke case en de inhoud ervan), de evaluators op inhoud, de metriekspecificaties en de policy, zodat een ingekorte suite of een soepelere policy een andere digest is. De policy moet er een zijn die de workspace heeft gecontroleerd. De run is de baseline waartegen elke vergelijkingsregel wordt beslist, getoond op haar pagina, dus je kunt hem niet kiezen via de volgorde waarin je pusht. Een pin wordt nooit vervangen: er wordt een nieuwe toegevoegd en de laatste geldt.

3. Je runnersleutels erkennen. Haar pagina toont elke registratie en intrekking van een runnersleutel van het project, zoals die plaatsvond, uit een log dat niemand kan bewerken. Een sleutel telt pas voor haar pin zodra ze de registratie ervan erkent, dus een sleutel die je later registreert beslist niets voor haar tot ze de publieke sleutel heeft vergeleken met die van je operator. Een run op de beheerde workers van Oloproof heeft geen erkenning nodig: die sleutel registreer of roteer je niet.

4. Elk record ophalen. De pagina toont elke systeemversie die tegen haar pin is beslist, met de status van elke regel en een Download-link voor het record. Ze haalt de records zelf op, zodat ze niet afhangt van de records die jij kiest te sturen.

Hoe elke versie wordt beslist

De worker neemt de vastgezette run als baseline, zodra die geverifieerde uitvoering is ondertekend door een sleutel die ze heeft erkend, en beslist elke systeemversie op haar vroegste start van die evaluatie, welke sleutel die ook ondertekende en wat er ook van werd. Een mislukte eerste run kan niet worden vervangen door een gelukkiger herhaling, en een versie die voor het eerst is gestart onder een sleutel die ze nooit erkende, blijft achtergehouden. De regels worden beslist door dezelfde code als je eigen gate, bij geverifieerde uitvoering.

Een beslissing overleeft niet waar ze op rust. Als de sleutel van de baseline wordt ingetrokken als gecompromitteerd, of ze opnieuw vastzet, wordt elke gate die de geldende pin niet meer beslist achtergehouden (MANUAL_REVIEW) met de reden. Een sleutel telt alleen met de publieke sleutel die ze erkende, en een run op de beheerde workers van Oloproof alleen onder de eigen sleutel van de deployment.

Wat haar record toevoegt

Een record dat voor een vertrouwende partij is geëxporteerd, bevat in de ondertekende verklaring van de workspace:

• de vertrouwende partij voor wie het is, en haar pin als de eis;
• elke start van de versie op de evaluatie, elk met het eigen ondertekende verzoek van de runner, dat record verify controleert tegen de sleutels die ze opgeeft;
• het sleutellog van elke sleutel die een start of een run van de versie ondertekende: de publieke sleutel, registratie, erkenning en eventuele intrekking.

record verify keurt het record af als een ondertekende start niet klopt of een andere run, versie, suite, workspace of project noemt, als de publieke sleutel van een gelogde sleutel niet die is die ze opgaf, als een geslaagde gate rust op een sleutel die ze niet erkende of een die als gecompromitteerd is gelogd, of, met --relying-party, als het record niet van haar is of de verklaring ervan niet is ondertekend met een sleutel voor workspaceverklaringen die ze opgaf. Zonder --relying-party leest een verklaring die niet is ondertekend not checked, nooit geverifieerd. De exitcodes zijn ongewijzigd: 0 als elke controle die kon worden gedaan slaagde, 5 als er een mislukte, 2 als een sleutel of bestand niet kan worden gelezen.

Wat het je niet kan vertellen

• Dat het account dat vastzette en erkende van de vertrouwende partij is: het e-mailadres wordt getoond, niet bewezen.
• Dat de runner alleen code uitvoerde die de operator beheert, of dat de geëvalueerde versie de versie is die in productie draait.
• Dat de evaluatie de juiste is: de keuze van de suite blijft bij de aanbieder, tenzij de vertrouwende partij de suite levert of een trafficevaluatie uit productie vastzet.
• Alles wat na de export is gezegd: een record is het woord van de workspace op het moment van export; haal bij twijfel een nieuw op.
• Niets nadat de operator de relatie beëindigt. Jij kunt die niet beëindigen: een project, of je account als laatste Owner van de workspace, kan niet worden verwijderd zolang er een vertrouwende partij aan gekoppeld is. Haal toch elk record op zodra het is beslist.
• Een PPI-interval: de labels achter een menselijke steekproef staan niet in het record.