How a stranger can verify the certificate

At sign time, we serialize the exact packet the guest agreed to (rules + fees + welcome + property identity) and take SHA-256 over the JSON. That hash is stored on the immutable snapshot row and printed on the certificate.

If you edit the live packet later, the hash on this certificate doesn't change. The snapshot is frozen at sign time. A claims reviewer can re-derive the hash from the printed packet text and confirm it matches.

One thing that catches careful reviewers off guard: re-downloading the same certificate produces a PDF that isn't byte-for-byte identical to the last one. That's by design, not tampering. The PDF carries a generation timestamp, so two downloads differ at the file level. Verification never depends on the file bytes. The content hash above is what's anchored; the PDF is just a printout of the frozen snapshot, and the hash keeps matching no matter how many times you re-download it.

The content hash alone proves "this hash exists somewhere." It doesn't prove "PreArrive issued this certificate." An attacker who lifts a content hash from a leaked PDF could in principle paste it into a forged cert.

The HMAC closes that gap. At sign time we compute:

• verify_token = HMAC-SHA256( server_secret, reservation_id | signed_at | content_hash ), truncated to 16 hex characters (64 bits of strength).

That truncated HMAC rides in the QR URL as the t=… parameter. The server secret never leaves us. An attacker can't recompute the HMAC without it.

Sixty-four bits is a deliberate ceiling, not a shortcut. The token is an HMAC nobody can compute without our server secret, so the only attack left is online guessing against a rate-limited verify endpoint, where 64 bits is far more than enough. A longer token would stretch the QR URL onto a denser module grid, shrinking each printed square below what a phone reads reliably at arm's length. We hold the size that keeps the certificate scannable.

The bottom of every certificate carries a QR code that encodes:

• https://prearrive.com/verify/<content_hash>?t=<hmac_token>

Scanning takes any reviewer to the public verify page. The page reads the hash, looks it up in our DB, recomputes the HMAC server-side, and renders one of:

• Verified: hash on file AND the HMAC matches. The certificate is genuine.
• Content hash known: hash on file but no token in the URL. Hash matches, but authenticity isn't proven this round.
• Token mismatch: hash on file but the token doesn't recompute. The URL was probably tampered with or the QR re-encoded.
• Hash not recognized: no PreArrive cert has this hash. The QR is from a different system, or the value was fabricated.

The verify page is public (anyone can hit it), so it reveals only what a claims reviewer needs: property name, stay dates, signed-at timestamp, content hash. Guest names, emails, IPs, and the signature image stay in the host's account.

That keeps the cert safe to attach to a public AirCover ticket or insurance filing without exposing PII along with it.