A tap between a phone and a reader is an appealing interaction because it looks simple. For a mobile credential, however, the tap is only the opening move.

In an ISO/IEC 18013-5-style proximity flow, NFC device engagement is the setup protocol that lets a wallet and a reader meet, exchange the information needed to establish a protected session, and agree on how the rest of the interaction will travel.

The important mental model is this:

“NFC engagement is a secure handover, not an ID-card read.”

The credential data and the cryptographic evidence that makes it trustworthy arrive later, inside the session that engagement makes possible.

Two roles, two NFC modes

The wallet and reader have deliberately asymmetric roles during engagement:

• The wallet behaves as an NFC Tag Device, exposing structured engagement information.

• The reader behaves as an NFC Reader Device and initiates the handover.

That does not mean the wallet is a passive identity card. It means NFC is used as a short-range rendezvous mechanism. The reader activates the interaction, reads the wallet’s NDEF content, and uses it to select a compatible connection method.

This setup commonly uses the NFC Forum Type 4 Tag model. The wallet exposes a small virtual file system: an NDEF application, a capability container, and an NDEF file. The reader uses familiar smart-card-style APDU operations such as SELECT, READ BINARY, and, when needed, GET RESPONSE to retrieve the engagement information.

Those details matter to implementers because “supports NFC” is not a sufficient requirement. A reader must also handle the transport rules around message sizes, chaining, timeouts, and a lost tag during the handover.

What the tap actually carries

The engagement message provides inputs for the next stage, rather than the attributes from a driving licence or identity credential.

It can include:

• an ephemeral public key from the wallet;

• a description of available connection methods; and

• information needed to establish a connection using a selected carrier.

The reader uses the wallet’s ephemeral key together with its own ephemeral key to derive session keys through Diffie-Hellman. Once both sides have derived the same keys, later messages are protected with symmetric encryption.

This distinction is easy to miss. The NFC exchange provides the doorway to a protected session; it is not the protected credential response. The wallet’s issuer-signed data, the holder’s device authentication, and the reader’s validation work belong to later stages of the proximity protocol.

Static handover: publish the options

The simplest handover is static.

The wallet publishes a Handover Select record containing one or more Alternative Carrier Records. Each record describes a connection method that the wallet can support. The reader reads those options and chooses one it can use.

Conceptually, the sequence is:

wallet NFC tag → reader: engagement data + available carriers reader → selected carrier: establish the data path reader ↔ wallet: protected verification session

The selected carrier might keep using NFC or move to another short-range transport such as Bluetooth Low Energy or Wi-Fi Aware. This is why it is misleading to describe NFC engagement as “sending the credential over NFC.” NFC may be the entire path, but it can also be the tap that launches another path.

Static handover works well when the wallet can advertise a useful set of options in advance and the reader can make the selection locally.

Negotiated handover: choose together

A negotiated handover lets the reader and wallet narrow the choice together.

Instead of publishing a final selection immediately, the wallet indicates that it supports handover negotiation. The reader sends a Handover Request containing the carriers it supports. The wallet returns a Handover Select with the chosen carrier.

wallet → reader: handover service + engagement information reader → wallet: supported carriers wallet → reader: selected carrier reader ↔ wallet: establish the selected data path

This is useful when compatible transports cannot be assumed. It makes the choice explicit rather than treating the reader’s preferred transport as an implementation detail.

The protocol can also carry optional engagement information from the reader and a session-establishment message during the NFC phase. When session establishment is used this way, the reader repeats it after moving to the selected data path and the wallet checks that the messages correspond. That repetition is a binding check: the session being continued over the chosen carrier must be the one negotiated at the tap.

Engagement and transport are separate choices

One of the most useful design distinctions is between engagement and transport.

Engagement answers: *How do these two devices discover each other and agree on the next step?*

Transport answers: *Where will the protected messages actually flow?*

NFC can answer both questions, but it does not have to. A user may tap a phone to start the interaction and then exchange the larger encrypted messages over BLE or Wi-Fi Aware. The handover records make that transition explicit.

For a product team, this means NFC support is not only a hardware decision. It affects interoperability choices, fallback paths, performance expectations, and the user’s perception of the interaction. A tap can be a clean consentful start to an exchange even when it is not the channel that carries every byte.

Security begins with a key exchange, not a visible code

It is tempting to put too much trust in the visible action: a tap looks local, and a QR code looks unique. Neither observation is enough on its own.

The security-relevant result of engagement is the ability to derive fresh session keys. The wallet provides an ephemeral public key during engagement; the reader contributes its own key material as the session is established. Both sides derive shared AES session keys and use them to protect the later request and response.

The initial NFC or QR data therefore should not be confused with the credential’s final trust evidence. It does not, by itself, prove which issuer signed a credential or which wallet key will authenticate a later response. Those questions are answered later by the mdoc’s signed Mobile Security Object, issuer-trust validation, and device authentication.

Keeping these layers separate is a feature, not a gap:

1. Engagement establishes fresh session context and a path to communicate.

2. Session protection keeps the request and response confidential in transit.

3. Issuer authentication and data integrity establish that disclosed attributes match a trusted issuer’s signed commitments.

4. Device authentication establishes that the responding wallet controls the key associated with the credential.

A robust reader needs all four. Proximity does not replace cryptographic verification.

The implementation boundary is interoperability

An implementation can fail before credential validation if its engagement layer is too narrow. A practical reader needs to account for matters such as:

• which handover modes and carriers it supports;

• APDU message lengths and response chaining;

• timeouts and interruption recovery when a user moves a device;

• the exact byte representation used in session-transcript inputs; and

• forward-compatible parsing when it encounters capabilities it does not recognize.

These are not cosmetic integration details. The handover must result in the same session context at both ends, and a reader that cannot handle a valid carrier or response shape can turn a standards-based flow into a device-specific one.

The right goal is not merely “the tap works in our demo.” It is that the tap produces a clear, protected, interoperable transition into verification.

What builders should take away

NFC device engagement gives a proximity interaction an elegant beginning: a deliberate short-range action that discovers a path, creates a fresh session context, and can move to the transport best suited to the exchange.

But it is not a shortcut around the rest of the trust model. The reader still needs a carefully scoped request, encrypted session messages, issuer-trust checks, integrity checks, and proof that the wallet controls the credential-bound key.

That framing leads to better systems. Treat the tap as a handover protocol—not as the credential itself—and the boundaries between usability, transport, and trust become much clearer.

References

This article is derived exclusively from the LLM Wiki pages listed in the source map. Those pages summarize ISO/IEC 18013-5, NFC Forum Connection Handover, and NFC Forum Type 4 Tag material; human review should confirm any standards-version or implementation-specific detail before publication.