Physical Scan Binding (HSB-1)

Purpose and claim boundary

HSB-1 commits one or more physical-capture descriptors to a credential without requiring the raw photograph or point cloud to travel in the portable package. An independent verifier can determine whether the carried descriptors are the descriptors the issuer signed. A presented capture can then be compared with the committed descriptors under a named rule.

This is a binding between recorded data and a signed record. It does not, by itself, prove that a capture depicts the claimed object or that a newly presented object is authentic. The distinction makes scan evidence useful without assigning it authority it does not have. A correctly signed photograph can still depict the wrong subject, and a new photograph of a genuine work can have completely different bytes.

Supported capture classes include ordinary photographs, depth or LiDAR point clouds, and other declared media. The descriptor identifies the kind of data and the comparison method; an interface label such as “3D scan” is not sufficient to establish a particular geometry profile.

The capture descriptor

Each descriptor uses the schema helix-scan-capture/v1. It records a modality and media type, a SHA3-512 digest of the exact capture bytes, an optional SHA3-512 digest of supported canonical geometry with its profile, and optional non-secret acquisition metadata.

Raw capture bytes remain outside the descriptor bundle unless another profile explicitly inventories them. A digest can support an integrity check when the corresponding bytes are available; it does not let a recipient reconstruct the original image or point cloud.

Canonical encoding and the suite identifier

The suite identifier is HSB-1/sha3-512/jcs. Each descriptor is encoded with RFC 8785-compatible JSON canonicalization before hashing. Canonicalization removes representational ambiguity relevant to the declared JSON contract, so implementations agree on the bytes being committed. It does not mean that any two semantically similar documents have the same representation.

The descriptor's leaf is:

SHA3-512(0x00 || JCS(descriptor))

The initial byte separates the leaf domain from the internal-node domain. The notation || denotes byte concatenation. Implementations must use the actual specified bytes, not the printed characters of the formula or an arbitrary pretty-printed JSON string.

The JSON Canonicalization Scheme, RFC 8785, supplies the referenced canonicalization rules. A parser or serializer that changes supported values before canonicalization can change the commitment. Conformance therefore needs vectors covering representation and rejection behavior, not only one uncomplicated example.

Building the scan-binding tree

Leaf hashes are sorted bytewise before tree construction. Adjacent pairs are reduced using:

SHA3-512(0x01 || left || right)

An unpaired final node is promoted unchanged to the next level. The process continues until one value remains. Its lowercase hexadecimal representation is the scan-binding root. Capture order therefore does not affect the root; changing a committed descriptor does.

For a conceptual example, let three sorted leaf hashes be a, b, and c. The next level contains H(0x01 || a || b) and the unchanged c. The root is H(0x01 || H(0x01 || a || b) || c), where H denotes SHA3-512. These letters are explanatory placeholders, not published test-vector digests.

A verifier must reproduce the same sorting and odd-node rule. Duplicating the final node instead of promoting it would describe a different construction. A familiar Merkle-tree implementation is not automatically compatible merely because it uses the same hash function.

Bind the root independently of the bundle

The signed artifact manifest carries the root independently from the descriptor bundle. A descriptor bundle without a signed root is invalid, as is a signed root without the descriptors needed to recompute it. Carrying both prevents an unsigned replacement bundle from defining its own reference commitment.

Verification recomputes the root from the supplied descriptors and compares it with the signed root. This establishes descriptor integrity under the artifact's signature and trust policy. The signature policy itself still needs evaluation: a recomputed root under an untrusted issuer does not establish recognized authority.

The broader portable package also has its own inventory and structural requirements. A successful scan-root comparison cannot excuse an unsafe archive, a missing required signature, or an unsupported mandatory package profile. HXP-001 and HXP-003 describe those independent checks.

The HGC-1 point-cloud input contract

The hgc-1 geometry profile accepts non-empty little-endian Float64 x, y, z triples. It rejects malformed lengths, non-finite coordinates, and payloads exceeding 500,000 points before canonicalization. An arbitrary mesh, compressed point-cloud file, or vendor-specific LiDAR export is not automatically this byte format.

