ISO/IEC 18013-5:2021

INTERNATIONAL ISO/IEC
STANDARD 18013-5
First edition
2021-09
Personal identification — ISO-
compliant driving licence —
Part 5:
Mobile driving licence (mDL)
application
Identification des personnes — Permis de conduire conforme à
l'ISO —
Partie 5: Application permis de conduire sur téléphone mobile
Reference number
© ISO/IEC 2021
© ISO/IEC 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
© ISO/IEC 2021 – All rights reserved

Contents Page
Foreword .v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 3
4 Abbreviated terms . 5
5 Conformance requirement . 6
6 mDL overview . 6
6.1 Interfaces . 6
6.2 Functional requirements . 7
6.3 Technical requirements . 8
6.3.1 Data model . 8
6.3.2 Data exchange . 8
6.3.3 Security mechanisms . 13
7 mDL data model .15
7.1 mDL document type and namespace . 15
7.2 mDL data . 16
7.2.1 Overview . 16
7.2.2 Portrait of mDL holder . 21
7.2.3 Issuing authority . 21
7.2.4 Categories of vehicles/restrictions/conditions . 21
7.2.5 Age attestation: nearest “true” attestation above request .22
7.2.6 Biometric template . 23
7.2.7 Signature or usual mark . 23
7.2.8 Domestic data elements .23
7.3 Country codes .23
8 Transaction .23
8.1 Encoding of data structures and data elements . 23
8.2 Device engagement . 24
8.2.1 Device engagement information . 24
8.2.2 Device engagement transmission technology . 26
8.2.3 Device engagement time-out .28
8.3 Data retrieval .29
8.3.1 Data model . 29
8.3.2 Data retrieval methods . .29
8.3.3 Data retrieval transmission technologies .36
9 Security mechanisms .47
9.1 Device retrieval . 47
9.1.1 Session encryption . 47
9.1.2 Issuer data authentication .49
9.1.3 mdoc authentication . 52
9.1.4 mdoc reader authentication . 55
9.1.5 Session transcript and cipher suite .56
9.2 Server retrieval .58
9.2.1 TLS .58
9.2.2 JWS .58
9.3 Validation and inspection procedures . 59
9.3.1 Inspection procedure for issuer data authentication . 59
9.3.2 Inspection procedure for JWS . 59
9.3.3 Certificate validation procedure .60
iii
© ISO/IEC 2021 – All rights reserved

