ISO/IEC 18013-5 is the international standard for mobile driving licence presentation and reader interaction. It defines how an mDL is stored, shared, and verified over proximity channels, so implementers must validate issuer signatures, consented disclosure, and compatibility with the prescribed presentation process.
What ISO/IEC 18013-5 Means in Practice
ISO/IEC 18013-5 is not just a file format for a mobile driving licence, it is the presentation model that determines how an mDL is shown to a reader, what data can be disclosed, and how the verifier interprets the exchange.
That matters because the standard is built around controlled disclosure and verification, not simple display. If implementers shortcut the prescribed flow, they can weaken issuer trust, expose more identity data than intended, or create interoperability failures across wallets and readers.
How mDL Presentation and Verification Work
At a high level, the standard separates issuance, storage, presentation, and reader verification. A wallet holds the credential, the holder initiates a presentation, and the relying party validates the issuer’s cryptographic assertions before trusting the disclosed attributes.
For implementers, the key design idea is that presentation is consented and scoped. The reader should only receive the data elements authorised for that transaction, and the verification logic must treat issuer signatures, device interaction, and prescribed presentation steps as part of one trust chain rather than isolated features.
The practical result is a standard that supports offline or proximity-based use cases without collapsing into a generic QR-code workflow. That distinction is important because proximity presentation changes user experience, device assurance expectations, and the security assumptions behind the reader interaction.
Interoperability, Trust, and Privacy Properties
ISO/IEC 18013-5 exists to make mDLs usable across issuers, wallets, and readers without every deployment inventing its own rules. It is therefore as much an interoperability standard as a credential standard, which is why reader compatibility and issuer validation are central to successful adoption.
It also encodes a privacy posture: the verifier should learn only what the transaction requires. Consent, selective disclosure, and presentation constraints reduce unnecessary exposure of personal data, especially when the mDL is used for age checks, access control, or identity proofing.
NHIMG’s Mobile Driving Licence (mDL) Guide goes deeper into how ISO 18013-5 relates to issuer data authentication, device engagement, and relying party verification.
For broader wallet ecosystems, the standard also sits alongside digital identity programme design. Digital Identity, eID and Identity Wallets Guide is useful context when organisations need to understand how mDLs fit into wallet-based identity architectures.
Implementation Failure Modes and Operational Consequences
The most common implementation failures are not theoretical, they are trust failures. If an app does not correctly validate issuer signatures, accepts an incompatible reader flow, or over-discloses attributes, the result can be false acceptance, privacy leakage, or rejection by legitimate verifiers.
There is also an operational interoperability risk. Because mDL presentation depends on both the wallet and the reader following the specification, one weak implementation can make an otherwise valid credential unusable in practice, even when the underlying credential itself is sound.
In environments that use mDLs for age assurance, regulated access, or high-volume verification, those failures can become business problems as well as security problems, because the organisation may lose trust in the credential or in the verification process itself.
Risk and Threat Considerations
mDL deployments concentrate trust into a small number of validation steps, which makes them attractive targets for spoofing, replay, weak reader validation, and privacy abuse. The main security concern is not the standard itself, but incorrect implementation of its consent and verification model.
Failure mechanism: An attacker or faulty integration can exploit weak signature checking, inconsistent reader behaviour, or excessive data release to cause false acceptance or unnecessary disclosure of identity attributes.
Impact: The organisation may accept a forged or improperly presented credential, expose more personal data than required, or create inconsistent verification outcomes across different wallets and readers.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | mDL systems rely on managed cryptographic assertions and presentation credentials. |
| IA-2 — Identification and Authentication (Organizational Users) | Verifiers must authenticate actors and trust presented identity assertions before relying on them. | |
| AU-2 — Event Logging | mDL verification needs auditable records of presentation and validation events. | |
| Recommendation — Enforce lifecycle controls for presentation credentials and related secrets. Require strong authentication before relying on mDL-validated access decisions. Log mDL presentation and verification events for later review. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | mDL presentation governs what identity data is disclosed to a relying party. |
| A.8.24 — Use of cryptography | The standard depends on issuer signatures and cryptographic verification. | |
| Recommendation — Define access rules for which mDL attributes may be disclosed and to whom. Protect issuer-signing and verification processes with approved cryptographic controls. | ||
Practitioner Guidance
Why practitioners should care: ISO/IEC 18013-5 only delivers its security and privacy value when the wallet, reader, and verifier all implement the presentation flow consistently. Treat compatibility testing and trust validation as part of the deployment, not as an integration afterthought.
Practitioner takeaway: If the reader cannot reliably validate the issuer and the prescribed disclosure flow, the mDL should not be treated as a trusted identity proof in production.
Related resources from NHI Mgmt Group
- Who is accountable for ISO/IEC 42001 evidence and AI access control?
- Why does ISO/IEC 27001:2022 matter for IAM and NHI programmes?
- Why do organisations choose ISO/IEC 27001 when they already have other security frameworks?
- What is the difference between ETSI TS 119 461 and ISO/IEC 30107 in identity proofing?