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..

www.kantarainitiative.org

IPR OPTION- ---Non-Assertion Covenant Page 1

Privacy & Identity protection in mobile Driving License

ecosystems

NOTICE

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.

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

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

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

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

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”

(PImDL) Discussion Group at the Kantara Initiative

. 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)

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

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

Mobile device manufacturers may enable various identity credential API’s or capabilities, for example.

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.

https://kantarainitiative.org

https://kantarainitiative.org/confluence/pages/viewpage.action?pageId=136675376

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 6 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

and issued by non-driver’s 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

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

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

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

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.

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

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

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.

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:

Discussion Group Charter: https://kantarainitiative.org/confluence/display/mdl/Charter

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

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

. 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.

Future developments of mDL’s, 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

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).

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.

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

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

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

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

. 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 STA’s Identity Council has developed a

set of educational materials directed broadly at all members of the mDL ecosystem

. These

materials include a substantial white paper

giving a technical overview of the mDL as

https://www.securetechalliance.org/publications-the-mobile-drivers-license-mdl-and-ecosystem/

See the Mobile Driver’s License Initiative on the STA website:

https://www.securetechalliance.org/mobile-drivers-license-initiative/

The intent is to leverage existing standards and/or best practices as far as possible.

Document Version : 1.0 Document Date : 2021-06-29

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

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

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

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

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.

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

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

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 Holder’s 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 Holder’s 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

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 Holder’s 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.

4.1.2.4 The Implementer should consider the use of notice and consent receipts

in their

workflow to document both the notice provided by the mDL Verifier, and the consent

received that the mDL Verifier will use.

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

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

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

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 22 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

Risk Considerations

4.1.4.1 IAs should provide data minimizing options, such as including “birth year” in addition

to “date of birth”.

4.1.4.2 Implementers should only process data for the purposes identified in the notice

provided to the mDL Holder.

4.1.4.3 Implementers may consider the processing of de-identified data for other purposes if a

measurable and reliable de-identification technique

is applied with appropriate

controls to minimize the risk of re-identification.

4.1.5 USE, RETENTION AND DISCLOSURE LIMITATION

The mDL Verifier should not use, retain, or disclose the personal data of the mDL Holder except

for the purposes specified and consistent with these other principles. mDL data should only be

retained for the period necessary to provide the service.

Risk Considerations

4.1.5.1 Implementers should only use data for the purposes identified in the notice provided to

the mDL Holder.

4.1.5.2 Implementers should retain mDL data only so long as the data is being used for

purposes identified in the notice provided to the mDL Holder.

4.1.5.3 Implementers should destroy all copies of mDL data when the retention period for the

data has expired.

4.1.5.4 Implementers may maintain records of the destruction of mDL data. Where such

records are required, Implementers should not retain identifying information.

4.1.5.5 Implementers should document and implement a retention schedule for mDL data.

Other considerations

ISO/IEC 20889 Privacy enhancing data de-identification terminology and classification of techniques

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 23 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

4.1.5.6 Implementers should work with their procurement and legal teams to ensure that third

party processors are bound by the implementation rules for use, retention, and

disclosure.

4.1.6 ACCURACY AND QUALITY

High accuracy of data being processed and held is in the best interest of the mDL Holder and

mDL Verifiers should take measures to ensure accuracy.

Risk Considerations

4.1.6.1 The Implementer should implement procedures to maintain the accuracy, quality, and

integrity of the mDL data.

Other considerations

4.1.6.2 Implementers should consider retention of data as an integral part of data quality, and

ensure that data is current and, where operationally appropriate, has a retention limit.

4.1.7 OPENNESS, TRANSPARENCY AND ACCESS

What mDL data, and how mDL data, is being processed should be well-known to the mDL

Holder, including obtaining consent, and posting and updating clear notices.

Risk Considerations

4.1.7.1 The Implementer should create a public privacy commitment that describes how it

processes mDL data and its consent practices.

4.1.7.2 The Implementer should publish or make available its public privacy commitment on

one or more of the following:

4.1.7.2.1 The Implementer’s web site; or

4.1.7.2.2 The Implementer’s phone number for privacy information; or

4.1.7.2.3 The Implementer’s corporate mailing address; or

4.1.7.2.4 An equivalent mechanism to make the commitment readily available.

4.1.7.3 The Implementer should respond to any enquiries about its public privacy commitment

within 30 days of receiving an enquiry

Other considerations

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 24 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

4.1.7.4 Where appropriate protocols and options exist, Implementers should consider systems

that give an Individual ongoing control over their own personal information.

4.1.8 INDIVIDUAL PARTICIPATION AND ACCESS

The mDL Holder should be involved in, or informed about, the collection, consent, processing,

and storage management of their personal data.

Risk Considerations

4.1.8.1 The Implementer should, to the extent practicable in the operational context, require

