ISO/IEC TS 18013-7:2024

Technical
Specification
ISO/IEC TS 18013-7
First edition
Personal identification — ISO-
2024-10
compliant driving licence —
Part 7:
Mobile driving licence (mDL) add-
on functions
Identification des personnes — Permis de conduire conforme
à l'ISO —
Partie 7: Fonctionnalités supplémentaires pour permis de
conduire sur téléphone mobile
Reference number
© ISO/IEC 2024
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2024 – All rights reserved
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 1
5 Conformance requirement . 2
6 mDL overview . 2
6.1 Standards context .2
6.2 Interfaces .2
6.3 Design objectives .3
6.4 Technical requirements .3
6.4.1 Data structures and data elements .3
6.4.2 Data model .3
6.4.3 Data exchange .3
6.4.4 Security mechanisms .5
6.5 Protocol considerations . .6
6.5.1 General .6
6.5.2 Discovery and invocation of mdoc using a custom URI scheme .7
6.5.3 Possible attack .7
6.5.4 Additional flows and methods .7
7 mDL data model . 7
Annex A (normative) Mechanisms for device retrieval to a website . 9
Annex B (normative) Use of OID4VP to retrieve an mdoc .15
Bibliography .39

© ISO/IEC 2024 – All rights reserved
iii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 17, Cards and security devices for personal identification.
A list of all parts in the ISO 18013 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-ommittees.

© ISO/IEC 2024 – All rights reserved
iv
Introduction
ISO/IEC 18013-5 describes interface and related requirements to facilitate ISO-compliant driving licence
functionality on a mobile device, standardizing the mobile driving licence (mDL) functionality.
This document augments the capabilities of the mDL by describing the interface and related requirements
for presentation to a mDL reader over the internet.
A mobile document conforming to this document primarily conveys the driving privileges associated with a
person. However, the transaction and security mechanisms in this document have been designed to support
other types of mobile documents, specifically including identification documents.
NOTE ISO/IEC 18013-5 places the onus on the mDL verifier to match data received (in an mdoc) to the person
presenting the mdoc. This version of this document does not change this.

© ISO/IEC 2024 – All rights reserved
v
Technical Specification ISO/IEC TS 18013-7:2024(en)
Personal identification — ISO-compliant driving licence —
Part 7:
Mobile driving licence (mDL) add-on functions
1 Scope
This document augments the capabilities of the mobile driving licence (mDL) standardized in ISO/IEC 18013-5
with the following additional functionality:
— presentation of a mobile driving licence to a reader over the internet.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 18013-5, Personal identification — ISO-compliant driving licence — Part 5: Mobile driving licence
(mDL) application
RFC 4648, S. Josefsson, The Base16, Base32, and Base64 Data Encodings
RFC 5280, D. Cooper et al., Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List
(CRL) Profile
RFC 9101, N. Sakimura, The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR
RFC 9112, R. Fielding et al., HTTP/1.1
OID4VP (OpenID for Verifiable Presentations), O. Terbu et al., Draft 18, April 2023
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 18013-5 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
mdoc reader
either device or service, or both, that can retrieve data from an mdoc and verify the authenticity of the data
Note 1 to entry: The mdoc reader includes, but is not limited to, the hardware and software components used.
4 Abbreviated terms
OID4VP OpenID for Verifiable Presentations

