# HXP-003 — Open Verification and Trust Roots

Status: Candidate Standard 0.2
Public article edition: 2026-09-09

## Overview

Verification is a sequence of questions about evidence, authority, history, and the object being presented. A useful verifier shows which question it answered, what evidence supported that answer, and what remains unknown. HXP-003 defines this interpretation for Helix credentials and physical-token material.

A certificate can be digitally intact while its signing authority is untrusted. A valid historical package can be out of date. A commissioned tag can carry a valid envelope while its attachment has not been inspected. These are ordinary, meaningful distinctions, not errors to be hidden behind a single green badge.

The current public verifier brings digital verification and History into one place. A package upload provides evidence carried in the file; a certificate locator retrieves an assisted current-record view. These entry points have different inputs and must describe their conclusions accordingly. This article explains the public contract, not the private operation of the issuance service.

## Select the claim before aggregating results

A result is evaluated against a named claim. Examples include integrity of an included evidence record, issuer-authorized credential validity, historical inclusion, or a qualified physical-continuity claim. The required checks depend on that claim.

The overall result is `VALID`, `INVALID`, or `INDETERMINATE`. Every required axis must pass for the named claim to be valid. A required failure makes it invalid. Missing trust, insufficient quality, stale evidence, or an unevaluated required axis makes it indeterminate. Passing an unrelated check cannot compensate for a required failure.

This prevents an attractive but unsafe shortcut: treating the existence of one valid signature as evidence for every property of an object. It also avoids the opposite error of calling a work counterfeit merely because a photograph cannot be compared under the available method.

## Independent verification axes

| Axis | Main question | Important limitation |
| --- | --- | --- |
| Package structure | Is the container safe and consistent with its inventory? | Safe parsing is not issuer trust. |
| Digital integrity | Do commitments and signatures correspond to the evaluated data? | Integrity does not make an assertion factually true. |
| Issuer authority | Is the signing key authorized under an independently trusted root and policy? | A self-supplied root is not independent authority. |
| Provenance | Do the evaluated events belong to this credential and its linked history? | A published assertion still has a stated author and basis. |
| Freshness and registry status | How current is the status observation? | Historical inclusion does not establish present status. |
| Intrinsic correspondence | Does a fresh observation satisfy a qualified same-object method? | Exact-file equality is a different comparison. |
| NFC envelope | Does the carried token payload validate under its profile? | Signed bytes can be copied. |
| Optical and attachment observations | Do the required physical signals satisfy their qualified procedures? | Missing hardware evidence must remain missing. |

Each `VerificationAxisResultV1` includes a result, reason, evidence context, execution class, trust-root source, and observation time where applicable. A reader needs enough explanation to understand a result without receiving protected enrollment data or private signer state.

## The result vocabulary

`PASS` means the evidence supplied for an individual check satisfied that check's policy. `FAIL` means the check found an invalid proof or a contradiction. `INDETERMINATE` means the evidence, quality, trust, or freshness was insufficient to decide. `NOT_EVALUATED` means the check was not performed.

These states should remain visible in exported reports and screen presentations. A missing optical observation is not an optical failure, and neither state is a pass. A trusted signature does not change the status of an unevaluated attachment check.

A good report includes the requested claim, evaluated inputs, policy/profile versions, observation time, required axes, result, and next useful action. For example, “obtain a current registry observation” is more helpful than “try again” when the missing ingredient is freshness rather than a temporary parsing error.

## Signature policy and delegated authority

The verifier must evaluate the policy as a whole, including required slots, thresholds, algorithms, keys, message commitments, and delegated purposes. Empty policies, duplicate slots, unsupported algorithms, missing required signatures, and substituted keys fail closed. A key cannot be substituted simply because it verifies another signature in the same package.

Delegation connects an operational signing key to an authority and a permitted use. The relevant validity interval and purpose must be checked in the context of the signed statement. A signature that is mathematically correct but outside the delegated purpose does not establish the requested authority.

