ISO/IEC TS 23220-3:2026

• Abstract:

  This document provides building blocks for mobile eID-System infrastructures and normalizes protocols, interfaces and services for mdoc apps by: specifying interfaces for data interchange for installing of software in installation phase as well as issuing and deriving of attributes and credentials in issuing phase; specifying security and data protection mechanisms; applying privacy-enhancing mechanisms; specifying discoverability mechanisms. Mechanisms for updating or revoking of attributes and credentials or mdocs are out of scope of this document and are provided by SA specific protocols. This document is applicable to entities involved in specifying, architecting, designing, testing, maintaining, administering and operating a mobile eID-System in parts or entirely.

• Status: Published
• Publication Date: 31-May-2026
• ICS: 35.240.15 - Identification cards. Chip cards. Biometrics
• Technical Committee: ISO/IEC JTC 1/SC 17 - Cards and security devices for personal identification
• Drafting Committee: ISO/IEC JTC 1/SC 17 - Cards and security devices for personal identification
• Current Stage: 6060 - International Standard published
• Start Date: 01-Jun-2026
• Due Date: 13-Apr-2026
• Completion Date: 01-Jun-2026

ISO/IEC TS 23220-3:2026 is an ISO technical specification for building blocks for identity management via mobile devices. It specifies protocols, interfaces and services for mdoc apps during installation and issuing, including device discovery, attribute and credential issuing, security and data protection, privacy-enhancing mechanisms and discoverability for mobile eID systems.

What does ISO/IEC TS 23220-3:2026 specify?

ISO/IEC TS 23220-3:2026 specifies the installation and issuing phase for mobile eID-System infrastructures. It covers how an mdoc app exchanges data with discovery and issuing services, and it keeps update and revocation of attributes, credentials or mdocs outside its scope.

The document is organized into eight clauses and nine annexes.

Annex	Status	What it covers
Annex A	Informative	Example of a discovery protocol
Annex B	Informative	Example of an issuing protocol with stateful RestAPI and E2EE
Annex C	Informative	Example of an issuing protocol using an OID4VCI profile
Annex D	Informative	Server-to-server issuing API and example protocol
Annex E	Informative	BER-TLV encoding scheme for the SAAO object
Annex F	Informative	Examples of deployment options
Annex G	Informative	Description of provisioning workflows and protocols
Annex H	Normative	HPKE profile of session encryption
Annex I	Informative	List of reason codes

Clause 5 sets out general principles, Clause 6 defines the mdoc app descriptor and attestations, Clause 7 defines structures for device discovery, and Clause 8 defines structures for mdoc provisioning. In practice, that means the document is not only about message formats but also about the sequence and trust model around issuance.

What are the key requirements of ISO/IEC TS 23220-3:2026?

ISO/IEC TS 23220-3:2026 gives issuers a common set of building blocks for discovering an mdoc app, assessing its capabilities and provisioning a mobile document. The most important requirements are in Clause 5 and in the data structures of Clauses 6 to 8.

Issuing must fit the issuer’s workflow and policy

Clause 5.4 says an issuing protocol shall support the issuer’s policy and workflow choices. In practice, an Issuing Authority needs to be able to perform user identification, authenticate the user during the session, validate the mdoc app or secure area, establish secure end-to-end communication, select a secure area, provision attributes and credentials, and handle deletion or revocation workflows.

Clause 5.4 also allows the protocol to support companion devices, multiple authentication form factors and the provisioning of a new authentication factor tied to the holder. That matters when the mobile device has limited input or output, or when a holder migrates to another device and needs a controlled re-issuance path.

The trust model is layered

Clause 5.3 uses a 3-Level trust model: Level 3 for the mdoc, Level 2 for the mdoc app, and Level 1 for the SA-Application. The practical point is that different parts of the chain are trusted for different evidence, so an issuer can decide whether it is trusting the document, the wallet app, or the secure area functions behind the wallet app.

Clause 5.2 says an mdoc app can support more than one SA-Application, and a SA-Application can be provided by different kinds of secure area. That matters because issuers must be able to evaluate which secure area type and which attestation path fit their policy.

The MCD is the main capability description

Clause 6.1 defines the mobile eID capability descriptor (MCD) as the minimum information an Issuing Authority uses to decide whether an mdoc app is acceptable for issuance. The MCD contains three main parts: the mdoc app application descriptor, one or more secure area attestation objects (SAAO), and an optional signature over the MCD.

Clause 6.2 says the app descriptor carries supported device features, engagement interfaces, data transmission interfaces and certifications. In practice, the issuer uses this information to see whether the app can work with its chosen flow, for example QR-based engagement, NFC, BLE, WiFi aware or Internet-based data transfer.

Clause 6.3 defines the SAAO and requires the SA index and SA Interface to be present. If an mdoc app supports more than one SA interface, it shall carry multiple SAAOs. That lets the discovery service select the correct secure-area-specific protocol and helps avoid sending the holder into a flow the device cannot complete.

