CEN/TR 17982:2023
(Main)European Digital Identity Wallets standards Gap Analysis
European Digital Identity Wallets standards Gap Analysis
This document identifies relevant existing standards and standards work in progress around European Digital Identity Wallets. It also identifies missing work items and overlaps in standards and is supposed to work as a roadmap for future standardization projects in the area.
Analyse von europäischen Normungsbedarfen für digitale Identitätsbrieftaschen
Analyse des écarts entre les standards existants et les exigences du portefeuille européen d’identité numérique
Analiza vrzeli v standardih evropskih denarnic za digitalno identiteto
Ta dokument določa ustrezne obstoječe standarde in nastajajoče standarde v zvezi z evropskimi denarnicami za digitalno identiteto. Prav tako ugotavlja manjkajoče delovne elemente in prekrivanja v standardih in naj bil deloval kot načrt za prihodnje projekte standardizacije na tem področju.
General Information
Standards Content (Sample)
SLOVENSKI STANDARD
01-februar-2024
Analiza vrzeli v standardih evropskih denarnic za digitalno identiteto
European Digital Identity Wallets standards Gap Analysis
Analyse von europäischen Normungsbedarfen für digitale Identitätsbrieftaschen
Analyse des écarts entre les standards existants et les exigences du portefeuille
européen d’identité numérique
Ta slovenski standard je istoveten z: CEN/TR 17982:2023
ICS:
35.030 Informacijska varnost IT Security
35.240.15 Identifikacijske kartice. Čipne Identification cards. Chip
kartice. Biometrija cards. Biometrics
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
CEN/TR 17982
TECHNICAL REPORT
RAPPORT TECHNIQUE
September 2023
TECHNISCHER REPORT
ICS 35.240.15; 35.030
English Version
European Digital Identity Wallets standards Gap Analysis
Analyse des écarts entre les standards existants et les Analyse von europäischen Normungsbedarfen für
exigences du portefeuille européen d'identité digitale Identitätsbrieftaschen
numérique
This Technical Report was approved by CEN on 14 August 2023. It has been drawn up by the Technical Committee CEN/TC 224.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia,
Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Türkiye and
United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2023 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TR 17982:2023 E
worldwide for CEN national Members.
Contents Page
European foreword . 3
Introduction . 4
1 Scope . 5
2 Normative references . 5
3 Terms and definitions . 5
4 Gap Analysis . 5
Annex A (informative) Status of ISO/IEC 23220 series . 38
Bibliography . 39
European foreword
This document (CEN/TR 17982:2023) has been prepared by Technical Committee CEN/TC 224
“Personal identification, electronic signature and cards and their related systems and operations”, the
secretariat of which is held by AFNOR.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
Any feedback and questions on this document should be directed to the users’ national standards body.
A complete listing of these bodies can be found on the CEN website.
Introduction
The proposal of revision of the eIDAS regulation [1] introduces the concept of European Digital Identity
Wallet.
Throughout the proposal of regulation, numerous requirements are set forth regarding the Wallet, its
functionalities, the services it shall provide to user, as well as its interactions with other entities it shall
support.
Interoperability and user experience of the Wallet are key factors for its uptake but also for its large use
and reach amongst European population. So much that the proposal of regulation also vests the European
Commission with the responsibility to define the technical specifications the Wallet shall meet through
implementing acts, which are legally binding. In that regards, standards are crucial.
This technical report aims at supporting the implementation of the Wallet as defined in the proposal of
regulation by:
• Identifying the articles and clauses in the proposal of regulation defining requirements that are
applicable to the Wallet;
• Identifying for each requirement listed above (1) the available standards or standards under
preparation that could be used or considered, as well as their scope of application, and (2) the
missing standards (named “Missing Standard” in the document) which may require to start
standardization activities;
• Proposing suggestions for standards under preparation so that they fully meet the requirements
listed above (named “Recommendation” in the document);
In that regards, this technical report may be useful to several stakeholders:
• European Commission that could use this technical report as a guide when preparing implementing
act for the implementation of the Wallet;
• Authorities willing to issue a Wallet or entities willing to provide Wallet that could use it to easily
identify available standards on which they could leverage to implement, use or interact with the
Wallet;
• Standardization Organisations that could use it to easily identify normalization gaps where they could
contribute by preparing standards in accordance with their mandate and core competencies;
• Entity tasked by the European Commission in charge of preparing the European Digital identity
Wallet reference implementation;
• Pilot projects launched by the European Commission to build and realize use cases based on the
European Digital Identity Wallet;
The purpose of this document that started before the Architecture Reference Framework (ARF) release
is to map the legal text (here the proposal of revision of the eIDAS regulation [1]) to available standards
and identify possible gaps. Note that the proposal of revision of the eIDAS regulation [1] is likely to be
updated as the legislative process is still ongoing at the time of preparation of this document.
1 Scope
This document identifies relevant existing standards and standards work in progress which could
support implementation of the European Digital Identity Wallets. It also identifies missing work items
and overlaps in standards and is supposed to serve as a roadmap for future standardization projects in
the area. This document takes into account the gap analysis produced by TC224/WG17.
This document is based on the proposal of revision of the eIDAS regulation [1] which was the only
available text at the time this document was initiated
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
wallet
product and service that allows the user to store identity data and attributes linked to her/his identity,
to provide them to relying parties on request and to use them for authentication, online and offline; and
to create qualified electronic signatures and seals
Note 1 to entry Adapted from article 3(42) of [1]
4 Gap Analysis
Item Article Topic Possible standards – for specific
requirements
1 3(42) “‘European Digital Identity Wallet’ is a The following standards have been
product and service that allows the identified
6a(3)b
user to store identity data, credentials
If the Wallet has the capacity to
and attributes linked to her/his
sign/seal by means of qualified
identity, to provide them to relying
electronic signature/seal:
parties on request and to use them for
-CEN/EN 419 212-1 - Application
authentication, online and offline, for a
Interface for Secure Elements for
service in accordance with Article 6a;
Electronic Identification,
and to create qualified electronic
Authentication and Trusted Services -
signatures and seals”;
Part 1: Introduction and common
“European Digital Identity Wallets shall
definitions
enable the user to:
-CEN/EN 419 212-2 - Application
(b) sign by means of qualified
Interface for Secure Elements for
electronic signatures.”
Electronic Identification,
This requirement may be achieved in Authentication and Trusted Services -
several ways: either (1) the Wallet has Part 2: Signature and Seal Services
the capacity to sign/seal by means of
If the Wallet relies on an external but
qualified electronic signature/seal –
local qualified signature/seal creation
and thus is a QSCD, or (2) relies on an
device:
external but local qualified
1/For applicative layer
signature/seal creation device with
which it interacts locally to create a
Item Article Topic Possible standards – for specific
requirements
qualified signature/seal or (3) relies on -CEN/EN 419 212-1 - Application
a remote qualified signature/seal Interface for Secure Elements for
creation device with which it interacts Electronic Identification,
to create a qualified signature/seal. Authentication and Trusted Services -
Part 1: Introduction and common
Case 1: If the Wallet has the capacity to
definitions
sign/seal by means of qualified
electronic signature/seal: -CEN/EN 419 212-2 - Application
Interface for Secure Elements for
The creation of qualified signature/seal
Electronic Identification,
is supported by a local secure
Authentication and Trusted Services -
hardware part of the Wallet, such as a
Part 2: Signature and Seal Services
SE, an eUICC, a TPM,….
-ISO/IEC IS 7816-15 - Identification
The standard CEN/EN 419 212
cards — Integrated circuit cards -
prepared by the CEN/TC224 to support
Cryptographic information application
qualified signature/seal is relevant and
should be considered with the 2/For the transport protocols to be used
following reservations: for the local communication between
the Wallet and the QSCD:
• The device authentication
protocols described in part 3 may -ISO/IEC IS 7816-3 - Identification
not be applicable depending on the cards — Integrated circuit cards -
form factor (SE/eUICC.); Cards with contacts — Electrical
interface and transmission protocols
• The privacy protocols described in
part 4 may not be relevant; -ISO/IEC IS 18004 - QR Code bar code
symbology specification
• The trust eServices described in
part 5 may not be relevant; -ISO/IEC IS 24778 - Aztec Code bar
code symbology specification
Part 1 and part 2 seem to be the most
relevant parts of this series. -ISO/IEC IS 16022 - Data Matrix bar
code symbology specification
Case 2: If the Wallet relies on an external
but local qualified signature/seal -ISO/IEC IS 23634 (DIS) - JAB Code
creation device: polychrome bar code symbology
specification
The creation of qualified signature/seal
is supported by a local but external -ISO/IEC IS 18092 – Near Field
secure hardware such as an external communication
token or an electronic identification -ETSI/EN 302190 - Near Field
document (e.g. national identity card). Communication
The standard CEN/EN 419 212 -USB specifications as defined by the
prepared by the CEN/TC224 to support USB forum
qualified signature/seal is relevant and
Note: This list is not exhaustive.
should be considered with the
Additional standards and protocols
following reservations:
may exist, or change in the future.
• The device authentication
If the Wallet relies on a remote qualified
protocols described in part 3 may
signature/seal creation device:
not be applicable depending on the
-CEN/EN 419 241-1 - Trustworthy
form factor;
Systems Supporting Server Signing -
• The privacy protocols described in
Part 1: General System Security
part 4 may not be relevant;
Requirements
Item Article Topic Possible standards – for specific
requirements
• The trust eServices described in -ETSI TS 119 462 - Electronic
part 5 may not be relevant; Signatures and Infrastructures (ESI);
Protocols for remote digital signature
Part 1 and part 2 seem to be the most
creation (relying on -“Architectures
relevant parts of this series.
and protocols for remote signature”
The following standards are available
v1.0.3 by Cloud Signature Consortium);
for the transport layer: ISO/IEC
-“Architectures and protocols for
IS 7816-3, barcode capture, BLE, Wifi
remote signature” v1.0.4 by Cloud
aware… These standards should be
Signature Consortium (CSC)
considered.
(https://cloudsignatureconsortium.or
While the transport layer is
g/wp-
standardized, the access to these
content/uploads/2020/01/CSC_API_V
services by the wallet application from
1_1.0.4.0.pdf);
the OS layer is not standardized and
For the provisioning of signature/seal
depends on the OS provider.
qualified certificate:
Standardization is needed.
-WI “Electronic Signatures and
ISO/IEC IS 7816-15 allows the Wallet
Infrastructures (ESI); Wallet interfaces
to use the QSCD by providing a
for trust services and signing “
harmonized description of its capacity,
(DTS/ESI-0019462 (TS)
and thus allowing the discovery of the
https://portal.etsi.org/webapp/Work
QSCD capacity by the Wallet.
Program/Report_WorkItem.asp?WKI_I
Case 3: If the Wallet relies on a remote
D=63566)
qualified signature/seal creation device:
The following standards are relevant:
• “Architectures and protocols for
remote signature” by Cloud
Signature Consortium (CSC)
defining the architecture and
protocols for interfacing each
components needed for remote
signing;
• ETSI TS 119 432 which defines
interfaces and protocols between a
server signing application service
component (managing the
signature key) and a signature
creation application service
component (requesting the
signature/seal). This standard
relies on the “Architectures and
protocols for remote signature”
v1.0.3 by Cloud Signature
Consortium (CSC);
CEN/EN 419 241-1 which defines
security requirements and
recommendations for Trustworthy
Systems Supporting Server Signing
that generate digital signatures/seals
Item Article Topic Possible standards – for specific
requirements
(entity managing the signature/seal
key);
Moreover, ETSI/TC ESI has launched
the WI “Electronic Signatures and
Infrastructures (ESI); Wallet interfaces
for trust services and signing “
(DTS/ESI-0019462 (TS)
https://portal.etsi.org/webapp/Work
Program/Report_WorkItem.asp?WKI_I
D=63566) covering the wallet interface
with provider of qualified
signature/seal certificate.
2 3(44) Format of the electronic attestation of The following standards have been
attribute. identified
45c
Several technical standards are already For the format of attestation of
used to authenticate attribute relating attribute:
to a person within various domain.
-W3C Verifiable Credential
These standards should all be
-AFNOR XP Z42-105 - Spécifications
considered, in particular to support
relatives à la mise en oeuvre du Cachet
qualified attestation of attributes
Électronique Visible (CEV) Otentik aux
fins d'authentification, de vérification
et de saisie automatique des données
véhiculées par un document ou un
objet
-ISO/IEC IS 22385 (CD) - Guidelines for
establishing a framework for trust and
interoperability
-ISO/IEC TS 7367 (AWI) - ISO-
compliant vehicle mobile registration
certificate
-ISO/IEC IS 18013-5 - Mobile driving
licence (mDL) application
-ICAO TR Digital Travel Credentials
-ISO/IEC IS 22376 (WD) - Security and
resilience — Authenticity, integrity and
trust for products and documents —
Electronic Storage Specifications for
use of Visible Digital Seal (VDS) for the
authentication, verification and
acquisition of data carried by a
document or object
-Generic presentation format based on
all or part:
• RFC 8259 - The JavaScript Object
Notation (JSON) Data Interchange
Format
Item Article Topic Possible standards – for specific
requirements
• RFC 7519 - JSON Web Token (JWT)
• RFC 7165 - Use Cases and
Requirements for JSON Object
Signing and Encryption (JOSE)
• RFC 4648 - The Base16, Base32,
and Base64 Data Encodings
• RFC 8610 - Concise Data Definition
Language (CDDL): A Notational
Convention to Express Concise
Binary Object Representation
(CBOR) and JSON Data Structures
• RFC 8949 - Concise Binary Object
Representation (CBOR)
• RFC 8152 - CBOR Object Signing
and Encryption (COSE)
• RFC 5280 - Internet X.509 Public
Key Infrastructure Certificate and
Certificate Revocation List (CRL)
Profile
• ISO/IEC IS 8825-1 - ASN.1
encoding rules: Specification of
Basic Encoding Rules (BER),
Canonical Encoding Rules (CER)
and Distinguished Encoding Rules
(DER)
-WI in progress “Electronic Signatures
and Infrastructures (ESI);
Profiles for Attribute Attestations” by
ETSI/TC ESI (DTS/ESI-0019472 (TS)
https://portal.etsi.org/webapp/Work
Program/Report_WorkItem.asp?WKI_I
D=63560)
Recommendations to ETSI/TC ESI
All the standards listed above should be
taken into consideration.
It is recommended to ETSI/TC ESI:
• that the overall structure of
attestations will be dealt with by
ETSI/TC ESI. However it’s
fundamental that such structure be
able to accommodate a wide range
of externally defined specific
attribute semantics, syntaxes and
encodings;
• to consider ISO/IEC TS 23220-2;
Item Article Topic Possible standards – for specific
requirements
3 3(43) A common semantic for attributes is The following standards have been
needed in order to achieve identified
interoperability between all the MS.
For the data model:
The proposed regulation envisions
-ISA deliverables
cross-border recognition of qualified
(https://joinup.ec.europa.eu/collectio
electronic attestation of attributes,
n/semantic-interoperability-
where appropriate i.e. without
community-semic/our-resources)
prejudice to Union or national law
• Core Person Vocabulary
defining additional sector specific
• Core Business Vocabulary
requirements as regards form with
• Core Location Vocabulary
underlying legal effects. Such
attestations of attributes can only be
• Core Criterion and Core Evidence
interoperable if there semantic is
Vocabulary
determined and shared by qualified
• Core Public Organization
eAA TSPs.
Vocabulary
For instance, different
Data model defined for eIDAS 1:
languages/alphabets and data
-eIDAS SAML Attribute Profile v1.2
structures and purposes for these
(https://ec.europa.eu/digital-
attributes should be understandable
building-
cross-border. In addition to usual
blocks/wikis/download/attachme
localization, there is a need for a
nts/467109280/eIDAS%20SAML
semantic specification. This can as
%20Attribute%20Profile%20v1.2
example be achieved by meta-data
%20Final.pdf?version=1&modific
heading the attributes to make it
ationDate=1639417533653&api=
interoperable. Those metadata may be
v2)
defined in binary coding with a
Missing standard
definition language as ASN.1, or with
markup language as XML or with
A standard ensuring any attribute
JavaScript notation as JSON, or else.
could be “resolved”. This standard
should make attribute “resolvable”
As an example, the international
(attribute should resolve to semantic
standard mDL/mID data model
so that it could be understood).
(ISO/IEC IS 18013-5, section 7.1 and
7.2) the semantic problem of cross-
This standard shall be independent of
border recognition of data elements by
the formatting of attestation of
adopting “namespaces” concept.
attributes, as portability of standalone
Accordingly, abstract containers are
attribute in Wallet in envisioned by the
used to host the attributes; they are
proposed regulation (article 3(42)). It
called DocType and NameSpace and
should include i.e. management of
are used to encapsulate the document
metadata, translation, purposes, term
type and the space in which the
of usage.
attributes are defined. Accordingly, the
This could be handled in the
document type field follows the
ISO/IEC TS 23220-2 (AWI).
following general format: [Reverse
Recommendations to ETSI/TC ESI
Domain].[Domain Specific Extension].
TC224 kindly requests ETSI/TC ESI to
The document type for an mDL
allow for an open format/any format of
document was fixed as
attestation in the WI “Electronic
“org.iso.18013.5.1.mDL” in which the
Signatures and Infrastructures (ESI);
reverse domain (org.iso) was selected
Profiles for Attribute Attestations”
to avoid collisions. This approach is
Item Article Topic Possible standards – for specific
requirements
extensible and can be used to define (DTS/ESI-0019472 (TS)
other doctypes. And the namespace for https://portal.etsi.org/webapp/Work
mDL data was fixed as Program/Report_WorkItem.asp?WKI_I
“org.iso.18013.5.1” where the number D=63560) dealing with format of
“1” in the namespace might be attestation.
increased in future versions of the
It is recommended to ETSI/TC ESI:
standard. Within this namespace, only
• that the overall structure of
data elements defined explicitly in the
attestations will be dealt with by
standard may be used. This simple
ETSI/TC ESI. However it’s
concept can be reemployed for
fundamental that such structure be
credentials and other attributes ported
able to accommodate a wide range
on the wallet. It suffices in practice to:
of externally defined specific
• define doctypes (compartments
attribute semantics, syntaxes and
standing for application
encodings;
containers) and their namespaces
• to consider ISO/IEC TS 23220-2
(set of attributes), and
(AWI);
• to allocate labels and to assign
value to each attribute (or data
element) within a namespace, and
• to register (e.g. in a decentralized
registry or a ledger) the attributes’
label and respective description
and coding type.
Last but not least, the ISA
(Interoperability solutions for public
administrations, businesses and
citizens) program has already defined
several data models that should be
considered
(https://joinup.ec.europa.eu/collectio
n/semantic-interoperability-
community-semic/our-resources).
Several core vocabularies have been
defined, which are simplified, reusable,
and extensible data models that
capture the fundamental
characteristics of an entity, such as a
person or a public organization, in a
context-neutral manner. In particular, a
core vocabulary defines the semantic
and the identification of each attribute,
as well as their relations, in a
technology neutral manner. The
following core vocabularies are
available:
• Core Person Vocabulary
• Core Business Vocabulary
• Core Location Vocabulary
Item Article Topic Possible standards – for specific
requirements
• Core Criterion and Core Evidence
Vocabulary
• Core Public Organization
Vocabulary
Besides, the data model already
defined for the implementation of
eIDAS 1 should also be considered.
4 6a(1) Each MS shall issue a wallet within a The following standards have been
given timeframe. One of the purpose is identified
6a(3)a
to be able to issue it onto user mobile
For the installation, issuance of the
phone.
wallet and provisioning of data in the
ISO/IEC 23220-3 describes interfaces wallet:
and protocols for (1) installation of
-ISO/IEC IS 23220-1 (DIS)
mobile identity application, as well as
-ISO/IEC TS 23220-2 (AWI)
for (2) the issuance of data and assets
-ISO/IEC TS 23220-3 (AWI)
within the mobile identity application.
Therefore this standard supports the
following requirements:
• Each MS shall issue a wallet within
a given timeframe, where one of
the main target is the user mobile
phone (as stated in 6a(1));
• “securely request and obtain,
store, select, combine and share, in
a manner that is transparent to and
traceable by the user, the
necessary legal person
identification data and
electronic attestation of
attributes to authenticate online
and offline in order to use online
public and private services” (as
stated in 6a(3)a);
ISO/IEC TS 23220-3 should be
considered.
ISO/IEC TS 23220-2 (part of the
ISO/IEC 23220 series) should also be
considered as it defines data structure.
5 6a(3) The eIDAS expert group is currently Recommendation
preparing the architecture reference
6a(4) At the very beginning of 2022 (when
framework (ARF) that should be
the ARF is available), launch a
general
available by the end of 2021. This will
comprehensive analysis to identify the
define the generic architecture of the
standards available for the building
system.
blocks and interfaces sorted out in the
Once available a comprehensive ARF, but also the missing ones.
analysis should be carried out to
identify the standards available for the
Item Article Topic Possible standards – for specific
requirements
building blocks and interfaces sorted This analysis could lead to three
out in the ARF, but also the missing deliverables:
ones.
1/Guidelines for implementation of the
This analysis could lead to three ARF. A first release could be published
deliverables: containing the existing standards that
have been identified.
1/Guidelines for implementation of the
ARF. A first release could be published Further releases could be published
containing the existing standards that once standards filling the identified
have been identified. Further releases gaps have been published;
could be published once standards
2/a series of NWI covering the gaps
filling the identified gaps have been
that have been identified;
published;
3/an evaluation against ISO/IEC
2/a serie of NWI covering the gaps that
IS 23220-1 to (1) perform the mapping
have been identified;
with the ARF, and (2) identify gaps.
3/an evaluation against ISO/IEC
Missing standard
IS 23220-1 to (1) perform the mapping
A first release of the guidelines for
with the ARF, and (2) identify gaps.
implementation of the ARF containing
As the ARF is to be released soon, a
the existing standards that have been
dedicated work could start as of
identified.
beginning 2022.
6 6a(3) “European Digital Identity Wallets shall The following standards have been
enable the user to: identified
6a(4)a
(a) securely request and obtain, store, For the wallet:
select, combine and share, in a manner
-ISO/IEC IS 18013-5
that is transparent to and traceable by
-ISO/IEC IS 23220-1 (DIS)
the user, the necessary legal person
-ISO/IEC TS 23220-4 (AWI)
identification data and electronic
-Open ID Connect and OIDC-SIOP also
attestation of attributes to authenticate
answer these needs (Open ID
online and offline in order to use online
Foundation). Also refer to Verifiable
public and private services;
presentation encompassing SIOP and
(b) sign by means of qualified
Connect:
electronic signatures.”
https://openid.net/specs/openid-
“Digital Identity Wallets shall, in
connect-4-verifiablepresentations-
particular:
1_0.html and
(a) provide a common interface:
https://identity.foundation/didcomm-
(1) to qualified and non-qualified trust messaging/spec/
service providers issuing qualified and
-SAML (Oasis)
non-qualified electronic attestations of
General recommendations for
attributes or other qualified and non-
ETSI/TC ESI:
qualified certificates for the purpose of
All the standards listed above should be
issuing such attestations and
taken into consideration when
certificates to the European Digital
preparing the WI “Electronic
Identity Wallet;
Signatures and Infrastructures (ESI);
(2) for relying parties to request and
Wallet interfaces for trust services and
validate person identification data and
signing “ (DTS/ESI-0019462 (TS)
electronic attestations of attributes;
Item Article Topic Possible standards – for specific
requirements
(3) for the presentation to relying https://portal.etsi.org/webapp/Work
parties of person identification data, Program/Report_WorkItem.asp?WKI_I
electronic attestation of attributes or D=63566).
other data such as credentials, in local
mode not requiring internet access for
the wallet;
(4) for the user to allow interaction
with the European Digital Identity
Wallet and display an “EU Digital
Identity Wallet Trust Mark””;
Several standards are available for the
wallet to fulfill these requirements:
• ISO/IEC IS 18013-5.
This standard supports the
following requirements:
-“[…] store, select, combine and
share, in a manner that is
transparent to and traceable by the
user, the necessary legal person
identification data and electronic
attestation of attributes to
authenticate online and offline
[…]”
-6a(4)a(1)
-6a(4)a(2)
-6a(4)a(3)
• ISO/IEC TS 23220-4 (part of the
ISO/IEC 23220 series)
This standard supports the
following requirements
-“[…] securely request and obtain,
store, select, combine and share,
in a manner that is transparent to
and traceable by the user, the
necessary legal person
identification data and electronic
attestation of attributes to
authenticate online and offline
[…]”
-6a(4)a(1)
-6a(4)a(2)
-6a(4)a(3)
7 3(42) STORE OFFLINE The following standards have been
identified
6a(3)a READ OFFLINE
Item Article Topic Possible standards – for specific
requirements
6a(4)a( The wallet shall support offline mode, 1/For the wallet to provide data:
3) which has several consequences:
-ISO/IEC IS 18013-5 - Mobile driving
Recital 1/”[…] store identity data, licence (mDL) application
(21) credentials and attributes linked to
— ICAO TR DTC Physical
her/his identity […] offline […] Component (please note that the
(3(42)) current scope of work is limited to
border control)
The following standards are available
for the transport layer: barcode 2/For the transport protocols to be used
capture, BLE, Wifi aware… These for the local communication with the
standards should be considered. wallet for (storage/provision of data):
While the transport layer is -ISO/IEC IS 18004 - QR Code bar code
standardized, the access to these symbology specification
services by the wallet application from
-ISO/IEC IS 24778 - Aztec Code bar
the OS layer is not standardized and
code symbology specification
depends on the OS provider.
-ISO/IEC IS 16022 - Data Matrix bar
Standardization is needed.
code symbology specification
Besides, in order to support the use
-ISO/IEC IS 23634 (DIS) - JAB Code
case of storage of identity data from an
polychrome bar code symbology
identity card compliant to EU
specification
regulation 2019/1157, the NFC
-ISO/IEC IS 18092 – Near Field
interface shall be used. While the
communication
transport layer is standardized, the
-ETSI/EN 302190 - Near Field
access to this service by the wallet
Communication
application from the OS layer is not
Note: This list is not exhaustive.
standardized and depends on the OS
Additional standards and protocols
provider. Standardization is needed.
may exist, or change in the future.
Last but not least, this particular use
Questions to ETSI/TC ESI
case is not covered in any existing
standard. Standardization is needed.
It is unclear whether the WI “Electronic
Signatures and Infrastructures (ESI);
2/”[…] securely request and obtain,
Wallet interfaces for trust services and
store, […], the necessary legal
signing “ (DTS/ESI-0019462 (TS)
person identification data and
https://portal.etsi.org/webapp/Work
electronic attestation of attributes
Program/Report_WorkItem.asp?WKI_I
to authenticate […] offline […]”
D=63566) launched by ETSI/TC ESI
(6a(3)a)
covering the wallet interface with
This article requires to be able to store
provider of attestation will also cover
offline electronic attestation of
the following cases:
attributes.
• Request/obtaining/storage of
The following standards are available
attestation of attribute in offline
for the transport layer: barcode
mode;
capture, BLE, Wifi aware… These
• Provision of electronic attestation
standards should be considered.
to relying party in local mode
While the transport layer is
(offline);
standardized, the access to these
Recommendations to ETSI/TC ESI
services by the wallet application from
the OS layer is not standardized and If offline mode is to be supported in the
WI “Electronic Signatures and
Item Article Topic Possible standards – for specific
requirements
depends on the OS provider. Infrastructures (ESI); Wallet interfaces
Standardization is needed. for trust services and signing
“(DTS/ESI-0019462 (TS)
Moreover, ETSI/TC ESI has launched
https://portal.etsi.org/webapp/Work
the WI “Electronic Signatures and
Program/Report_WorkItem.asp?WKI_I
Infrastructures (ESI); Wallet interfaces
D=63566), ETSI/TC ESI is invited to
for trust services and signing “
consider supporting all transport
(DTS/ESI-0019462 (TS)
protocols identified above.
https://portal.etsi.org/webapp/Work
Missing standard
Program/Report_WorkItem.asp?WKI_I
D=63566) covering the wallet interface -Standards - applicable on any
with provider of attestation. It is Operating System - for wallet
unclear whether this WI will also cover application to access the NFC, BLE, Wifi
this case. aware and optical reader feature from
the OS in order to support offline
This particular use case is not covered
interaction with the wallet application.
in any existing standard.
This is of the utmost importance as for
Standardization is needed.
example many EU countries have
3/”[…] to provide them (i.e. identity
notified digital identity schemes
data, credentials and attributes
relying on identity card: EST, ESP, DEU,
linked to her/his identity) to relying
CZE, ITA, NLD, LVA, SVK, HRV, BEL,
parties on request
LUX, LTU, PRT…
and to use them for authentication,
(https://ec.europa.eu/cefdigital/wiki/
[…] offline, […]” (3(42))
display/EIDCOMMUNITY/Overview+o
“[…] for the presentation to relying
f+pre-
parties of person identification data,
notified+and+notified+eID+schemes+
electronic attestation of attributes
under+eIDAS).
or other data such as credentials, in
-Standards describing how to store
local mode not requiring internet
data in offline mode in the wallet
access for the wallet” (6a(4)a(3))
covering amongst other:
This may be achieved thanks to the
• Process;
mechanisms defined in ISO/IEC
• Transport layer;
IS 18013-5 or ICAO TR DTC Physical
Component (please note that the • Interfaces;
current scope of work is limited to
-In the case where the Wallet is made
border control).
up with (1) a user side and (2) a server
The following standards are available side, where the latter manages all these
for the transport layer: barcode features, there are no available
capture, NFC, BLE, Wifi aware… These standards covering:
standards should be considered.
• the interface and communication
While the transport layer is between both of them;
standardized, the access to these
• the security mechanisms to be put
services by the wallet application from
in place to ensure both parts are
the OS layer is not standardized and
securely paired;
depends on the OS provider.
• the security requirements to be
Standardization is needed.
fulfilled by each part so that the
Moreover, ETSI/TC ESI has launched
wallet as a whole meets the
the WI “Electronic Signatures and
necessary security requirements;
Infrastructures (ESI); Wallet interfaces
Item Article Topic Possible standards – for specific
requirements
for trust services and signing -If offline mode is not supported in the
“(DTS/ESI-0019462 (TS) WI prepared by ETSI/TC ESI, a NWI
https://portal.etsi.org/webapp/Work should be prepared. This case should
Program/Report_WorkItem.asp?WKI_I be investigated.
D=63566) covering the wallet interface
with trust services. It is unclear
whether this WI will also cover this
case.
Besides, such standardization will also
serve the purpose of the DMA -
indicated in the recital (21) - which
aims at ensuring that business users
and providers can interoperate with
hardware and software features of the
platforms offered by the gatekeepers
(i.e. NFC, SE, eUICC, BLE, Wifi,…):
“[…] Article 6(1)(f) of the Regulation
XXX/XXXX [Digital Markets Act]
requires gatekeepers to allow business
users and providers of ancillary
services access to and interoperability
with the same operating system,
hardware or software features that are
available or used in the provision by
the gatekeeper of any ancillary
services.
According to Article 2 (15) of [Digital
Markets Act] identification services
constitute a type of ancillary services.
Business users and providers of
ancillary services should therefore be
able to access smartphones, and to
interoperate with them through the
European Digital Identity Wallets or
Member States’ notified electronic
identification means. […]”
In addition, in the case where the
Wallet is made up with (1) a user side
and (2) a server side, where the latter
manages all these features, there are no
available standards covering:
• the interface and communication
between both of them;
• the security mechanisms to be put
in place to ensure both parts are
securely paired;
• the security requirements to be
fulfilled by each part so that the
Item Article Topic Possible standards – for specific
requirements
wallet as a whole meets the
necessary security requirements;
8 6a(3)a STORE ONLINE The following standards have been
identified
The wallet shall be able to store data
online For the secure online
provisioning/storage of identity data,
“to store identity data, credentials
credentials, attributes, and electronic
and attributes linked to her/his
attestation:
identity, to provide them to relying
parties on request and to use them for -ISO/IEC IS 23220-1 (DIS)
authentication, online and offline […]”
-ISO/IEC TS 23220-2 (AWI)
(3(42))
-ISO/IEC TS 23220-3 (AWI)
“securely request and obtain, store,
-ISO/IEC TS 23220-4 (AWI)
[select, combine and share], [in a
-RFC 6455 - The WebSocket Protocol
manner that is transparent to and
Missing standard
traceable by the user], the
-In the case where the Wallet is made
necessary legal person
up with (1) a user side and (2) a server
identification data and electronic
side, where the latter manages all these
attestation of attributes to
authenticate online [and offline] in features, there are no available
standards covering:
order to use online public and private
services”; (6a(3)a)
• the interface and communication
between both of them;
ISO/IEC TS 23220-3 (part of the
ISO/IEC 23220 series) should be
• the security mechanisms to be put
considered as it defines online
in place to ensure both parts are
provisioning with end-to-end security
securely paired;
to protect personal data
• the security requirements to be
confidentiality.
fulfilled by each part so that the
ISO/IEC TS 23220-4 (part of the
wallet as a whole meets the
ISO/IEC 23220 series) should be
necessary security requirements;
considered as it provides mechanism
Recommendations to ETSI/TC ESI
for user binding prior to provisioning
To ensure consistency, the WI
data.
“Electronic Signatures and
ISO/IEC TS 23220-2 (part of the
Infrastructures (ESI); Wallet interfaces
ISO/IEC 23220 series) should be
for trust services and signing “
considered as it defines data structure.
(DTS/ESI-0019462 (TS)
Websocket protocol as defined in
https://portal.etsi.org/webapp/Work
RFC 6455 supports fulfillment of online
Program/Report_WorkItem.asp?WKI_I
connection in asynchronous manner
D=63566) launched by ETSI/TC ESI
and should be considered. Where
shall fully leverage on the standards
online connection is used for the
identified above for the use case of
provisioning of data within the wallet
storage of attestation of attribute in the
(PID, attestation), asynchronous use
wallet.
cases should also be considered as it
Comments on ETSI WI
appears useful to solve some issues
The WI “Electronic Signatures and
online interaction may raise:
Infrastructures (ESI); Wallet interfaces
for trust services and signing “
Item Article Topic Possible standards – for specific
requirements
• Wallet provisioning with PID or (DTS/ESI-0019462 (TS)
attestation etc. may require time- https://portal.etsi.org/webapp/Work
consuming processing that may Program/Report_WorkItem.asp?WKI_I
exceed common timeouts and D=63566) launched by ETSI/TC ESI
makes synchronous may not fully cover the case of
communication (i.e. HTTPS) identification data and attributes.
inappropriate and detrimental to Could ETSI/TC ESI clarify this point?
UX;
• Wallet demand may temporary
exceed the capacity of the issuance
entity;
• The provisioning service is
unlikely to provide immediate
answer;
• The user experience will greatly
benefit from polling rather than
keeping the connection active until
provisioning is completed, or from
protocol switch to websocket such
as to establish an asynchronous
full-duplex communication with
the server;
Moreover, ETSI/TC ESI has launched
the WI “Electronic Signatures and
Infrastructures (ESI); Wallet interfaces
for trust services and signing “
(DTS/ESI-0019462 (TS)
https://portal.etsi.org/webapp/Work
Program/Report_WorkItem.asp?WKI_I
D=63566) covering the wallet interface
with provider of attestation, which may
apply to store attestation of attribute in
the wallet. To ensure consistency, this
standard being prepared shall fully
leverage on the standards listed above
for this use case.
In addition, in the case where the
Wallet is made up with (1) a user side
and (2) a server side, where the latter
manages all these features, there are no
available standards covering:
• the interface and communication
between both of them;
• the security mechanisms to be put
in place to ensure both parts are
securely paired;
• the security requirements to be
fulfilled by each part so that the
Item Article Topic Possible standards – for specific
requirements
wallet as a whole meets the
necessary security requirements;
9 6a(3)a SHARE ONLINE The following standards have been
identified
The wallet shall share data in online
mode: For reading data (of any kind) from the
wallet
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...