Threshold-signature verification

For a standalone signed attestation, use:

witness --gateway http://localhost:8080 verify signed-attestation.json
witness --gateway http://localhost:8080 verify signed-attestation.json \
  --output json

The file must be a SignedAttestation, not the surrounding AttestationJobResponse. For a saved job, extract the signed object only:

jq '.signed_attestation' job.json > signed-attestation.json

The command fetches /v1/network from the selected gateway and verifies locally. It has no --network-config option; use verify-proof with --bundle and --network-config for an explicitly offline workflow. When --output json is used, cryptographic failure is reported as "valid": false while the command exits successfully. Scripts must inspect the JSON valid field rather than relying only on the exit status.

Signature shapes

An Ed25519 network uses:

{"signatures":[{"witness_id":"w1","signature":"<hex>"}]}

A BLS network uses:

{"signature":"<hex>","signers":["w1","w2"]}

The shape must match signature_scheme in the verification configuration. Signatures, public keys, and hashes are lowercase hex on the documented wire format. The verifier rejects ambiguous signature objects, duplicate signers, unknown witnesses, malformed keys or signatures, network-ID mismatches, and fewer than the configured threshold of valid signatures. For BLS, the threshold is a count of distinct listed signer IDs whose configured public keys are used in the aggregate check; current verification does not check PoP. This requires trusted membership registration with authenticated witness/key bindings and PoP. Without that assumption, the listed distinct IDs do not by themselves prove that distinct witnesses participated.

VALID means the configured public keys verify the signed attestation and the threshold is met. In BLS mode, that result has the trusted membership registration/PoP assumption above. It does not authenticate the configuration source, prove content ownership, or establish a globally agreed timestamp. The gateway's POST /v1/verify response is non-authoritative; local verification against a reviewed configuration is preferred.