Verifier System

Offline verifier i bundles

Verifier bundle to portable evidence pack. Zawiera proof objects potrzebne do weryfikacji zakresu stream bez dostępu do backendu Attesto oraz manifest, który wiąże dołączone pliki.

Offline verifier

Offline verifier sprawdza lokalnie. Online anchor re-checks są opcjonalne i jawne, więc reviewer może nadal zweryfikować core bundle przy ograniczonym dostępie do sieci.

attesto receipts verify \
  --file ./receipt.json \
  --public-key-hex "$ATTESTO_RECEIPT_SIGNER_PUBLIC_KEY_HEX"

attesto bundles offline-verify --file ./attesto-bundle.json
attesto verify file --file ./receipt.attesto.json \
  --public-key-hex "$ATTESTO_RECEIPT_SIGNER_PUBLIC_KEY_HEX"
attesto verify truth-package --file ./truth-package.zip

Weryfikację windows, checkpoints, anchors, IVC i pełnych bundles można też uruchomić przez online verifier API z tej samej CLI:

attesto windows verify --file ./window.json
attesto checkpoints verify --file ./checkpoint.json
attesto anchors verify --file ./anchor.json
attesto ivc epochs verify --file ./ivc-epoch.json
attesto bundles verify --file ./attesto-bundle.json

Portable receipts

Portable receipt to self-contained export *.attesto.json wokół jednego signed receipt. Odbiorca może zweryfikować receipt przez Python SDK, TypeScript SDK, Go SDK, CLI albo browser verifier bez wywoływania backendu Attesto. Przypięty public key jest zaufaną ścieżką weryfikacji; embedded key jest tylko transport hint i nie może zastąpić trust policy verifiera.

Portable receipts są przydatne dla email attachments, support tickets, data-room uploads i regulator workflows, gdy pełny bundle nie jest jeszcze potrzebny. Nadal fail-closed przy zmienionych payload commitments, zmienionych event hashes, błędnych signatures albo mismatched stream linkage.

Browser WASM verifier

Build WebAssembly verifier-only udostępnia receipt, inclusion, checkpoint-root i completeness verification dla browser page. Nie ma client creation flow, API key handling ani background network requirement. JavaScript shell przekazuje JSON do WASM verifier i otrzymuje JSON report, więc browser verification pozostaje cienką lokalną warstwą nad tymi samymi Go verifier semantics, których używa CLI.

Verify portal

Browser Verify portal pod /verify.html służy do szybkiej receipt verification przez zewnętrznego odbiorcę, audytora lub zespół supportu. Upuść receipt JSON albo portable receipt file na stronę, wklej przypięty witness public key i zweryfikuj lokalnie. Strona ładuje WASM verifier z /assets/attesto-verify.wasm, ale nie uploaduje receipt, payload, public key ani verifier result do Attesto.

Dla regulowanych workflow przypnij witness public key out-of-band i porównaj hash WASM asset z release manifestem, zanim oprzesz się na wyniku z przeglądarki. Użyj POST /v1/public/verify dla receipt verification w server workflow oraz POST /v2/verify dla Proofstream object i bundle verification. Browser verification, CLI verification, SDK verification i API verification muszą stosować tę samą semantykę canonical JSON i signature.

Bundle structure

{
  "manifest": {
    "bundle_id": "bundle_...",
    "protocol": "ATTESTO-PROOFSTREAM-001",
    "created_at": "2026-06-07T12:00:00Z",
    "stream_id": "str_...",
    "from_seq_no": 1,
    "to_seq_no": 250,
    "artifact_hashes": {
      "receipts.json": "sha256-hex",
      "windows.json": "sha256-hex",
      "checkpoints.json": "sha256-hex",
      "witnesses.json": "sha256-hex",
      "anchors.json": "sha256-hex"
    }
  }
}

Truth packages

Tenant export ZIPs są także lifecycle evidence. Gdy Attesto buduje package, zapisuje attesto.truth-package.manifest.json w ZIP, hashuje sfinalizowany ZIP i rejestruje Proofstream event truth_package.generated. Każdy znaczący dashboard lub auditor access rejestruje event truth_package.accessed z unique access id, timestamp, package hash, manifest hash, actor type, access method i hashowaną network metadata. Gdy user, auditor, SDK lub CLI przesyła do Attesto udany cryptographic verifier report, backend waliduje report względem zapisanych package i manifest hashes oraz rejestruje event truth_package.verified.

To dowodzi package integrity i lifecycle provenance. Nie dowodzi samoistnie legal compliance i nie dowodzi, że odbiorca przeczytał lub zaakceptował treść. Download/access dowodzi, że package został udostępniony; truth_package.verified dowodzi, że verifier rzeczywiście ponownie obliczył ZIP i artifact hashes.

Finalny ZIP hash jest celowo rejestrowany po finalizacji ZIP i poza samym ZIP. Umieszczenie receipt nad finalnym ZIP hash w tym samym ZIP stworzyłoby circular self-reference: zmiana ZIP w celu dodania receipt zmieniłaby hash, który receipt podpisuje.

attesto verify truth-package --file ./truth-package.zip

Komenda czyta ZIP, ponownie oblicza pełny package SHA-256, wymaga attesto.truth-package.manifest.json, weryfikuje każdy artifact hash wymieniony w manifest i odrzuca zabronione archive paths takie jak absolute paths, parent traversal, macOS metadata, workstation paths i local filesystem references. Zmieniony events.csv, proofs.json lub manifest.json musi oblać verification zanim package będzie można traktować jako wiarygodne evidence.

curl -X POST https://dashboard.attesto.eu/v1/exports/exp_.../truth-package/verify \
  -H "Authorization: Bearer $ATTESTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "verifierKind": "attesto-cli",
    "verifierVersion": "0.4.0",
    "accessId": "tpa_...",
    "verificationReport": {
      "ok": true,
      "packageSha256": "hex...",
      "manifestSha256": "hex...",
      "verifiedArtifacts": 4,
      "problems": []
    }
  }'

Verifier matrix

Public verification API

Użyj POST /v2/verify, gdy online service potrzebuje tych samych verifier semantics co CLI.

curl -X POST https://verify.attesto.eu/v2/verify \
  -H "Content-Type: application/json" \
  --data-binary @attesto-bundle.json