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
| Mutation | Ré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 checkpoint | Reject: le checkpoint ne correspond pas à la stream progression attendue. |
| Wrong witness signature | Reject: statement signature ou key epoch invalide. |
| Wrong anchor | Reject: anchor commitment ne lie pas l'included epoch. |
| Checkpoint heads conflictuels | Reject 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
