Overview
A Helix credential is a portable account of what an issuer recorded about a particular object, the evidence to which that account refers, and the authority under which it was signed. The Core Evidence Capsule makes those relationships inspectable after the record leaves the issuing application. Its purpose is to preserve a verifiable assertion through storage, exchange, and later changes in custody.
For an artwork, the subject might be a painting described by its title, declared creator, material, and certificate identifier. Evidence might include a studio photograph and a close-up capture. A gallery receiving the capsule can check the integrity of the committed record and the signing authority without treating a screenshot of a certificate as proof. Whether a newly presented painting is that same physical object remains a separate question requiring an appropriate observation method.
This article explains the current digital profile. It does not create new wire formats or change existing verification policy. Physical correspondence, tag response, and attachment qualification are addressed by the other HXP papers.
The information carried by a capsule
The .hlx file is a ZIP-compatible transport container. The security-relevant structure is the inventory and the signed data inside it. File ordering, compression settings, and ZIP timestamps are not the identity of the evidence record.
| Layer | Information | Why it matters |
|---|---|---|
| Subject | Certificate identity, declared creator, title, and object context | States what the issuer is describing. A declared name is not independent identity verification. |
| Evidence | Ordered inventory, file lengths, media types, and exact commitments | Makes substitution, omission, and changes to included evidence detectable. |
| Interpretation | Evidence profile, template, and issuance policy | Describes how the evidence is to be interpreted and which signatures are required. |
| Authority | Signatures, keys, and issuer delegations | Allows a verifier to evaluate whether the signing keys were authorized. |
| History | Custody events, checkpoints, and inclusion material | Places the record within a verifiable historical sequence. |
| Optional physical material | Declared capture commitments or commissioned token information | Supports additional checks without making them implicit prerequisites for every digital claim. |
A reader should be able to identify which layer supports each displayed conclusion. A valid inventory does not establish an issuer's authority. An authorized issuer does not make every submitted photograph truthful. A historical checkpoint does not establish that no later event occurred.
The stable evidence commitment
The core commitment is constructed using the existing public domain and deterministic encoding:
EvidenceRootV1 = SHA3-512(
"HELIX-EVIDENCE-ROOT-V1" || 0x00 || deterministic-CBOR(input)
)
The input includes the certificate identifier, subject descriptor, evidence profile, evidence template, canonical inventory, content hash, metadata hash, and issuance policy. These components jointly identify the assertion being signed. Changing the title, replacing a capture, or altering the policy is not merely a cosmetic edit to an issued credential.
Determinism matters because independent implementations must obtain the same commitment from the same valid input. Generic JSON serialization, an arbitrary CBOR encoder, or a display string is not an interchangeable encoding. Implementations must use the specified profile and conformance vectors. RFC 8949 provides the CBOR foundation; Helix's selected encoding behavior must still be checked at the profile level.
The hash is a commitment to data, not a visual fingerprint of the object. Different photographs of the same painting normally have different exact-byte digests. The evidence root preserves what was recorded; a correspondence method is needed to compare a fresh observation with the original subject.
Evidence delivery and confidentiality
Committing to evidence and distributing evidence are distinct decisions. A capsule can describe a delivery policy in which original captures remain protected. The verifier must state what it actually received and evaluated. It cannot claim to have inspected a private source photograph solely because its digest is listed in a signed manifest.
When files are included, each file must satisfy its declared inventory entry. When files are retained privately, an authorized workflow may make them available separately, subject to their existing access policy. Neither a public certificate locator nor possession of the capsule should silently grant access to private files.
Hashes are not encryption. Sensitive low-entropy facts can sometimes be guessed and tested against commitments. Publishers should minimize unnecessary personal information and avoid treating a digest as a general substitute for confidential storage. Public display should use the approved publication fields, rather than exposing every nested field simply because a manifest is signed.
Issuing and resuming a credential
The issuance workflow first saves the work and evidence, then freezes the signing input. A saved work is not yet an issued credential. The configured signature policy must complete, the resulting signatures must validate, and the required checkpoint must be sealed before the initial package is presented as ready.
Long signing operations may advance through authenticated saved steps. Resumption continues the existing credential and event identity. Creation retries remain idempotent when they use the same tenant-bound request identity and matching inputs. Reusing an identity for changed inputs is not a valid retry.
These distinctions protect both reliability and meaning. A temporary interruption should not require a user to upload evidence again, create duplicate records, or accept a partially signed credential. The interface can explain the public operation and its progress, but private signer state and intermediate secret material do not belong in progress messages.
ML-DSA and SLH-DSA are specified by NIST FIPS 204 and FIPS 205. Using these algorithm families does not establish that a particular deployment or cryptographic module has received independent certification. The credential's actual algorithm identifiers, required slots, and trust policy remain decisive.
Extending history without rewriting evidence
A capsule may later carry an updated custody chain or a commissioned physical-token receipt. The original evidence root, manifest, and signatures remain stable. Updating the package to include a later sealed checkpoint is a new presentation of the record with additional historical material, not permission to rewrite the original assertion.
Consider a studio that issues a credential and later transfers platform custody to a gallery. The first downloaded capsule remains a historical artifact. The gallery's updated package can contain the accepted handoff and its proof. A verifier must distinguish the time represented by each package from the current registry state.
New evidence requires a new issuance rather than silent replacement inside the old signed inventory. Corrections and successor credentials should be explained clearly to recipients. A label such as “updated” is insufficient unless the reader can determine whether the update concerns evidence, custody, package presentation, or current status.
Safe package processing
The current package policy rejects unsafe paths and excessive expansion before ordinary verification. This includes absolute and drive paths, backslashes, empty path segments, traversal segments, control characters, and duplicate entries. A parser must not extract a package into arbitrary filesystem locations or execute its contents.
The present limits are 256 entries, 50 MiB per entry, 200 MiB total expanded content, and a maximum declared compression ratio of 100:1. These are container-validation limits, not a promise that the web upload gateway accepts every package or combination of files up to those sizes. Upload limits and safe parsing limits serve different purposes.
Unknown mandatory profiles fail closed. Optional material may be ignored only after inventory validation and only when the evaluated claim does not require it. An implementation must not convert unsupported content into a successful check simply to keep the interface moving.
A worked reading example
A collector receives a capsule for a work called “Study in Blue,” with a declared creator and two committed images. The following outcomes are different and should remain visible:
| Observation | Appropriate interpretation |
|---|---|
| Included images match the inventory and the evidence root recomputes | The supplied files match the committed digital evidence. |
| Signatures validate, but the root was supplied only inside the package | Cryptographic consistency has been checked; independent issuer trust is still missing. |
| Issuer authority and historical inclusion validate | The assertion was authorized under the evaluated policy and included in the stated checkpoint. |
| A new phone photograph has a different digest | The bytes differ; no conclusion about counterfeit status follows from that fact alone. |
| A current registry read shows a later custody event | The old capsule remains historical; obtain the current handoff information before relying on present custody. |
No single row answers every authenticity question. The capsule is useful because it makes these questions separable and their evidence portable.
Compatibility and review
Existing helix-auth/1.0 material remains a legacy format and is not upgraded in place. A bridge may commit to a legacy signed manifest and its exact evidence, but it must retain the limitations LEGACY_CREDENTIAL_VALIDITY_ONLY, INTRINSIC_MATCH_UNAVAILABLE, and PHYSICAL_BINDING_UNVALIDATED until the required new evidence is enrolled.
Conformance review should include inventory mutation, altered subject fields, substituted keys, missing signatures, unsupported versions, hostile archives, interrupted issuance, and refreshed packages with unchanged original evidence. Successful digital tests do not qualify a physical tag or establish authorship independently.
Continue with HXP-003: verification and trust, HXP-009: conformance, and HXP-011: physical scan commitments.