© ISO/IEC 2024 – All rights reserved
5 Conformance requirement
An mDL is in conformance with this document if it meets all the requirements specified directly or by
reference herein.
An mDL reader is in conformance with this document if it meets all the requirements specified directly or
referenced herein.
NOTE Conformance of an mDL or an mDL reader with ISO/IEC 18013-5 is not required for conformance with this
document, except for those clauses normatively referenced in this document. An mDL or an mDL reader conforming
with this document can also be in conformity with ISO/IEC 18013-5.
6 mDL overview
6.1 Standards context
ISO/IEC 18013-5 describes the interface and related requirements to specifically facilitate ISO-compliant
driving licence functionality on a mobile device. This document adds functionality by building on top of
ISO/IEC 18013-5.
The transaction and security mechanisms in this document have been designed to also be applicable to
other types of mobile documents besides the mobile driving licence.
6.2 Interfaces
Figure 1 shows the interfaces in scope for this document. The explanation of each interface is as follows:
— Interface 1 in Figure 1 is the interface between the issuing authority (IA) infrastructure and the mDL.
This interface is out of scope for this document.
— Interface 2 in Figure 1 is the interface between the mDL and the mDL reader. This interface is specified
in this document. The interface can be used for connection setup and for the device retrieval method.
— Interface 3 in Figure 1 is the interface between the IA infrastructure and the mDL reader. This interface
is defined in ISO/IEC 18013-5. No new requirements are added in this document.
Figure 1 — mDL interfaces
© ISO/IEC 2024 – All rights reserved
6.3 Design objectives
The objectives underlying the requirements in this document include at least the following:
a) An mDL verifier together with an mDL reader is able to request and receive an mDL, and validate its
integrity and authenticity.
b) An mDL verifier not associated with the IA is able to verify the integrity and authenticity of an mDL.
c) An mDL verifier is enabled to confirm the binding between the person presenting the mDL and the
mDL holder.
d) The interface between the mDL and the mDL reader supports the selective release of mDL data to an
mDL reader.
NOTE As in ISO 18013-5, the portrait image can be used for verifying that the person presenting the mDL is the
mDL holder. Depending on the transaction details, in an unattended transaction this data element might not be able to
serve the purpose of confirming that the person presenting the mDL is the mDL holder. Other methods can be used as
well but are out of scope of this document. Other mechanisms are described in References [1] and [2].
6.4 Technical requirements
6.4.1 Data structures and data elements
The descriptions and requirements for Concise Binary Object Representation (CBOR), Concise Data
Definition Language (CDDL), and version elements in ISO/IEC 18013-5 shall apply in this document.
Additionally, unless explicitly stated otherwise for a data structure, an mdoc or mdoc reader shall not give
an error purely on the basis that it does not know the element. This requirement also applies when the CDDL
definition of the data structure does not allow the presence of additional key-value pairs in the map, next to
the specified ones.
6.4.2 Data model
The data model is described in Clause 7. It describes the identifier and format of the data elements.
6.4.3 Data exchange
6.4.3.1 Overview
An mDL or mDL reader shall support at least one of the flows and may support more:
a) Using the device retrieval messages structures and transmission channel as defined in 6.4.3.3 that is setup:
1) using remote engagement, as defined in 6.4.3.2; or
2) using an out-of-band mechanism, as defined in 6.4.3.2;
b) Using OID4VP as a transmission channel, as defined in Annex B.
The different flows are depicted in Figure 2.

© ISO/IEC 2024 – All rights reserved
Figure 2 — Flows for unattended cases
An mDL and mDL reader shall support at least one of the following data retrieval methods and may support
more. Table 1 shows the requirements.
— device retrieval as defined in 6.4.3.3;
— OID4VP as defined in Annex B.
Table 1 — Data retrieval methods
Data retrieval method Support Reference in this
document
mDL mDL reader
a a
Device retrieval C C 6.4.3.3
a a
OID4VP C C Annex B
Key
C  conditional
a
Support for at least one of these methods is mandatory.
6.4.3.2 Device retrieval engagement phase
The engagement mechanism for remote engagement can be used to exchange the information required
to set up a secure data retrieval mechanism between the mDL and mDL reader. When performing remote
engagement, the following flow shall be used:
a) The mDL reader transmits the ReaderEngagement structure to the mDL.
b) The mDL sets up a data transmission channel with the mDL reader using the information from the
ReaderEngagement structure.
c) The mDL sends a DeviceEngagement structure to the mDL reader using the newly setup data
transmission channel.
The ReaderEngagement and DeviceEngagement structures are defined in A.1 and A.2. A possible mechanism
for transmission of the ReaderEngagement structure is defined in A.4. Support for this transmission
mechanism is recommended for the mDL and mDL reader, since this is the only mechanism currently
provided in this document. However, other mechanisms for transmitting the ReaderEngagement structure,
which are not defined in this document, can be used.

