ISO/IEC 18013-7: presenting your licence to a website

Mobile driver licences already work well face to face. A reader connects to a phone, receives signed data, and checks the signature. Our ISO/IEC 18013-5 explainer covers how that works.

Most identity checks no longer happen at a counter, though. People open bank accounts, hire cars and register for wagering from the couch. ISO/IEC 18013-7 is designed to bring the same signed credential to those remote journeys.

Why in-person verification needed an online sibling

ISO/IEC 18013-5 assumes the holder and the verifier share a room. Its transports — QR engagement, NFC, Bluetooth — are all short range. A website on the other side of the country cannot tap a phone.

So remote teams built around photo uploads instead. A customer photographs their plastic card, then records a selfie. Software inspects the images and estimates whether they are genuine.

That approach works, but the evidence is pixels, not cryptography. Images can be edited, replayed or generated by AI. A signature check either passes or fails, with no judgement call in between.

What ISO/IEC 18013-7 defines, in plain words

ISO/IEC TS 18013-7 was published as a technical specification in 2024, with a revised edition in 2025. It adds one capability to the mDL: presentation to a reader over the internet. The credential itself does not change.

The data format, the issuer signature and the device keys all stay as Part 5 defined them. Part 7 specifies how a website or app requests that credential remotely. It defines a REST API and an interoperable profile of OpenID4VP.

OpenID4VP — OpenID for Verifiable Presentations — is an open protocol built on OAuth 2.0. A verifier sends a request; a wallet returns a signed presentation. Version 1.0 of the protocol was finalised in July 2025.

The 2025 edition also describes retrieval through a browser-mediated credentials interface. That route lets the browser broker the handoff between website and wallet. Both paths are designed to deliver the same signed response.

A remote presentation, end to end

Here is how a flow looks from the customer's side. The details vary by wallet, but the shape is consistent.

• The customer clicks "Verify with your digital licence" on a website or in an app.
• The site sends a request naming the fields it needs, such as name and date of birth.
• The phone hands the request to the customer's wallet, which opens on screen.
• The wallet shows who is asking and exactly which fields they want.
• The customer approves with a face or fingerprint unlock, or declines.
• The wallet returns a signed response, bound to that session, back to the website.

The relying party then verifies the response server-side. It checks the issuer signature, the device signature and the session binding. Only then does the data enter the onboarding decision.

Selective disclosure carries over from the in-person model. A wagering site can request date of birth without the home address. The consent screen makes the ask visible to the customer.

For the customer, the exchange is designed to take seconds. There is no photographing a card under bad light. There are no retries because a hologram glared.

What the relying party actually receives

A photo upload gives you an image that resembles a licence. An 18013-7 response gives you three stronger things.

• Issuer-signed data: every field carries the licensing authority's signature, so tampering is detectable.
• Device binding: a signature from keys held in the phone's secure hardware, tying the credential to that device.
• Session binding: the response is tied to this specific request, which is designed to defeat replays.

Trust anchors work the same way as in-person checks. The verifier validates signatures against published issuer certificates from trusted lists. Our offline verification article walks through that trust model.

The practical difference is the nature of the evidence. A stolen card photo can pass a lenient image check. It cannot produce a fresh device signature over a new session.

What this changes for remote onboarding

Today's remote onboarding standard is document photo plus selfie. OCR extracts the fields, forensics scores the document, and liveness ties the selfie to a real person. It works, and it is universal — everyone with a passport or licence can attempt it.

An 18013-7 presentation compresses that pipeline for eligible users. There is nothing to OCR and no document forensics to run. The wallet's own unlock provides the holder check, backed by device binding.

It complements photo pipelines rather than replacing them. Most customers do not hold a digital credential yet. OCR plus liveness remains the path for them, and will for years.

The sensible architecture is one decision layer with two evidence routes. Offer the credential path where wallets exist. Fall back to document capture everywhere else.

An honest word on maturity

ISO/IEC 18013-7 is young. The first edition landed in 2024, and the OpenID4VP protocol it profiles was only finalised in mid-2025. AAMVA added Part 7 guidance to its mDL implementation guidelines in May 2025.

Wallet and issuer support is still rolling out, and it varies by jurisdiction. Some wallets already support remote presentation; many issuers have yet to enable it. Anyone planning around Part 7 should assume uneven coverage for a while.

That argues for hybrid strategies, not waiting. Teams that wire in credential verification now can grow coverage as wallets do. The photo pipeline keeps carrying everyone else in the meantime.

If you are weighing this up, our TENSAI mDL verification SDK verifies credentials to both ISO/IEC 18013-5 and 18013-7. It sits alongside document OCR and liveness in our digital identity platform. Both evidence routes land in one place.