mDL Holder participation in the mDL data processing data flows.

4.1.8.2 Where participation in the mDL data flows is not practicable, the Implementer should

make records of mDL data processing, including processing by sub-processor, available

upon request

4.1.8.3 The Implementer should put in place procedures to verify the identity of the mDL

Holder to ensure that only the mDL Holder may access their own data. If this is not

practicable in the operational context then the notice and consent process should make

clear to the mDL Holder that they will not have access to their own data.

Other considerations

4.1.8.4 Where participation and access is unfeasible, extra care should be taken to ensure

openness and auditability.

4.1.9 ACCOUNTABILITY

The mDL Verifier should be accountable for all aspects of the processing of mDL Holder data

and provide audit logs and auditability to the mDL Holder.

Risk Considerations

4.1.9.1 The Implementer should have a privacy policy and process to give effect to the

considerations in this report

4.1.9.2 The Implementer should appoint a senior executive to be accountable for ensuring the

privacy of mDL Holders

4.1.9.3 The Implementer should make the name and the contact details of the accountable

privacy officer publicly available and readily accessible.

Other considerations

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 25 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

4.1.9.4 Where accountability is unfeasible, such as in Use Cases where the processing of mDL

Holder data is ephemeral and no data is retained, extra care should be taken with respect

to ensuring that Openness and Notice principles are observed.

4.1.10 INFORMATION SECURITY

Personal data of the mDL Holder should be protected by security safeguards against such risks as

loss or unauthorized access, destruction, use, modification, or disclosure.

Risk Considerations

4.1.10.1 The Implementer should have an Information Security Management System (ISMS)

with safeguards appropriate for the sensitivity of the information it protects.

4.1.10.2 The ISMS should include:

4.1.10.2.1 Administrative safeguards (i.e., contracts or training);

4.1.10.2.2 Physical safeguards (i.e., secure facilities); and

4.1.10.2.3 Technical safeguards (i.e., access control, encryption, etc.).

Other considerations

4.1.10.3 Systems that process mDL data should consider following a structure security

framework such as ISO 2700, COBIT, or the NIST Security Guideline.

4.1.11 PRIVACY COMPLIANCE

The mDL Verifier should be accountable for all aspects of the processing of mDL data and

should provide audit logs and auditability to the mDL Holder.

Risk Considerations

4.1.11.1 The Implementer should maintain records of mDL data processing.

4.1.11.2 Upon confirmation of the identity of the requestor, the Implementer will provide them

with copies or access to records of their mDL data processing.

Other considerations

4.1.11.3 Compliance efforts’ successes depends on ensuring that the Implementer’s organization

is aware of the current state of regulations and industry practices. This requires a

proactive regulatory and standards monitoring program.

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 26 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

4.2 IDENTITY CONSIDERATIONS FOR THE EXTENDED ARCHITECTURE

The security of the core mDL transaction under ISO/IEC 18013-5 relies on mDL Issuers being

the only party allowed to generate and sign mDL attributes. While not included explicitly in the

standard, DF-1 is the only interface which is allowed for the generation and modification of the

mDL on the mDL Holder’s devices.

The dataset contained on the device is limited to the

mandatory and optional attributes defined in ISO/IEC 18013-5 and any additional namespace

attributes defined by and specific to the mDL Issuer. Within the compliant mDL ecosystem, a

mDL will have only one valid IA. While not required by the ISO/IEC 18013-5 standard, in most

cases the mDL Issuer will maintain a database, within their control, which contains a duplication

of the datasets for each issued mDL. The requirements for these identity databases will vary

based on the local jurisdiction’s regulations and laws.

It is foreseeable that multiple Issuers may wish to provide an Individual with attribute data under

ISO/IEC 18013-5. For example, a Game & Fish regulator of a state may wish to include an

individual’s hunting or fishing license within the mDL dataset issued by the Department of

Motor Vehicles (DMV). This can be accomplished by one Issuer (the DMV in this

example) taking the authority and liability to include other attribute namespaces within their

mDL issuing infrastructure and issue the mDL credential with the added namespace attributes.

Another potential mechanism is creating data attributes which themselves are third-party signed

objects such as a VC, JSON Web Signature (JWS) object, or other type of signed data payload to

be included within the mDL dataset. If this architecture is used it should be made clear, through

additional attributes, if the third-party signed data was validated at the time of provisioning. RPs

are advised to consult the relevant namespace standard to confirm the extent to which the Issuer

assumes responsibility for third-party signed data objects. For completeness, RPs are advised to

include individual validation for third-party signed data objects within their own business

processes and should not rely solely on the validation performed during issuance. In lieu of an

architecture which includes third-party signed objects, the simplest solution may be a mDL

Holder’s device containing multiple ISO/IEC 18013-5 compliant documents from different