Clause 6.4 defines the CDDL structure for the MCD and SAAO. The MCD signature uses COSE_Sign1 and carries the Mobile ID Attestation Signer Certificate as an x5chain element. In practice, this gives integrity and authenticity for the descriptor, but Clause 6.1 notes that the signature alone does not create a strong link to the mdoc app.

Discovery starts with Service Engagement Data

Clause 7.1 defines Service Engagement Data (SED) with a server URL, an optional provisioning code and an optional DocType. The SED is what starts the discovery process, and the holder can receive it as a QR code, a mobile deep-link or by manual entry in the app.

Clause 7.2 makes the provisioning code a backend link between a holder session and a provisioning transaction. That matters because the code can be time-limited and scope-limited, and the standard recommends invalidating it after use.

Clause 7.3 defines the additional information path. The webUrl option opens an ephemeral HTTPS page inside the mdoc app, while SimpleView lets the discovery service ask the holder for short, typed responses. This is used for extra holder interaction and session binding, not for replacing user identification.

Provisioning can carry evidence and encrypted data

Clause 8.2 defines claim gathering structures for InputData and InputMetadata. These structures let the mdoc app send evidence or supporting metadata to the issuing authority, optionally encrypted, so the issuer can assess whether the applicant matches the expected holder.

Clause 8.3 defines encrypted transport using Hybrid Public Key Encryption (HPKE), and Annex H gives the HPKE profile. If IssuerE2EEParams are present in the SED, end-to-end encryption is required, so implementers need to align key management and message handling from the start.

Clause 8.4 defines feedback from the issuing service back to the app. That feedback can explain provision, rejection or pending decisions with data-specific items, and Annex I provides the reason codes used for those status messages.

What terms does ISO/IEC TS 23220-3:2026 define?

• attestation statement - proof that data was created by a certain entity and has authenticity and integrity, usually through a digital signature.
• proof of association (PoA) - evidence that two sets of data are managed by the same secure area.
• proof of possession (PoP) - evidence that an entity has access to specific data, such as a private key.
• mobile eID capability descriptor (MCD) - the object that carries the minimum information an Issuing Authority uses to decide whether to issue into an mdoc app.
• secure area attestation object (SAAO) - the object that describes the capabilities of a SA-Application.
• service engagement data (SED) - the data package that starts discovery, including the server URL and, optionally, the provisioning code and DocType.
• mdoc app capability descriptor - the set of data that describes mdoc app capabilities, including one or more SAAO objects.
• mobile security object (MSO) - the mobile document security object referred to in the trust and issuing model.

Who uses ISO/IEC TS 23220-3:2026?

ISO/IEC TS 23220-3:2026 is used by entities that specify, architect, design, test, maintain, administer and operate a mobile eID-System, either in parts or as a whole. In practice, that includes Issuing Authorities, mdoc app providers, secure area providers, discovery service operators and issuing service operators.

It is also relevant to teams that build wallet-like mdoc apps, secure area implementations, device discovery flows and provisioning back ends. Quality managers and buyers can use it to check whether a proposed solution supports the expected discovery, attestation and issuing interactions.

Which standards are used with ISO/IEC TS 23220-3:2026?

Standard	What it contributes
ISO/IEC TS 23220-2	Data objects and encoding rules for generic eID systems; used for document data objects and crypto suite references
ISO/IEC TS 23220-4	Protocols and services for the operational phase; used for related issuance and presentation concepts
ISO/IEC TS 23220-5	Trust models and confidence level assessment; used for SA-supported user authentication mechanisms
ISO/IEC TS 23220-6	Mechanism for use of certification on trustworthiness of secure area; used for SA certification references
ISO/IEC 7816-15	Cryptographic information application; used as an encoding option for SAAO
RFC 9360	COSE header parameters for carrying and referencing X.509 certificates; used for MCD signing
RFC 9180, RFC 5869, RFC 5116	HPKE, HKDF and AEAD building blocks used by the session encryption profile in Annex H
RFC 6455	WebSocket protocol used for the discovery-service message exchange
RFC 6749, RFC 9126, RFC 9449, RFC 7636, RFC 8414, RFC draft 06	OAuth 2.0 and related profiles used in the OID4VCI-based and attestation-based issuance examples
ISO/IEC 18004	QR code bar code symbology used for Service Engagement Data transport
ISO 639	Language codes used for holder-facing text in SimpleView

What does the ISO/IEC TS 23220-3:2026 document contain?

ISO/IEC TS 23220-3:2026 contains CDDL definitions, message structures and example flows for discovery and issuance. It includes the MCD and SAAO structures, ServiceEngagement, additional information structures, claim gathering structures, encrypted transport structures and issuer feedback structures.

