Przejdź do głównej treści
Raport zgodności jest użyteczny dla audytora tylko wtedy, gdy może zaufać, że nie został edytowany od czasu wygenerowania. Każdy raport, który produkuje OrcaRouter, niesie dwie rzeczy, które umożliwiają tę kontrolę bez żadnego dostępu do konta: skrót treści SHA-256 kanonicznych dowodów oraz podpis Ed25519 nad tym skrótem. Ta strona pokazuje, jak zweryfikować raport zgodności — pobierz klucz publiczny, potwierdź skrót i sprawdź podpis — używając wyłącznie publicznych endpointów. Przypadek użycia jest konkretny: wręczasz audytorowi podpisany raport (lub link do portalu udostępniania), a oni muszą udowodnić, że jest autentyczny i niezmanipulowany, zanim na nim polegną. Nigdy nie dotykają twojej przestrzeni roboczej, twojego klucza ani konsoli.

​
1. Co podróżuje z raportem

Trzy wartości czynią raport samo-weryfikującym. Pojawiają się na artefakcie raportu oraz w publicznych metadanych portalu udostępniania dla linku.
Skrót SHA-256 w małych literach hex kanonicznego JSON dowodów raportu. Bajty są deterministyczne dla danego raportu, więc każdy z tymi samymi dowodami przelicza identyczny skrót. Każda edycja dowodów zmienia tę wartość.
Podpis Ed25519 w base64 obliczony nad hex content_hash. Dowodzi, że skrót został podpisany kluczem podpisującym OrcaRouter i nie został sfałszowany.
Krótki, stabilny identyfikator aktywnego klucza publicznego (na przykład orca- z następującym fragmentem hex). Weryfikator używa go do potwierdzenia, że raport został podpisany aktualnie opublikowanym kluczem — raport podpisany nieznanym id klucza fail closed.
Podpis pokrywa skrót treści, nie wyrenderowane bajty PDF, CSV lub JSON bezpośrednio. Te same dowody renderują się do wszystkich trzech formatów z jednego skrótu, więc gwarancja integralności dotyczy leżących u podstaw dowodów — każdy eksport danego raportu współdzieli jeden content_hash, signature i sig_key_id.

​
2. Pobierz klucz publiczny

Klucz publiczny podpisujący jest publikowany na otwartym endpoincie — bez auth, bez kontekstu przestrzeni roboczej. Audytor wywołuje go bezpośrednio. 
curl https://api.orcarouter.ai/api/public/compliance/pubkey

{
  "success": true,
  "message": "",
  "data": {
    "algo": "ed25519",
    "key_id": "orca-1a2b3c4d5e6f",
    "public_key": "base64-encoded-ed25519-public-key"
  }
}
public_key to zakodowany base64 32-bajtowy klucz publiczny Ed25519. key_id tutaj musi pasować do sig_key_id na raporcie — jeśli nie pasuje, raport został podpisany innym (prawdopodobnie zrotowanym lub starszym) kluczem i nie zweryfikuje się wobec tego opublikowanego klucza.

​
3. Zweryfikuj podpis

Możesz zweryfikować podpis na dwa sposoby. Albo poproś OrcaRouter o sprawdzenie krotki za ciebie, albo zweryfikuj całkowicie offline opublikowanym kluczem publicznym.

​
Hostowany endpoint weryfikacji

Wyślij POST z trzema wartościami z raportu do otwartego endpointu weryfikacji. Jest publiczny — audytor wywołuje go bez poświadczeń. 
curl -X POST https://api.orcarouter.ai/api/public/compliance/verify \
  -H "Content-Type: application/json" \
  -d '{
    "content_hash": "9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08",
    "signature": "base64-ed25519-signature-from-the-report",
    "sig_key_id": "orca-1a2b3c4d5e6f"
  }'