Annex A (informative) BLE L2CAP transmission profile .61
Annex B (normative) Certificate and CRL profiles .62
Annex C (informative) Verified issuer certificate authority list (VICAL) provider .90
Annex D (informative) Data structure examples . 112
Annex E (informative) Privacy and security recommendations . 135
Annex F (informative) IANA Considerations . 149
Bibliography . 153
iv
© ISO/IEC 2021 – All rights reserved

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
The procedures used to develop this document and those intended for its further maintenance
are described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria
needed for the different types of document should be noted. This document was drafted in
accordance with the editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives or
www.iec.ch/members_experts/refdocs).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents) or the IEC
list of patent declarations received (see https://patents.iec.ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see
www.iso.org/iso/foreword.html. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 17, Cards and security devices for personal identification.
A list of all parts in the ISO/IEC 18013 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.
v
© ISO/IEC 2021 – All rights reserved

Introduction
The ISO/IEC 18013 series establishes guidelines for the design format and data content of an ISO-
compliant driving licence (IDL) with regard to human-readable features (ISO/IEC 18013-1), ISO
machine-readable technologies (ISO/IEC 18013-2), access control, authentication and integrity
validation (ISO/IEC 18013-3), and associated test methods (ISO/IEC 18013-4). It creates a common
basis for international use and mutual recognition of the IDL without impeding individual countries/
states in applying their privacy rules and national/community/regional motor vehicle authorities in
taking care of their specific needs.
This document describes interface and related requirements to facilitate ISO-compliant driving
licence (IDL) functionality on a mobile device. The requirements are specifically intended to enable
verifiers not affiliated with or associated with the issuing authority to gain access to and authenticate
the information. In addition, the requirements allow the holder of the driving licence to decide what
information to release to a verifier. Other characteristics include the ability to update information
frequently, and to authenticate information at a high level of confidence.
A mobile document conforming to this document primarily conveys the driving privileges associated
with a person. It does so by providing means to associate the person presenting the mobile document
with the mobile document itself. However, the transaction and security mechanisms in this document
have been designed to support other types of mobile documents, specifically including identification
documents. Consequently the mechanisms in this document can be used for any type of mobile
identification document, regardless of the additional attributes the mobile document may convey. The
details of the data elements to be used by other mobile documents are left to the respective issuing
authority and are not within the scope of this document.
vi
© ISO/IEC 2021 – All rights reserved

INTERNATIONAL STANDARD ISO/IEC 18013-5:2021(E)
Personal identification — ISO-compliant driving licence —
Part 5:
Mobile driving licence (mDL) application
1 Scope
This document establishes interface specifications for the implementation of a driving licence in
association with a mobile device. This document specifies the interface between the mDL and mDL
reader and the interface between the mDL reader and the issuing authority infrastructure. This
document also enables parties other than the issuing authority (e.g. other issuing authorities, or mDL
verifiers in other countries) to:
— use a machine to obtain the mDL data;
— tie the mDL to the mDL holder;
— authenticate the origin of the mDL data;
— verify the integrity of the mDL data.
The following items are out of scope for this document:
— how mDL holder consent to share data is obtained;
— requirements on storage of mDL data and mDL private keys.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO 3166-1, Codes for the representation of names of countries and their subdivisions — Part 1: Country
code
ISO 3166-2:2020, Codes for the representation of names of countries and their subdivisions — Part 2:
Country subdivision code
ISO/IEC 5218, Information technology — Codes for the representation of human sexes
ISO/IEC 7816-4:2020, Identification cards — Integrated circuit cards — Part 4: Organization, security and
commands for interchange
ISO/IEC 8859-1, Information technology — 8-bit single-byte coded graphic character sets — Part 1: Latin
alphabet No. 1
ISO/IEC 18004, Information technology — Automatic identification and data capture techniques — QR
Code bar code symbology specification
ISO/IEC 18013-1:2018, Information technology — Personal identification — ISO-compliant driving licence
— Part 1: Physical characteristics and basic data set
ISO/IEC 18013-2:2020, Personal identification — ISO-compliant driving licence — Part 2: Machine-
readable technologies
© ISO/IEC 2021 – All rights reserved

ISO/IEC 19785-3:2020, Information technology — Common Biometric Exchange Formats Framework —
Part 3: Patron format specifications
BSI TR-03111, Elliptic Curve Cryptography, Version 2.10, June 2018
FIPS 186-4:2013, D                                   igital Signature Standard (DSS)
NFC Forum, Connection Handover (CH) Technical Specification, Version 1.5
NIST SP 800-38D, M. Dworkin, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode
(GCM) and GMAC, November 2007
OpenID Foundation OpenID Connect Core 1.0 incorporating errata set 1
OpenID Foundation OpenID Connect Discovery 1.0 incorporating errata set 1
RFC 4122, P. Leach et al., A Universally Unique IDentifier (UUID) URN Namespace, July 2005
RFC 4648, S. Josefsson, The Base16, Base32, and Base64 Data Encodings, October 2006
RFC 5246, T. Dierks et al., The Transport Layer Security (TLS) Protocol Version 1.2, August 2008
RFC 5280, D. Cooper et al., Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile, May 2008
RFC 5639, M. Lochter et al., Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve
Generation, March 2010
RFC 5869, H. Krawczyk, HMAC-based Extract-and-Expand Key Derivation Function (HKDF), May 2010
RFC 6066, D. Eastlake 3rd, Transport Layer Security (TLS) Extensions: Extension Definitions, January 2011
RFC 7049, C. Bormann et al., Concise Binary Object Representation (CBOR), October 2013
RFC 7515, J. Bradley et al., JSON Web Signature (JWS), May 2015
RFC 7518, M. Jones et al., JSON Web Algorithms (JWA), May 2015
RFC 7519, J. Bradley et al., JSON Web Token (JWT), May 2015
RFC 7748, A. Langley et al., Elliptic Curves for Security, January 2016
RFC 7905, A. Langley et al., ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS), June 2016
RFC 8032, S. Josefsson et al., Edwards-Curve Digital Signature Algorithm (EdDSA), January 2017
RFC 8152, J. Schaad, CBOR Object Signing and Encryption (COSE), July 2017
RFC 8252, W. Denniss et al., Oauth 2.0 for Native Apps, October 2017
RFC 8259, T. Bray, The JavaScript Object Notation (JSON) Data Interchange Format, December 2017
RFC 8410, S. Josefsson et al., Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the
Internet X.509 Public Key Infrastructure, August 2018
RFC 8422, Y. Nir et al., Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
Versions 1.2 and Earlier, August 2018
RFC 8943, M. Jones et al., Concise Binary Object Representation (CBOR) Tags for Date, November 2020
RFC, CBOR Object Signing and Encryption (COSE): Headers for carrying and referencing X.509 certificates
Wi-Fi Alliance, Neighbor Awareness Networking Specification, Version 3.1
© ISO/IEC 2021 – All rights reserved