The document also contains a general action flow diagram, protocol examples in Annexes A to D, a BER-TLV SAAO example in Annex E, deployment options in Annex F and provisioning workflows in Annex G. Annex H provides the normative HPKE profile, and Annex I lists reason codes for proofing and life-cycle management decisions.

Technical
Specification
ISO/IEC TS 23220-3
First edition
Cards and security devices for
2026-06
personal identification — Building
blocks for identity management via
mobile devices —
Part 3:
Protocols and services for
installation and issuing phase
Cartes et dispositifs de sécurité pour l’identification des
personnes — Blocs fonctionnels pour la gestion des identités via
les dispositifs mobiles —
Partie 3: Protocoles et services pour la phase d'installation et
d'émission
Reference number
© ISO/IEC 2026
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: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2026 – All rights reserved
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviations . 2
5 General principles . 3
5.1 Security principles .3
5.2 Design principles .3
5.3 Trust model .4
5.4 General requirements of protocols for mdoc issuing .4
5.5 General action flow diagram of issuing protocols .6
6 mdoc app descriptor and attestations . 8
6.1 General description of MCD .8
6.2 Data objects of mdoc app application descriptor .8
6.3 Data objects of SAAO .10
6.4 CDDL definition of MCD and SAAO .11
6.5 mdoc app attestations . 13
6.5.1 General . 13
6.5.2 Encodings of mdoc app attestation . 13
7 Structures for device discovery .15
7.1 Structure of Service Engagement Data . 15
7.2 Provisioning code .16
7.3 Additional information structure . .16
8 Structures for mdoc provisioning .18
8.1 mdoc data structures .18
8.1.1 NameSpacedData structure .18
8.1.2 mdoc IssuerSignedDehydrated structure.18
8.1.3 Generation of IssuerSigned structure . 20
8.2 Claim gathering structures . 20
8.3 Session encryption . 22
8.4 Issuer feedback structure . 23
Annex A (informative) Example of protocol for discovery services .25
Annex B (informative) Example of issuing protocol with stateful RestAPI and E2EE .31
Annex C (informative) Example of issuing protocol OID4VCI profile .37
Annex D (informative) Issuing API Server-to-Server and example protocol .46
Annex E (informative) BER-TLV encoding scheme for SAAO object .59
Annex F (informative) Examples of deployment options . 61
Annex G (informative) Description of provisioning workflows and protocols .64
Annex H (normative) HPKE profile of session encryption .71
Annex I (informative) List of reason codes . 74
Bibliography .81

© ISO/IEC 2026 – 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/IEC 23220 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.

© ISO/IEC 2026 – All rights reserved
iv
Introduction
The ISO/IEC 23220 series consists of the following parts, under the general title Cards and security devices
for personal identification — Building blocks for identity management via mobile devices:
— Part 1: Generic system architectures of mobile eID systems
— Part 2: Data objects and encoding rules for generic eID systems
— Part 3: Protocols and services for the installation and issuing phase
— Part 4: Protocols and services for the operational phase
— Part 5: Trust models and confidence level assessment
— Part 6: Mechanisms for use of certification on trustworthiness of secure area
— Part 7: Registration Authority Procedures for Mobile Documents
The objective of ISO/IEC TS 23220-3 is to:
— minimize the burden on issuers to engage in device discovery, device attestation, device binding;
— ease the process of categorizing a mdoc app implementation according to the issuer’s policy;
— ease the process of provisioning mobile documents;
— rely on a third party for integral Mobile eID function characterization.
This document introduces data structures and APIs applicable for discoverability mechanisms and for mdoc
provisioning purposes. Future versions of this document can specify normative protocols based on the data
structures and APIs defined in this document that can be referenced by a profile identifier.

© ISO/IEC 2026 – All rights reserved
v
Technical Specification ISO/IEC TS 23220-3:2026(en)
Cards and security devices for personal identification —
Building blocks for identity management via mobile
devices —
Part 3:
Protocols and services for installation and issuing phase
1 Scope
This document provides building blocks for mobile eID-System infrastructures and normalizes protocols,
interfaces and services for mdoc apps by:
— specifying interfaces for data interchange for installing of software in installation phase as well as
issuing and deriving of attributes and credentials in issuing phase;
— specifying security and data protection mechanisms;
— applying privacy-enhancing mechanisms;
— specifying discoverability mechanisms.
Mechanisms for updating or revoking of attributes and credentials or mdocs are out of scope of this
document and are provided by SA specific protocols.
This document is applicable to entities involved in specifying, architecting, designing, testing, maintaining,
administering and operating a mobile eID-System in parts or entirely.
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 TS 23220-2, Cards and security devices for personal identification — Building blocks for identity
management via mobile devices — Part 2: Data objects and encoding rules for generic eID systems
ISO/IEC TS 23220-4, Cards and security devices for personal identification — Building blocks for identity
management via mobile devices — Part 4: Protocols and services for operational phase
ISO/IEC 7816-15, Identification cards — Integrated circuit cards — Part 15: Cryptographic information
application
RFC 9360, J. Schaad, CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and
Referencing X.509 Certificates, February 2023
IETF RFC draft 06, OAuth 2.0 Attestation-Based Client Authentication, July 2025
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.

