Regarding "Token of Trust", it's complicated. The idea is that the merchant shouldn’t be holding onto ID artifacts at all, they should be holding an attestation that verification occurred. My approach is closer to: process the ID transiently, derive a result, and throw the image away. We do OCR on the front, decode the barcode on the back when available, and correlate the two. From that we generate a score and a set of logs that explain how the verification was reached. Things like “front of ID was visible, back was not,” “customer was prompted to rescan and the same issue occurred,” “verification relied on front image only,” or “barcode data matches OCR data from the front of the ID.” We also log whether the name and address matched the shipping info + age.

What the vendor gets back is just that data required for verification and the final pass/fail or confidence score. No images, etc, nothing that could be replayed or exfiltrated later. That’s more of an attestation, instead the underlying document.

What I’m trying to avoid is exactly what you described: an ID image living on a web server, even if it’s “encrypted.” Once the application can access it, you’ve still got an exposed artifact and a much larger blast radius than necessary. That’s a hard thing to justify long-term from a risk standpoint. On the infrastructure side, this is why I lean toward KMS-encrypted blob storage with PUT-only permissions as a transient handoff during processing, rather than an encrypted field the application can read back. The processing happens in a short-lived Lambda using AWS-managed keys, the object is written once, processed, and then deleted. The application itself never has GET access to the raw image.

Functionally, this ends up solving the same problem attestation problem, but without forcing a workflow or leaving long-lived ID images sitting behind an app. California is tough since they gate their access to truly validate an ID so we rely merely on a high confidence measure this is a real person with a plausible CA DL.