Issuers.

In the context of the extended ecosystem, other parties (mDL Holder, mDL Verifier, an

Individual, or RP for the scope of this report) will only be able to read and verify mDL data.

Because the mDL is a composite dataset of Direct Identifiers, Indirect Identifiers, Unique

Identifiers, and Quasi-Identifiers, for a given transaction the specific data elements exchanged

will determine the level of identity risk. It is the responsibility of the parties involved in the

transaction to appropriately handle identity information according to local regulations and good

privacy practices during and after the transaction for each type of identifier. Good practice is to

ensure that all involved parties in a mDL transaction can adequately assess the transaction risk

DF-1 will be explicitly covered under the forthcoming standard ISO/IEC 23220 Cards and security devices for

personal identification — Building blocks for identity management via mobile devices

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 27 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

and then make an informed decision about identity protection requirements by adopting the

following principles at a minimum:

1) Adopting the principles of data minimization for all transactions;

2) Implementing use, retention, and disclosure limitations; and

3) Providing the mDL Holder with consent and choice over the release of their attribute data.

Additional considerations are presented in the following sections for specific types of identifiers

found in the mDL data. A summary table of these considerations are included in Section 7.2

4.2.1 DIRECT IDENTIFIERS

Direct identifiers are attributes that alone enable the unique identification of a data principal

within a specific operational context. [REF ISO 20889] For mDL data, like the facial portrait or

biometric data, direct identifiers may be self-contextualizing and fully identify the data principal

with their solitary release.

Risk Considerations

4.2.1.1 Direct Identifiers should be encrypted at rest.

4.2.1.2 Direct Identifiers should only be transacted through encrypted channels.

4.2.1.3 Direct Identifiers should not be collected and stored by RPs without the informed

consent of the data principal.

4.2.1.4 If collected, Direct Identifiers should only be stored for the minimum length of time

needed to complete business need and comply with applicable jurisdictional and

contractual obligations (See 4.1.5 Use, Retention and Disclosure Limitation) after

which they should be securely destroyed.

Note: In most cases for mDL Identification Data, the data principal’s direct identifiers will be

core identity information like their name, facial image or other biometric data. The storage and

collection of these direct identifiers is inherently high risk because they can identify an

Individual without context and in perpetuity. This data is difficult, if not impossible, to change

after it has been compromised. For all RPs, it is strongly encouraged that business processes are

pursued that do not require the storage of Direct Identifiers

The Kantara Initiative Report on Blinding Identity Taxonomy may be useful for some use cases.

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 28 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

4.2.2 INDIRECT IDENTIFIERS

Indirect identifiers are attributes that enable unique identification of a data principal within a

specific operational context. This context can be provided by the combination with other

attributes which may be in the dataset or external to it. [REF ISO 20889]

Risk Considerations

4.2.2.1 Indirect Identifiers should be encrypted at rest.

4.2.2.2 Indirect Identifiers should only be transacted through encrypted channels.

4.2.2.3 Indirect Identifiers should not be collected and stored by RPs without the informed

consent of the data principal.

4.2.2.4 If collected and stored, Indirect Identifiers should undergo a process of de-identification

to protect data principle while meeting business needs.

4.2.2.5 If collected, Indirect Identifiers should only be stored for the minimum length of time

needed to complete business need after which they should be securely destroyed.

Note: In the case of mDLs all collected data can be considered indirect identifiers because the

dataset is cryptographically linked through the MSO. Implementers should pursue business

processes that do not require the collection and storage of indirect identifiers. If indirect

identifiers are collected, business processes should be pursued that make use of de-identification

techniques to protect individual identity within the dataset.

4.2.3 UNIQUE IDENTIFIERS

Unique identifiers are attributes in a dataset that alone single out a data principal in the dataset

[REF ISO 20889].

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 29 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

Risk Considerations

4.2.3.1 Unique Identifiers should be encrypted at rest when aggregated with the contextual

dataset.

4.2.3.2 Unique Identifiers should only be transacted through encrypted channels.

4.2.3.3 Unique Identifiers should only be collected and stored by RPs with the informed

consent of the data principal.

4.2.3.4 If collected and stored, Indirect Identifiers should undergo a process of de-identification

to protect data principle while meeting business needs.

4.2.3.5 Unique Identifiers should not be stored beyond the length of time determined by the

business need and should be destroyed securely after they are no longer needed.

Note: In the case of mDL datasets, all data associated with the mDL are unique identifiers when

held on the device as part of the mDL Holder’s mDL dataset. In addition to mDL attributes, this

includes device keys and any transaction data which may persist on the device such as ephemeral

keys, transaction history, or consent receipts when bound to the identifying dataset.

Implementers should provide tools and protection measures for this data such as encryption and

de-identification techniques.