3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
mobile device
portable computing device that at least:
— has a small form factor such that it can easily be carried by a single individual;
— is designed to operate, transmit and receive information without a wired connection;
— possesses local, nonremovable or removable data storage;
— includes a self-contained power source;
— includes a display;
— includes a means for the holder of the portable computing device to interact with the device
Note 1 to entry: Adapted from NIST SP 800-157.
3.2
mdoc
document or application that resides on a mobile device (3.1) or requires a mobile device as part of the
process to gain access to the document or application
3.3
mdoc reader
device that can retrieve mdoc (3.2) data for verification purposes
3.4
mdoc holder
individual to whom an mdoc (3.2) is issued
3.5
mdoc verifier
person or organization using and/or controlling an mdoc reader (3.3) to verify an mdoc (3.2)
3.6
mDL
driving licence that fulfils at least the same function as an IDL but, instead of being paper or plastic
based, is an mdoc (3.2)
Note 1 to entry: ISO-compliant driving licence (IDL) is defined in ISO/IEC 18013-1.
3.7
mDL reader
mdoc reader (3.3) that can retrieve mDL (3.6) data
3.8
mDL holder
individual to whom an mDL (3.6) is issued, i.e. legitimate holder of the driving privileges reflected on an
mDL
© ISO/IEC 2021 – All rights reserved

3.9
mDL verifier
person or organization using and/or controlling an mDL reader (3.7) to verify an mDL (3.6)
3.10
licensing authority
authorized agent organisation that issues a driving licence
EXAMPLE National, federal, state, provincial, regional, territorial, or local Ministry of Transport, Department
of Motor Vehicles, or Police Agency.
[SOURCE: ISO/IEC 18013-1:2018, 3.15]
3.11
issuing country
country which issued the driving licence or within which the licensing authority (3.10) is located
[SOURCE: ISO/IEC 18013-1:2018, 3.12, modified — The words “according to Annex F” have been
removed.]
3.12
issuing authority
licensing authority (3.10), or issuing country (3.11) if separate licensing authorities have not been
authorized
[SOURCE: ISO/IEC 18013-1:2018, 3.11]
3.13
issuing authority infrastructure
infrastructure under control of the issuing authority (3.12)
3.14
issuing authority CA
certificate authority operated by or on behalf of an issuing authority (3.12)
3.15
device retrieval
method of data retrieval exclusively using the interface between the mdoc (3.2) and the mdoc reader
(3.3)
3.16
server retrieval
method of data retrieval using the interface between the mdoc reader (3.3) and the issuing authority
infrastructure (3.13)
3.17
server retrieval token
token identifying the mdoc holder (3.4) and the mdoc (3.2) to the issuing authority (3.12)
3.18
PCD mode
mode in which an NFC-enabled mobile device (3.1) operates as a PCD
[SOURCE: ISO/IEC 14443-3:2018, 3.7, modified — The words “a PXD” have been replaced with “an NFC-
enabled mobile device”.]
3.19
PICC mode
mode in which an NFC-enabled mobile device (3.1) operates as a PICC
[SOURCE: ISO/IEC 14443-3:2018, 3.8, modified — The words “a PXD” have been replaced with “an NFC-
enabled mobile device”.]
© ISO/IEC 2021 – All rights reserved

