ISO/IEC TS 23220-2:2024

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

This document specifies data objects and encoding rules of generic eID-Systems in terms of building blocks for mobile document system infrastructures, and standardizes generic data models for data exchanges between mdoc apps and verification applications. This document is applicable to entities involved in specifying, architecting, designing, testing, maintaining, administering, and operating a mobile eID-System in parts or as a whole.

Cartes et dispositifs de sécurité pour l’identification des personnes — Blocs fonctionnels pour la gestion des identités via les dispositifs mobiles — Partie 2: Objets de données et règles d'encodage pour les systèmes eID génériques

General Information

• Status: Published
• Publication Date: 31-Oct-2024
• 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: 9092 - International Standard to be revised
• Start Date: 22-Dec-2024
• Completion Date: 30-Oct-2025

Relations

• Revised: ISO/IEC DTS 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
• Effective Date: 07-Jan-2025

Standards Content (Sample)

Technical
Specification
ISO/IEC TS 23220-2
First edition
Cards and security devices for
2024-11
personal identification — Building
blocks for identity management via
mobile devices —
Part 2:
Data objects and encoding rules for
generic eID systems
Cartes et dispositifs de sécurité pour l’identification des
personnes — Blocs fonctionnels pour la gestion des identités via
les dispositifs mobiles —
Partie 2: Objets de données et règles d'encodage pour les systèmes
eID génériques
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: [phone]
Email: [e-mail]
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 . 2
4 Symbols and abbreviated terms. 3
5 General . 3
6 Data model . 5
6.1 General .5
6.2 Data format and encoding rules .6
6.2.1 Identifier .6
6.2.2 Field format .6
6.2.3 Encoding .6
6.2.4 namespace . .7
6.3 Standard meta-attributes .7
6.3.1 Meta attributes for person entity — personal attributes .7
6.3.2 Attribute statement .11
6.3.3 Meta-attribute for issuer entity . 13
6.3.4 Data elements for document entity . 13
6.3.5 Data elements for document authenticity .14
6.4 Data element for level of confidence . .14
7 Cipher suites . 14
7.1 General .14
7.2 Elliptic curves .14
7.3 TLS . 15
7.4 Digest algorithms . 15
7.5 Signature algorithms . 15
7.6 HMAC algorithm .16
8 Generic data models . 16
8.1 General .16
8.2 mdoc data model .16
8.2.1 General .16
8.2.2 CBOR encoding .16
8.2.3 JSON conversion .17
8.3 JSON data model .19
8.3.1 General .19
8.3.2 Issuer-signed .19
8.3.3 Holder-signed . 20
Annex A (informative) Examples .22
Bibliography .24

© 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/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 2024 – All rights reserved
iv
Introduction
Electronic ID-Applications (eID-Apps) are today commonly used in badges and ID cards with integrated
circuits and allow users to complete electronic identification, authentication, or optionally, to create digital
signatures. Many different application areas have an essential need for these mechanisms and use different
means to provide these features (e.g. health system with health assurance cards or health professional
cards, financial sector with payment cards, governmental ID with national ID cards, electronic passports
or driver's licenses, educational systems with student cards or library cards, in the company sector with
employee cards and in the private sector with any kind of member cards).
Mobile devices (e.g. mobile phones or smart phones, wearable devices) are a central part of the daily life for
many individuals. They are not only used for communication, but also for emailing, access to social media,
gaming, shopping, banking, and storing of private content such as photos, videos and music. They are used
today as a personal device for business and private applications. With the ubiquity of mobile devices in
day-to-day activities there is a strong demand from users to have eID-Apps or services with identification/
authentication mechanisms on their mobile equipment, i.e. an mdoc app.
An mdoc app can be deployed to provide a number of different digital ID-documents. Additionally, it can
reside among other eID-Apps on a mobile device. Moreover, users can possess more than one mobile device
holding an mdoc app, which leads to enhanced mechanisms for the management of credentials and attributes.
The technical preconditions for the deployment of mdoc apps exist and they are partly standardized to
support security and privacy on a mobile device. Examples for containers of eID-App solutions are the
software-based Trusted Execution Environment (TEE), hardware-based secure elements such as universal
integrated circuit card (UICC), embedded or integrated UICC (eUICC or iUICC), embedded secure elements,
secure memory cards with cryptographic module or other dedicated internal security devices residing on
the mobile device, as well as solutions with server-based security means.
As mdoc apps can be located on different forms of mobile devices featuring different security means, being as
generic as possible helps them to be adoptable to different variants of trusted eID-Management. This diversity
leads also to different levels of security, trust and assurance. Trusted eID-Management thereby implies the
(remote) administration and use of one or several security elements (e.g. in form of an intelligent network),
credentials and user attributes with different levels of security suitable to their capability and power.
Access to the mdoc app by the external world is performed by the available transmission channels. Typical
local communication channels are Bluetooth Low Energy (BLE), Near Field Communication (NFC) and Wi-Fi
aware, whereas remote communication is typically an internet connection over mobile networks and Wi-Fi
networks. The way of identification and choice of the transmission interface and protocols is an essential
part for a trusted eID-Management.
Those mdoc apps are used in different areas of daily life and are the focus of different standardization
activities. This document aims at delivering mechanisms and protocols usable by other standards to provide
interoperability and interchangeability. With these basics in mind, future mdoc apps can be derived and
extend the ISO/IEC 23220 series.
The ISO/IEC 23220 series builds upon existing standards comprising four main subjects:
a) secure channel establishment;
b) API call serialization method;
c) data element naming convention; and
d) payload transport over communication channel protocols, which are constitutive of the interoperability
pillars.
In addition, it adds means to establish Trust on First Use (TOFU).
NOTE The ISO/IEC 23220 series inherits and enhances the functionality that was adopted by mobile driving
licence (mDL) applications whereby ensuring backward compatibility with ISO/IEC 18013-5.