4.2.4 QUASI-IDENTIFIERS

Quasi-identifiers are attributes in a dataset that single out a data principal when considered in

conjunction with other attributes in the dataset. [REF ISO 20889]

Risk Considerations

4.2.4.1 Quasi-Identifiers should only be transacted through encrypted channels.

4.2.4.2 Quasi-Identifiers should only be collected and stored by RPs with the informed consent

of the data principal.

4.2.4.3 If collected and stored, Quasi-Identifiers should undergo a process of de-identification

to protect data principle while meeting business needs.

4.2.4.4 Quasi-Identifiers should not be stored beyond the length of time determined by the

business need and should be destroyed securely after they are no longer needed.

Note: The collection of quasi-identifiers is coupled with the additional risk from aggregation.

Attributes which may not be identifying on their own can become identifiers when combined

with other datasets. The source of this data may be additional attributes collected from the mDL

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 30 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

dataset or attributes collected from other datasets like health records or loyalty programs. Data

principals will bear the negative outcome from this.

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 31 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

4.2.5 IDENTITY ATTRIBUTES IN CONTEXT

The attributes below are a subset of the ISO/IEC 18013-5 data elements that have been

identified, for the purposes of this report, as identity attributes. To understand the identity risk

posed for a transaction, each attribute should be considered both on its own without context and

within the operational context of the two most common datasets that will be encountered. The

first dataset is the Individual’s mDL data as held by their mobile device and the second dataset is

any collection of mDL data attributes from multiple mDL Holders collected by a RP or held by

the IA. Once the risk to identity is understood in its operational context, business processes can

be chosen to minimize harm posed to involved parties by each risk.

Attribute

Necessity

Operational Context

Solitary Release

Within mDL

Holder’s mDL

Dataset

Within dataset of

multiple mDL

Holders or other

non-mDL

datasets

Family Name

Required

Indirect

Identifier

Direct Identifier

Given Name

Required

Indirect

Identifier

Direct Identifier

Birth Date

Required

Indirect

Identifier

Unique Identifier

Quasi-Identifier

Document

Number

Required

Indirect

Identifier

Unique Identifier

Administrative

number

Optional

Indirect

Identifier

Unique Identifier

Sex

Optional

Not Identifying

Unique Identifier

Quasi-Identifier

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 32 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

Height

Optional

Not Identifying

Unique Identifier

Quasi-Identifier

Weight

Optional

Not Identifying

Unique Identifier

Quasi-Identifier

Eye Color

Optional

Not Identifying

Unique Identifier

Quasi-Identifier

Hair Color

Optional

Not Identifying

Unique Identifier

Quasi-Identifier

Birthplace

Optional

Not Identifying

Unique Identifier

Quasi-Identifier

Resident

Address

Optional

Direct Identifier

Portrait

Required

Direct Identifier

Age in Years

Optional

Not Identifying

Unique Identifier

Quasi-Identifier

Birth Year

Optional

Not Identifying

Unique Identifier

Quasi-Identifier

age_over_NN

Optional

Not Identifying

Unique Identifier

Quasi-Identifier

Nationality

Optional

Not Identifying

Unique Identifier

Quasi-Identifier

Resident City

Optional

Not Identifying

Unique Identifier

Quasi-Identifier

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 33 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

Resident State

Optional

Not Identifying

Unique Identifier

Quasi-Identifier

Resident Post

Code

Optional

Not Identifying

Unique Identifier

Quasi-Identifier

Biometric

template

Optional

Direct Identifier

Name in

National

Characters

Optional

Direct Identifier

Signature Mark

Optional

Direct Identifier

Table 2 Identity Attributes in Context

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 34 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

5 DATA FLOWS

5.1 DATA FLOW 1 (DF-1)

5.1.1 OVERVIEW

Data Flow 1 is the primary flow by which an IA issues a mDL to a mDL Holder. This will tend

to be proscribed by the IA, and each of the interfaces, a & b, below contain several data flows

and technical requirements defined outside of ISO/IEC 18013-5.

Figure 4 Data Flow 1

5.1.2 SPECIFIC PRIVACY REQUIREMENTS FOR DF-1

In addition to the general privacy requirements for the extended architecture, implementation

should consider the following:

5.1.2.1 IAs may consider following the general privacy requirements for the IA Infrastructure

for the collection, use, and disclosure of driver personal data outside the confines of

the18013 standard for mDL data.

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 35 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

5.1.3 SPECIFIC IDENTITY CONSIDERATIONS FOR DF-1

In addition to the general identity considerations for the extended architecture, implementation

should consider the following:

5.1.3.1 Out-of-Band confirmation of mDL Holder mobile device control should be used as part

of authentication during the provisioning process.

Note 1: mDL Holders should take additional consideration in understanding the terms and

conditions Issuers may place on their mobile devices and management of the mDL. Generally,