4 Abbreviated terms
AES advanced encryption standard
APDU application protocol data unit ®
BLE Bluetooth low energy
BT SIG Bluetooth special interest group
CA certificate authority
CBOR concise binary object representation
CDDL concise data definition language
COSE CBOR object signing and encryption
CSPRNG cryptographically secure pseudo-random number generator
CRL certificate revocation list
DER distinguished encoding rules
DS document signer
ECDH elliptic curve Diffie-Hellman key agreement
ECDSA elliptic curve digital signature algorithm
EdDSA Edwards-curve digital signature algorithm
GATT generic attribute profile
HKDF HMAC-based extract-and-expand key derivation function
HMAC hash-based MAC
IA issuing authority
IACA issuing authority certificate authority
IANA internet assigned number authority
IDL ISO-compliant driving licence
IKM input keying material
JSON JavaScript object notation
JWK JSON web key
JWS JSON web signature
JWT JSON web token
KDF key derivation function
MAC message authentication code
MITM man-in-the-middle attack
© ISO/IEC 2021 – All rights reserved

MSO mobile security object
MTU maximum transmission unit
NDEF NFC data exchange format
NFC near field communication
OCSP online certificate status protocol
OID object identifier
OIDC OpenID connect
PCD proximity coupling device
PICC proximity card or object
PKI public key infrastructure
RF radiofrequency
RFU reserved for future use
SHA secure hash algorithm
TLS transport layer security
URI uniform resource identifier
URL uniform resource locator
UTC coordinated universal time
UUID universally unique identifier
VICAL verified issuer certificate authority list
5 Conformance requirement
An mDL is in conformance with this document if it meets all the requirements specified directly or
by reference herein. Conformance with ISO/IEC 18013-1, ISO/IEC 18013-2, ISO/IEC 18013-3, and ISO/
IEC 18013-4 is not required for conformance with this document, except for those clauses normatively
referenced in this document.
An mDL reader is in conformance with this document if it meets all the requirements specified directly
or referenced herein.
An issuing authority infrastructure is in conformance with this document if it meets all the requirements
specified directly or referenced herein.
6 mDL overview
6.1 Interfaces
Figure 1 shows the interfaces in scope for this document. The explanation of each interface is as follows.
— Interface 1 in Figure 1 is the interface between the issuing authority infrastructure and the mDL.
This interface is out of scope for this document.
© ISO/IEC 2021 – All rights reserved

— Interface 2 in Figure 1 is the interface between the mDL and the mDL reader. This interface
is specified in this document. The interface can be used for connection setup and for the device
retrieval method.
— Interface 3 in Figure 1 is the interface between the issuing authority infrastructure and the mDL
reader. This interface is specified in this document. The interface can be used for the server retrieval
method.
See Reference [9] for examples of use cases.
Figure 1 — mDL interfaces
6.2 Functional requirements
The functional requirements include at least the following.
a) An mDL verifier together with an mDL reader shall be able to request, receive and verify the
integrity and authenticity of an mDL whether online connectivity is present or not for either the
mDL or mDL reader.
b) An mDL verifier not associated with the issuing authority shall be able to verify the integrity and
authenticity of an mDL.
c) An mDL verifier shall be enabled to confirm the binding between the person presenting the mDL
and the mDL holder.
d) The interface between the mDL and the mDL reader shall support the selective release of mDL data
to an mDL reader.
© ISO/IEC 2021 – All rights reserved

