Privacy & Identity protection in mobile Driving
License ecosystems
Version: 1.0
Document Date: 2021-06-29
Editors: John Wunderlich, Loffie Jordaan, Christopher William, Richard Wilsher,
Tom Jones, Ken Dagg
Contributors: See the Discussion Group Participant Roster
Produced by: PImDL DG
Status: This document is a Kantara Initiative Report produced by the Privacy &
Identity protection in mobile Driving License ecosystems Discussion
Group (PImDL DG). See Article 7 Document Development and
Publication of the Kantara Initiative Operating Procedures v3.0 for more
information on the supporting process.
Abstract: This report elaborates on the non-normative privacy and identity
protections contained in ISO/IEC 18013-5 Personal identification —
ISO-compliant driving licence — Part 5:Mobile driving licence (mDL)
application in order to enable Implementers of software or hardware in
mobile Driving License ecosystems to take a proactive, and user centric,
approach to privacy and identity.
IPR Option: Non-Assertion Covenant--
Suggested Citation: Privacy & Identity protection in mobile Driving License ecosystems 1.0
Kantara Initiative Report, Kantara Initiative PImDL DG. 2021-06-29..
Kantara Initiative Report © 2021 Kantara Initiative, Inc.
www.kantarainitiative.org
IPR OPTION- ---Non-Assertion Covenant Page 1
Privacy & Identity protection in mobile Driving License
ecosystems
NOTICE
Copyright: The content of this document is copyright of Kantara Initiative, Inc.
© 2021 Kantara Initiative, Inc.
This document is provided "AS IS," and no Participant in Kantara Initiative Inc makes any
warranty of any kind, expressed or implied, including any implied warranties of merchantability,
non-infringement of third-party intellectual property rights, and fitness for a particular purpose.
All rights reserved. This document has been prepared by Participants of the Privacy and Identity
protection in mobile Driving License ecosystems Discussion Group (PImDL DG) of the Kantara
Initiative, Inc. Entities seeking permission to reproduce portions of this document should contact
Kantara Initiative, Inc, should use the suggested citation and must include attribution.
Document Version : 1.0 Document Date : 2021-06-29
Kantara Initiative Report © 2021 Kantara Initiative, Inc.
www.kantarainitiative.org
IPR OPTION - ---Non-Assertion Covenant Page 2 of 54
Privacy & Identity protection in mobile Driving License
ecosystems
Contents
1 EXECUTIVE SUMMARY 5
1.1 SCOPE OF THE REPORT 5
2 INTRODUCTION 7
2.1 PURPOSE OF THE DISCUSSION GROUP 7
2.2 RISK CONSIDERATIONS 8
2.3 OTHER CONSIDERATIONS 9
3 THE MDL INTERNATIONAL STANDARD 10
3.1 OVERVIEW 11
3.2 ISO/IEC 18013-5 MECHANICS 11
3.3 KEY MANAGEMENT 12
3.4 AAMVA MDL GUIDELINES 13
3.5 3.5 SECURE TECHNOLOGY ALLIANCE 13
4 PIMDL OVERVIEW 14
4.1 PRIVACY CONSIDERATIONS FOR THE EXTENDED ECOSYSTEM 16
4.2 IDENTITY CONSIDERATIONS FOR THE EXTENDED ARCHITECTURE 24
5 DATA FLOWS 30
5.1 DATA FLOW 1 (DF-1) 30
5.2 DATA FLOW 2 (DF-2) 32
5.3 DATA FLOW 3 (DF-3) 34
5.4 DATA FLOW A (DF-A) 36
5.5 DATA FLOW B (DF-B) 39
5.6 DATA FLOW C (DF-C) 41
5.7 INTEROPERABILITY RISK 42
6 SUMMARY 43
7 APPENDICES 44
7.1 ADDITIONAL CONSIDERATIONS 44
7.2 IDENTIFIER PROTECTION SUMMARY 45
7.3 BIBLIOGRAPHY 46
Document Version : 1.0 Document Date : 2021-06-29
Kantara Initiative Report © 2021 Kantara Initiative, Inc.
www.kantarainitiative.org
IPR OPTION - ---Non-Assertion Covenant Page 3 of 54
Privacy & Identity protection in mobile Driving License
ecosystems
7.4 TERMINOLOGY 46
Document Version : 1.0 Document Date : 2021-06-29
Kantara Initiative Report © 2021 Kantara Initiative, Inc.
www.kantarainitiative.org
IPR OPTION - ---Non-Assertion Covenant Page 4 of 54
Privacy & Identity protection in mobile Driving License
ecosystems
Tables
Table 1Scope Considerations 6
Table 2 Identity Attributes in Context 28
Table 3 Additional Security Considerations 44
Figures
Figure 1 Interfaces from ISO/IEC 18013-5 10
Figure 2 PImDL Data Flows 14
Figure 3 List of Data Flows in Scope 15
Figure 4 Data Flow 1 29
Figure 5 Data Flow 2 31
Figure 6 Data Flow 3 33
Figure 7 Data Flow A.1 35
Figure 8 Data Flow A.2 36
Figure 9 Data Flow B.1 38
Figure 10 Data Flow B.2 38
Figure 11 Data Flow C 40
Document Version : 1.0 Document Date : 2021-06-29
Kantara Initiative Report © 2021 Kantara Initiative, Inc.
www.kantarainitiative.org
IPR OPTION - ---Non-Assertion Covenant Page 5 of 54
Privacy & Identity protection in mobile Driving License
ecosystems
1 EXECUTIVE SUMMARY
This report is the result of the work of the “Privacy & Identity Protection in mobile Driving
License ecosystems”
1
(PImDL) Discussion Group at the Kantara Initiative
2
. It provides the
reader with an overview of mobile Driving License (mDL) systems along with guidance on
protecting the individual privacy of natural persons and the digital identifiers of an Individual
who carries, or uses, a mDL.
1.1 SCOPE OF THE REPORT
The intended audience of this report includes product managers, engineers, compliance teams,
architects, developers, assessors, and others with responsibilities for implementing, supporting,
or interfacing with mobile credentials that comply with ISO/IEC 18013-5 Personal
identification — ISO-compliant driving license — Part 5: Mobile driving license (mDL)
application (ISO/IEC 18013-5)
3
.
ISO/IEC 18013-5 provides clear and detailed guidance for implementing a mDL or identity
document. This report is not, nor should it be taken as, guidance in contradiction of that standard.
In other words, ISO/IEC 18013-5 is the baseline upon which this report builds.
Although in some cases inadvisable, mDL Issuers may allow access to mDL data using methods
not defined in ISO/IEC 18013-5 (“undefined data access”). Examples are an ISO/IEC 18013-5
compliant application that allows access via a separate API, a completely non-compliant data
exchange protocol, or a “flash pass.” The privacy and security considerations will equally apply
to such methods and serve as guidance towards ISO/IEC 18013-5 compliant implementations.
While this report does not explicitly cover undefined data access, where appropriate, it does
expand on the privacy and security implications that may arise from such access
4
.
ISO/IEC designed 18013-5 to bring digitally secure driving licenses to mobile devices.
Implementers of ISO/IEC 18013-5 will not be limited to public identity Issuing Authorities
(IAs), such as motor vehicle administrators. Other entities, public and private, may choose to
utilize this standard for issuing mobile identities for specific ecosystem use cases (e.g., national
agencies, colleges and universities, private commercial organizations such as retail and
healthcare, etc.). Even though such identities (i.e., compliant with the ISO/IEC 18013-5 standard
4
Mobile device manufacturers may enable various identity credential API’s or capabilities, for example.
3
ISO/IEC 18013-5 Personal Identification — ISO-compliant driving license — Part 5: Mobile driving license
(mDL) application. At the time of writing this draft, the standard is at the DIS (Draft International Standard) and
should be finalized in 2021.
2
https://kantarainitiative.org
1
https://kantarainitiative.org/confluence/pages/viewpage.action?pageId=136675376
Document Version : 1.0 Document Date : 2021-06-29
Kantara Initiative Report © 2021 Kantara Initiative, Inc.
www.kantarainitiative.org
IPR OPTION - ---Non-Assertion Covenant Page 6 of 54
Privacy & Identity protection in mobile Driving License
ecosystems
and issued by non-drivers license issuers) may not be able to interoperate within a mDL
ecosystem, the security and privacy considerations of these identities are within the scope of this
report.
1.1.1 IN SCOPE
1) Use of the mDL on a mobile device at the point of interaction;
2) Use of the mDL as a read-only data source for other systems, such as:
a) As an input to Federated Identity Systems; or
b) As an attribute source for a W3C Verified Credential (VC); or
c) As part of a W3C Decentralized Identifier (DID) method; or
d) As an attribute source for Self-Sovereign Identity (SSI); and
3) Privacy and security implications of making mDL data available via methods not
supported in ISO/IEC 18013-5
5
.
1.1.2 OUT OF SCOPE
If an item is not specifically “In Scope” then it is assumed to be out of scope. The following table
captures in and out of scope considerations:
DL-ID Issuers
Other ID Issuers
ISO/IEC 18013-5
Compliant
In Scope
Defined data access
In Scope
Defined data access
ISO/IEC 18013-5
Non-compliant
In Scope
Privacy and Identity
considerations only
Undefined data access
Out of Scope
Undefined data access
Table 1 Scope Considerations
5
We note that at the time of writing, the mDL standard does NOT include the use of on-line transactions. Because
extending the mDL ecosystem to include on-line transaction and unattended mDL Holder authentication is planned,
this report may include commentary or suggestions related to on-line presentation of mDL both with and without
unattended authentication. These elements of the report will be preliminary or suggestive. Online mDL functionality
is now expected to be released in ISO/IEC 18013-7.
Document Version : 1.0 Document Date : 2021-06-29
Kantara Initiative Report © 2021 Kantara Initiative, Inc.
www.kantarainitiative.org
IPR OPTION - ---Non-Assertion Covenant Page 7 of 54
Privacy & Identity protection in mobile Driving License
ecosystems
2 INTRODUCTION
This section provides an outline of an ecosystem as described by ISO/IEC 18013-5. It explains
how providers of hardware/software can meet, or extend, the privacy and identity considerations
set out in ISO/IEC 18013-5, both for mDLs and non-mDL credentials issued in compliance with
6
ISO/IEC 18013-5. The rest of the document discusses how Implementers and entities on both the
‘reading’ side and the ‘provisioning’ side of their ecosystem can meet stakeholder privacy
expectations and protect identity attributes. The ‘reading’ side of the ecosystem includes entities
with use cases that require them to read some, or all, of an ISO/IEC 18013-5 compliant
credential. In other words, the reading side of the ecosystem relies on some or all of the data of a
compliant credential. The ‘provisioning’ side consists of the providers of hardware or software
that support the issuing of an ISO/IEC 18013-5 compliant credential and will support the process
by which a credential holder shares information with a Relying Party (RP).
This report identifies privacy and identity-related requirements, or expectations, for the use of
any ISO/IEC 18013-5 compliant credential to enable a robust and privacy-protective system for
all stakeholders. By supporting the requirements and expectations in this report, RPs can provide
substantive, and potentially verifiable, assurances about how they protect the privacy and identity
of an Individual. There will be a difference between specific, technical conformance and
interoperability with ISO/IEC 18013-5 and meeting jurisdictional requirements or stakeholder
expectations. This report therefore identifies a baseline set of requirements and expectations for
the protection of privacy and identity for mobile digital identifier stakeholders. The ISO/IEC
18013-5 standard provides a specific and secure architecture with which stakeholders should
start. That being said, it is the case that some mDL IAs are already issuing credentials using
architectures that are not compliant with ISO/IEC 18013-5. This report provides privacy and
identity guidance that can be applied in those circumstances. This serves two purposes: to foster
good privacy and identity practices regardless of the architecture, and to identify possible
pathways to bring mDL architectures into compliance with ISO/IEC 18013-5.
Any Implementers of a system that may collect, use, or disclose personal information; or
process identity attributes, should consider using the information in this report as input to the
functional or non-functional requirements for their implementation.
6
For purposes of this Report, a credential that uses a data model different from what is described in clause 7 of
ISO/IEC 18013-5 but otherwise follows ISO/IEC 18013-5 is considered compliant with ISO/IEC 18013-5.
Document Version : 1.0 Document Date : 2021-06-29
Kantara Initiative Report © 2021 Kantara Initiative, Inc.
www.kantarainitiative.org
IPR OPTION - ---Non-Assertion Covenant Page 8 of 54
Privacy & Identity protection in mobile Driving License
ecosystems
2.1 PURPOSE OF THE DISCUSSION GROUP
The Charter of the Discussion Group states,
Emerging standards around mobile Drivers Licenses, particularly ISO/IEC 18013-5
“Personal identification — ISO-compliant driving license”, raise questions of Identity
Proofing and Individual Privacy. In particular, the issuing authorities for mobile Driving
Licenses (mDLs) have a legitimate requirement for detailed and deeply personal
information about individuals, while many relying parties will only have legitimate bases
for selected subsets of the identity-related data available in an ISO/IEC 18013-5
compliant credential. Similarly, holders of such credentials will appreciate the
convenience of having a standard verified credential that can be used in many contexts
but will need assurances that their privacy will be protected and that their identity will be
secure.
This Discussion Group engaged stakeholders to produce a report intended to enrich and
inform the broader community that will create, deploy, administer, and use ISO/IEC
18013-5 compliant credentials. This report draws on prior Kantara reports and
standards, the work of the Secure Technology Alliance and others to create a report that
may
7
be used as the basis for the creation of a Kantara Work Group to create and
maintain a conformance standard for Privacy and Identity protective implementations of
ISO/IEC 18013-5 compliant credentials.
8
2.2 RISK CONSIDERATIONS
There is a risk that personally identifiable information (PII), once shared, can be used beyond the
purpose for which it was shared. Therefore, transactions that consume identity attributes from a
mDL need to incorporate considerations to reduce the risks to privacy and identity in any given
operational context associated with the transaction.
This report identifies the general nature of risks that should be considered in the use of mDLs
and offers a notional indication of the scale of risk. This report encompasses re-identification
risk, identity theft risk, the risks of unauthorized or inappropriate use of personal information,
and related risks. These risk considerations include:
1) The operational context in which the transaction is taking place. For example, is the
transaction using a kiosk in a formalized setting, environment, or installation (such as
airport security) or is it in a casual environment where the user is obliged to hold many
more assumptions about the other parties involved in the transaction? Example of these
more casual contexts could be street vendors, clubs, concerts, or other social contexts.
2) The specific types of identity attributes being required for the transaction:
8
Discussion Group Charter: https://kantarainitiative.org/confluence/display/mdl/Charter
7
The charter says ‘will’, but the DG notes that we can’t predict this for sure.
Document Version : 1.0 Document Date : 2021-06-29
Kantara Initiative Report © 2021 Kantara Initiative, Inc.
www.kantarainitiative.org
IPR OPTION - ---Non-Assertion Covenant Page 9 of 54
Privacy & Identity protection in mobile Driving License
ecosystems
i) Direct or Unique Identifiers (e.g., name and dob, system identifier); or
ii) Indirect Identifiers (e.g., dob and address); or
iii) Quasi-Identifiers (e.g., a true false indicator, e.g. eligibility based on age or any other
characteristic, such as entitlement to operate specific classes of vehicles).
3) The use of data for purposes other than those specified when the data was collected.
Additionally, this report does not predicate control selection for the mitigation of these risks.
Control suites abound, as do frameworks for managing information security risks, based on
international and national standards and other publications and paradigms.
A final consideration is the extent to which any device, application, or service interacting with a
mDL (whether automated or with human interaction involved) can be relied upon to protect the
integrity and privacy of information stored in the mobile device
9
. Ensuring this protection will
require technical infrastructure, both for the consuming devices, applications, and services as
well as for user devices, and may be performed internally on the user device or require access to
a supporting infrastructure (e.g., a register of assured devices, applications, and services). In
addition to technical infrastructure, implementation will require governance and related
processes to protect personal information. Future work may address these needs and provide
assurance criteria and describe an appropriate certification scheme.
2.3 OTHER CONSIDERATIONS
In the context of this report, considerations (e.g., Section 4.1.2) other than specific privacy or
identity risks, were raised by the discussion group. These might be ‘orthogonal’ to the scope of
the report but still germane to individuals concerned with building or enhancing an ecosystem
that is more respectful of individual autonomy.
9
Future developments of mDLs, while out of scope of this report, are likely to include a need for validating devices,
applications, and services and for that validation to be verified dynamically at the time of transaction.
Document Version : 1.0 Document Date : 2021-06-29
Kantara Initiative Report © 2021 Kantara Initiative, Inc.
www.kantarainitiative.org
IPR OPTION - ---Non-Assertion Covenant Page 10 of 54
Privacy & Identity protection in mobile Driving License
ecosystems
3 THE MDL INTERNATIONAL STANDARD
The mobile Driving License (mDL) International Standard referred to throughout this report is
ISO/IEC 18013-5 Personal identification — ISO-compliant driving licence — Part 5: Mobile
driving license (mDL) application (ISO/IEC 18013-5).
10
This section of the report provides a
summary of the standard with some ancillary information not contained in the standard.
The figure below shows the mDL Interfaces:
1) Interface 1 is the interface between the IA infrastructure and the mDL (Not in scope of
ISO/IEC 18013-5).
2) Interface 2 is the interface between the mDL and the mDL Reader, as specified in
ISO/IEC 18013-5.
3) Interface 3 is the interface between the IA infrastructure and the mDL Reader, as
specified in ISO/IEC 18013-5.
10
The table of contents and some of the introductory material is viewable on the ISO Online Browsing Platform at
https://www.iso.org/obp/ui/#iso:std:iso-iec:18013:-5:dis:ed-1:v1:en
Document Version : 1.0 Document Date : 2021-06-29
Kantara Initiative Report © 2021 Kantara Initiative, Inc.
www.kantarainitiative.org
IPR OPTION - ---Non-Assertion Covenant Page 11 of 54
Privacy & Identity protection in mobile Driving License
ecosystems
Figure 1 Interfaces from ISO/IEC 18013-5
3.1 OVERVIEW
From the introduction to ISO/IEC 18013-5:
ISO/IEC 18013 (all parts) establishes guidelines for the design format and data content of an
ISO-compliant driving license (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 the interface and related requirements to facilitate ISO-compliant
driving license (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 license to decide what information to release to a verifier. Other characteristics include
Document Version : 1.0 Document Date : 2021-06-29
Kantara Initiative Report © 2021 Kantara Initiative, Inc.
www.kantarainitiative.org
IPR OPTION - ---Non-Assertion Covenant Page 12 of 54
Privacy & Identity protection in mobile Driving License
ecosystems
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 in the scope of this
document.
3.2 ISO/IEC 18013-5 MECHANICS
A mDL transaction commences with a user-initiated engagement step. Sufficient information is
exchanged during this step to define the following data retrieval methods: device retrieval
(sometimes referred to as the offline method), and server retrieval (sometimes referred to as the
online method, and not to be confused with unattended use of a mDL over the Internet). Device
retrieval can make use of p, NFC or Wi-Fi Aware. Server retrieval can make use of WebAPI or
OIDC (both via the Internet). Device engagement can occur using NFC or a QR code.
Data retrieval generally commences with a request from the mDL Reader to the mDL (Interface
2 in Figure 1). This request lists all the individual data elements the mDL Reader would like to
receive. For each data element, the mDL Reader has to indicate whether it intends to retain the
information once received. This approach supports the creation of apps that allow a mDL Holder
full visibility of, and control over, what data elements are being requested, being released, and
under what conditions.
ISO/IEC 18013-5 defines the set of data elements supported in a mDL implementation. Driving
license issuing authorities (DL-ID Issuers) have the option to define additional local data
elements. In addition, as noted in the extract from the ISO/IEC 18013-5 Introduction above,
non-driving license issuing authorities (i.e., other DL-ID Issuers) can adapt the standard for other
types of identity credentials.
For the device retrieval method, data freshness is controlled via the validity period of the Mobile
Security Object (MSO).
3.3 KEY MANAGEMENT
The authenticity of mDL data is confirmed using passive authentication. This requires the mDL
Verifier to possess the public key of the IA signing key. It is a critical responsibility of the
Document Version : 1.0 Document Date : 2021-06-29
Kantara Initiative Report © 2021 Kantara Initiative, Inc.
www.kantarainitiative.org
IPR OPTION - ---Non-Assertion Covenant Page 13 of 54
Privacy & Identity protection in mobile Driving License
ecosystems
verifying party to apply a trusted process in obtaining the public keys it possesses for each
trusted IA. ISO/IEC 18013-5 defines, and suggests, the use of a mDL master list as a mechanism
for the distribution of trusted public keys. Other methods may exist as well, such as obtaining
public keys directly from trusted issuing authorities. Also, see ETSI TS 119 612 which defines a
flexible and extensible structure for a human/machine parsable Trust Status List which could
serve as a mDL Master List.
An initiative driven by AAMVA ( American Association of Motor Vehicle Administrators) is
currently (spring 2021) underway to identify viable and practical public-key collection and
dissemination solutions for its members, called the Verified Issuer Certificate Authority List
(VICAL). It is envisioned that a public key administrator will act as a focal point for this
purpose. In addition, the public key administrator will accept public keys only if the IA complies
with a minimum set of requirements determined by AAMVA and its members
11
. Other
public-key administrators will exist for international Issuers and non-AAMVA members and
those public key administrators may adhere to different requirements for acceptance. Although
there is an initiative to align such requirements between different mDL public key
administrators, it is the responsibility of the mDL Verifier to understand the requirements set by a
public key administrator to establish trust in the included issuing authorities.
3.4 AAMVA MDL GUIDELINES
As a service to its members, AAMVA has published guidelines for Issuing Authorities (IAs) on
mDL administration. The intent of the guidelines is to serve as a comprehensive set of
requirements states can follow when setting up, and operating, a mDL solution. While the
current version of the guidelines primarily addresses the interface between a mDL and a mDL
Reader, the next version is envisioned to also cover areas such as provisioning, app functionality,
and local PKI operation. Within each area, requirements for functionality, privacy, security, and
technology will be addressed as needed.
3.5 3.5 SECURE TECHNOLOGY ALLIANCE
The Secure Technology Alliance (STA), composed of members from the digital security industry,
provides a neutral forum that brings together leading providers and adopters of end-to-end
security solutions designed to protect the privacy and digital assets of Individuals in a variety of
vertical markets. As part of achieving this mission, the STAs Identity Council has developed a
set of educational materials directed broadly at all members of the mDL ecosystem
12
. These
materials include a substantial white paper
13
giving a technical overview of the mDL as
13
https://www.securetechalliance.org/publications-the-mobile-drivers-license-mdl-and-ecosystem/
12
See the Mobile Drivers License Initiative on the STA website:
https://www.securetechalliance.org/mobile-drivers-license-initiative/
11
The intent is to leverage existing standards and/or best practices as far as possible.
Document Version : 1.0 Document Date : 2021-06-29
Kantara Initiative Report © 2021 Kantara Initiative, Inc.
www.kantarainitiative.org
IPR OPTION - ---Non-Assertion Covenant Page 14 of 54
Privacy & Identity protection in mobile Driving License
ecosystems
described in ISO/IEC 18013-5, considerations for securing such ecosystems, and a number of
use cases highlighting areas where the mDL provides a new value for mDL Holders and RPs.
The STA also produced a series of educational webinars covering the content of their white
paper. Additionally, the STA has produced the mDL Connection website
(www.mdlconnection.com) which contains links to the discussed white paper and webinars, as
well as additional FAQs, Implementers map, and other resources to inform and continually
update the community on the development of mDLs in the United States for global consumption.
Document Version : 1.0 Document Date : 2021-06-29
Kantara Initiative Report © 2021 Kantara Initiative, Inc.
www.kantarainitiative.org
IPR OPTION - ---Non-Assertion Covenant Page 15 of 54
Privacy & Identity protection in mobile Driving License
ecosystems
4 PIMDL OVERVIEW
The diagram below shows the potential connections between actors in the mDL ecosystem.
Actors that are identified in ISO/IEC 18013-5 are on the left, and their equivalent, in a more
general view of the actors in an identity system, are on the right. This report is based on
protecting mDL data issued by IAs. While acknowledging that there may be theoretical
connections between all these entities, this report focuses on those interfaces that have the
potential to have real-world use cases involving IA issued mDLs. The numbered data flows:
DF-1, DF-2, and DF-3 are the interfaces defined in ISO/IEC 18013-5. The lettered data flows:
DF-A, DF-B, and DF-C involve implementations involving Individuals and RPs that exchange
mDL data in an undefined manner.
It should be noted that “in real life”, the “mDL Holder” and the “Individual” actor will be the
same natural person in any given operational context.
Document Version : 1.0 Document Date : 2021-06-29
Kantara Initiative Report © 2021 Kantara Initiative, Inc.
www.kantarainitiative.org
IPR OPTION - ---Non-Assertion Covenant Page 16 of 54
Privacy & Identity protection in mobile Driving License
ecosystems
Figure 2 PImDL Data Flows
Legend:
DF-1: Issuing Authority – mDL Holder data
flows
DF-A: mDL Holder – Individual data flows
DF-2: mDL Holder – mDL Verifier data flows
DF-B: mDL Verifier – RP data flows
DF-3: Issuing Authority – mDL Verifier data
flows
DF-C: Individual – RP data flows
Figure 3 List of Data Flows in Scope
Document Version : 1.0 Document Date : 2021-06-29
Kantara Initiative Report © 2021 Kantara Initiative, Inc.
www.kantarainitiative.org
IPR OPTION - ---Non-Assertion Covenant Page 17 of 54
Privacy & Identity protection in mobile Driving License
ecosystems
Before discussing the privacy and identity protection considerations of each of the data flows,
the report sets out the general privacy and identity protection considerations for the extended
ecosystem (i.e., all six data flows).
For the purposes of this report an “Implementer” is a person or organization that is accountable,
or responsible, for implementing one or more of the of endpoints identified in the Data Flows
below. This may be software, hardware, infrastructure, or some combination of these elements as
shown below:
Data Flow
Implementers
Notes
DF-1
Issuing
Authority
Self-explanatory in ISO/IEC 18013-5.
DF-1
DF-2
DF-A
mDL Developer
The mDL Developer is the entity that creates the mDL
software being used by the mDL Holder on their chosen
device.
DF-2
DF-3
DF-C
mDL Reader
Developer
The mDL Reader Developer is the entity that creates and/or
is responsible for the device that reads the mDL. This may be
a dedicated hardware reader or software on a device that has
the capability of reading the mDL when presented.
DF-A
DF-C
Mobile Device
Developer
The Mobile Device Developer is the entity that creates the
software (“wallet”) being used by an Individual, who is also
a mDL Holder, on their chosen device.
DF-B
DF-C
RP Reader
Developer
The RP Reader Developer is the entity that creates and/or is
responsible for the device that reads the mDL. This may be a
dedicated hardware reader or software on a device that has
the capability of reading the mDL when presented.
Document Version : 1.0 Document Date : 2021-06-29
Kantara Initiative Report © 2021 Kantara Initiative, Inc.
www.kantarainitiative.org
IPR OPTION - ---Non-Assertion Covenant Page 18 of 54
Privacy & Identity protection in mobile Driving License
ecosystems
4.1 PRIVACY CONSIDERATIONS FOR THE EXTENDED ECOSYSTEM
Implementers may consider each of the following principles to determine how their
implementation can demonstrate conformance with the privacy considerations in each of the
following principles:
1. Consent and choice;
2. Purpose legitimacy and specification;
3. Collection limitation;
4. Data minimization;
5. Use, retention and disclosure limitation;
6. Accuracy and quality;
7. Openness, transparency and access;
8. Individual participation and access;
9. Accountability;
10. Information Security; and
11. Privacy compliance.
Where Implementers are not able to conform with a principle, they may choose to document the
gap and the reasons for the gap (e.g., operationally unfeasible, regulatory requirement, etc.).
Such gaps may be included in the product or system documentation and be made available to the
mDL Holder, preferably proactively.
14
4.1.1 CONSENT AND CHOICE
The mDL Holder should consent to the processing of their personal information. Use cases
where there is a non-consent-based authority for collecting information about the Individual are
out of the scope of this report. However, it should be noted that the absence of consent does NOT
imply a lack of authority NOR a reduction in the obligation of Implementers to respect privacy
and protect identity in their operational context. In the case of ISO/IEC 18013-5, the consent
may be implicit because the mDL Holder has initiated the data flow by presenting their mDL in
the context of an in-person transaction. The consent that can be implied will be specific to the
context of the presentation. If the presentation is required for age verification, for example,
consent to the sharing of age may be implied but not consent to the sharing of a birth date if the
IA included the necessary age statement in the credential.
Risk Considerations
14
See Annex E of ISO/IEC 18013-5 or ISO/IEC 29100 Privacy framework for a list of the privacy principles
enumerated here.
Document Version : 1.0 Document Date : 2021-06-29
Kantara Initiative Report © 2021 Kantara Initiative, Inc.
www.kantarainitiative.org
IPR OPTION - ---Non-Assertion Covenant Page 19 of 54
Privacy & Identity protection in mobile Driving License
ecosystems
Implementers should address the following considerations in developing their mDL applications:
4.1.1.1 The Implementer should document the content and type of consent to be obtained.
Consent may be implied or expressed, and the Implementer should document the
allowable uses of data for which consent will be obtained. If the Implementer retains
information from the mDL Holder, this creates a relationship with the mDL Holder,
with ongoing obligations to respect the mDL Holders privacy preferences. The
Implementer may use a consent management system to accomplish this.
4.1.1.2 The Implementer should allow a user to choose not to consent to any collection or use
of their data. If a service consists of multiple elements, and if only partial consent is
obtained, those elements of the service for which consent was obtained should continue
to be provided and should not be impacted by the refusal;
4.1.1.3 Where the transaction is on-line there should be some means of proof of presence
supplied by the mobile device. For example, using a mobile phone biometric proof of
presence such as facial recognition;
4.1.1.4 Consent choices of the mDL Holder may be stored by the mDL Verifier as well as by
mDL application on the mDL Holders mobile device for future transactions.
Depending on the stage of the mDL transaction the storage location of the consent
choices may vary and be inaccessible to either party. If modification or withdrawal of
consent choices is outside the direct control of the mDL Holder, the mDL Verifier
should allow consent for any future transactions to be withdrawn or modified at any
time:
4.1.1.4.1 The mDL Verifier may consider the use of consent receipts for the purpose of
informing the mDL Holder of what the mDL Verifier has recorded; and
4.1.1.4.2 If consent is withdrawn, the mDL Verifier should inform the user of the types of uses
of their data that have already been completed and cannot be deleted or withdrawn.
Other considerations
4.1.1.5 Where transactions are in-person, the possibility of a coerced presentation exists, and
Implementers are encouraged to explore UX options for the mDL Holder to identify
coerced presentations.
Document Version : 1.0 Document Date : 2021-06-29
Kantara Initiative Report © 2021 Kantara Initiative, Inc.
www.kantarainitiative.org
IPR OPTION - ---Non-Assertion Covenant Page 20 of 54
Privacy & Identity protection in mobile Driving License
ecosystems
4.1.2 PURPOSE LEGITIMACY AND SPECIFICATION
The mDL Holder should be fully aware of the purpose for which their personal data is being
collected, processed, and potentially stored. Upon, or prior to, the presentation of their mDL to
the mDL Verifier the mDL Holder should receive a notice that identifies the purpose of
collection and the uses of the data after collection.
Risk Considerations
4.1.2.1 The Implementer should ensure that the purposes for which they are collecting mDL
data are legitimate (legal, required for the purpose of collection, and with risks to
privacy proportionate to the proposed use of mDL data) before the implementation of
their solution.
4.1.2.2 The Implementer should provide a notice to mDL Holders that is appropriate to the
operational context. mDL Holders should understand what information about them will
be collected before they present their mDL or before data is transferred from the mDL.
A notice may be a posted or printed notice, a text message or application pop-up, or
spoken communication. The notice should be in advance of any collection of personal
information about the Individual.
4.1.2.3 The Implementer should consider the mDL Holders understanding of the completed
interaction. Where any user data is retained a notice or consent receipt should be
provided to the mDL Holder in printed or electronic format.
15
4.1.2.4 The Implementer should consider the use of notice and consent receipts
16
in their
workflow to document both the notice provided by the mDL Verifier, and the consent
received that the mDL Verifier will use.
16
See the Kantara Consent Receipt 1.1 data structure, WD3 of ISO/IEC TS 27560 Consent record: Information
structure (in process), UMA, JLINC as potential examples
15
Examples are available in the Kantara Consent Receipt Specification 1.1
https://kantarainitiative.org/download/7902/ or the JLINC protocol https://protocol.jlinc.org/ which includes a log of
permissions and an Information Sharing Agreement in JSON-LD
Document Version : 1.0 Document Date : 2021-06-29
Kantara Initiative Report © 2021 Kantara Initiative, Inc.
www.kantarainitiative.org
IPR OPTION - ---Non-Assertion Covenant Page 21 of 54
Privacy & Identity protection in mobile Driving License
ecosystems
Other considerations
4.1.2.5 If the implementation flow allows a meaningful (as opposed to a ‘click through’) notice
and consent transaction, consent will be expressed consent, although still with the
caveats above. This kind of flow has limited support with ISO/IEC 18013-5. For
example, verbal consent is not supported but may be used by the Implementer.
4.1.3 COLLECTION LIMITATION
The mDL Verifier should only collect the data necessary for its purpose and should only collect
data consistent with these considerations. Necessary in this context refers to the necessity to
complete the business purpose(s) specified in the notice provided to the user.
Risk Considerations
4.1.3.1 Implementers should document the business purpose for each field of the mDL to be
collected. (4.2 Identity Considerations for the extended architecture)
4.1.3.2 Implementers should identify whether express or implied consent is required based on
the sensitivity of the operational context. Express consent requires affirmative action
from the Individual (like an ‘opt-in’ option) where implied consent is implied from the
context of the transaction. Express consent is usually regarded as more likely to be
necessary for processing sensitive information. Implementers may consider using a
Privacy Impact Assessment standard such as ISO 29134 to make this determination.
Other considerations
4.1.3.3 The necessity for collection should be determined from the point of view of the user and
what they would reasonably expect in the operational context.
4.1.4 DATA MINIMIZATION
Processing (collection, use, retention, accessing, sharing, disclosing, or other manipulation or
viewing of data) of mDL data should be minimized to that specifically necessary for the purpose
specified.
Document Version : 1.0 Document Date : 2021-06-29
Kantara Initiative Report © 2021 Kantara Initiative, Inc.
www.kantarainitiative.org
IPR OPTION - ---Non-Assertion Covenant Page 22 of 54