Issuers should prefer a passive management model, relying on mDL validity periods which are

as short as possible. If an active management model is pursued, mDL Holders should be made

aware of the additional permissions, or device management functionally, an Issuer may request.

Additional device access could create the potential for serious privacy implications for the mDL

Holder through both unreasonable access by an Issuer and the potential for unintended

consequences due to programmatic bugs which could be exploited.

Note 2: DF-1 represents the only channel available for provisioning and management of the

mDL on the mDL Holder’s mobile device. (See Section 4.2). Specifically, for the case of

provisioning, Issuers should weigh the risk of remote interactions with the mDL Holder where

privacy and identity risk is greater than an in-person issuance action. These risks are higher

because issuance and provisioning necessitates the creation and collection of all identifying

elements in the mDL, including the collection of biometrics to create the basis for identity

binding in ISO/IEC 18013-5.

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 36 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

5.2 DATA FLOW 2 (DF-2)

5.2.1 OVERVIEW

DF-2 is the data flow that occurs on the interface between the mDL (presumptively a mobile

phone application acting as software wallet containing the mDL) and the mDL Reader. The data

flow includes:

1) Engagement through a positive mDL Holder action such as a gesture, NFC tap, or similar

positive step; and

2) Data Exchange.

Note: Privacy considerations are more likely to be administrative, such as policies or contracts,

while identity considerations are more likely to be technical, such as input validation or

encryption.

Figure 5 Data Flow 2

5.2.2 SPECIFIC PRIVACY REQUIREMENTS FOR DF-2

In addition to the general privacy requirements for the extended architecture, implementation

should consider the following:

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 37 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

5.2.2.1 The Implementer should consider physical controls to ensure that the information

received by the mDL Verifier is not displayed to others.

5.2.2.2 The Implementer should perform a test of mDL Holder presence in the transaction flow

as a means to ensure positive mDL Holder control of the data released. In ISO/IEC

18013-5 this is achieved through the physical engagement process using a NFC tap or

QR code scan.

5.2.3 SPECIFIC IDENTITY CONSIDERATIONS FOR DF-2

In addition to the general identity considerations for the extended architecture, implementation

should consider the following:

5.2.3.1 The Implementer should make clear the intended use and storage policy for the data

requested. If the intention cannot be made clear in a single transaction, multiple data

transactions should be used to allow the mDL Holder fully informed consent. For

example, an age-verification sale combined with the sign-up for a loyalty program.

While this data could all be transmitted in one transaction, the consent to collect and

store all the data may not be clear enough to the user. As such, the age verification

transaction should be separate from the loyalty sign-up process to ensure that the mDL

Holder has full control over the data release.

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 38 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

5.3 DATA FLOW 3 (DF-3)

5.3.1 OVERVIEW

DF-3 is the date flow by which a mDL Verifier requests a mDL Holder’s data directly from the

IA. As defined in ISO/IEC 18013-5, the mDL Verifier must obtain the mDL Holder’s server

retrieval token to perform the DF-3 data request. This is accomplished through the use of DF-2

and all Privacy and Identity considerations from DF-2 should apply.

Figure 6 Data Flow 3

5.3.2 SPECIFIC PRIVACY REQUIREMENTS FOR DF-3

In addition to the general privacy requirements for the extended architecture, implementation

should consider the following:

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 39 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

5.3.2.1 To protect against surveillance, mDL Verifiers should minimize the information about

the mDL Holder from a mDL transaction transferred to the IA and the information

requested from the IA.

5.3.2.2 In addition to surveillance of the mDL Holder’s behavior, DF-3 creates the potential for

an Issuer to surveil mDL Verifiers. This risk should be considered when evaluating the

use of DF-3 over DF-2 for mDL verification.

5.3.2.3 Due to the higher privacy risks, DF-2 should be favored over DF-3 unless required by

business need or compliance with applicable jurisdictional and contractual obligations.

5.3.3 SPECIFIC IDENTITY CONSIDERATIONS FOR DF-3

In addition to the general identity considerations for the extended architecture, implementation

should consider the following:

5.3.3.1 Implementers should make the mDL Holder aware that their data is being retrieved

online from the Issuer and that the mDL Verifier provides no guarantees against the

surveillance of the transaction.

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 40 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

5.4 DATA FLOW A (DF-A)

5.4.1 OVERVIEW

This data flow has two instances, based on the fact that the mDL Holder actor and the Individual

Actor are, in real life, the same natural person holding a single mobile device. It is conceptually

the case that mDL data can be held in an app that also holds other, or the same, information as

part of another ecosystem such as a multifunction wallet. It is also the case that the person may

have a need to have their ‘wallet’ app read data from their mDL app. These are variants A.1 and

A.2 below. DF-A.1 is an “in app” variant where mDL identity attributes are made available as