© ISO/IEC 2024 – All rights reserved
When the mDL and mDL reader have an existing two-way data transmission channel that is set up out-of-
band for exchange of data, the device retrieval engagement phase can be skipped.
6.4.3.3 Device retrieval data retrieval phase
The general data retrieval architecture is described in ISO/IEC 18013-5. If an mDL or mDL reader supports
the device retrieval data retrieval phase, they shall use the mdoc request and mdoc response structures as
specified in ISO/IEC 18013-5.
A.6.2 defines a transmission technology for device retrieval that may be supported by an mDL or an mDL reader.
NOTE ISO/IEC 18013-5 defines the server retrieval data retrieval method. This document does not specify any
additional requirements for server retrieval.
6.4.4 Security mechanisms
6.4.4.1 Security architecture
The security of mDL data exchanged with an mDL reader is designed to preserve the triad of confidentiality,
integrity, and authenticity by design and by default.
The security architecture aims to achieve the following goals:
a) Protection against forgery: Data elements are signed by the IA. The degree of protection against forgery
depends on the degree to which the IA's keys are protected. Minimizing the validity period of the data
limits the value of the data.
b) Protection against cloning: The mDL produces a signature or message authentication code over session
data. The private key used to authenticate the session data is stored only in the mDL. The corresponding
public key in turn is signed by the IA. The degree of protection against cloning depends on the degree to
which the mDL authentication key is protected. In addition to protecting DeviceKey by secure storage,
an mdoc/mDL can require the user to be authenticated before this key is usable. This depends on the
jurisdiction/issuer's policy (e.g. AAL as per eIDAS Regulation, NIST SP 800-63, ISO/IEC 29115).
c) Protection against eavesdropping: Communications between mDL and mDL readers are encrypted and
authenticated. The mDL reader can detect man-in-the-middle (MITM) attacks by validating the anti-
cloning signature or message authentication code, which is created using a key for which the public
part is signed by the IA in the mobile security object (MSO), see ISO/IEC 18013-5. If mdoc reader
authentication is used, the mDL can detect MITM attacks before returning any data.
d) Protection against unauthorized access: An mDL is protected from unauthorized access by an mDL
reader by multiple mechanisms. When session encryption is used, the encryption key used for
communications between the mDL and mDL reader is derived from an ephemeral key pair from both
the mDL and mDL reader. The mDL can optionally authenticate the mDL reader by means of an mDL
reader authentication certificate and a signature created by the mDL reader using the corresponding
private key. The mDL reader certificate is signed by a certificate authority trusted by the mDL for this
purpose.
e) Protection of the mDL holder against relayed engagement information: the mDL includes in the device
engagement data, the origin information of the engagement channel or the data transmission channel for
the mDL reader to confirm it. The origin is determined by the mDL independently from the information
transmitted in the reader engagement structure. The transaction is cancelled by the mDL reader when
the origin is different from the expected value.
Revocation of an mDL is out of scope for this document. However, the MSO includes update information and
validity time frames which enable the mDL reader to check the freshness of the data. The IA shall define
appropriate periods of validity that balance freshness with offline capability, considering that a shorter
validity period mitigates certain security risks.

© ISO/IEC 2024 – All rights reserved
6.4.4.2 Security mechanisms support requirements
Table 2 describes the security mechanisms that can be implemented by an mDL or an mDL reader. Issuer
data authentication, and mdoc authentication shall be implemented by the mDL and mDL reader. Session
encryption shall be implemented if the device retrieval to a website mechanism, specified in A.6 is used.
mdoc reader authentication is optional for the mDL and mDL reader.
mdoc authentication, mdoc reader authentication and session encryption shall use the session transcript as
defined in A.8
A.5 contains further requirements on the use of mdoc mac authentication.
NOTE 1 ISO/IEC 18013-5 describes the use of the X.509 certificates when using mdoc reader authentication. Other
mechanisms for providing the mDL reader public key and trust information can also be used.
The certificate and CRL profile requirements in ISO/IEC 18013-5 shall be applied for the following profiles:
IACA root certificate, IACA link certificate, document signer certificate, mdoc reader authentication
certificate, Online Certificate Status Protocol (OCSP) signer certificate, CRL profile.
All certificates issued by an IACA or another CA shall be validated according to ISO/IEC 18013-5.
An mDL reader needs access to the issuing authority’s certificate authority (IACA) root certificate to
verify issuer data authentication. An optional method to get access to these certificates is described in
ISO/IEC 18013-5 using a verified issuer certificate authority list (VICAL) provider.
See the privacy and security recommendations in ISO/IEC 18013-5 for additional information on privacy
and security.
Table 2 — Security mechanisms
Security mechanisms Support Reference
Session encryption Conditional (see 6.4.3) A.6
Issuer data authentication Mandatory ISO/IEC 18013-5
mdoc authentication Mandatory ISO/IEC 18013-5
mdoc reader authentication Optional ISO/IEC 18013-5
6.4.4.3 Additional verification requirements
If the OriginInfo as defined in A.3 contains the domain origin type as defined in A.3.2, the mDL reader shall
verify whether it matches the domain of where the mDL was requested.
The behaviour of the mDL reader when it receives an empty string as value for the key "domain" in the
"details" field of the domain origin OriginInfo type is out of scope of this document.
The mDL reader shall also verify any other elements in the OriginInfo that it understands and for which it
can obtain the info to verify it. If the verification fails, the mDL reader shall terminate the transaction and
invalidate any received data.
6.5 Protocol considerations
6.5.1 General
This clause reflects security and privacy considerations that implementers of flows and methods described
in this document can consider.