{
  "success": true,
  "message": "",
  "data": {
    "valid": true,
    "key_id": "orca-1a2b3c4d5e6f"
  }
}
valid: true oznacza, że podpis sprawdza się wobec aktywnego klucza dla tego id klucza. valid: false oznacza, że albo podpis nie pasuje do skrótu, skrót jest pusty, albo sig_key_id nie pasuje do aktualnie opublikowanego klucza.
Endpoint weryfikacji odsyła z powrotem aktywne key_id. Porównaj je z sig_key_id, które przesłałeś: jeśli się różnią, raport został podpisany kluczem, który nie jest już aktywnym, dlatego nie udało się go zweryfikować.

​
Zweryfikuj offline kluczem publicznym

Sceptyczny audytor w ogóle nie musi ufać endpointowi weryfikacji. Ponieważ algorytm to standardowy Ed25519 nad hex skrótem treści, podpis jest sprawdzalny dowolną biblioteką kryptograficzną: 
import base64
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey

# public_key from GET /api/public/compliance/pubkey
pub = Ed25519PublicKey.from_public_bytes(base64.b64decode(PUBLIC_KEY_B64))

# content_hash + signature from the report
message = CONTENT_HASH.encode()            # the hex hash string, as bytes
signature = base64.b64decode(SIGNATURE_B64)

pub.verify(signature, message)             # raises if invalid; returns None if valid
Podpisana wiadomość to sam ciąg hex skrótu, zakodowany jako bajty ASCII — nie surowe 32 bajty, na które skrót się dekoduje. Przekaż wartość content_hash jak jest, przed weryfikacją podpisu, w przeciwnym razie kontrola zawiedzie na poprawnym raporcie.

​
4. Co pokrywa podpis

Podpis dowodzi, że content_hash raportu został podpisany przez OrcaRouter, a skrót dowodzi, że dowody są nieedytowane. Jedna subtelność: skrót jest obliczany nad formą kanoniczną dowodów, które brama buduje — nie nad surowymi bajtami pliku JSON lub PDF. Więc samodzielne ponowne haszowanie pobranego artefaktu nie odtworzy content_hash. Użyj endpointu weryfikacji (§2/§3), który przelicza ponownie skrót kanoniczny i sprawdza za ciebie podpis Ed25519:
KontrolaZnaczenie
signature_valid: truecontent_hash został podpisany kluczem OrcaRouter — dowody są autentyczne i nieedytowane.
Id klucza pasujeRaport sig_key_id == opublikowane id klucza → podpisany aktywnym kluczem.
Obie przechodzące oznaczają, że raport jest autentyczny i niezmanipulowany. Nieudany podpis oznacza, że skrót, dowody lub id klucza nie należą do klucza podpisującego OrcaRouter.

​
5. Weryfikacja udostępnionego raportu

Gdy wysyłasz audytorowi link do portalu udostępniania zamiast pliku, metadane portalu już niosą content_hash, signature i sig_key_id, plus obliczoną przez serwer flagę signature_valid. Audytor może zaufać fladze oraz ponownie uruchomić powyższe kontrole wobec klucza publicznego niezależnie — portal udostępniania nie potrzebuje logowania, a ścieżka weryfikacji jest identyczna.
Udostępniony artefakt jest serwowany tylko dopóki jego stemplowany region wciąż pasuje do zadeklarowanego regionu rezydencji danych twojej przestrzeni roboczej. Jeśli region został zmieniony, pobrania są wstrzymywane, mimo że metadane podpisu pozostają weryfikowalne. To zgodne z projektem — zobacz Odczyty międzyregionalne.

​
6. Gdzie iść dalej

Podpisane raporty

Jak generowany jest podpisany raport, jakie dowody uchwytuje i jak wybić link udostępniania dla audytora.

Eksport dowodów

Pobierz dowody raportu jako PDF, CSV lub JSON do dokumentów roboczych twojego audytora.

Rezydencja danych

Jak stempel regionu na raporcie zarządza tym, gdzie jest przechowywany i serwowany.

Współdzielona odpowiedzialność

Co gwarantuje OrcaRouter na ścieżce bramy, a co pozostaje twoje.
Klucz podpisujący należy do OrcaRouter; weryfikacja należy do każdego. Ten podział to cały sens — audytor dowodzi, że raport jest autentyczny, nigdy nie potrzebując dostępu do przestrzeni roboczej, która go wyprodukowała.