Attestation Receipt Schema — Specification v1.0.0

1. Abstract

This document specifies the attestation receipt: the full-fidelity record from which the compact H33-74 primitive is derived. A receipt contains all fields necessary for an independent verifier to reconstruct and validate the attestation without trusting the issuing system.

Receipts are JSON objects. They carry input and output commitments, policy and authority hashes, a chain position linking each receipt to its predecessor, a three-family post-quantum signature bundle, and the derived H33-74 commitment and cached receipt bytes. This specification defines the canonical field set, serialization rules for hash computation, chain-linking semantics, and the verification algorithm.

2. Status of This Document

This specification is at Production status. The receipt schema, hash computation rules, and chain-linking semantics defined herein are frozen per the H33 Protocol Stability policy.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

3. Definitions

Receipt

A JSON object containing all fields necessary to independently verify an attestation. The receipt is the source of truth; the H33-74 primitive is a compact, derived representation.

Receipt Hash

The SHA3-256 digest of the canonical serialization of a receipt. This value is used as the receipt's unique identifier within a hash chain and as the commitment stored on-chain.

Predecessor Hash

The receipt hash of the immediately preceding receipt in the same tenant's chain. The first receipt in a chain uses the 32-byte zero value (0x00...00) as its predecessor hash.

Chain Position

A monotonically increasing uint64 counter representing the receipt's ordinal position within its tenant's chain. The first receipt has chain_position 0.

Domain Separator

A fixed byte prefix used in hash computation to prevent cross-context collisions. For receipt hashing, the domain separator is the UTF-8 encoding of H33:receipt:v1:hash: (21 bytes).

Signer Set

The ordered triple of public keys (ML-DSA-65, FALCON-512, SLH-DSA-SHA2-128f-simple) that signed the receipt. The signer set is identified by the authority_hash, which is the SHA3-256 digest of the concatenated public key bytes.

4. Receipt Structure

An attestation receipt is a JSON object with the following fields. All fields are REQUIRED unless marked OPTIONAL.

Field	Type	Required	Description
receipt_id	string (UUID v4)	Yes	Unique identifier for this receipt. MUST be a valid UUID v4 in lowercase hyphenated form.
tenant_id	string (UUID v4)	Yes	The tenant that owns this receipt.
computation_type	string	Yes	One of the enumerated computation type names (e.g., "BIOMETRIC_AUTH"). MUST correspond to a value defined in H33-74 Section 5.
input_commitment	string (hex, 64 chars)	Yes	SHA3-256 digest of the computation input, hex-encoded. Lowercase.
output_commitment	string (hex, 64 chars)	Yes	SHA3-256 digest of the computation output, hex-encoded. Lowercase.
policy_hash	string (hex, 64 chars)	Yes	SHA3-256 digest of the policy document under which the computation was evaluated.
authority_hash	string (hex, 64 chars)	Yes	SHA3-256 digest of the concatenated signer set public key bytes (ML-DSA || FALCON || SLH-DSA).
timestamp	string (ISO 8601)	Yes	Time of attestation. MUST be in UTC with second precision and the Z suffix (e.g., 2026-05-18T09:14:22Z).
predecessor_hash	string (hex, 64 chars)	Yes	Receipt hash of the preceding receipt in this tenant's chain. "0000...0000" (64 zeros) for the first receipt.
chain_position	integer (uint64)	Yes	Ordinal position in the tenant's chain. First receipt is 0. MUST be exactly predecessor.chain_position + 1 for all subsequent receipts.
domain_separator	string	Yes	The domain separator used for this receipt's hash computation. MUST be "H33:receipt:v1:hash:".
signatures	object	Yes	The three-family PQ signature bundle. See Section 7.
h33_74_commitment	string (hex, 64 chars)	Yes	The 32-byte commitment that appears in the H33-74 primitive, hex-encoded.
cached_receipt	string (hex, 84 chars)	Yes	The 42-byte cached receipt portion of the H33-74 primitive, hex-encoded.
metadata	object	OPTIONAL	Implementation-specific metadata. Verifiers MUST ignore unrecognized fields within this object. MUST NOT affect hash computation.

5. Hash Computation

The receipt hash is computed over a canonical byte serialization. This section defines the canonical form. Implementations MUST produce identical hash outputs for semantically identical receipts.

5.1. Canonicalization Rules