© ISO/IEC 2026 – All rights reserved
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
attestation statement
proof of authenticity and integrity of data created by a certain entity
Note 1 to entry: Proof of authenticity and integrity is usually achieved by the creation of a digital signature over a
particular attestation
3.2
key attestation
attestation statement (3.1) about capabilities of one or more cryptographic keys managed by a SA-application
of a secure area
3.3
mdoc app attestation
attestation statement (3.1) about capabilities of an mdoc app instance issued by the mdoc app provider
service
3.4
mdoc app capability descriptor
set of data describing capabilities of mdoc app including one or more secure area attestation objects (3.7)
Note 1 to entry: See ISO/IEC 23220-1.
3.5
proof of association
statement by an entity providing evidence that two sets of data are managed by the same secure area
EXAMPLE An attestation statement that digitally signs to public keys can serve as Proof of Association that the
corresponding private keys are managed by the same SA-Application of a secure area.
Note 1 to entry: Data structures and protocols addressing proof of associations are not yet part of this document but
can be specified in future editions. Implementations of proof of associations can require updates on existing secure
area solutions in particular hardware-based solutions.
3.6
proof of possession
statement by an entity providing evidence that the entity has access to specific data
EXAMPLE Proof of possession of a cryptographic private key can be achieved by creation of a digital signature
over a nonce provided by a verifying entity by applying the cryptographic private key.
3.7
secure area attestation object
SAAO
set of data describing capabilities of SA-Application
Note 1 to entry: See ISO/IEC 23220-1.
4 Symbols and abbreviations
For the purposes of this document, the following abbreviations apply.

© ISO/IEC 2026 – All rights reserved
CBOR concise binary object representation
CDDL concise data definition language
IA issuing authority
IIN issuer identification number
MCD mobile eID capability descriptor
MSO mobile security object
PoA proof of association
PoP proof of possession
SAAO secure area attestation object
SED service engagement data
5 General principles
5.1 Security principles
The process of issuing a mobile document into an mdoc app is divided into three sub-phases (see
ISO/IEC 23220-1) whereas the respective services can be operated by or under supervision of the Issuing
Authority: user identification service, mdoc app discovery service and issuing service. As the mobile device
and the mdoc app are considered not under the control of the Issuing Authority three issues are of concern:
— Mechanism and strength of binding of respective installation of mdoc app or mobile document or both to
the mobile device to prevent from cloning;
— Mechanism and strength of secure storage of document data to preserve data privacy;
— Mechanism and strength of binding of holder to the mdoc app or mdoc or both to preserve holder-binding
and sharing protection.
This document introduces amongst others the concept of mdoc app capability descriptor (MCD) including
Secure Area Attestation Object (SAAO) and its retrieval and verification. The concept includes specifications
of mechanisms for implementation of interfaces IS-1, IS-2, IS-3 and IS-4 in ISO/IEC 23220-1. In addition,
mechanisms for issuing service including the generation of mobile document specific keys and storage of data
is specified in this document, see Interface IS-5 in ISO/IEC 23220-1. Mechanisms of the user identification
service are out of scope of this document.
5.2 Design principles
The specifications in this document are based on the following principles:
1. The Issuing Authority trusts at least the mdoc app and mdoc app provider or the secure area provider
and, if involved in the framework, the ID-Provisioning Entity.
2. The arrangement and negotiation between the Issuing Authority, the device manufacturer or OEM-
Vendor and the secure area provider covering the choice of secure area form-factor, its capabilities, its
drivers, its hardware interface customization, etc. is out of scope of this document.
3. An mdoc app can support more than one SA-Application and hence, can manage different attestation
statements related to each SA-Application.
4. A SA-Application can be of various kinds such as a System-On-Chip acc. to Trusted Connectivity Alliance,
part of the operating system, Trustlet of TEE or Java Card Applet of an embedded secure element.