© ISO/IEC 2024 – All rights reserved
6.5.2 Discovery and invocation of mdoc using a custom URI scheme
mdoc and mdoc-openID4VP URI schemes present limitations when used to invoke the wallet. Examples of
limitations include (but are not limited to):
EXAMPLE 1 When using the custom URI scheme on iOS, the developer documentation notes that "If multiple apps
register the same scheme, the app the system targets is undefined. There’s no mechanism to change the app or to
change the order apps appear in a Share sheet" (see Reference [19]).
EXAMPLE 2 Discussions are circulating around the possible deprecation of support for certain URI schemes that
can cause implementations to break (see Reference [19]).
EXAMPLE 3 The user receives no assistance in selecting the appropriate wallet since the custom URI scheme only
provides selection based on protocol. This can lead to the user making an incorrect wallet selection.
EXAMPLE 4 Custom URI schemes require apps to ensure protection from malformed input data. Further solutions
that assist in executing this protection (see 6.5.3) can be helpful.
EXAMPLE 5 Custom URI schemes inhibit the capabilities of the browser to protect the user.
6.5.3 Possible attack
6.5.3.1 Attack description
A possible attack is when a victim authenticates for a session at the relying party that is under the attacker’s
control, or more specifically, when an attacker interacts with a relying party to generate a link to then
forward that link to a victim to have the victim complete the process on behalf of the attacker.
6.5.3.2 Device retrieval to a website
For device retrieval to a website, the solution is for the user agent to provide the domain origin to the
mdoc application. Certain browsers have settings that can prevent the domain origin information from
being provided by the user agent. In addition, some browsers do not support providing the domain origin
information via schemes. In situations like this, if the presentment is performed, engagement information
can be forwarded by an attacker and the mDL holder is vulnerable to the above attack.
6.5.3.3 OID4VP
For OID4VP, a solution is for the mdoc reader to maintain the binding between the user session and the nonce
authorization request parameter. While a reader is required to implement a mechanism to maintain the
binding, this document does not define one. In addition, absent a list of trusted readers (that are confirmed
to maintain the binding, and that can be used by the mdoc to make/inform decisions about the transaction),
the mdoc does not have a way to check if the binding is maintained. If the binding is not maintained and the
presentment is performed, engagement information can be forwarded by an attacker and the mDL holder
is vulnerable to the above attack. There are ongoing discussions in the OpenID Foundation to propose a
solution (see Reference [20]).
6.5.4 Additional flows and methods
Work is ongoing to improve the way in which an mdoc reader and an mdoc can interact when not in close
proximity. This includes work on a browser API in an incubator group of the World Wide Web Consortium
(W3C). Work is also ongoing in the OpenID Foundation on this subject (see Reference [3]).
7 mDL data model
The mDL data model descriptions and requirements in ISO/IEC 18013-5 shall apply in this document with
the following exception: an mDL may require mdoc reader authentication as a precondition for the release of
any of the mandatory data elements.
NOTE 1 This differs from the requirement from ISO/IEC 18013-5

© ISO/IEC 2024 – All rights reserved
NOTE 2 In order for an mDL and mDL reader to use mdoc reader authentication, a trust relationship between the
parties involved must exist.
© ISO/IEC 2024 – All rights reserved
Annex A
(normative)
Mechanisms for device retrieval to a website
A.1 Reader engagement
The reader engagement structure contains the information to perform the engagement flow as defined in
6.4.3.2. The reader engagement structure shall be CBOR encoded and formatted as follows:
ReaderEngagement =
{
0: tstr,      ; Version
1: Security,
? 2: DeviceRetrievalMethods,
* int => any
}
Security = [
int,        ; Cipher suite identifier
EReaderKeyBytes
]
DeviceRetrievalMethods = [
+ DeviceRetrievalMethod
]
DeviceRetrievalMethod = [
uint,        ; Type
uint,        ; Version
RetrievalOptions  ; Specific option(s) to the type of retrieval method
]
RetrievalOptions = RestApiOptions / any