1. Unicode normalization. All string values MUST be NFC-normalized (Unicode Normalization Form C) before serialization.
2. Field ordering. Fields are serialized in the following fixed order: receipt_id, tenant_id, computation_type, input_commitment, output_commitment, policy_hash, authority_hash, timestamp, predecessor_hash, chain_position, domain_separator. The signatures, h33_74_commitment, cached_receipt, and metadata fields are excluded from hash computation.
3. Length-prefixed encoding. Each field is serialized as a 4-byte little-endian length prefix followed by the UTF-8 byte representation of the value. For chain_position, the value is the 8-byte little-endian encoding of the uint64 integer (no length prefix).
4. Concatenation. The serialized fields are concatenated in order with no separators.
5. Domain separator. The domain separator string H33:receipt:v1:hash: (21 bytes, UTF-8, no null terminator) is prepended to the concatenated field bytes.
6. Digest. The receipt hash is SHA3-256(domain_separator || serialized_fields).

5.2. Pseudocode

6. Chain Linking

Attestation receipts form a hash chain per tenant. Each receipt references the hash of its predecessor, creating an append-only, tamper-evident sequence.

6.1. Chain Invariants

1. chain_position MUST start at 0 for the first receipt of a tenant.
2. For all subsequent receipts: receipt.chain_position == predecessor.chain_position + 1.
3. predecessor_hash MUST equal compute_receipt_hash(predecessor_receipt).
4. The first receipt in a chain MUST use "0000000000000000000000000000000000000000000000000000000000000000" (64 hex zeros) as its predecessor_hash.
5. Chain positions MUST NOT have gaps. A missing position breaks the chain.

6.2. Chain Verification

To verify a chain segment from position N to position M:

1. Retrieve all receipts with chain_position in [N, M] for the given tenant_id.
2. For each receipt at position i (where i > N), verify that receipt[i].predecessor_hash == compute_receipt_hash(receipt[i-1]).
3. If N > 0, verify that receipt[N].predecessor_hash matches the known hash of the receipt at position N-1. If this receipt is unavailable, the chain segment cannot be fully anchored.
4. The chain segment is INTACT if all predecessor hashes match. It is BROKEN if any mismatch is found.

7. Signature Bundle

The signatures field is a JSON object with three keys, each containing the hex-encoded signature bytes:

Key	Algorithm	Standard	Approx. Size	Description
ml_dsa	ML-DSA-65	FIPS 204	3,309 bytes	Module-Lattice Digital Signature. MLWE hardness assumption.
falcon	FALCON-512	NIST Round 3	~690 bytes	NTRU-lattice-based signature. Independent lattice assumption from ML-DSA.
slh_dsa	SLH-DSA-SHA2-128f-simple	FIPS 205	17,088 bytes	Stateless hash-based signature. Security depends only on hash function properties.

All three signatures MUST be computed over the canonical receipt bytes (the same byte sequence input to SHA3-256 in Section 5, without the domain separator prefix). Each signature MUST be hex-encoded in lowercase.

8. Verification Algorithm

An independent verifier MUST execute the following steps in order. Failure at any step terminates verification with the corresponding error code.

1. Schema validation. Verify that all REQUIRED fields are present and correctly typed. Error: RCPT_ERR_SCHEMA.
2. UUID format. Verify receipt_id and tenant_id are valid UUID v4 in lowercase hyphenated form. Error: RCPT_ERR_UUID.
3. Computation type. Verify computation_type is one of the defined values. Error: RCPT_ERR_COMP_TYPE.
4. Hex fields. Verify all hex-encoded fields are exactly the expected length and contain only lowercase hex characters. Error: RCPT_ERR_HEX.
5. Timestamp format. Verify timestamp is a valid ISO 8601 UTC string with the Z suffix. Verify it is not in the future by more than 300 seconds. Error: RCPT_ERR_TIMESTAMP.
6. Domain separator. Verify domain_separator is exactly "H33:receipt:v1:hash:". Error: RCPT_ERR_DOMAIN.
7. Recompute receipt hash. Serialize the receipt canonically per Section 5 and compute SHA3-256. Error: RCPT_ERR_HASH (used in the next step).
8. Commitment match. Verify h33_74_commitment matches the commitment derivation defined in H33-74 Section 4.2. Error: RCPT_ERR_COMMITMENT.
9. Chain linking. If the receipt is not the first in its chain (chain_position > 0), fetch the predecessor and verify predecessor_hash == compute_receipt_hash(predecessor). Error: RCPT_ERR_CHAIN.
10. Signature verification. For each of the three signatures (ml_dsa, falcon, slh_dsa): decode the hex signature, obtain the corresponding public key from the authority identified by authority_hash, and verify the signature over the canonical receipt bytes. Error: RCPT_ERR_SIG_MLDSA, RCPT_ERR_SIG_FALCON, or RCPT_ERR_SIG_SLHDSA.

