Barcode scanning is the most common technology upgrade an age-gated business makes. It feels like the rigorous choice: a machine reads the card, so no one is squinting at a hologram. It is worth being precise about what it actually does.
What a barcode scan reads
The two-dimensional barcode on the back of a US driver’s licence encodes a structured data set: name, address, date of birth, document number, issue and expiry dates, physical characteristics, and more. A scanner reads all of it, because it is one encoded block. There is no partial read.
The scanner then applies logic — usually just comparing the birth date against a threshold — and the operator’s software decides what, if anything, to store.
So the sequence is: collect everything, then decide what to keep.
What a mobile ID request reads
A mobile ID is a set of independently verifiable elements. A verifier names the elements it wants, and only those are released. The credential includes pre-computed, issuer-signed age attestations such as age_over_21, so a verifier can request the answer to the age question directly.
The sequence is: decide what to ask for, then collect only that.
Why the ordering is the entire argument
“We do not retain the data” is a claim about the second step of the first sequence. It requires trusting a configuration, a software version, a deployment, a backup regime, a support engineer’s debug session, and every future product decision by that vendor.
“We never received the data” is a claim about the first step of the second sequence. It cannot be undone by a configuration change, because the data was never in the system to be mishandled.
Every security reviewer who has worked on a data-breach response understands this distinction instinctively. It is the difference between a control and a promise.
The three secondary differences
Authentication. A barcode is not signed. Its contents can be re-encoded onto a new card, and a scanner that reads it has no cryptographic basis for believing it. Some scanners apply heuristics about formatting; heuristics are not signatures. A mobile ID carries an issuer signature that a reader validates against a published list of legitimate issuing authorities.
Format drift. Barcode encoding varies by jurisdiction and by issuance generation, and scanner software needs continual maintenance to keep up. The mobile ID data model is defined by the standard, with common element names across issuers.
What ends up in your systems. Barcode workflows tend to spread data: a scan log here, a POS record there, an export somewhere else. A single-element mobile ID request produces one outcome value with nothing attached to it.
Where barcode scanning still wins
Coverage. Nearly every adult carries a card with a barcode. Mobile ID adoption is partial and will remain so for years. This is a real advantage and should not be waved away.
Familiarity. Staff know it. Hardware is cheap and everywhere.
Which is why the useful question is not “which one,” but “what is your default.” A business whose default is scanning has chosen to collect a complete identity record on every age-gated transaction. A business whose default is mobile ID, with a manual fallback for everyone else, has chosen to collect nothing — and the second position is much easier to explain to a customer, a regulator, or a plaintiff’s lawyer.
The comparison in one table
| ID barcode scanning | Mobile ID verification | |
|---|---|---|
| Data read | The full encoded record | Only the requested elements |
| Minimum possible read | The whole barcode | One signed age attestation |
| Authenticity | Not cryptographically signed | Issuer signature, validated against a trust list |
| Format maintenance | Per jurisdiction and generation | Standardised element names |
| Privacy claim type | Retention policy | Structural — never received |
| Coverage | Nearly universal | Partial and growing |
A question worth asking your current vendor
If you already scan IDs, ask your provider for the complete list of fields their system receives, and the complete list it stores, per store, today.
The answers are frequently surprising to the people who own the contract. That surprise is the risk this comparison is really about.
What LaurelID does instead
Laurel’s own product.
LaurelID has no barcode reader and no camera. Its entire request is one element — age_over_21 — with intentToRetain set to false, and the platform behind it has no column for a name, an address, a birth date, or a document number. Outcomes are stored as aggregate counters per location and day, with rows suppressed below a minimum group size of three.
The result is that the question “what did you collect about our customers?” has a one-word answer. See the privacy architecture for how that is enforced rather than promised.
Sources
- ISO/IEC 18013-5:2021 — Mobile driving licence (mDL) application — ISO
- Mobile Driver License Digital Trust Service — AAMVA
- Supported attributes for credentials in Google Wallet — Google
How to read this article
Statements about standards, wallets, and issuing authorities are drawn from the primary sources listed above. Statements about what LaurelID does are ours, and are marked as such in the text. Nothing here is legal advice, and wallet or jurisdiction availability changes — check the source before relying on a detail.