A wallet-based identity check can look deceptively simple: a person taps a phone, scans a code, or holds a device near a reader. A name, an age, or a driving privilege appears on screen.

But the screen is not what makes the result trustworthy.

In a proximity flow, the wallet and the reader run a compact security protocol. They establish a protected channel, the reader asks for specific data, the wallet returns cryptographically authenticated evidence, and the reader checks both the evidence and the context in which it arrived.

That is the useful model for proximity verification: not “reading an ID from a phone,” but verifying a live, selective presentation of a mobile credential nearby.

The two participants

The interaction has two roles:

• The wallet holds a mobile document, or mdoc, on behalf of its holder.
• The reader is the verifier. It requests evidence and decides whether the response meets its trust policy.

An mdoc is not a screenshot or a plain data container. Its issuer signs a Mobile Security Object (MSO) that commits to the credential’s data elements and includes information such as its validity period and a public key associated with the holder’s device.

That structure enables three distinct checks:

1. the data came from a trusted issuer;
2. the disclosed values match what the issuer signed; and
3. the responding wallet controls the key associated with the credential.

A five-stage interaction

1. Device engagement

First, the devices need a way to find each other and agree on how to communicate. This is called device engagement.

The wallet can provide engagement information through a QR code or NFC. That information includes an ephemeral public key and one or more connection methods. Depending on the devices and implementation, the subsequent data channel can use BLE, NFC, or Wi-Fi Aware.

A useful distinction is that engagement is not the credential transfer. It is the setup phase: it gives both sides the inputs they need to establish a secure session and select a transport.

NFC can play more than one role here. It may be the tap used to exchange the initial handover information, while the actual credential exchange continues over another transport such as BLE. The engagement mechanism and the data transport are related, but they are not the same decision.

2. Establish an encrypted session

Once the reader has the wallet’s ephemeral public key, both sides derive shared session keys through an ephemeral Diffie-Hellman exchange. Subsequent protocol messages are encrypted with symmetric session keys.

This matters because physical proximity alone is not a security property. A tap or a QR scan must not turn the credential exchange into readable radio traffic. The protected session binds the later request and response to the interaction that the two devices just established.

3. Ask for the minimum necessary evidence

The reader sends a DeviceRequest through that encrypted session. It identifies the document and the attributes the service needs.

This is where a product decision becomes a protocol decision. A well-designed request asks for the minimum evidence needed to complete the transaction. For example, a service may need proof that a person meets an age threshold, not a full copy of every attribute in an identity document.

The wallet can then obtain the holder’s approval and prepare a response containing the requested subset of data. Selective disclosure is not an add-on to this model; it is part of why the model is useful.

4. Return a live presentation

The wallet returns a DeviceResponse over the encrypted channel. It contains the selected issuer-signed data and the proof material needed to verify it.

The MSO is central here. The issuer has signed a structure containing digests for the credential’s data elements. The reader can verify that each disclosed value corresponds to an issuer-committed digest, even though other values remain undisclosed.

The wallet also performs device authentication: it proves possession of the private key corresponding to the credential’s DeviceKey. This is holder binding in the mdoc world. It gives the reader evidence that it is interacting with the wallet that controls the credential’s associated key, rather than merely receiving a copied data file.

5. Validate a stack of evidence

A reliable reader does not stop after parsing a response. It evaluates several layers of evidence:

1. Session protection: Was the request/response exchange carried inside the established encrypted session?
2. Issuer trust: Is the issuer signature valid, and does the document-signing certificate lead to an acceptable trust authority?
3. Data integrity: Do the disclosed values match the signed MSO digests?
4. Holder binding: Did the wallet successfully authenticate with the key associated with the credential?
5. Validity and status: Is the credential within its allowed validity period, and are relevant certificate-status checks acceptable under the verifier’s policy?

These checks answer different questions. An issuer signature establishes where claims came from. Digest verification establishes that selected values have not changed. Device authentication establishes that the response is a live use of the credential by the key-holding wallet. Session encryption protects the exchange itself.

Skipping one does not make the others redundant.

Trust is more than a signature

It is tempting to describe credential verification as “check a signature.” That is necessary, but incomplete.

For mdocs, issuer trust is commonly expressed through a certificate hierarchy. An issuer authority signs document-signer certificates, which in turn sign the MSO. A verifier evaluates that chain against the trust material it accepts. A verified list of issuer authorities can help distribute that trust information without giving the list operator the power to revoke each authority directly.

This is a useful reminder for system design: cryptography authenticates statements relative to keys and trust anchors. The verifier still needs an explicit policy about which authorities, validity windows, and status signals it accepts.

Why the QR code is not the credential

A common misconception is that all security must be visible in the engagement QR code or NFC tap. That is not how the model works.

The engagement data bootstraps the session. The secure binding emerges from the cryptographic session establishment and the authenticated response that follows. The credential’s issuer evidence and the wallet’s device authentication are evaluated later, inside the verification flow.

This separation is a strength. It allows the initial interaction to be lightweight while keeping the meaningful security checks in the protected protocol exchange.

What builders should design for

A proximity-verification implementation is not complete when two devices can connect. The important design questions are:

• Which facts are necessary for the transaction, and which are excessive?
• Which connection methods must work in the environments where the service operates?
• Which issuers and certificate chains are trusted?
• How will the reader distinguish issuer authentication, data integrity, holder binding, expiry, and status failures?
• How will the user understand and approve the requested disclosure?
• What should happen when an online status check is unavailable?

The technical flow is short, but the trust boundary is substantial. The reader is not consuming an identity-card image; it is making a decision from a set of cryptographic proofs, a fresh session, and a carefully scoped request.

That is the promise of proximity verification: in-person interactions can request less data while getting stronger evidence about the data they do receive.