The reader engagement structure contains the key-value pairs described below. Additional positive key-
value pairs within the engagement structure are RFU. An application-specific extension shall use a negative
integer for the key. An mdoc or mdoc reader shall ignore any key-value pairs with a negative key value that
it is not able to interpret.
0) Version: the version of the reader engagement structure, in the current version of this document its
value shall be “1.1”.
1) Security: an array that contains two mandatory elements. The first element is the cipher suite identifier,
defined in ISO/IEC 18013-5. The second element is EReaderKeyBytes, defined in ISO/IEC 18013-5.
2) DeviceRetrievalMethods: an array that shall contain one or more DeviceRetrievalMethod. A
DeviceRetrievalMethod array holds three mandatory values (Type, Version, RetrievalOptions).
This document only specifies the values for the device retrieval to a website method from A.6. When
using this method, the value for Type shall be 4, the value for Version shall be 1, and the value for
RetrievalOptions shall be RestApiOptions as defined in A.6.
A.2 DeviceEngagement
The device engagement structure contains the information the mdoc reader needs to perform the
engagement flow as defined in 6.4.3.2. The device engagement structure shall be CBOR encoded and
formatted as follows:
© ISO/IEC 2024 – All rights reserved
DeviceEngagement =
{
0: tstr,      ; Version
1: Security,
5: OriginInfos,
? 6: Capabilities,
* int => any
}
Capabilities = {
? 0: MacKeysSupport,
? 1: MacKeysCurves,
* int => any
}
MacKeysSupport = bool
MacKeysCurves = [*crv]
crv = int
The device engagement structure contains the key-value pairs described below. Additional positive key-
value pairs within the engagement structure are RFU. An application-specific extension shall use a negative
integer for the key. An mdoc or mdoc reader shall ignore any key-value pairs with a negative key value that
it is not able to interpret.
0) Version: the version of the device engagement structure, in the current version of this document its
value shall be “1.1”.
1) Security: This structure is defined in ISO/IEC 18013-5. A.7 describes how this structure is used.
5) OriginInfos: The OriginInfos structure provides information about the interface used to receive and
deliver the engagement structure, it is defined in A.3. OriginInfos shall be present.
6) Capabilities: Contains a map of capabilities the mdoc supports. Currently two optional elements are
defined: MacKeysSupport and MacKeysCurves. The contents of these two values are defined below.
The MacKeysSupport element in the Capabilities structure can be used by the mdoc to indicate whether it
supports the MacKeys element in the mdoc request, as defined in A.5. When the value is set to True, the mdoc
indicates support for the MacKeys element.
The MacKeysCurves element in the Capabilities structure may be used by the mdoc to indicate which curves
it supports for mdoc mac authentication. If present it shall contain all the curves that are supported by the
mdoc application for mdoc mac authentication. The value of MacKeysCurves is an array of cry, as defined in
the IANA COSE Elliptic Curves registry. For privacy reasons, the contents of this field shall not be determined
by actual presence of any mobile documents.
A.3 Origin info
A.3.1 General
The mdoc reader shall use the origin info to detect if engagement information from a different mdoc reader is
forwarded by a malicious mdoc reader. This is done by indicating to the mdoc reader through what channel
the mdoc received the engagement information.
The origin information structure that contains this information is OriginInfos. It shall be CBOR encoded
and formatted as follows:
OriginInfos = [
* OriginInfo
]
OriginInfo = {
"cat" : Category,   ; Category
"type" : Type,   ; Type
"details" : Details  ; Details

© ISO/IEC 2024 – All rights reserved
}
Category = uint
Type = uint
Details = {
+ tstr: any
}
The OriginInfos is an array that consists of one or more OriginInfo structures. The value for Category shall
be 1, any other value is RFU. The value of Details depends on the value of Type. This document defines the
types “Domain origin” with type = 1, and “Other” with type = 0. Any other values for the type are RFU.
NOTE One of the reserved values can in the future be used for purposes of providing information about Qualified
Website Authentication Certificate (QWAC) as defined in ETSI TS 119 495.
A.3.2 Domain origin
This type indicates the origin of the channel used to retrieve the engagement information.
For type 1, the “Details" map structure shall contain one field with “domain” as the identifier and the website
domain as the value.
The value of the “domain” element may be an empty string. This signifies that the mdoc received the
engagement information through a channel that has a domain, but the mdoc did not receive the value, or did
not receive it from a source trusted by the mdoc.
In order for the domain origin field to mitigate phishing attacks, the value must be received from a source
trusted by the mdoc. This document does not define what source the mdoc must receive the website domain
from, but one of the options is to retrieve it from the referrer URL of the page from which the mdoc was
requested.
The value shall not be determined using data from the ReaderEngagement structure.
EXAMPLE
Referrer URL = “https:// gov .example .com/ present/ session1 ?hi = 2"
Contents of Details = {
“domain“ = “gov.example.com”
}
A.3.3 Other
This type can be used to provide additional information about the channel via which the mdoc received the
engagement information.
The value for this type shall be 0.
The value of the elements of Details is out of scope of this document.
A.4 mdoc scheme
To invoke the mdoc App through the mdoc scheme (mdoc://), the mdoc reader shall use:
— URI starts with “mdoc://”
— Followed by the readerEngagement data encoded base64 url-without-padding according to RFC 4648.
Note The URI scheme “mdoc://” has been reserved by ISO/IEC 18013-5 with Internet Assigned Numbers
Authority (IANA).
© ISO/IEC 2024 – All rights reserved
A.5 MacKeys support
When performing mdoc authentication using a MAC as specified in ISO/IEC 18013-5, the ephemeral reader
key and static device key are used to calculate the MAC. Since the static device key typically cannot be
changed, this requires the ephemeral reader key to use the same curve as the static device key. In the flow
specified in ISO/IEC 18013-5, this is solved by letting the mdoc generate the ephemeral device key for session
encryption to be of the same curve as its static device key. The mdoc reader will then always generate an
ephemeral reader key that uses the same curve.
However, in the flow specified in 6.4.3.2, the mdoc reader decides on the curve to use for the ephemeral
reader key without having knowledge yet about the static device key of the mdoc. To mitigate this issue,
this document defines an additional optional element, MacKeys, to the DeviceRequest structure as defined
in ISO/IEC 18013-5. This provides the capability for the mdoc reader to send multiple keys with different
curves which can be used for mdoc mac authentication. This mitigates the issue of the mdoc reader not
knowing which key to send, or when the mdoc contains documents with different curves for mdoc mac
authentication. The MacKeys element has the following definition:
? “macKeys” : MacKeys
MacKeys = [+ COSE_Key]
This results in the following definition of DeviceRequest:
DeviceRequest = {
"version" : tstr,          ; Version of DeviceRequest structure
"docRequests" : [+ DocRequest]   ; Requested documents
? "macKeys" : MacKeys
}
If present, the MacKeys element shall contain one or more ephemeral reader keys. The MacKeys element shall
not contain more than one key for each curve. The mdoc reader shall not include the MacKeys element unless
the mdoc indicated support for it in the DeviceEngagement structure as defined in A.2. When MacKeys are
provided in the request structure, the version element shall have value “1.1”.
It is recommended for the mdoc reader to include all the curves supported by this document in the MacKeys
element. However, if the mdoc uses the MacKeysCurves to indicate which keys it supports, the mdoc reader
can use this information to limit the amount of different curves it should send.
If an mdoc reader provides the MacKeys element in the request structure, and the mdoc chooses to perform
mdoc MAC authentication, the mdoc shall choose the applicable reader key from this element.
A.6 Device retrieval to a website
A.6.1 Engagement
To be able to set up the connection, the mdoc must know the URI at which the mdoc reader can be reached.
When engagement is performed using the reader engagement structure, this information is included in
RestApiOptions element in the reader engagement structure, which is formatted as follows:
RestApiOptions = {
0: tstr, ; URI of the website
}
The string shall contain the URI of the website in which to connect. The mdoc reader shall ensure that the
URI contains the path that the mdoc reader uses to determine to which session the URI belongs.
A.6.2 Transport protocol
The mdoc shall use HTTP/1.1 POST according to RFC 9112 commands for sending DeviceEngagementMessage
or SessionData and receiving SessionEstablishment or SessionData as follows:
HTTP POST messages shall have the following structure:

© ISO/IEC 2024 – All rights reserved
POST [path of URI] HTTP/1.1
Host: [host of URI]
Content-Length: [content length]
Content-Type: application/cbor

[
DeviceEngagementMessage or SessionData message]

HTTP successful response message shall have the following structure:
HTTP/1.1 200 OK
Content-length: [content length]
Content-type: application/cbor

[SessionEstablishment or SessionData message]

The content-type shall be application/cbor. Other header fields may be included.
The SessionEstablishment and SessionData messages are defined in ISO/IEC 18013-5,
DeviceEngagementMessage is defined in A.7.
HTTP error responses are specified in RFC 9110:2022, section 15. Communication between the mdoc and the
mdoc reader shall use Transport Layer Security with server authentication as specified in ISO/IEC 18013-5.
When Device Retrieval to a website is used as a transport mechanism, the “Domain origin” element shall be
present in the OriginInfo structure.
A.7 Session encryption
When performing the remote engagement flow, and if session encryption is used, session encryption shall
be implemented in accordance with ISO/IEC 18013-5 with the following changes:
The following step shall be added:
0) Reader engagement. The mdoc reader generates a new ephemeral key pair (EReaderKey.Priv,
EReaderKey.Pub), and populates the Security element in the ReaderEngagement structure with the
cipher suite identifier, the identifier of the elliptic curve to be used for key agreement and the ephemeral
mdoc reader public key.
Step 1 and 2 shall be changed to:
1) Device engagement. The mdoc generates a new ephemeral key pair (EDeviceKey.Priv, EDeviceKey.Pub).
To do so, the mdoc should use the curve of the ephemeral reader public key it received, if it supports
that curve. The mdoc shall populate the Security element in the DeviceEngagement with the cipher suite
identifier, the identifier of the elliptic curve to be used for key agreement and the ephemeral pub key. If
the curves used by the mdoc and mdoc reader ephemeral keys are the same, the mdoc shall derive the
session keys as defined in ISO/IEC 18013-5. The mdoc shall send the device engagement structure to the
mdoc reader in a DeviceEngagementMessage as specified below.
2) Session establishment. The mdoc reader shall derive the session keys as defined in ISO/IEC 18013-5. using
the cipher suite, the elliptic curve and the ephemeral device public key received in the deviceEngagement
structure. If this curve is the same as the curve of the mdoc reader ephemeral key pair the mdoc reader
generated in step 0, the mdoc reader shall use the associated private key for session key derivation. If
not, the mdoc reader shall generate a new ephemeral key pair (EReaderKey.Priv, EReaderKey.Pub) using
the elliptic curve identified by the mdoc and shall use that private key.
The mdoc reader shall encrypt the mdoc request with the appropriate session key. If the mdoc reader
derived a new ephemeral reader key pair in this step, it shall send the encrypted mdoc request to the
mdoc in a SessionEstablishment message, together with EReaderKey.Pub. If the mdoc reader used the
ephemeral reader key pair from step 0 instead, it shall send the encrypted mdoc request in a SessionData
message, leaving out the “status” pair.