© ISO/IEC 2026 – All rights reserved
5. An attestation of the SA-Application can be provided by a secure area provider, such as DLOA by Global
Platform or FIDO attestation. An attestation is SA-Application specific.
6. The MCD can be optionally signed by the mdoc app provider in addition to the SA-Application statements
provided by SA-Application providers.
This document describes the issuing procedure as given in general in ISO/IEC 23220-1 by specifying basic
data structures (see Clauses 7 and 8). These basic data structures can be combined to construct data
structures and specific messages according to an issuing protocol. An ordered sequence of messages is
considered an issuing protocol. General requirements and general action flows of issuing protocols are given
in 5.4 and 5.5. Examples of issuing protocols are given in Annex A, Annex B, Annex C and Annex D.
Basic data structures are specified for the purpose of encoding:
1. service engagement data;
2. session encryption data;
3. user attributes (see ISO/IEC 23220-1:2023, 3.1);
4. one or more credentials linked to user attributes (see ISO/IEC 23220-1:2023, 3.5);
5. user binding data;
6. control or access rules to be applied by mdoc app;
7. error codes to be returned by mdoc app or issuing service;
8. attestation information about issuing process to be used at presentation time;
9. attestation information about mdoc app or secure area;
10. lifecycle management information about the issued mobile document to be applied by mdoc app.
5.3 Trust model
The trust model follows a 3-Level approach according to the generic architecture given in Figure 3 (see
ISO/IEC 23220-1).
Level 3 describes the mdoc level. Attestation of Level 3 is created by the respective Issuing Authority
by means of mobile document specific mechanisms (e.g. Mobile Security Object in ISO/IEC 18013-5 and
ISO/IEC TS 23220-4). The mdocs are managed by the mdoc app and SA-Application. A relying party operating
a verification application trusts the Issuing Authority.
Level 2 describes the mdoc app level. Attestation of the Level 2 is created by the mdoc app provider service
typically operated by the mdoc app provider by means of issuing an mdoc app attestation. An Issuing
Authority operating an issuing service trusts the mdoc app provider service. A relying party operating a
verification service can also trust the mdoc app provider service.
Level 1 describes the SA-Application level. Attestation of Level 1 is created by the SA-Application provisioning
service. Either an mdoc provider operating a mdoc app provider service or the Issuing Authority operating
an Issuing Service or both trust the SA-Application service.
5.4 General requirements of protocols for mdoc issuing
Protocols for mdoc issuing shall meet the requirements of issuing authorities listed in this clause. A
respective protocol or set of protocols may fulfil all or parts of the requirements. Issuing authorities can
choose protocols according to their intended workflows and issuing policies.
An issuing authority is able to:
1. Perform out-of-band user identification either in-person or electronically and to perform in-session user
authentication.
© ISO/IEC 2026 – All rights reserved
2. Perform in-session user data capturing to enable user identification and user authentication.
3. Invoke validation processes to determine suitability of the mdoc app, secure areas, mobile device or all.
EXAMPLE 1 Requesting and receiving attestation statements from the mdoc app by the IA allows for
determination of confidence levels.
4. Establish a secure end-to-end data transmission between remote services of the issuing authority and
either the mdoc app or secure area.
5. Uniquely identify and authenticate an mdoc (i.e. different identifiers to different IAs).
6. Select a respective secure area out of a choice.
7. Provision user attributes, i.e. the mdoc, and the MSO simultaneously or at different times.
8. Update user attributes, i.e. the mdoc, and the MSO simultaneously or at different times.
9. Provision of one or more MSOs for the same user attributes, i.e. the mdoc.
EXAMPLE 2 An IA can update MSOs without updating the user attributes and without performing user
identification.
EXAMPLE 3 Multiple MSOs allow for the single use of a respective MSO to prevent from tracking by the verifier.
10. Provision one mdoc at a time.
NOTE 1 An IA can process the respective workflow multiple times in order to provision multiple mdocs.
NOTE 2 Conveying information about already provisioned mdocs in one mdoc app instance to an IA is out of
scope of the protocol.
EXAMPLE 4 A wallet mdoc app manages more than one mdocs.
EXAMPLE 5 Holders can get issued two mdocs with same user attributes but different MSOs from the same IA.
EXAMPLE 6 Parents can provision mdocs of their kids in the mdoc app instance of the parents.
11. Perform a provisioning workflow, an update workflow, a deletion workflow and a revocation workflow.
12. Provision an mdoc into an mdoc app and mobile device with limited input/output capacities by
leveraging a companion device with suitable input/output capacities.
NOTE 3 A companion device to a mobile device is a device that has been securely paired with the mobile device.
EXAMPLE 7 A smart watch can not feature a camera and the camera of the coupled smart phone can be used
for capturing QR codes or face images or taking a photo of the plastic card.
EXAMPLE 8 An mdoc already provisioned onto an mdoc app of one mobile device is available on a companion
mobile device.
13. Use different authentication form factors of authentication as part of user identification.
14. Provision a new factor of authentication as part of the mdoc provisioning that is uniquely associated to
the holder and stored by the mdoc app.
NOTE 4 The new factor of authentication is stored by the mdoc app and can be part of the backup system of the
mdoc app.
EXAMPLE 9 IA can request the image of the plastic card as factor of possession as well as a portrait image to
provision a first mdoc to the holder. The IA can return a new factor of authentication to the holder as part of the
provisioning of the first mdoc (e.g. a digital secret number stored by the mdoc app). The new digital factor and
additional user authentication means can in turn be used by the IA to provision a second mdoc onto a further
mobile device assigned to the holder.

