# HXP-002 — Physical Token Envelope and Carrier

Status: Candidate Standard 0.1
Protocol: `helix-token/1.0`
Public article edition: 2026-09-09

## Overview

The Physical Token Envelope carries a compact, signed association between a commissioned unit and a Helix credential. It is intended for a physical carrier whose available memory and transfer rate are much smaller than those of a complete `.hlx` package. Its purpose is to make the association checkable, including where a reader cannot immediately obtain the full package.

The envelope is not the same thing as a serial number, a URL, or a secure chip. A serial identifies an allocated unit. A URL locates a record. A signature protects the meaning and integrity of the token payload under a trusted key. Resistance to copying or moving the physical carrier requires additional hardware and attachment evidence.

This distinction is central to a useful deployment. A gallery can use a simple NFC locator for convenient access today while recognizing that a commissioned envelope and qualified physical observations provide different assurance. The public software's ability to prepare or read NDEF data does not mean that a particular tag has passed physical qualification.

## Three carrier modes

| Mode | What is stored or presented | What a successful read establishes |
| --- | --- | --- |
| QR or NFC locator | A certificate URL or identifier | The reader obtained a locator. The record still needs to be evaluated. |
| Signed token envelope | Compact payload, signatures, and delegation material | The envelope's integrity and authority can be evaluated against independently trusted roots. |
| Qualified physical unit | Signed association plus enrolled response and attachment evidence | The named physical checks may support a continuity claim within their qualified conditions. |

These modes should never share an undifferentiated “authentic” badge. Copying a locator may reproduce its behavior perfectly. Copying a signed payload preserves its mathematical validity. Neither act reproduces a separately enrolled physical response or establishes that the carrier remains attached to the original host.

## Capacity and format

The candidate baseline is an NFC Forum Type 4 carrier with 8 KiB EEPROM and a 7,680-byte NDEF payload budget. Capacity is a profile requirement to verify on a selected carrier, not a statement that every NFC tag offers this space. Envelope generation must fail when the payload does not fit; silent truncation produces an incomplete and potentially misleading record.

The compact envelope uses deterministic CBOR. Its payload and delegation use ML-DSA-44 in separate signing domains. The larger `.hlx` capsule retains its own configured ML-DSA/SLH-DSA policy. The smaller carrier therefore does not imply that all signatures from the full capsule have been embedded in the tag.

[NIST FIPS 204](https://csrc.nist.gov/pubs/fips/204/final) defines ML-DSA. The carrier profile must additionally specify the exact payload encoding, domain, delegation constraints, capacity accounting, and supported reader behavior. A reader cannot infer interoperability from the algorithm name alone.

## What the envelope binds

| Payload element | Relationship being committed |
| --- | --- |
| Certificate and evidence root | The unit's association with a particular digital record and its original evidence commitment. |
| Subject digest | The subject description associated with that record. |
| Optical design digest | The intended deterministic design supplied for that credential. |
| Optical and attachment profiles | The methods under which later physical observations are to be interpreted. |
| Enrollment-template digest | The reference to the unit's enrolled physical-response template, when commissioned. |
| Unit and lot identifiers | The allocated unit and its manufacturing/commissioning context. |
| NFC profile and commissioning time | The carrier interpretation and the declared commissioning event. |

The deterministic design derives from the work evidence commitment and declared context. It must not be described as containing a passkey, private signing key, or independently established real-world identity. Assigned unit serials remain a separate tracking mechanism. The physical unit's measured variation and attachment condition remain separate observations.

Only the information needed for public verification belongs in the public envelope. Protected raw enrollment observations, manufacturing recipes, calibration secrets, and signing material are not required to explain the envelope and must not be added to it for convenience.

## Delegation and independent trust

The envelope carries an operational public key and the relevant root-signed delegation. A verifier checks the delegated purpose, applicable validity interval, algorithm, and relationship to the payload. It must also establish root trust independently of the object being inspected.

A counterfeit package can contain a mathematically coherent key hierarchy created by its author. That hierarchy is not an authority merely because every signature is internally consistent. The reader needs a previously trusted root or a bundle digest obtained through an independent trusted channel.

An offline reader can check the carried signatures and the historical commissioning assertion with the material it possesses. It cannot infer current revocation, later custody, or recovery events from an old envelope. The result should state its trust source and time context, and identify any current-status question that remains unresolved.

## Commissioning as a controlled lifecycle

A manufactured unit starts uncommissioned. The intended physical workflow associates a received unit with its design, enrollment evidence, attachment profile, and the work's active credential. Commissioning then produces the signed relationship and a recorded event. The complete assurance process includes verifying written bytes, sealing the relevant checkpoint, and retaining a receipt.

The candidate carrier profile also describes a final write-lock step. This is an operational requirement for a qualified carrier procedure, **not a capability automatically performed by the current browser writer**. The browser flow prepares supported NDEF payloads, writes them when the device allows it, and reads them back; it does not perform permanent locking or secure-chip provisioning.

A partially completed operation must retain its actual state. Receiving a unit is not enrollment. Enrollment is not a validated observation from a trusted reader. A successful write is not successful attachment qualification. If a step is interrupted, the operator should recover the existing unit's workflow rather than creating another identity to conceal the interruption.

## Browser preparation and read-back

The current application can prepare a certificate locator and, for an eligible already commissioned unit, its existing verified envelope. A complete exported `.ndef` message may be used with compatible vendor utilities. It is not an EEPROM image, a firmware image, or a file of secure-element keys.

Web NFC provides NDEF interaction on supported devices and browsers. It does not expose general UHF EPC programming, arbitrary chip firmware flashing, or low-level secure-key provisioning. Device-specific operations require a supported native integration and separate acceptance testing. See the [Chrome Web NFC documentation](https://developer.chrome.com/docs/capabilities/nfc) for the browser capability boundary.

Read-back compares the actual record types and bytes with the prepared message. A mismatch must remain a mismatch. A successful comparison establishes that the expected data was read from the presented tag at that moment; it does not establish physical uniqueness, resistance to emulation, or attachment continuity.

## Worked example: a gallery handoff

A studio prepares a locator tag for an artwork. A gallery scans the tag and opens the credential's verification page. The digital record may validate, but the locator itself supplies no evidence that the tag was not copied. The gallery must inspect the work and any required physical evidence separately.

If a commissioned signed envelope is also available, the gallery can examine the association with the original evidence root and the unit's declared profiles. If the optical observation is missing or outside its qualified range, the physical result remains unresolved even when the envelope signatures pass.

After an accepted ownership handoff, the original token association does not rewrite the original artwork evidence. The recipient should obtain current custody information and the updated package where required. An old carrier or package is not a guarantee that the registry has no newer event.

## Failure handling and qualification

Conformance should test an oversized payload, truncated records, altered certificate identity, changed evidence roots, unsupported carrier profiles, key substitution, untrusted roots, stale delegations, and copied payloads. Hardware acceptance should test the named tags, readers, operating systems, replacement behavior, and read-back failures with real equipment.

Qualification of optical response and attachment is governed separately by [HXP-006](/standards/optical-puf), [HXP-007](/standards/tamper), and [HXP-008](/standards/conservation). No universal hardware assurance follows from a successful software test or vendor specification. [ISO/IEC 20248:2022](https://www.iso.org/standard/81314.html) is a relevant reference for signed automatic-identification data; Helix does not claim that its post-quantum envelope is automatically conformant with that separate standard.