read only fields. DF-A.2 is an on-device variant where another app reads identity attributes from

a mDL app. We assume that the mDL is a read-only store for these purposes. Only the mDL

Issuer should alter the attributes in a mDL.

DF-A.1

Figure 7 Data Flow A.1

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 41 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

DF-A.2

Figure 8 Data Flow A.2

5.4.2 SPECIFIC PRIVACY REQUIREMENTS FOR DF-A

In addition to the general privacy requirements for the extended architecture, implementation

should consider the following:

5.4.2.1 The flow of mDL information to the wallet should be a read-only flow.

5.4.2.2 mDL information used to populate fields in a wallet should be under the control of the

Individual, such that they can delete the non-mDL fields, or their contents, from the

wallet.

5.4.3 SPECIFIC IDENTITY CONSIDERATIONS FOR DF-A

In addition to the general identity considerations for the extended architecture, implementation

should consider the following:

5.4.3.1 Because DF-A is occurring on the device, consent of data release may exist beyond a

single transaction. Implementers should take appropriate action to inform the mDL

Holder of any ongoing consent, including periodic re-authorization.

On-device management and access of mDL data is not in scope of the ISO/IEC 18013-5 standard

and all data access over DF-A is undefined data access. If mDL applications make this channel

available to mDL Holders and/or mDL Implementers, the on-device interfaces may be

proprietary APIs and may not be standardized between different application vendors which

creates additional risk in the ecosystem. Without standardized privacy and identity controls,

mDL Holders, mDL Issuers, and mDL Verifiers will carry this additional risk and may not be

aware when the level of risk has changed relative to the standardized data flows.

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 42 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

Note 1: mDL Holders will carry significant risk when data is transacted over the DF-A interface

because they may not be made aware of the operations of DF-A when the mDL application is

operating under a non-standard API. One of the most significant risks associated with undefined

data access is the potential loss of consent over data release. mDL Holders should be made aware

if mDL data is being accessed without their consent. Additionally, data access and identity

disclosure risk may change without notifying the mDL Holder because this type of notification is

not required during undefined data access. Changes in risk which are not indicated to parties in

the transaction creates the potential for increased harm. mDL Holders should exercise increased

caution when completing mDL transactions using undefined data access.

Note 2: Implementers should pursue business processes which prioritize the use of data flows

defined in the ISO/IEC 18013-5 standard. If business processes necessitate the use of DF-A,

considerations should be taken to meet the privacy and identity considerations discussed herein

to protect the mDL Holder’s identity attributes. Also, processes should be pursued to

communicate changes of risk level to all parties involved in an identity transaction. Special

consideration should be taken to ensure that mDL Holders are given the ability to consent and

control the release of their data over DF-A. mDL Holders should be made aware of these risks

and the controls available to mitigate these risks.

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 43 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

5.5 DATA FLOW B (DF-B)

5.5.1 OVERVIEW

This data flow also has two instances for similar use cases as in DF-A. Also note that the ‘mDL

Verifier’ and the ‘RP’ in these data flows will be the same entity reading the mDL attributes

presented by a mDL Holder.

DF-B.1

Figure 9 Data Flow B.1

DF-B.2

Figure 10 Data Flow B.2

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 44 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

5.5.2 SPECIFIC PRIVACY REQUIREMENTS FOR DF-B

In addition to the general privacy requirements for the extended architecture, implementation

should consider the following:

5.5.2.1 Data from the mDL Reader may only flow to the RP Read Software/Hardware if the RP

has provided adequate notice to the mDL Holder about how their mDL data will be

consumed by the RP Reader.

5.5.3 SPECIFIC IDENTITY CONSIDERATIONS FOR DF-B

In addition to the general identity considerations for the extended architecture, implementation

should consider the following:

5.5.3.1 Implementers should consider the impact of combining mDL data with other non-mDL

datasets and evaluate the changes of operational context which may occur for the

collected identifiers.

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 45 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

5.6 DATA FLOW C (DF-C)

5.6.1 OVERVIEW

DF-C represents the transport of mDL data from the mDL Holder’s device through any channel

not defined in ISO/IEC 18013-5. This data flow presents a very high risk to the mDL Holder

because it is not standardized and will be subject to proprietary processes that may not have clear

privacy and identity protection by design.

DF-C

Figure 11 Data Flow C

5.6.2 SPECIFIC PRIVACY REQUIREMENTS FOR DF-C

In addition to the general privacy requirements for the extended architecture, implementation

should consider the following:

5.6.2.1 If using Verified Credentials, consider using the IA Infrastructure.

5.6.2.2 Simple graphical captures of physical cards (flash passes) bypass the physical security

of the card without substituting any digital equivalent to ensure validity and integrity of

the credential.

5.6.2.3 See the considerations for DF-2.