[NIST FIPS 204](https://csrc.nist.gov/pubs/fips/204/final) and [FIPS 205](https://csrc.nist.gov/pubs/fips/205/final) specify the ML-DSA and SLH-DSA families. Helix's policy, delegation, packaging, and trust decisions are additional protocol responsibilities. Algorithm support alone is not deployment certification or proof of a signer's real-world identity.

## Establishing a trust root independently

A portable artifact may carry public keys and signed delegation material. It cannot make its own root trustworthy. Otherwise an attacker could create a new root, issue a matching delegation, sign a fabricated record, and ask the same artifact to establish the authority that validates it.

The trust anchor must be acquired independently of the presented object and package. A verifier may already hold a trusted key or an independently obtained `TrustRootBundleV1` digest. The report should identify the trust source and the relevant bundle version without exposing any private credentials.

A published root bundle is inspectable material. Serving it from a URL does not, by itself, establish independent trust. Rollback-linked bundle history helps inspect continuity, but an implementation still needs a trusted starting point and a policy for changes. Historical packages must not silently adopt an arbitrary newer or older root to obtain a passing result.

## Offline evidence and online freshness

Offline operation can evaluate package structure, evidence-root recomputation, carried signatures, delegations under an independently pinned root, and included historical proofs. Its result is limited by the material and time context available to the reader.

Current revocation, later custody, and recovery events require current information. A sealed checkpoint proves inclusion at the represented checkpoint; it does not prove that no subsequent event exists. Failure to contact a registry must not be interpreted as an affirmative statement that a credential remains active.

A practical report can therefore say that historical integrity and authority pass while current status is indeterminate. That is a useful result for an archive or a disconnected inspection, provided the relying party understands the missing current observation and decides whether its use case requires it.

## History and public provenance

The History panel presents signed lifecycle material and explicitly published provenance. Event integrity, sequence, and inclusion proofs are assessed against the credential identity, original evidence root, prior event, and relevant checkpoint. A proof for a different work cannot be transplanted merely because the event text looks similar.

Public provenance entries describe their author, category, time, and stated basis. Publication is not an independent audit of an exhibition, restoration, or ownership assertion. The reader must distinguish the fact that an authorized party published a statement from the truth of every fact inside that statement.

Public views use permitted publication fields. Transfer acceptance secrets, private contacts, protected source evidence, and internal notes are not public-history material. Downloading an inclusion proof should expose the proof needed for the public claim, not the entire private operational record.

## Worked example: one package, several conclusions

A collector receives an old package for “Study in Blue” and a new phone photograph. The package parses safely, its signatures validate, and its issuer delegation leads to a root the collector already trusts. The included checkpoint is six months old. No current registry connection is available, and no qualified fresh-image method is supplied.

The digital and historical checks can pass. Present registry status remains indeterminate. The new photograph's exact digest differs from the enrolled file, which says only that the bytes differ. Intrinsic correspondence is not established. If the collector needs assurance before accepting custody today, the appropriate next steps are a current status observation and any physical inspection required by the transaction.

If one required signature is later found invalid, the relevant credential-validity claim fails. The report should retain the independent physical and freshness statuses rather than rewriting every axis to the same value. This preserves diagnostic value and prevents unsupported conclusions.

## Conformance and public implementation boundaries

Conformance should exercise both positive cases and carefully separated failures: valid signatures under an untrusted root, wrong delegated purpose, stale checkpoint, altered nested fields, transplanted history, unsupported profiles, and missing physical evidence. Tests must verify the explanation and aggregation, not merely a success boolean.

The public surface includes the formats, deterministic encodings, domains, trust behavior, result vocabulary, observation requirements, and conformance expectations needed for independent evaluation. Private issuance infrastructure, manufacturing controls, calibration secrets, and protected enrollment observations are outside this article.

Read [HXP-001](/standards/core-capsule) for the capsule, [HXP-004](/standards/threat-model) for the threat model, and [HXP-009](/standards/conformance) for the evidence required to claim conformance.