© ISO/IEC 2026 – All rights reserved
EXAMPLE 10 Holder has been provisioned an mdoc on one mobile device together with a QR code stored by
the mdoc app, which is still operational and wants to migrate onto another device without going through the
same user identification procedure but by presenting QR code provisioned by the IA. The former mdoc might be
revoked by the IA according to IA policy.
EXAMPLE 11 Holder is no longer in possession of an mdoc and wants to restore an mdoc from a backend
onto new mobile device without going through the same user identification procedure. The holder restores the
mdoc app from a backend onto the new mobile device and holder uses the restored factor of authentication to
authenticate towards the IA and in turn to get mdoc provisioned to the new mdoc app.
15. Interact with the applicant as part of the protocol.
EXAMPLE 12 IA can request the applicant to approve the deletion of a previously provisioned mdoc to the
holder.
16. Provision mdoc through the mdoc app provider service.
5.5 General action flow diagram of issuing protocols
Figure 1 specifies general action flows that are supported by the protocols. An issuing protocol can include
all or parts of the steps in the general action flow in any order. Examples of workflows of provisioning mdocs
into an mdoc app according to the action flows are given in Annex G.
The specific action flow is determined by the issuing policy of the IA and controlled by the entity operating
the respective remote services. The protocols require the holder to have the mdoc app installed and to be
informed by the IA about the general procedure.
User identification should be performed out-of-band prior to the issuing protocol or in-session as part of the
issuing protocol and mdoc app. The former option allows for the integration of any kind of user identification
and proofing either electronically or in-person. The latter depends on the capabilities of the mdoc app and
mobile device.
In a next step, the holder selects the method to initiate the issuing process. This can be done by launch
of the mdoc app followed by selection of "QR code", "Update" or "select IA" from a list. Alternatively, this
step can also be initiated by another application, e.g. a browser app or mobile app, installed on the mobile
device. The mdoc app connects to the respective remote service and both establish a secure communication.
Furthermore, the mdoc app provider service can connect to a specific mdoc app instance, e.g. by means of
push notification, in order to receive status information or to start a provisioning or update flow.
Through the secure communication the remote service requests and receives information about mdoc app
capabilities and supported secure area applications. This information can include the public parts of the
device keys that will be part of the MSOs. The remote service may perform user authentication that links to
the out-of-band user identification or may perform in-session user identification and user authentication.
Based on these information the remote service checks for a record in the backend system and, if present,
may proceed with the selection of a secure area according to the issuing authority policy. If no record is
present, the remote service should abort the session and inform the holder about possible next actions not
part of the protocol.
In a last step, the service prepares mdoc data and MSOs and sends these data to the mdoc app or secure area
application. This step may include the establishment of a further secure communication between remote
service and secure area application. Eventually the holder can use the mdoc for verification purposes.

© ISO/IEC 2026 – All rights reserved
Key
steps in scope
steps out of scope
Figure 1 — General action flow diagram of issuing protocols

© ISO/IEC 2026 – All rights reserved
6 mdoc app descriptor and attestations
6.1 General description of MCD
The MCD capability descriptor object encodes the minimal required information needed for issuing a mobile
document into the mdoc app. An Issuing Authority should examine the MCD to decide whether a mdoc app
fulfils its policy of a mobile document or the issuing into the mdoc app is to be denied. If the mdoc app fulfils
the Issuing Authority's policy, the Issuing Authority should select the mdoc app's options based on the MCD
information.
The MCD is structured into three main objects:
— mdoc app application descriptor listing the main features of the mdoc app,
— SA-Attestation Object (SAAO) listing the main features of the supported SA-Applications,
— Signature over the MCD (optionally) created by the MCD Attestation Service.
The MCD shall be created and shall be made available in the installation phase of the mdoc app by the mdoc
app provider. Updates of the mdoc app that change the feature set of the app requires an update of the MCD.
The SA-Application and SA-Attestation information encoded in the SAAO may be provided by an entity
different to the mdoc app provider. As an mdoc app may support more than one SA-Application, an MCD
may hold multiple SAAOs. The MCD may be signed by the MCD Attestation Service. The signature provides
authenticity and integrity of the MCD but does not provide a strong link to the mdoc app. Such a link can be
provided by an SA-Application Statement created as part of the SA-Application specific protocol.
6.2 Data objects of mdoc app application descriptor
The mdoc app application descriptor shall encode the information given in Table 1. In the tables below,
identifiers serve as map keys and denote simple digit or number for the sake of compact encoding; they
shall be of type UTF-8 string. When identifiers indicate map values, they shall be of type integer (see 6.4 for
CDDL definition). The existence of an identifier in the array of identifiers indicates support of the respective
feature by the mdoc app. Any negative values of the identifier, i.e. –n in the tables below, indicate support of
further proprietary features.
Table 1 — Data objects of mdoc app application descriptor
Name of object Occurrences Description/ Specified values Identifier Encoding
App supported
o list of supported features of mdoc app and 0 see Table 2
device features
mobile device
App engagement
o List of supported device engagement in- 1 see Table 3
interfaces
terfaces provided by mdoc app and mobile
device
App data
o List of supported data transmission interfac- 2 see Table 4
transmission IF
es provided by mobile device
Certifications
o List of certifications assigned to mdoc app 4 see Table 5