6.3 Technical requirements
6.3.1 Data model
The mDL data is organized as individual data elements which can be requested and returned
independently from each other. The mDL data model is described in Clause 7. It describes the identifier
and format of the data elements.
NOTE The concepts used in this document have been designed so that other mobile credentials, e.g. mobile
identity or other credentials that substitute Table 5 with a different set of data elements, can also make use of
the engagement and retrieval protocols described in this document. Specifically, the mdoc data model, which is
illustrated in Figure 2, is based on elements with unique identifiers within a namespace. The number of elements
can vary, and the model is indifferent to the value and data format of each element. As such the data model is
generic and can apply to any kind of document.
Figure 2 — mdoc data model
6.3.2 Data exchange
6.3.2.1 Overview
The mDL and mDL reader are implemented as an mdoc and mdoc reader, for which the requirements
are described in Clause 8 and Clause 9.
© ISO/IEC 2021 – All rights reserved

Data exchange is divided into three phases: the initialization phase, the device engagement phase, and
the data retrieval phase (as illustrated in Figure 3). After initialization between the mDL and the mDL
reader three different transaction flows are distinguished:
— device engagement, followed by exchange of data using device retrieval between the mDL and the
mDL reader [see (1) in Figure 3];
— device engagement, followed by exchange of server retrieval information using device retrieval
between the mDL and the mDL reader, followed by exchange of data using server retrieval between
the mDL reader and the issuing authority infrastructure [see (2) in Figure 3];
— device engagement, followed by exchange of data using server retrieval between the mDL reader
and the issuing authority infrastructure [see (3) in Figure 3].
NOTE 1 For device retrieval, there is no requirement for any device involved in the transaction to be connected
to the internet.
If the mDL reader receives the server retrieval token and URL from the mDL, either during device
engagement or device retrieval, it may either use device retrieval or server retrieval. If it chooses to use
device retrieval, either BLE, NFC or Wi-Fi Aware can be used to retrieve the information. If it chooses to
use server retrieval, either OIDC or WebAPI can be used to retrieve the information.
NOTE 2 The transaction has been designed such that it is not necessary for the mDL holder to physically hand
over the mobile device to the mDL verifier.
NOTE 3 The transaction protocols in this document provide generic means for a user to share connection
information and optionally a server retrieval token.
The device data retrieval transport applies to any kind of data as it is designed to transport an encrypted blob.
The request and response commands (transported encrypted) are applicable to any kinds of document based
on the mdoc data model and/or request for server retrieval token. Furthermore, the request and response
commands are wallet compliant as elements from different documents can be requested and the response can
include multiple documents from the same or different kinds.
The server retrieval method relies on OpenID Connect that is not specific to mDL, or on WebAPI that relies on the
generic mdoc data model.
© ISO/IEC 2021 – All rights reserved

Figure 3 — mDL transaction flow
6.3.2.2 Initialization
During initialization, the mDL is activated. Activation is done by the mDL holder, or triggered by an
mDL reader using NFC. Simultaneously, the mDL reader is activated. No requirements are specified for
this phase.
NOTE It is important to avoid unauthorized access by an mDL reader if mDL activation is triggered by NFC.
6.3.2.3 Device engagement
During device engagement, information required to setup and secure data retrieval is exchanged
between the mDL and the mDL reader. Transmission technologies available to transfer the device
engagement data are as follows:
a) NFC,
b) QR code.
Table 1 shows the different transmission technologies for device engagement.
© ISO/IEC 2021 – All rights reserved

Table 1 — Device engagement technologies
Support
Transmission
Reference
technologies
mDL mDL reader
a
NFC C M 8.2.2.1
a
QR code C M 8.2.2.3
Key
C  conditional
M  mandatory
a
Support for at least one of these methods is mandatory.
The device engagement information, described in 8.2.1, is transferred using one of the transmission
technologies, described in 8.2.2.
To ensure that the device engagement is always possible, an mDL shall support at least one of the
transmission technologies in Table 1. An mDL reader shall support all transmission technologies.
If the mDL supports NFC for device engagement, it shall support Static Handover, Negotiated Handover,
or both, as described in 8.2.2.1. The mDL reader shall support both handover methods.
6.3.2.4 Data retrieval architecture
Figure 4 shows the different data retrieval interfaces and the flow of the messages.
When using device retrieval, the mDL and mDL reader communicate using mdoc request and mdoc
response messages encoded with CBOR. These messages are transported using a data retrieval method.
The data retrieval methods are agnostic to the information that is transferred.
After device engagement, if the mDL reader sets up a device retrieval connection, the mDL reader
asks for data as defined in 8.3.2.1.2.1. The mDL sends an mdoc response according to 8.3.2.1.2.2. The
mdoc request may include a request for server retrieval information used to perform server retrieval.
If server retrieval information is requested next to other mDL data, the mDL shall return either the
server retrieval information or the other requested data, but not both.
The different data retrieval methods are described in 6.3.2.5.
© ISO/IEC 2021 – All rights reserved