© ISO/IEC 2024 – All rights reserved
If the mdoc did not yet derive the session keys in step 1, it shall do so now, using the mdoc reader
ephemeral public key in the SessionEstablishment message. If the mdoc derived session keys in step 1
and it received a new ephemeral reader key in step 2, the mdoc shall terminate the session. The mdoc
shall decrypt the mdoc request. The session shall continue as described in ISO/IEC 18013-5.
The Device Engagement message in step 1 shall be CBOR encoded and formatted as follows:
DeviceEngagementMessage = {
“deviceEngagementBytes”: DeviceEngagementBytes ;
}
DeviceEngagementBytes = #6.24(bstr .cbor DeviceEngagement); see Annex A.2
A.8 Session transcript
The SessionTranscript as defined in ISO/IEC 18013-5 shall be used with the following changes:
The handover element is defined as:
Handover = EngagementToApp / any
EngagementToApp = ReaderEngagementBytesHash

ReaderEngagementBytesHash = bstr

ReaderEngagementBytes = #6.24(bstr .cbor ReaderEngagement)

Where ReaderEngagementBytesHash is the SHA-256 hash of ReaderEngagementBytes.
EngagementToApp shall be used when the remote engagement flow is used.
When an mdoc and mdoc reader uses an out-of-band mechanism to set up the device retrieval phase, the
contents of the Handover element is out of scope of this document.
When DeviceEngagement is not applicable to the transfer mechanism used, the value shall be null.
When EReaderKey is not applicable to the transfer mechanism used, the value shall be null.

© ISO/IEC 2024 – All rights reserved
Annex B
(normative)
Use of OID4VP to retrieve an md
...