m – mandatory object,  o – optional object any other values are RFU
The data object "App supported device features" encodes supported features of the mdoc app and the mobile
device that are required by protocols and services described in the ISO/IEC 23220 series (see Table 2). The
value other encodes proprietary information about further app features and may be interpreted by the
discovery service.
© ISO/IEC 2026 – All rights reserved
Table 2 — Values and identifiers of "App supported device features"
Specified values Identifier Encoding
Webview feature 0 uint
Simple view feature 1 uint
other -n uint
Any other values are RFU
The data object "App engagement interfaces" encodes supported device engagement transmission
technologies (see Table 3). The value other encodes proprietary information about further transmission
technologies and may be interpreted by the discovery service.
Table 3 — Values and identifiers of "App engagement interfaces"
Specified values Identifier Encoding
QR 0 uint
NFC 1 uint
other -n uint
Any other values are RFU
The data object "App data transmission IF" encodes supported data retrieval transmission technologies (see
Table 4). The value other encodes proprietary information about further transmission technologies and may
be interpreted by the discovery service.
Table 4 — Values and identifiers of "App data transmission IF"
Specified values Identifier Encoding
NFC in accordance with ISO/IEC TS 23220-3 and ISO/IEC TS 23220-4 0 uint
BLE 1 uint
WiFi aware 2 uint
Internet 3 uint
other -n uint
Any other values are RFU
The data object "Certifications" encodes information about approvals or certifications assigned to the mdoc
app or SA-Application (see Table 5). The mdoc app may be subject to a security certification that is bound to
a certification of the SA-Application (see 6.3). If the mdoc app does not provide any certification but the SA-
Application is certified, it is in the responsibility of the issuing service to trust the security functions applied
by the mdoc app. The issuing service may alternatively establish a trusted communication with the certified
SA-Application.
The value other encodes proprietary information about further app certifications and may be interpreted
by the discovery service.
Table 5 — Values and identifiers of "Certification"
Specified values Identifier Encoding
Common Criteria Protection Profile number 0 bstr
Common Criteria certification number 1 bstr
Certification number according to ISO/IEC 19790 2 bstr
[1]
Reference to Digital Letter Of Approval of the secure area platform according to 3 tstr
[1]
Reference to Digital Letter Of Approval of the SA-Application according to 4 tstr

© ISO/IEC 2026 – All rights reserved
TTabablele 5 5 ((ccoonnttiinnueuedd))
Specified values Identifier Encoding
SA application certification according to ISO/IEC TS 23220-6 5 bstr
other -n uint
Any other values are RFU
6.3 Data objects of SAAO
The SAAO encodes information given in Table 6 and Table 7. The MCD shall encode one or more SAAOs.
The SAAO shall be encoded with one of the encoding schemes given in Table 6. All encodings other than
identifier "0" are proprietary and optional. In addition to BER-TLV encoding given in Annex E, an SAAO may
be encoded according to ISO/IEC 7816-15.
Table 6 — Encoding scheme for SAAO
Name of object Occurrence Specified values Identifier Encoding
SAAO object encoding m according to 7.3 0 uint
BER-TLV SAAO profile acc. to 1 uint
Annex E
ISO/IEC 7816-15 2 uint
Any other values are RFU
m – mandatory object,  o – optional object
Table 7 — Data objects of SAAO
Name of object Occurrence Description Identifier Encoding
SA index
m Unique index of SA-Application within MCD 0 uint
Determines basic type of secure area ac-
SA type o 1 see Table 8
cording to ISO/IEC 23220-1
SA supported user SA provided mechanisms for user authen- ISO/IEC TS
o 2
authentication
tication 23220-5
SA supported cryptographic protocols and ISO/IEC TS
SA crypto suites
o 3
key derivation mechanisms 23220-2
SA crypto key SA supported cryptographic primitives ISO/IEC TS
o 4
definition
and key or block sizes 23220-2
Reference to interface specification of
SA Interface
m SA-Application to be used by discovery 5 see Table 9
service and issuing service
Public part of attestation key of SA-Appli-
Attestation PublicKey o 6 COSE_Key
cation
attestation statement
o Attestation statement about SAAO 7 bstr
Determines structure and encoding of
attestation format
o attestation statement, if attestation state- 8 see Table 10
ment is not part of SAAO (see identifier 7)
List of certifications issued to the SA Appli-
Certifications
o 9 see Table 5
cations
Any other values are RFU
m – mandatory object,  o – optional object
The data object SA index encodes a reference to the SAAO within the MCD and the SA Interface to be selected
by the discovery service. The objects SA index and SA Interface shall be present. In case an MCD encodes
more than one SAAO, the SA index shall uniquely identify a particular SAAO within the MCD. If an SA-
Application supports more than one SA Interface, a respective SAAO shall be present for each SA interface.