© ISO/IEC 2024 – All rights reserved
v
Technical Specification ISO/IEC TS 23220-2:2024(en)
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
1 Scope
This document specifies data objects and encoding rules of generic eID-Systems in terms of building blocks
for mobile document system infrastructures, and standardizes generic data models for data exchanges
between mdoc apps and verification applications.
This document is applicable to entities involved in specifying, architecting, designing, testing, maintaining,
administering, and operating a mobile eID-System in parts or as a whole.
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 3166-1, Codes for the representation of names of countries and their subdivisions — Part 1: Country code
ISO 3166-2, Codes for the representation of names of countries and their subdivisions — Part 2: Country
subdivision code
ISO/IEC 5218, Information technology — Codes for the representation of human sexes
ISO/IEC 7816-11, Identification cards — Integrated circuit cards — Part 11: Personal verification through
biometric methods
ISO/IEC 10646, Information technology — Universal coded character set (UCS)
ISO/IEC 18013-2:2020, Personal identification — ISO-compliant driving licence — Part 2: Machine-readable
technologies
ISO/IEC 18013-5:2021, Personal identification — ISO-compliant driving licence — Part 5: Mobile driving licence
(mDL) application
ISO/IEC 19785-3, Information technology — Common Biometric Exchange Formats Framework — Part 3:
Patron format specifications
ISO/IEC 19794-4, Information technology — Biometric data interchange formats — Part 4: Finger image data
ISO/IEC 19794-5, Information technology — Biometric data interchange formats — Part 5: Finger image data
ISO/IEC 39794-4, Information technology — Extensible biometric data interchange formats — Part 5: Face
image data
ISO/IEC 39794-5, Information technology — Extensible biometric data interchange formats — Part 5: Face
image data
© ISO/IEC 2024 – All rights reserved
RFC 4648, The Base16, Base32, and Base64 Data Encodings, October 2006
RFC 7165, Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)
RFC 7515, JSON Web Signature
RFC 8949, Concise Binary Object Representation (CBOR)
ITU-T E.123, Notation for national and international telephone numbers, e-mail addresses and web addresses
ITU-T E.164, The international public telecommunication numbering plan
3 Terms and definitions
For the purposes of this document, the following terms and definitions 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
alphabetic character
A
hexadecimal ranges '41' – '5A' (Latin capital letters), '61' – '7A' (Latin small letters), 'C0' – 'D6', 'D8' – 'F6' and
'F8' – 'FF' of ISO/IEC 8859-1
3.2
boolean
logical values, TRUE and FALSE
3.3
byte string
bstr
sequence of bytes
3.4
label
identifier that is attached to a data element
3.5
numeric character
N
hexadecimal range '30' – '39' (digits 0 to 9) of ISO/IEC 8859-1
3.6
special character
S
hexadecimal ranges '20' – '2F' ( ! “ # $ % & ‘ ( ) * + , - . /), '3A' (:), '3C' – '40' (< = > ? @), '5B' – '60'
([\]^_`),'7B'–'7E'({|}~),'A1'–'AC'(¡¢£¤¥¦§ ̈©a«¬),'AE'–'A5'(® ̄°±2 3 ́μ), and'A7'–'BF'(· ̧ 1 ° » 1⁄4 1⁄2 3⁄4 ¿) of
ISO/IEC 8859-1
3.7
text string
tstr
string of characters
3.8
unsigned integer
uint
binary value of a number of consecutive bits

© ISO/IEC 2024 – All rights reserved
4 Symbols and abbreviated terms
For the purposes of this document, the following abbreviated terms apply.
BCD Binary Coded Decimal
CBEFF Common Biometric Exchange Formats Framework
CBOR Concise Binary Object Representation
CDDL Concise Data Definition Language
eID electronic IDentification
F Fixed length
JSON JavaScript Object Notation
JWS JSON Web Signature
mDL mobile driving license
mdoc mobile document
URI Uniform Resource Identifier
V Variable length
5 General
ID documents are issued by binding an applicant with a real-life identity. An issuer collects evidence to verify
the attributes provided by the applicant, and this process is called identity proofing. An applicant provides
his or her attributes in specific application form. In such an application form, character formats of each data
element are taken into account in order to avoid a mismatch with the ID document format. The issuer of the
ID document verifies the attributes provided by the applicant with evidence and confirms the value of each
attribute. ID documents issued by authoritative organisations are usually used as evidence.
Figure 1 illustrates an example of the issuing process of an eID document. An applicant provides an
application form and evidence (e.g. ID cards issued by Authority) to the issuer. The issuer collects other
evidence if needed and proves his or her identity and binds his or her identity with the holder and confirms
the applicant by photo ID or by person of authority. As a result, his or her eID card is issued as "something
you have", optionally together with "something you are (e.g. portrait)" and "something you know (e.g.
1)
password)", as defined in ISO/IEC TS 23220-5 .
1) Under preparation. Stage at the time of publication: ISO/IEC CD TS 23220-5

© ISO/IEC 2024 – All rights reserved
Figure 1 — Identity data collection and confirmation of its values
According to digitalisation of the issuing process, attributes used for application form and evidence are
described as digital data. The specification of data elements and encoding rules for application form can
be identical to that of Mobile eID. In case eID card or Mobile eID is used as evidence, a set of data elements
and encoding rule is not always identical to Mobile eID. Character format, type and length are not always
identical, and are out of scope of this document because they are specified by the issuer.
Figure 2 describes an example which shows a difference of attribute name between application form evidence
and Mobile eID. Attributes for "Date of birth" and "Place of birth" are expressed by different attribute names
in a different entity. The attribute "Date of birth" is expressed as "birth_date" in ISO/IEC 18013-5, whereas it
is expressed as "birthdate" in OpenID connect standard claims.
Figure 2 — Comparison of attribute names (example)

© ISO/IEC 2024 – All rights reserved
In this document, meta attributes are defined to clarify the same attributes with different identifiers to be
used as a reference, supporting comparison and re-use of attribute name between two standards of eID data
elements.
2) 3)
This document also specifies the requirement of ISO/IEC TS 23220-3 and ISO/IEC TS 23220-4 data
elements as a generic extension of ISO/IEC 18013-5 specified for mDL. The data model for each ID document
is specified by issuing authority and out of scope of this document.
6 Data model
6.1 General
Issuing authority should select data element identifiers from this document for interoperability if applicable.
It makes it difficult for authorities to change such a specification because it sometimes requires an
amendment of regulations. It results in a difference of document format, vocabulary and encoding rule.
In general, content of an eID document consists of four kinds of entities: person, document, issuer and proof.
Each entity has attributes which are used to identify an instance of entity. Regardless of vocabulary, some
attributes are commonly used for identifying an instance of entity. In this document, such attributes are
defined as "meta-attribute".
Figure 3 shows an example of a basic data model and how an instance of an entity is identified by values for
a set of attributes. In this document, such attributes are defined as personal attributes.
Figure 3 — Example of basic data model for identifying a person
Relationships with other persons (e.g. parental authority, proxy) can also be expressed with attributes. In
this document, Figure 4 shows a relation between entity and attribute.
2) Under preparation. Stage at the time of publication: ISO/IEC CD TS 23220-3.
3) Under preparation. Stage at the time of publication: ISO/IEC CD TS 23220-4.

© ISO/IEC 2024 – All rights reserved
Figure 4 — Example of data model including relationship attribute
In eID documents, such attributes are described as data elements. In this subclause, this document specifies
a set of data elements to identify a person.
6.2 Data format and encoding rules
6.2.1 Identifier
The “Identifier” is assigned to identify a data element. The value of “Identifier” can be a tag, an address
(URI), a name, an identifier or else according to the definition language employed. The value type can be
also determined by the definition language employed.
6.2.2 Field format
The field format of data elements is specified with:
— flexibility of length (F/V);
— integer denoting a length of the field;
— character format [alphabetic character (A), numeric character (N) and special character (S)].
EXAMPLE V150AS indicates Variable length, maximum 150 characters with alphabetical characters and special
characters.
6.2.3 Encoding
The following encoding types are used for each data element:
— text string (tstr)
— byte string (bstr)
— uint
— tdate
— boolean (true/false)
— full-date
© ISO/IEC 2024 – All rights reserved
Text string shall be encoded by unicode as specified in ISO/IEC 10646. If binary data is encoded as text
string, Base64URL encoding as specified in RFC 4648 shall be used. There are no length restrictions for the
encoding of the elements, unless otherwise indicated.
Data elements shall be encoded and serialised according to CBOR as specified in RFC 8949.
RFC 8949:2020, section 4.2.1 describes the “core deterministic encoding requirements” for CBOR.
The requirements regarding preferred serialization and indefinite-length shall be implemented. The
requirements regarding sorting of map keys may be implemented.
Table 1 describes a list of Tag values of CBOR major type applied for each encoding type.
Table 1 — Tag value of CBOR major type
Encoding types Tag value of CBOR major type Remarks
text string type 3 unicode encoding
byte string type 2
uint type 0 Unsigned integer
tdate type 6 See below
boolean type 7 true; value 21, false; value 20
Field format of date and time is date-time or full-date as specified in ISO 8601-2. Unless otherwise indicated.
date-time shall be encoded according to RFC 8949:2020, 3.4.1 and uses Tag value 0 of major type 6, described
as tdate (tdate = #6.0(tstr)).
6.2.4 namespace
A namespace defines a data element identifier and specifies the encoding of the format of its value. A
document may have multiple namespaces. The meaning of data elements is dependent on which namespace
it belongs to.
The namespace field follows the following general format:
[Reverse Domain].[Domain Specific Extension].
EXAMPLE The namespace for the mdoc data defined in this document is “org.iso.23220.1”. The last number “1” in
the namespace will be replaced by the edition number of this document.
In case the subdivision of issuing country or issuing authority specifies an extension of the namespace, the
structure of namespace shall add its subdivision code (see 6.3.3) as a suffix.
6.3 Standard meta-attributes
6.3.1 Meta attributes for person entity — personal attributes
6.3.1.1 Data element identifier for personal attributes
This subclause specifies data element identifiers which express attributes for describing a natural or legal
person and requirements for values of each data element. This subclause specifies data element identifiers
and their meaning is namespace specific.
Table 2 describes a set of data elements to express personal attributes. When an implementation of this
document uses a data element from Table 2 under the “org.iso.23220.1” namespace, these shall implement
the definition and encoding as defined in Table 2. For JSON data model, claims as defined in the IANA JOSE
4)
elliptic curves registry shall be used.
4) https:// www .iana .org/ assignments/ jose/ jose .xhtml

© ISO/IEC 2024 – All rights reserved
If an implementation of this document wants to use a data element from Table 2 that changes the definition
or the encoding, it shall be used with a different namespace.
More than two images/biometrics template can be used according to the issuer’s policy, if more than two
values can be supported for a data element.
Table 2 — Data elements for personal attributes
Data element identi-
Data element Description Encoding
fier
family_name_unicode Last name, surname, or primary identifier, of the holder tstr
Family name
Last name, surname, or primary identifier, of the holder,
family_name_latin1 tstr
Latin1 characters
First name(s), other name(s), or secondary identifier, of
given_name_unicode tstr
the holder
Given names
First name(s), other name(s), or secondary identifier, of
given_name_latin1 tstr
the holder. Latin1 characters
Day, month and year on which the holder was born. Un- See birth_date
Date of birth birth_date known parts (i.e., year, month, day) are masked with 1 s t r u c t u r e
(6.3.1.3)
Holder’s sex using values as defined in ISO/IEC 5218. (0
Sex sex uint
= Not Known, 1 = Male, 2 = Female, 9 = Non-applicable)
Height (cm) height Holder’s height in centimetres uint
Weight (kg) weight Holder’s weight in kilograms uint
Country and municipality or state/province where the
Place of birth birthplace tstr
holder was born
The place where the holder resides and/or may be con-
resident_address_unicode tstr
tacted (street/house number, municipality etc.)
Normal place of res-
The place where the holder resides and/or may be con-
idence
resident_address_latin1 tacted (street/house number, municipality etc.), Latin 1 tstr
characters
resident_city_unicode The city/municipality (or equivalent) where the holder lives tstr
Residence city
The city/municipality (or equivalent) where the holder
resident_city_latin1 tstr
lives, Latin 1 characters
Postal code resident_postal_code The postal code of the holder tstr
The country where the holder lives as a two letter country
Resident country resident_country
code (alpha-2 code) defined in ISO 3166-1
Biometric template A reproduction of the holder’s portrait. See 6.3.1.1.2
biometric_template_face bstr
(face image)
Portrait portrait Portrait data as specified in ISO/IEC 18013-2:2020, C.4.5. bstr
Portrait image Date when portrait was taken
portrait_capture_date tdate
timestamp
Fingerprint data fingerprint A reproduction of the holder’s fingerprint data (TBC) bstr
Nationality of the Holder as two letter country code
Nationality nationality (alpha-2 code) or three letter code alpha-3 code) defined tstr
a
in ISO 3166-1
business_name_unicode Business name of the holder tstr
Business name
business_name_latin1 Business name of the holder, Latin1 characters tstr
organization_name_uni- Name of legal person
tstr
code
Organization name
organization_name_latin1 Name of legal person, Latin1 characters tstr
Name at birth name_at_birth The name(s)which holder was born tstr
a th
For persons without a defined nationality, the data model should be encoded as the values specified in ICAO Doc 9303-3 8
edition Clause 5, Part E.
© ISO/IEC 2024 – All rights reserved
TTaabblle 2 e 2 ((ccoonnttiinnueuedd))
Data element identi-
Data element Description Encoding
fier
Telephone num- Telephone number of the holder, including country code
telephone_number tstr
ber(s) as specified ITU-T E.123 and ITU-T E.164
e-mail address(es) email_address E-mail address of the holder tstr
Profession profession Profession of the holder tstr
Academic title title Academic title of the holder tstr
a th
For persons without a defined nationality, the data model should be encoded as the values specified in ICAO Doc 9303-3 8
edition Clause 5, Part E.
NOTE 1 Some major eID applications, such as ePassport defined in ICAO Doc 9303-10 and driving licence, defined in
ISO/IEC 18013-2 define two different face image data elements, e.g. portrait image and biometric. The latter is used for
both visual inspection and biometric comparison, but the former is not usually used. This document defines one face
image in a biometric information template.
NOTE 2 Biometric information record structure defined in CBEFF (ISO/IEC 19785 series) consisting of standard
biometric header and biometric data block are encapsulated in ASN.1 constructed data object such as biometric
information template. This ASN.1 constructed data object is binary string.
6.3.1.2 Portrait image
The portrait image shall be encoded as follows (see Figure 5):
— Application specific identifier, e.g. DG2 with tag '75' as defined by ICAO 9303-10.
— Biometric information template as defined in ISO/IEC 19785-3 (and Biometric information template Group
defined in ISO/IEC 7816-11, if the multiple biometric information templates are supported) encapsulating
CBEFF (Common Biometric Exchange Formats Framework) structure defined in ISO/IEC 19785-3 (see
Table 3).
— CBEFF structure contains biometric data block in accordance with ISO/IEC 19794-5 or ISO/IEC 39794-5
(see Table 4).
Figure 5 — Encoding of portrait image
This structure is also applicable to fingerprint, and then shall support ISO/IEC 19794-4 or ISO/IEC 39794-4.

© ISO/IEC 2024 – All rights reserved
Table 3 — Parameter of Group biometric information table
Element Parameter Value Description
Biometric number of biometric information
Number of the supported
information template
instance of biometric infor-
template Group
mation templates Mandato-
ry, if the multiple biometric
information templates are
supported)
biometric CBEFF_patron_header_version
'0101' Version of CBEFF patron for-
information
mat header (Optional)
template
CBEFF_BDB_biometric_type
As specified in ISO/ Optional
IEC 19785-3
CBEFF_BDB_biometric_subtype
As specified in ISO/ Optional for face image, man-
IEC 19785-3 datory for fingerprint
CBEFF_BDB_creation_date
As specified in ISO/ creation date and time of biom-
IEC 19785-3 etric reference data: fourteen
BCD digits (YYYYMMDDH-
HMMSS) Optional
CBEFF_BDB_validity_period
As specifies in ISO/ A pair of dates (not before,
IEC 19785-3 not after): sixteen BCD digits
(YYYYMMDDYYYYMMDD)
Optional
CBEFF_BIR_creator
Optional
CBEFF_BDB_format_owner
JTC 1/SC 37 Mandatory
CBEFF_BDB_format_type
ISO/IEC 19794-4 Mandatory
(for fingerprint)
ISO/IEC 19794-5
(for face image)
CBEFF_BDB
biometric reference Mandatory
data
Table 4 — Parameters for biometric data
Element Parameter Value Description
versionBlock Generation
Year
representationBlocks-> imageRepresentationBlock->
The face
RepresentationBlock imageRepresentation2DBlock->
image data
representationData2D
in JPEG2000
format
imageRepresentationBlock->
Static photograph
imageRepresentation2DBlock-> ca
from scanner
ptureDeviceTechnology2DBlock->
classOfDeviceTechnology
imageRepresentationBlock->
mrtd
imageRepresentation2DBlock->
imageInformation2DBlock->
faceImageKind2D-> faceImage2DType
imageRepresentationBlock->
TRUE
imageRepresentation2DBlock->
imageInformation2DBlock->
postAcquisitionProcessingBlock ->
multiplyCompressed
imageRepresentationBlock->
JPEG2000Lossy
imageRepresentation2DBlock->
imageInformation2DBlock->
imageDataFormat -> imageDataFormat

© ISO/IEC 2024 – All rights reserved
TTaabblle 4 e 4 ((ccoonnttiinnueuedd))
Element Parameter Value Description
imageRepresentationBlock->
width = 413 height
imageRepresentation2DBlock->
= 531
imageInformation2DBlock->
imageSizeBlock
representationId

captureDateTimeBlock
ye a r = < v a r >
month =
day =
qualityBlocks-> QualityBlock ->

organisation
qualityBlocks-> QualityBlock ->

identifier
qualityBlocks-> QualityBlock ->

scoreOrError -> score
identityMetadataBlock -> eyeColour

6.3.1.3 Date of birth as either uncertain or approximate, or both
If date of birth includes an unknown part, the following birth_date structure may be used.
birth_date = {
“birth_date” : full-date,
? “approximate_mask”: tstr
}
approximate_mask is an 8 digit flag to denote the location of the mask in YYYYMMDD format. 1 denotes mask.
NOTE 1 “approximate_mask” is not intended to be used for calculation.
NOTE 2 The birth_date structure is always used, not just when the mask is present.
6.3.2 Attribute statement
6.3.2.1 Data elements for attribute statements
This subclause specifies data elements which express statement attributes for describing an attribute
statement of a holder and requirements for values of each data element.
Table 5 describes a set of data elements to express an attribute statement. When an implementation of this
document uses a data element from Table 5 under the “org.iso.23220.1” namespace, these shall implement
the definition and encoding as defined in Table 5.
If an implementation of this document wants to use a data element from Table 5 that changes the definition
or the encoding, it shall be used with a different namespace.
Table 5 — Data elements for attribute statement
Data element Data element identifier Description Encoding
Age attestation: How
age_in_years The age of the holder uint
old are you (in years)?
Age attestation: In
what year were you age_birth_year The year when the holder was born uint
born?
Age attestation: Near-
est “true” attestation age_over_NN See 6.3.2.2 bool
above request
© ISO/IEC 2024 – All rights reserved
6.3.2.2 Age attestation: Nearest “true” attestation above request
This set of elements is used to convey to a verifier, in a data-minimized fashion, if the holder is as old or older
than a specified age, or if the holder is younger than a specified age. To achieve this, the mdoc contains age
attestation identifiers. An age attestation identifier has the format age_over_NN where NN is a value from 00
to 99. The value of an age attestation identifier can be TRUE or FALSE.
If a verifier includes age_over_NN in a request, it has the meaning of “provide the nearest age attestation
equal to or larger than NN with value TRUE, or smaller than NN with value FALSE”. More specifically, after
receiving an age_over_NN request, the logic to determine the appropriate response shall be equivalent to the
following:
a) For all age attestations of the form age_over_NN stored on the mdoc, consider all the attestations with
value TRUE. From among these attestations, check if an attestation exists where nn is equal to or
larger than NN. If one and only one such attestation exists, this is the response. If more than one such
attestation exists, the response shall be the attestation with the smallest difference between nn and NN.
b) If step 1 does not produce a response, for all age attestations of the form age_over_NN stored on the
mdoc, consider all the attestations with value FALSE. From among these attestations, check if an
attestation exists where nn is equal to or smaller than NN. If one and only one such attestation exists,
this is the response. If more than one such attestation exists, the response shall be the attestation with
the smallest difference between NN and nn.
c) If step 2 does not produce a response, no age_over_NN data element shall be returned.
In case of device retrieval, the value of an age_over_NN data element shall be calculated by the issuing
authority infrastructure to be valid at the value of the timestamp in the validFrom element in the mobile
security object (MSO) from 8.2.2.4.
In case of server retrieval, the value of an age_over_NN data element shall be valid at the value of the iat
timestamp as defined in 8.2.3.3.2.
For the use of age_over_NN data element, see ISO/IEC TS 23220-4.
6.3.2.3 Relationship attributes
This subclause specifies data elements which express attributes for describing a relationship with another
person entity and requirements for values of each data element. Legal definitions of these data elements are
up to the profile.
Table 6 describes a set of data elements to express relationship attributes. When an implementation of this
document uses a data element from Table 6 under the “org.iso.23220.1” namespace, these shall implement
the definition and encoding as defined in Table 6.
If an implementation of this document wants to use a data element from Table 6, encoding of values shall be
specified in each namespace.
Table 6 — Data elements for relationship attribute
Data element Data element identifier Description Encoding
Father father The father of the holder tstr
Mother mother The mother of the holder tstr
Parent parent A parent of the holder tstr
Son son The son of the holder tstr
Daughter daughter The daughter of the holder tstr
Brother brother The brother of the holder tstr
Sister sister The sister of the holder tstr
Sibling sibling The sibling of the holder tstr

© ISO/IEC 2024 – All rights reserved
TTaabblle 6 e 6 ((ccoonnttiinnueuedd))
Data element Data element identifier Description Encoding
Spouse spouse The spouse of the holder tstr
Father-in-Law father_in_law The father-in-law of the holder tstr
Mother-in-Law mother_in_law The mother-in-law of the holder tstr
Parent-in-Law parent_in_law The parent-in-law of the holder tstr
Son-in-Law son_in_law The son-in-law of the holder tstr
Daughter-in-Law daughter_in_law The daughter-in-Law of the holder tstr
Child-in-Law child_in_law The child-in-law of the holder tstr
Parental authority parental_authority The parental authority of the holder tstr
Legal representative legal_representative The legal representative of the holder tstr
Agent agent The voluntary agent of the holder tstr
6.3.3 Meta-attribute for issuer entity
This subclause specifies data elements which express attributes for describing an issuer and requirements
for values of each data element.
Table 7 describes a set of data elements to express attributes for issuer. When an implementation of this
document uses a data element from Table 7 under the “org.iso.23220.1” namespace, these shall implement
the definition and encoding as defined in Table 7.
If an implementation of this document wants to use a data element from Table 7 that changes the definition
or the encoding, it shall be used with a different namespace.
Table 7 — Data e
...