Attesto

Verifier System

Offline verifier et bundles

Un verifier bundle est un evidence pack portable. Il contient les proof objects nécessaires pour vérifier une plage de stream sans accès au backend Attesto, plus un manifest qui lie les fichiers inclus.

Offline verifier

L'offline verifier contrôle localement. Les online anchor re-checks sont optionnels et explicites, ce qui permet à un reviewer de vérifier le cœur du bundle même lorsque l'accès réseau est restreint.

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

La vérification des windows, checkpoints, anchors, IVC et bundles complets peut aussi passer par l'API verifier en ligne depuis la même 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

Un portable receipt est un export *.attesto.json self-contained autour d'un signed receipt. Un destinataire peut vérifier le receipt avec le Python SDK, TypeScript SDK, Go SDK, CLI ou browser verifier sans appeler le backend Attesto. Une public key épinglée est le chemin de vérification fiable; une embedded key n'est qu'un transport hint et ne doit pas remplacer la trust policy du verifier.

Les portable receipts sont utiles pour email attachments, support tickets, data-room uploads et regulator workflows lorsqu'un bundle complet n'est pas encore nécessaire. Ils fail-closed toujours sur payload commitments modifiés, event hashes modifiés, signatures incorrectes ou mismatched stream linkage.

Browser WASM verifier

Le build WebAssembly verifier-only expose receipt, inclusion, checkpoint-root et completeness verification à une browser page. Il n'a pas de client creation flow, pas d'API key handling et pas de background network requirement. Le shell JavaScript passe du JSON au WASM verifier et reçoit un JSON report, donc la browser verification reste un wrapper local mince autour des mêmes Go verifier semantics que la CLI.

Verify portal

Le Verify portal navigateur sur /verify.html sert à la vérification rapide d'un receipt par un destinataire externe, un auditeur ou une équipe support. Déposez un receipt JSON ou un fichier portable receipt dans la page, collez la witness public key épinglée et vérifiez localement. La page charge le WASM verifier depuis /assets/attesto-verify.wasm, mais n'upload pas le receipt, le payload, la public key ou le verifier result vers Attesto.

Pour les workflows réglementés, épinglez la witness public key out-of-band et comparez le hash de l'asset WASM avec le release manifest avant de vous appuyer sur un résultat navigateur. Utilisez POST /v1/public/verify pour la receipt verification dans un server workflow, et POST /v2/verify pour la verification des Proofstream objects et bundles. Browser verification, CLI verification, SDK verification et API verification doivent suivre les mêmes sémantiques canonical JSON et 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

Les ZIPs d'export tenant sont aussi de la lifecycle evidence. Lorsqu'Attesto construit un package, il écrit attesto.truth-package.manifest.json dans le ZIP, calcule le hash du ZIP finalisé et enregistre un event Proofstream truth_package.generated. Chaque accès significatif par dashboard ou auditor enregistre un event truth_package.accessed avec un access id unique, timestamp, package hash, manifest hash, actor type, access method et network metadata hashée. Lorsqu'un user, auditor, SDK ou CLI renvoie à Attesto un cryptographic verifier report réussi, le backend valide le report contre les package et manifest hashes stockés et enregistre un event truth_package.verified.

Cela prouve l'intégrité du package et la lifecycle provenance. Cela ne prouve pas la conformité juridique à lui seul et ne prouve pas qu'un destinataire a lu ou accepté les contenus. Download/access prouve que le package a été servi; truth_package.verified prouve qu'un verifier a réellement recalculé les hashes du ZIP et des artifacts.

Le hash final du ZIP est volontairement enregistré après la finalisation du ZIP et hors du ZIP lui-même. Inclure dans ce même ZIP une receipt sur le hash final créerait une self-reference circulaire: modifier le ZIP pour ajouter la receipt changerait le hash que la receipt signe.

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

La commande lit le ZIP, recalcule le package SHA-256 complet, exige attesto.truth-package.manifest.json, vérifie chaque artifact hash listé dans le manifest et rejette les archive paths interdits comme absolute paths, parent traversal, macOS metadata, workstation paths et local filesystem references. Un events.csv, proofs.json ou manifest.json modifié doit faire échouer la vérification avant que le package puisse être traité comme evidence fiable.

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

MutationRésultat attendu
Payload modifiéReject: le payload hash ne correspond plus à l'event commitment.
Sequence number modifiéReject: le stream ordering et le head hash se cassent.
Event suppriméReject: window inclusion ou stream range est incomplet.
Event inséréReject: sequence, previous hash ou window commitment change.
Stale checkpointReject: le checkpoint ne correspond pas à la stream progression attendue.
Wrong witness signatureReject: statement signature ou key epoch invalide.
Wrong anchorReject: anchor commitment ne lie pas l'included epoch.
Checkpoint heads conflictuelsReject et report de fork evidence.

Public verification API

Utilisez POST /v2/verify lorsqu'un service online veut les mêmes verifier semantics que la CLI.

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