© ISO/IEC 2026 – All rights reserved
The data object "SA type" encodes information about the basic type of the secure area according to
ISO/IEC 23220-1:2023, Figure 2. An SA-Application shall be assigned one SA type only. The value other
encodes proprietary information about further types and may be interpreted by the discovery service.
Table 8 — Values and identifiers of "SA type"
Specified values Identifier Encoding
Embedded secure element 0 uint
removable secure element 1 uint
integrated secure element 2 uint
external secure element 3 uint
TEE based 4 uint
software component 5 uint
other -n uint
Any other values are RFU
The data object "SA supported user authentication" encodes user authentication mechanisms in accordance
with ISO/IEC TS 23220-5 supported by the SA-Application. The SA-Application may support more than one
user authentication mechanism.
The data object "SA Interface" encodes information about the SA-specific protocol supported by the
SA-Application. The object shall be present and each SAAO shall implement one interface only. If the SA-
Application supports more than one SA Interface, multiple SAAOs shall be encoded. The value other encodes
proprietary information about further SA-specific protocols. If none of the specified SA-Application specific
protocols is set, the discovery service shall interpret the value other.
NOTE The SA-specific protocol is selected by the discovery service by means of SA type and processed by the
issuing service.
Table 9 — Values and identifiers of "SA Interface"
Specified values Identifier Encoding
org.iso.23220.3.HPKE-SA according to Annex B 0 uint
OID4VCI profile according to Annex C 1 uint
Server-to-Server protocol according to Annex D 2 uint
com.android.identity_credential 3 uint
other -n uint
Any other values are RFU
The data object "SA certification" encodes information about approvals or certifications assigned to the SA-
Application (see Table 5).
Table 10 — Values and identifiers of "SA attestation format"
Specified values Identifier Encoding
[5]
JSON Web Token according to 0 uint
other -n uint
Any other values are RFU
An example of an attestation statement encoded as JSON Web Token is given in C.4.
6.4 CDDL definition of MCD and SAAO
The MCD has the following CDDL structure.

© ISO/IEC 2026 – All rights reserved
MobileIdCapabilityDescriptor = {

"version": uint,
"mobileIdApplicationDescriptor": MobileIdApplicationDescriptor,
"secureAreaAttestationObjects": [+ SaAttestationObject]

}
MobileIdCapabilityBytes = #6.24(bstr .cbor MobileIdCapabilityDescriptor)

MobileIdCapability = COSE_Sign1   ;(RFC 8152 [17]), the payload is MobileIdCapabilityBytes

The payload is MobileIdCapabilityDescriptor. The Mobile ID Attestation Signer Certificate shall be included
as an x5chain element as described in RFC 9360. It shall be included as an unprotected header element. The
x5chain element only consists of a single certificate. The protected header element shall contain only the alg
element (see RFC 8152). The external_aad field used in Sig_structure shall be a bytestring of size zero.

MobileIdApplicationDescriptor = {

? 0: AppSupportedDevFeatures,
? 1: AppEngagementInterface,
? 2: AppDataTransmissionInterface,
? 3: AppAttestationKeyBytes,
? 4: Certification,
}
AppSupportedDevFeatures = [+ uint]      ;acc. to Table 2
AppEngagementInterfaces = [+ uint]      ;acc. to Table 3
AppDataTransmissionInterfaces = [+ uint]   ;acc. to Table 4
AppAttestationKeyBytes = #6.24 (bstr .cbor)  ;MobileIdAttestationKey
Certification = [+ bstr//tstr]        ;acc. to Table 5

SaAttestationObject = {
"saEncoding": SaEncoding,              ; according to Table 6
" saAttestationObjectValue": SaAttestationObjectValue; according to Table 7

}
SaEncoding = 0 / 1 / 2                 ; the value is either 0, 1, or 2

SaAttestationObjectValue ={
0: SaIndex,
? 1: SaType,
? 2: SaSupportedUserAuth,
? 3: SaCryptoSuites,
? 4: SaCryptoKeyDefinition,
: SaInterface,
? 6: SaAttestationKeyBytes,
? 7: SaAttestationStatement,
? 8: Certifications
}
SaIndex = uint
SaType = uint                   ; acc. to Table 8
SaSupportedUserAuth = [+ uint]
SaCryptoSuites = [+ uint]             ; acc. to ISO/IEC 23220-2
SaCryptoKeyDefinition = [+ uint]          ; acc. to ISO/IEC 23220-2
SaInterface = uint                 ; acc. to Table 9
SaAttestationKeyBytes = #6.24(bstr .cbor COSE_Key);containing the public part of the
attestation key
AttestationStatement = bstr            ;generated attestation statement,
Certifi
...