5.6.3 SPECIFIC IDENTITY CONSIDERATIONS FOR DF-C

In addition to the general identity considerations for the extended architecture, implementation

should consider the following:

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 46 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

5.6.3.1 Due to the largely proprietary nature of the DF-C data flow, a mDL Holder may not be

aware of changes in operational context. Implementers should take extra considerations

to ensure mDL Holders are informed and provide adequate consent for data that is to be

released.

5.7 INTEROPERABILITY RISK

Interoperability of a mDL with a mDL Verifier’s hardware becomes a significant privacy

consideration when it interrupts the normal course of business. In most cases when the mDL

transaction fails due to interoperability issues, the mDL Verifier and/or mDL Holder, not wanting

to abandon the transaction, may attempt to find a work around by leveraging DF-C in an

unintended way. When either party pursues a transaction solution outside of scope of the

ISO/IEC 18013-5 standard, there may be no remaining technical controls in place to protect the

mDL Holder’s privacy or identity data. An example of such a work around may be reverting to

using the application displayed on the mDL Holder’s device as a flash pass to fulfill the

requirements of visual data transmission which is the current method used with physical ID

cards.

While this work around may interoperate with existing point of sale systems which are designed

for the mDL Verifier to read data from a physical card, the data minimization and selective data

release mechanism built into the ISO/IEC 18013-5 standard may no longer be available to the

mDL Holder if the mDL vendor has designed their application in that manner. Further, the mDL

Verifier loses the ability to cryptographically verify the identity information provided and

therefore will be limited to making a risk decision based on the visual appearance of a mobile

application. In most cases, cloning the visual aspects of a mobile application is significantly

easier than the security features of a physical ID which puts the mDL Verifier at risk of accepting

a counterfeit mDL.

mDL Verifiers and IAs should work together with mobile handset manufacturers and mDL

application developers to ensure broad interoperability within the mDL ecosystem. For added

protection, mDL Developers may build applications which, by design, cannot be used in a

manner other than intended. One such method is to create applications which do not display

sufficient information on the mDL Holder’s mobile device to use the application as a flash pass.

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 47 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

6 SUMMARY

This report provides identity and privacy considerations for product managers, engineers,

compliance teams, architects, developers, assessors, and others with responsibilities for

implementing, supporting, or interfacing with mobile credentials. The intent of these

considerations is to ensure that a mDL Holder can be assured that their privacy and their identity

attributes will be protected through the entire life cycle of that information. These considerations

include ensuring that the analog protections provided by anti-counterfeiting controls in physical

driving licenses do not get bypassed by digital processes that reduce identity protections, such as

‘flash passes’. It is the case that the more control that is vested in the mDL Holder with respect to

their own information, the more likely it is that the mDL solution will be able to build trust. The

guidance provided in this Report lays the groundwork for subsequent conformance work such as

developing assessment criteria for each emerging requirement, provided there is ecosystem

demand and support to do so, and in a workgroup chartered to do so.

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION - ---Non-Assertion Covenant Page 48 of 54

Privacy & Identity protection in mobile Driving License

ecosystems

7 A

PPENDICES

7.1 ADDITIONAL CONSIDERATIONS

7.1.1 SECURITY CONSIDERATIONS:

During the discussions leading to this report, a number of particular threat scenarios were

identified:

Threat

Notes

Spoofing: where the

attacker can authenticate

using another’s mDL data.

It can also be that the

mDL Verifier spoofs a

known site the user trusts.

Somehow the trust

registries need to be made

known to the mDL

Verifier and perhaps to the

user.

mDL authentication is performed using a public key. In the Day

1 solution, after authentication, the RP has to tie the

authenticated data to the person presenting the data using the

authenticated portrait image. The attack here would be a person

trying to match the mDL portrait image of someone else. This

is a problem with physical cards already, and is expected to

become more challenging in the case of a mDL given the

higher quality and larger portrait image involved.

The current version of 18013-5 does not address unattended use

(e.g. use over the Internet).

Unauthorized Information

Disclosure (loss of privacy)

18013-5 supports selective disclosure of information (and

informing the mDL Holder of the RP's intent to retain the

information or not) to address exactly this concern. Having said

that, a big concern is that once data is released, the mDL

Holder no longer has control of the data.

Linking

A form of disclosure where one set of attributes are aggregated

to the point where the real-world user is identified.

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION – --Non-Assertion Covenant Page 49 of 51

Privacy & Identity protection in mobile Driving License

ecosystems

Repudiation

This is where a user is able to deny having provided the

information. 18013-5 intentionally did not design the mDL for

non-repudiation use.

Denial of Service

This is where a user is unable to access the resource desired.

Note that this includes both intentional and unintentional

outages and could be a reliability issue.

Tampering

This is where an attacker is able to change the data in-flight.

