How NFC and Bluetooth Work Together in Mobile ID Verification

An in-person mobile ID check uses two radios, and people often assume that is redundancy or complexity for its own sake. It is neither. Each transport is doing a job the other is bad at.

The division of labour

NFC handles engagement. Engagement is the short exchange that establishes how the phone and reader will talk, including the key material for the session that follows. It is small, and it needs to be unambiguous about which device is participating.

BLE carries the response. The credential response is much larger than engagement, and NFC’s range and throughput make it a poor fit for sustaining that exchange while a phone is being moved around near a reader.

So: tap to agree, then talk over Bluetooth.

Why the tap matters more than it looks

ISO/IEC 18013-5 also permits engagement via a QR code the reader scans. Both work. In a service environment, the tap has three practical advantages.

It is unambiguous. In a queue, several phones are within Bluetooth range. A tap identifies precisely one device without anyone having to disambiguate.

It is a deliberate act. Touching a phone to a reader is an intentional, physical decision by the holder. That is a clearer consent signal than a scan that could in principle be performed from a distance.

It works in bad conditions. Aiming a camera at a screen in a dark, crowded venue is unreliable; a tap is not affected by light, glare, or a cracked screen protector.

There is a fourth advantage that only matters after deployment: a tap is a gesture everyone already knows from contactless payment. Staff need no training for it and neither do customers.

Why the reader also needs the Bluetooth peripheral role

This is a detail that catches out hardware evaluations.

In the ISO/IEC 18013-5 device-retrieval flow, the reader may need to operate in a Bluetooth role that involves advertising and running a GATT server — behaviour people intuitively associate with the phone, not the reader. On modern Android, that role requires an advertising permission that a naive implementation will not have requested, because a reader “obviously” does not advertise.

The consequence for a buyer: an application can pass every functional test on a bench and fail on a specific Android version because of a permission that was never needed until the transport role was understood correctly. If you are qualifying hardware, this is one of the classes of failure to expect.

What varies between devices

The standard defines the protocol. It does not eliminate the differences between chipsets, radio firmware, and OEM Android builds. Three things vary in practice:

NFC reader-mode behaviour. Reader-mode activation is mediated by the platform, and there is a window where an application may believe it is scanning before the platform has actually enabled it. An implementation that renders “present your ID” before the platform call returns has a race that will surface as intermittent, hard-to-reproduce failures.

BLE connection behaviour. Connection setup timing, MTU negotiation, and stability under interference all differ. A concourse full of phones is a materially different radio environment from an office.

Timing under load. Everything above degrades when the venue is full — which is exactly when your age checks happen.

This is why physical validation on the specific hardware you intend to deploy is not a formality. A reader that works on one enterprise handheld has demonstrated something about its code, not about your device.

What staff should be told

Very little, which is the point:

• Hold the verifier so the customer can tap it. Do not take their phone.
• The customer keeps the phone throughout, including during the Bluetooth part.
• If the tap does not take, try again once; if it still does not, that is a cannot verify and the manual fallback applies.

Staff do not need to know which radio is doing what. They need to know what to do when it does not work, which should be the same thing every time.

Questions worth asking a vendor

• Which engagement methods does the reader support, and which is the default in production?
• Which Bluetooth roles does the reader implement, and which permissions does it request?
• On which specific devices and Android versions has the full transport path been physically tested?
• When the reader says “connected,” what has actually happened at that point?

That last one sounds pedantic and is not. A user interface that claims a connection before the transport can carry messages trains staff to trust a screen that is ahead of reality, and it makes real failures look like user error.

LaurelID’s transport behaviour

Laurel’s own implementation.

Engagement is NFC tap, and the session completes over BLE. There is no QR engagement in the current release. Reader mode is activated through a controlled path so the interface does not show a ready-to-present state before the platform call has returned, and the Bluetooth advertising permission the reader role actually requires is requested rather than assumed absent.

The interface reports only what is true at each stage: phone detected after ISO-DEP, connecting through handover and transport open, and receiving only once a response is present. Physical validation to date uses a Laurel-qualified enterprise Android profile; see hardware compatibility for the qualification approach.

Sources

1. ISO/IEC 18013-5:2021 — Mobile driving licence (mDL) application — ISO
2. In-person acceptance of digital credentials — Google
3. Present your driver's license or state ID from Apple Wallet — Apple