Figure 4 — Data retrieval architecture
NOTE 1 The secure area as present in Figure 4 indicates an area that provides additional protection of
sensitive mDL related data. Security requirements regarding storage of credential information are outside
the scope of this document. This includes the mDL private key and the mDL reader private key, if mdoc reader
authentication or TLS client authentication is supported by the mDL reader. It is the responsibility of the issuing
authority to ensure that all data stored on the mDL is stored securely.
NOTE 2 Implementation possibilities for a secure area are non-exhaustively listed in Clause E.5.
6.3.2.5 Data retrieval methods
The following methods are defined for retrieval of mDL data. Requirements for supporting these
methods are defined in Table 2.
mDL data can be retrieved in two ways:
a) using device retrieval (interface 2 in Figure 1), see 8.3.2.1;
b) using server retrieval (interface 3 in Figure 1), see 8.3.2.2, where the server retrieval token may be
retrieved by the mDL reader from the mDL during device engagement or during device retrieval.
Table 2 shows the transmission technologies and data retrieval methods.
© ISO/IEC 2021 – All rights reserved

Table 2 — Data retrieval methods
Support
Data retrieval Transmission
issuing author-
Reference
method technology
mDL mDL reader ity infrastruc-
ture
a
BLE C M N/A 8.3.3.1.1
a
Device retrieval NFC C M N/A 8.3.3.1.2
Wi-Fi Aware O R N/A 8.3.3.1.3
WebAPI O R O 8.3.3.2.1
Server retrieval
OIDC O R O 8.3.3.2.2
Key
M  mandatory
C   conditional
R   recommended
O   optional
N/A  not applicable
a
Support for at least one of these methods is mandatory.
To ensure that data retrieval is always possible, an mDL shall support device retrieval using BLE,
NFC, or both transmission technologies. An mDL reader shall support the BLE and NFC transmission
technology for device retrieval.
An mDL may support Wi-Fi Aware and an mDL reader should support Wi-Fi Aware.
An mDL and an issuing authority infrastructure may support WebAPI, OIDC or both and an mDL reader
should support WebAPI and OIDC.
For device retrieval using BLE, the mDL reader shall support the mdoc central client mode and mdoc
peripheral server mode, as defined in 8.3.3.1.1. The mDL and mDL reader may support the BLE L2CAP
transmission profile as defined in Annex A.
All data retrieval methods shall use the data model as defined in Clause 7.
See Annex D for examples of data structures.
NOTE 1 If QR is used for device engagement and the mDL reader chooses to use NFC for data transfer, then
there is no mechanism available for the mDL reader to indicate the choice for NFC data transfer to the mDL. It is
possible that the mDL holder is not aware that the mDL needs to interface with the mDL reader using NFC. On the
contrary, if NFC is used for device engagement, this problem does not exist.
NOTE 2 Due to the limited data transfer rate for NFC, if a large amount of data is required for a transaction, it
is possible that it is neither practical nor reasonable to have an mDL holder hold the device within the RF range
of the mDL reader for the duration of the transaction. Furthermore, due to the loss of signal when a device leaves
the RF field, any mDL holder interactions with the mDL causing the mDL to leave the RF field require a new
transaction to be initiated. This can be avoided by having all mDL holder interactions with the mDL done while
the mDL stays in the field or if mDL does not require any mDL holder interactions while it is in the RF field.
6.3.3 Security mechanisms
The security of mDL data exchanged with an mDL reader is designed to preserve the triad of
confidentiality, integrity, and authenticity by design and by default.
The security architecture aims to achieve four distinct goals.
a) Protection against forgery: data elements are signed by the issuing authority (IA). The degree of
protection against forgery depends on the degree to which the IA's keys are protected. Minimizing
the validity period of the data limits the value of the data.
© ISO/IEC 2021 – All rights reserved

