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
| Mutation | Erwartetes Ergebnis |
|---|---|
| Geänderte payload | Reject: payload hash passt nicht mehr zur event commitment. |
| Geänderte sequence number | Reject: stream ordering und head hash brechen. |
| Entferntes event | Reject: window inclusion oder stream range ist unvollständig. |
| Eingefügtes event | Reject: sequence, previous hash oder window commitment ändert sich. |
| Stale checkpoint | Reject: checkpoint passt nicht zur erwarteten stream progression. |
| Falsche witness signature | Reject: statement signature oder key epoch ist ungültig. |
| Falscher anchor | Reject: anchor commitment bindet die included epoch nicht. |
| Konfliktierende checkpoint heads | Reject 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