9. Failure Modes

Error Code	Condition	Severity
RCPT_ERR_SCHEMA	Missing or incorrectly typed required field	Critical
RCPT_ERR_UUID	Invalid UUID v4 format in receipt_id or tenant_id	Critical
RCPT_ERR_COMP_TYPE	Unrecognized computation type string	Critical
RCPT_ERR_HEX	Hex field has wrong length or contains non-hex characters	Critical
RCPT_ERR_TIMESTAMP	Invalid ISO 8601 format or future timestamp exceeds tolerance	Critical
RCPT_ERR_DOMAIN	Domain separator does not match expected value	Critical
RCPT_ERR_COMMITMENT	Recomputed commitment does not match h33_74_commitment	Critical
RCPT_ERR_CHAIN	Predecessor hash mismatch or chain position gap	Critical
RCPT_ERR_CHAIN_FETCH	Predecessor receipt could not be retrieved	Warning
RCPT_ERR_SIG_MLDSA	ML-DSA-65 signature verification failed	Critical
RCPT_ERR_SIG_FALCON	FALCON-512 signature verification failed	Critical
RCPT_ERR_SIG_SLHDSA	SLH-DSA signature verification failed	Critical
RCPT_ERR_AUTHORITY	Authority public keys not found for given authority_hash	Critical

10. Conformance Requirements

An implementation claiming conformance to this specification MUST:

1. Produce receipts containing all REQUIRED fields with correct types as defined in Section 4.
2. Implement the canonical serialization and hash computation algorithm in Section 5 exactly, including NFC normalization, field ordering, and length-prefixed encoding.
3. Use SHA3-256 (FIPS 202) for all hash computations. SHA-256 is not acceptable.
4. Maintain chain invariants (Section 6.1) for all receipts within a tenant's chain.
5. Sign all receipts with all three PQ families (Section 7).
6. Implement the full verification algorithm (Section 8) including all 13 error codes (Section 9).
7. Produce structured error output including the error code and severity for each failure.
8. Reject receipts that fail any Critical-severity check.

Implementations SHOULD:

1. Support chain segment verification (Section 6.2) for arbitrary position ranges.
2. Emit Warning-severity results (e.g., RCPT_ERR_CHAIN_FETCH) as advisory information without halting verification of other checks.
3. Validate the metadata field, if present, as a valid JSON object, but ignore its contents for hash computation.

11. JSON Schema

12. Example: Valid Receipt

13. Example: Invalid Receipt (Chain Break)

The following receipt has chain_position: 1428 but its predecessor_hash does not match the hash of receipt 1427. A conformant verifier MUST produce RCPT_ERR_CHAIN.

14. Changelog

Version	Date	Changes
1.0.0	2026-05-22	Initial publication. Receipt schema frozen. Hash computation algorithm specified. Chain linking invariants defined. JSON Schema published. 13 error codes enumerated.

15. References

15.1. Normative References

• [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [FIPS 202] NIST, "SHA-3 Standard", FIPS PUB 202, August 2015.
• [FIPS 204] NIST, "Module-Lattice-Based Digital Signature Standard", FIPS PUB 204, August 2024.
• [FIPS 205] NIST, "Stateless Hash-Based Digital Signature Standard", FIPS PUB 205, August 2024.
• [UAX #15] Unicode Consortium, "Unicode Normalization Forms", UAX #15.
• [JSON Schema 2020-12] JSON Schema specification, 2020.
• [H33-74] H33.ai, Inc., "H33-74 Attestation Primitive Specification v1.0", 2026.

15.2. Informative References

• [H33-GOV] H33.ai, Inc., "Governance Proof Model Specification v1.0", 2026.
• [H33-STABILITY] H33.ai, Inc., "Protocol Stability & Replay Integrity", 2026.
• [HATS] H33.ai, Inc., "HATS Standard v1.0", 2026.
• [CONTINUOUS] H33.ai, Inc., "Continuous Attestation", 2026.