---
title: "Verification Process"
description: "
"
url: https://instituteofprovenance.org/docs/verification-process
source: Institute of Provenance
---
# Verification Process

Verification of a XION artifact proceeds through four mandatory stages. All four must pass for the artifact to be considered valid. The stages are ordered by computational cost — cheap checks run first to fail fast.

## Stage 1: Signature Validity

**Question:** Is the Ed25519 signature mathematically valid against the BLAKE3 content hash?

**Procedure:**

1. Extract the trust block from the artifact
2. Identify the content (everything in the artifact excluding the trust block)
3. Canonicalize the content using the appropriate canonicalization rules for the content type
4. Compute the BLAKE3 hash of the canonicalized content
5. Compare the computed hash with `hash_blake3_hex` in the trust block — they MUST match
6. Extract the public key from the leaf certificate (first entry in `x509_chain_pem`)
7. Verify the Ed25519 signature (`sig_b64`) against the content hash using the extracted public key
8. Verify that `key_id` matches the derivation from the leaf certificate's public key

**Failure modes:**
- Content has been modified since signing (hash mismatch)
- Signature was produced with a different key (verification failure)
- Trust block has been tampered with (key_id mismatch)

## Stage 2: Chain Integrity

**Question:** Does the certificate chain trace from the leaf through intermediates to the Institute of Provenance Root CA?

**Procedure:**

1. Parse each certificate in `x509_chain_pem` (leaf first)
2. For each consecutive pair (certificate[i], certificate[i+1]):
   - Verify that certificate[i].issuer matches certificate[i+1].subject
   - Verify that certificate[i+1] signed certificate[i] (Ed25519 signature check)
3. For the last certificate in the chain (the intermediate closest to root):
   - Verify that it was signed by the known Root CA public key
4. Verify Basic Constraints:
   - Leaf certificate: CA:FALSE
   - Intermediate certificates: CA:TRUE with appropriate pathLenConstraint

**Failure modes:**
- Broken chain (issuer/subject mismatch)
- Invalid certificate signature (certificate was not signed by its claimed issuer)
- Chain does not terminate at the known Root CA
- Constraint violations (leaf claiming CA authority, intermediate exceeding path length)

## Stage 3: Revocation Status

**Question:** Has any certificate in the chain been revoked?

**Procedure:**

For each certificate in the chain, check revocation status against the appropriate Sparse Merkle Tree:

1. Obtain the current Proof record for the certificate's serial number from the relevant Orbital
2. If the proof is an **exclusion proof**: the certificate has NOT been revoked — verify the proof against the published tree root
3. If the proof is an **inclusion proof**: the certificate HAS been revoked — the artifact is invalid

Revocation checks are the only stage that may require network access (to fetch current Proof records). However:

- Proof records can be cached for the duration of an epoch
- A verifier that is offline can skip revocation checking if it accepts the risk of validating against a potentially-revoked certificate
- Short leaf certificate lifetimes mean that expired certificates are effectively self-revoking

**Failure modes:**
- Any certificate in the chain has been revoked
- Proof record is invalid (does not verify against the published tree root)

## Stage 4: Temporal Validity

**Question:** Was the leaf certificate valid at the time the content was signed?

**Procedure:**

1. Parse `created_at` from the trust block
2. Parse the `notBefore` and `notAfter` fields from the leaf certificate
3. Verify that `notBefore` <= `created_at` <= `notAfter`
4. Optionally, verify that intermediate certificates were valid at signing time as well

**Failure modes:**
- Content was signed before the leaf certificate became valid
- Content was signed after the leaf certificate expired
- Clock skew exceeding acceptable tolerance (implementations SHOULD allow up to 5 minutes of skew)

## Verification Result

A XION artifact is **valid** if and only if all four stages pass. Implementations MUST NOT report partial validity — the result is binary (valid or invalid).

Implementations SHOULD report which stage failed to aid debugging, but MUST NOT allow users to override individual stage failures.

## Offline Verification

Stages 1, 2, and 4 can be performed entirely offline using only the artifact and the known Root CA public key. Stage 3 (revocation) requires network access for current proofs, but can be deferred or skipped in offline contexts with appropriate risk acknowledgment.