Verification Model

Verification Does Not Require NexArt

A Certified Execution Record (CER) is a self-contained cryptographic artifact. Verification is a pure function of the bundle and the signing node's published public keys. NexArt's hosted services, runtime, and account system are not part of the trust path. The SDK is an optional convenience; any party with the bundle, the node key set, SHA-256, and Ed25519 can produce the same PASS/FAIL/SKIPPED outcome.

Two Independent Properties: Integrity and Authenticity

NexArt verification reports two distinct cryptographic properties. They are evaluated independently and MUST NOT be conflated.

• Integrity — SHA-256 hash recomputation over the canonicalized whitelist projection of the bundle, compared with the declared certificateHash. Proves that the covered fields have not been modified. Requires no keys, no network, and no node.
• Authenticity — Ed25519 signature verification against the public key resolved from the receipt's kid. Proves that a specific node attested this specific certificateHash. Authenticity requires BOTH a valid signature AND the correct public key for that kid.

Unsigned bundles can still be verified (integrity only). A sealed bundle with no attestation is a valid CER and has a valid integrity proof; the signature layer correctly reports SKIPPED, not FAILED. The aggregate status: VERIFIED reported by the SDK is an additive classification over the applicable layers; integrity and signature MUST be evaluated as independent checks. The attestation node recomputes verification independently for every certified record. The SDK provides classification, not the primary verdict.

Four Verification Surfaces

The protocol defines four interchangeable verification surfaces. They MUST produce identical results for the same bundle.

1. CLI — nexart ai verify <bundle.json> from @nexart/cli@1.0.0. Runs offline; only fetches the node key set when the bundle declares an attestation.
2. SDK — verifyCer (Node) or verifyCerAsync (browser / Edge) from @nexart/ai-execution@1.0.0.
3. Public endpoint — verify.nexart.io and the JSON API at /v1/cer/public?certificate_hash=<certificateHash>. Convenience surface; not a trust anchor.
4. External implementation — any conformant verifier built directly against the AI CER Package Format using only SHA-256, Ed25519, and a canonicalizer matching the bundle's protocolVersion.

Independent Verification Requirements

To verify any CER end-to-end, an implementer needs exactly:

• The CER bundle.
• The signing node's public key for the receipt's kid (published at /.well-known/nexart-node.json).
• SHA-256.
• Ed25519.
• A canonicalizer matching the bundle's protocolVersion.

No NexArt account is required. No NexArt runtime is required. The SDK is optional. See External Verification for a from-scratch reference implementation.

protocolVersion → Canonicalization Profile

meta.attestation.protocolVersion declares which canonicalization profile MUST be used to recompute the certificateHash and reconstruct the envelope signing payload. Canonicalization is protocol-bound: there is no universal default.

protocolVersion = "1.2.0"   profile = "nexart-v1"   status = default (custom canonicalization)
protocolVersion = "1.3.0"   profile = "jcs-v1"      status = opt-in  (RFC 8785, standards-based)

Defaults and Opt-in

• 1.2.0 (nexart-v1) is the current default. If protocolVersion is omitted, null, or not set on the snapshot, the SDK, CLI, and node all treat the record as 1.2.0 for backward compatibility with pre-1.3.0 clients and historical records.
• 1.3.0 (jcs-v1) is opt-in. Producers select it via createSnapshot({ protocolVersion: "1.3.0" }) in the SDK or the CLI flag --protocol-version 1.3.0. It is standards-based (RFC 8785 / JCS) and intended for environments that require a published canonicalization specification.
• Both profiles are accepted indefinitely. Verifiers MUST support both to remain compliant. protocolVersion is part of the attestation projection signed by the verification envelope; it cannot be silently retargeted to a different profile.
• The node mirrors protocolVersion from the sealed snapshot into the receipt and the verification envelope attestation. A 1.3.0 record MUST carry "1.3.0" in all three signed surfaces (snapshot, receipt, envelope). If the full bundle is not present at verification time, a verifier MAY still check the receipt signature but cannot recompute full bundle integrity.

Signature Model

Authenticity is asserted with an Ed25519 signature produced by the attestation node. The signed payload is NOT the raw bundle. It is a derived canonical payload (the SDK exposes this as deriveSignablePayload): the strict whitelist projection of the bundle and the attestation projection of the receipt, canonicalized per the bundle's protocolVersion.

Authenticity therefore requires both:

• A valid Ed25519 signature over the canonical signed payload.
• The correct public key — resolved from the node key set by the receipt's kid. An unresolvable kid MUST fail closed.

Fail-closed Behavior

Verification MUST fail closed. Any condition where a verifier cannot determine the correct rule to apply is reported as FAILED, never as PASS. SKIPPED is reserved for layers that are not applicable to the bundle as received (for example, an unsigned sealed bundle has no signature layer to run).

• Unknown protocolVersion → FAILED.
• Unknown bundleType → FAILED.
• Receipt kid not present in the node key set → FAILED (signature layer).
• Envelope present but a required projection field is missing or cannot be canonicalized → FAILED (envelope layer).
• Envelope absent → SKIPPED. Not a failure; the bundle does not carry that proof.

Trust Boundaries

NexArt proves a narrow, precisely-defined set of properties. Anything not listed below is out of scope and MUST NOT be inferred from a PASS result.

NexArt proves:

• Integrity of the covered whitelist fields (SHA-256 recomputation).
• Authenticity of the attestation, if a valid signature is present (Ed25519 against the node's published key).

NexArt does NOT prove:

• Independent time of existence. attestedAt is a node-issued timestamp bound to the certificateHash by the receipt signature. It provides an ordering guarantee relative to other records signed by the same node; it is NOT independent proof of existence at that wall-clock time. An external TSA (e.g. RFC 3161 via DigiCert) MAY be integrated alongside the receipt without modifying existing records.
• Completeness of execution. Verification does not prove that the bundle represents every step of a larger workflow. Capture coverage is an integration concern.
• Public log inclusion. The current attestation log is node-internal. There is no public Merkle tree, no external witness, and no transparency-log inclusion proof at this protocol version.
• Semantic correctness. NexArt proves the bundle was produced as recorded. It does not assert that the model output was correct, appropriate, or compliant.
• Deterministic replay. Recomputing the same model output from the same inputs only applies in controlled environments (fixed model version, seed, temperature 0, deterministic decoding).

See Also

• External Verification Guide — step-by-step verification using only public primitives.
• AI CER Package Format — normative specification.
• AI CER Verification Layers — per-layer detail.