These input rules serve reproducibility and bounded processing. The media description and the actual bytes must agree with the supported adapter. A reader should not guess an encoding and then present the resulting digest as though the declared profile had been followed.

The exact-byte digest remains present even when a geometry digest is available. This preserves both questions: which original capture was committed, and which normalized geometric representation it produced. The geometry digest does not replace the original-byte commitment or conceal a change in the source file.

Canonical geometry construction

HGC-1 centers the cloud, normalizes root-mean-square scale, aligns principal axes, resolves axis signs from third moments, quantizes coordinates at 2^-12, removes duplicate rows, and sorts the remaining rows. SHA3-512 over the resulting canonical bytes produces the geometry digest.

These transformations define a particular representation. They are intended to make equivalent ordered, translated, or uniformly scaled point data comparable. They do not establish a general-purpose biometric or object-correspondence model. Quantization deliberately discards some precision, and normalization can remove differences that would matter to a different application.

Degenerate or low-information geometry must not be interpreted as a strong identity signal. Nearly symmetric shapes, uncertain axes, incomplete captures, and measurement noise can complicate comparisons. The profile does not justify a universal promise that arbitrary rotations, sensors, occlusions, or repeated real-world scans produce identical digests.

A geometry match therefore means a match under HGC-1's named representation. It should not be translated into an unsupported conclusion about the unique physical identity of every object capable of producing that representation.

Issuance establishes authoritative descriptors

At issuance, the service recomputes every descriptor and the HSB-1 root from the uploaded bytes. Client-supplied digest strings are display aids, not authority. This prevents a client from asking the issuer to commit an asserted digest without the corresponding capture being processed under the supported rules.

The resulting root and descriptor bundle are covered by the artifact signature and portable .hlx package. A saved upload and a completed signature remain separate lifecycle states. The existence of capture files does not mean a credential has already been issued.

The server-side calculation establishes what data the service received and committed. It does not independently certify the truth of user-supplied acquisition context or the physical circumstances of capture. Those questions require their own authority, observation process, and validation evidence.

Verification and a fresh scan

An independent verifier reports scan binding as its own signal. It recomputes the descriptor root and checks its relationship to the signed manifest. A presented capture can then be checked for an exact content-digest match or, where supported, an HGC-1 geometry-digest match.

A fresh scan miss is supplementary information and is never, by itself, evidence of forgery. Consider a collector photographing a work under different lighting with a different phone. The resulting bytes normally differ from the artist's enrollment image. The exact-match result can accurately say that the new file is not the enrolled file while the digital credential remains valid.

A same-object correspondence claim requires a declared capture profile, calibrated feature extractor, threshold, quality controls, and a validation dossier under HXP-005. HSB-1 supplies the signed data binding that such a process can reference; it does not replace that process.

Privacy and disclosure choices

Descriptor-only packaging can reduce unnecessary distribution of raw imagery and point clouds. It does not automatically make all metadata harmless. Acquisition timestamps, device identifiers, location fields, or descriptive text can reveal information about an owner, collection, or handling process. Public metadata should be limited to what is needed for the declared comparison.

No descriptor should contain private keys, service credentials, session tokens, protected calibration material, or unnecessary personal data. A publication decision for a raw capture is separate from the decision to publish its digest. Access to the source evidence should continue to follow the existing document and artifact permissions.

A recipient who lacks the raw capture can still evaluate the descriptor bundle's signed commitment. The recipient cannot independently inspect the original pixels or recompute the original file digest without obtaining those bytes. The report should make that evidence availability clear.

Conformance and neighboring claims

Tests should cover descriptor mutations, capture-order independence, odd-node promotion, canonicalization agreement, root-and-bundle pairing, malformed point-cloud inputs, geometry limits, and the difference between exact and geometric comparison. Synthetic fixtures can exercise these properties without exposing customer captures or private enrollment material.

HSB-1 does not establish issuer authority, current registry status, provenance continuity, physical-token continuity, or universal authenticity. Those predicates remain separate verifier signals with their own evidence and failure states. HXP-009 explains how the software checks fit into a broader qualification case, while HXP-004 describes why a valid commitment cannot answer every physical or operational trust question.