This can be just a form of Denial of Service, or this can result

in spoofing one of the attributes (e.g., age).

The mDL in 18013-5 was designed to specifically guard

against Man-In-The-Middle (MITM) attacks, and otherwise

changing data would require breaking the private document

signer key.

Table 3 Additional Security Considerations

7.2 IDENTIFIER PROTECTION SUMMARY

The following table is a summary of identity protection considerations for the types of identifiers

contained in the mDL dataset.

Direct Identifier

Indirect

Identifier

Unique

Identifier

Quasi-Identifier

Encrypted at Rest

Yes

Yes, if stored in

identifying context

Encrypted in

transit

Yes

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION – --Non-Assertion Covenant Page 50 of 51

Privacy & Identity protection in mobile Driving License

ecosystems

Collected and

stored without

consent

Stored for

minimum length

of time needed

Yes

Undergo a process

de-identification if

stored

Yes, but storage

should be

minimized if

possible

Yes

7.3 BIBLIOGRAPHY

The Mobile Driver’s License (mDL) and Ecosystem, The Secure Technology Alliance, Version

1, March 2020,

https://www.securetechalliance.org/wp-content/uploads/Mobile-Drivers-License-WP-FINAL-Up

date-March-2020-4.pdf

7.4 TERMINOLOGY

This section defines terms and abbreviations as they are used in this report.

Term/Abbreviation

Definition(s)

AAMVA

American Association of Motor Vehicle Administrators

API

Application Programming Interface

BLE

Bluetooth Low Energy

COBIT

Control OBjectives for Information and related Technology

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION – --Non-Assertion Covenant Page 51 of 51

Privacy & Identity protection in mobile Driving License

ecosystems

DID

W3C Decentralized Identifier

DIS

Draft International Standard

DMV

Department of Motor Vehicles

Flash Pass

Visual presentation of an image of a mobile ID without cryptographic

verification

Issuing Authority

IDL

ISO-compliant driving licence

Implementer

a person or organization that is accountable, or responsible, for

implementing one or more of the of endpoints identified in the PImDL

Data Flows.

Individual

a single person: a person who is considered separate from the rest of a

group [Merriam Webster]

ISO/IEC

International Organization for Standardization / International

Electrotechnical Commission

Issuer

Generic term that may encapsulate different types of Issuer in a range

of roles and contexts

Issuing Authority

refers to ISO18013-5 section 3.13 issuing authority, which may be at a

national level (ISO18013-5 section 3.11 issuing country) or a local

level jurisdiction. [attribution: Future Identity Council]

JWS

JSON Web Signature

mDL

mobile Driving License

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION – --Non-Assertion Covenant Page 52 of 51

Privacy & Identity protection in mobile Driving License

ecosystems

mDL Developer

The entity that creates the mDL software being used by the mDL

Holder on their chosen device.

mDL Holder

Refers to the owner of a mobile device. (US DHS) [attribution: Future

Identity Council]

mDL Issuer

Alternative informal term for Issuing Authority

mDL Provider

A generic term describing the entity undertaking mDL provisioning

mDL Reader

refers to an electronic device that ingests mDL Data from a mobile

device. (DHS) Also refers to ISO/IEC 18013-5 section 3.7.mDL

Reader. [attribution: Future Identity Council]

mDL Reader

Developer

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

mDL Verifier

person or organization using and/or controlling an mDL reader (3.6) to

verify an mDL (3.4) [ISO/IEC 18013-5]

MITM

Man-in-the-middle attack

Mobile Device

Developer

The entity that creates the software (“wallet”) being used by an

Individual, who is also a mDL Holder, on their chosen device

MSO

Mobile Security Object

NFC

Near Field Communication

OIDC

OpenID Connect

PII

Personally Identifiable Information

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION – --Non-Assertion Covenant Page 53 of 51

Privacy & Identity protection in mobile Driving License

ecosystems

PImDL

Privacy & Identity Protection in mobile Driving License ecosystems

PKI

Public Key Infrastructure

QR code

two-dimensional machine readable optical symbol. Note 1 to entry:

QR code formats are specified in ISO.IEC 18004:2015 [ISO/TS

22691:2021 (en), 3.3]

Relying Party

means ISO 18013-5 section 3.5 mdoc verifier or a 3.9 mDL Verifier

[attribution: Future Identity Council]

Relying Party

RP Reader Developer

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

SSI

Self-Sovereign Identity

STA

Secure Technology Access

Undefined data

access

Access of mDL data by a method not included in ISO/IEC 18013-5

W3C Verified Credential

WebAPI

Web Application Programing Interface

Table 5.

Document Version : 1.0 Document Date : 2021-06-29

www.kantarainitiative.org

IPR OPTION – --Non-Assertion Covenant Page 54 of 51