Attesto

Verifier System

Offline Verifier und Bundles

Ein Verifier Bundle ist ein portables Evidence Pack. Es enthält die Proof Objects, die nötig sind, um einen Stream-Bereich ohne Zugriff auf das Attesto Backend zu verifizieren, plus ein Manifest, das die enthaltenen Dateien bindet.

Offline verifier

Der Offline Verifier prüft lokal. Online Anchor Re-checks sind optional und explizit, sodass ein Reviewer den Kern der Bundle auch bei eingeschränktem Netzwerkzugang verifizieren kann.

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

Window-, Checkpoint-, Anchor-, IVC- und vollständige Bundle-Verifikation kann aus derselben CLI auch über die Online Verifier API laufen:

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

Eine portable receipt ist ein self-contained *.attesto.json Export um eine signed receipt. Ein Empfänger kann die Receipt mit Python SDK, TypeScript SDK, Go SDK, CLI oder browser verifier verifizieren, ohne das Attesto Backend aufzurufen. Ein gepinnter public key ist der vertrauenswürdige Verifikationspfad; ein embedded key ist nur ein Transport-Hinweis und darf die trust policy des Verifiers nicht ersetzen.

Portable receipts sind nützlich für Email Attachments, Support Tickets, Data-room Uploads und Regulator Workflows, wenn noch kein vollständiges Bundle nötig ist. Sie fail-closed weiterhin bei geänderten payload commitments, geänderten event hashes, falschen signatures oder mismatched stream linkage.

Browser WASM verifier

Der verifier-only WebAssembly Build exponiert receipt, inclusion, checkpoint-root und completeness verification für eine Browser Page. Es gibt keinen client creation flow, kein API key handling und keine background network requirement. Die JavaScript Shell übergibt JSON an den WASM verifier und erhält einen JSON Report zurück, sodass Browser Verification eine dünne lokale Hülle um dieselben Go verifier semantics bleibt, die auch die CLI verwendet.

Verify portal

Das Browser Verify Portal unter /verify.html ist für schnelle Receipt Verification durch externe Empfänger, Auditoren oder Support Teams gedacht. Droppe ein Receipt JSON oder eine portable receipt file in die Seite, füge den gepinnten Witness Public Key ein und verifiziere lokal. Die Seite lädt den WASM verifier aus /assets/attesto-verify.wasm, lädt aber weder Receipt, Payload, Public Key noch verifier result zu Attesto hoch.

Für regulierte Workflows den Witness Public Key out-of-band pinnen und den WASM Asset Hash mit dem Release Manifest vergleichen, bevor ein Browserresultat als vertrauenswürdig gilt. Verwenden Sie POST /v1/public/verify für Receipt Verification in einem Serverworkflow und POST /v2/verify für Proofstream Object und Bundle Verification. Browser Verification, CLI Verification, SDK Verification und API Verification müssen dieselbe canonical JSON- und Signature-Semantik verwenden.

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 sind ebenfalls Lifecycle Evidence. Wenn Attesto ein Package baut, schreibt es attesto.truth-package.manifest.json in die ZIP, hasht die finalisierte ZIP und zeichnet ein truth_package.generated Proofstream Event auf. Jeder relevante Dashboard- oder Auditor-Zugriff erzeugt ein truth_package.accessed Event mit eindeutiger access id, timestamp, package hash, manifest hash, actor type, access method und gehashter network metadata. Wenn ein User, Auditor, SDK oder CLI einen erfolgreichen cryptographic verifier report an Attesto zurücksendet, validiert das Backend den Report gegen die gespeicherten Package- und Manifest-Hashes und zeichnet ein truth_package.verified Event auf.

Das beweist Package Integrity und Lifecycle Provenance. Es beweist keine rechtliche Compliance für sich allein und beweist nicht, dass ein Empfänger die Inhalte gelesen oder akzeptiert hat. Download/access beweist, dass das Package ausgeliefert wurde; truth_package.verified beweist, dass ein Verifier die ZIP- und Artifact-Hashes tatsächlich neu berechnet hat.

Der finale ZIP-Hash wird bewusst nach der ZIP-Finalisierung und außerhalb der ZIP selbst aufgezeichnet. Eine Receipt über den finalen ZIP-Hash in dieselbe ZIP einzubetten würde eine zirkuläre Self-reference erzeugen: Die Änderung der ZIP zum Hinzufügen der Receipt würde den Hash ändern, den die Receipt signiert.

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

Der Befehl liest die ZIP, berechnet die vollständige Package SHA-256 neu, verlangt attesto.truth-package.manifest.json, verifiziert jeden im Manifest aufgeführten Artifact Hash und verwirft verbotene Archive Paths wie absolute paths, parent traversal, macOS metadata, workstation paths und lokale filesystem references. Eine geänderte events.csv, proofs.json oder manifest.json muss die Verification fehlschlagen lassen, bevor das Package als vertrauenswürdige Evidence behandelt werden kann.

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

MutationErwartetes Ergebnis
Geänderte payloadReject: payload hash passt nicht mehr zur event commitment.
Geänderte sequence numberReject: stream ordering und head hash brechen.
Entferntes eventReject: window inclusion oder stream range ist unvollständig.
Eingefügtes eventReject: sequence, previous hash oder window commitment ändert sich.
Stale checkpointReject: checkpoint passt nicht zur erwarteten stream progression.
Falsche witness signatureReject: statement signature oder key epoch ist ungültig.
Falscher anchorReject: anchor commitment bindet die included epoch nicht.
Konfliktierende checkpoint headsReject und fork evidence melden.

Public verification API

Nutze POST /v2/verify, wenn ein Online-Service dieselben verifier semantics wie die CLI benötigt.

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