b) Protection against cloning: the mDL produces a signature or message authentication code over
session data. The private key used to authenticate the session data is stored only in the mDL. The
corresponding public key in turn is signed by the IA. The degree of protection against cloning
depends on the degree to which the mDL authentication key or the TLS server key is protected.
c) Protection against eavesdropping: communications between mDL and mDL reader are encrypted
and authenticated. Device engagement uses a separate communication channel to mitigate the
risk of Man in the Middle (MITM) attacks. In addition, the mDL reader can detect MITM attacks by
validating the anti-cloning signature or message authentication code, which is created using a key
for which the public part is signed by the IA in the mobile security object (MSO, see 9.1.2.4). If mdoc
reader authentication is used, the mDL can detect MITM attacks before returning any data. Server
retrieval uses TLS for encryption to further protect against eavesdropping and MITM attacks.
d) Protection against unauthorized access: an mDL is protected from unauthorized access by
an mDL reader by multiple mechanisms. If device retrieval is used, the encryption key used for
communications between the mDL and mDL reader is derived from an ephemeral key pair from
both the mDL and mDL reader. The public key of the mDL is shared only through short-range
device engagement. This ensures data is only transferred between the mDL and a particular mDL
reader. The mDL can optionally authenticate the mDL reader by means of an mDL reader certificate
and a signature created by the mDL reader using the corresponding private key. The mDL reader
certificate is signed by a certificate authority trusted by the mDL for this purpose.
Server retrieval uses a server retrieval token which can be used to ensure that data is only
transferred between the IA infrastructure and a particular mDL reader. Moreover, the IA can
optionally authenticate the mDL reader by means of TLS client authentication.
Revocation of an mDL is out of scope for this document. However, the MSO includes update information
and validity time frames which enable the mDL reader to check the freshness of the data. The issuing
authority shall define appropriate periods of validity that balance freshness with offline capability,
taking into account that a shorter validity period mitigates certain security risks.
Table 3 describes the security mechanisms that can be implemented for each data retrieval interface.
For device retrieval, issuer data authentication, session encryption and mdoc authentication shall be
implemented. mdoc reader authentication is optional for device retrieval and TLS client authentication
is optional for server retrieval. For server retrieval, Transport Layer Security (TLS), and JSON Web
Signature (JWS) shall be implemented.
Table 4 describes security goals and mechanisms for different data retrieval methods.
When server retrieval is used, the mDL should use one-time server retrieval tokens.
The certificate and CRL profile requirements in Annex B shall be applied.
All certificates issued by an IACA or another CA shall be validated according to 9.3.3.
An mDL reader needs access to the issuing authority’s certificate authority (IACA) root certificate to
verify issuer data authentication, verify the JWS and perform TLS. One optional method to get access to
these certificates is described in Annex C.
See Annex E for additional information on privacy and security.
Table 3 — Security mechanisms
Data retrieval method Security mechanisms Reference
Device retrieval Session encryption 9.1.1
Issuer data authentication 9.1.2
mdoc authentication 9.1.3
mdoc reader authentication 9.1.4
a
Only applicable if the server retrieval token is transferred using device retrieval.
© ISO/IEC 2021 – All rights reserved

Table 3 (continued)
Data retrieval method Security mechanisms Reference
Server retrieval TLS 9.2.1
JWS 9.2.2
a
mdoc authentication 9.1.3
a
Only applicable if the server retrieval token is transferred using device retrieval.

Table 4 — Security goals and mechanisms
Security goal Functionality Device retrieval Server retrieval
Authenticate the origin of mDL data Issuer data authentication JWS
Verify mDL data has not changed Issuer data authentication JWS
Protection
from
against forgery
issuing authority
Verify how up to date the mDL data is Issuer data authentication JWS
Protection Protect against cloning of mDL/ mdoc authentication mdoc authentica-
a
against cloning binding tion
mDL
...