ISO/IEC 30108-1:2026

International
Standard
ISO/IEC 30108-1
Second edition
Biometrics — Identity attributes
2026-01
verification services —
Part 1:
IAVS services
Biométrie — Services de vérification d’attributs d’identité —
Partie 1: Services IAVS
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: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
© ISO/IEC 2026 – All rights reserved
ii
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms. 2
5 Conformance . 3
6 System Context . . 3
6.1 Service-Oriented Architectures .3
6.2 IAVS architecture .4
6.3 Identity models .5
6.4 Identity databases .7
6.5 IAVS Implementation Considerations .8
6.6 Structure of this document .9
7 Identity Attributes Verification Services . 9
7.1 General .9
7.2 IAVS Interface XML Schema .10
7.3 Primitive Services .11
7.3.1 AddSubjectToGallery .11
7.3.2 CheckQuality .11
7.3.3 ClassifyBiometricData . 12
7.3.4 CreateEncounter . 13
7.3.5 Create Subject .14
7.3.6 DeleteBiographicData .14
7.3.7 DeleteBiometricData . . 15
7.3.8 DeleteDocumentData . 15
7.3.9 DeleteEncounter .16
7.3.10 DeleteSubject .16
7.3.11 DeleteSubjectFromGallery.17
7.3.12 GetIdentifySubjectResults .17
7.3.13 IdentifySubject .18
7.3.14 ListBiographicData.19
7.3.15 ListBiometricData . 20
7.3.16 ListDocumentData .21
7.3.17 PerformFusion . .21
7.3.18 QueryCapabilities . 22
7.3.19 RetrieveBiographicData . . . 23
7.3.20 RetrieveBiometricData . 23
7.3.21 RetrieveDocumentData .24
7.3.22 SetBiographicData . 25
7.3.23 SetBiometricData . 26
7.3.24 SetDocumentData . 26
7.3.25 TransformBiometricData .27
7.3.26 UpdateBiographicData . 28
7.3.27 UpdateBiometricData. 28
7.3.28 UpdateDocumentData . 29
7.3.29 VerifySubject . 30
7.4 Aggregated Services .31
7.4.1 Delete .31
7.4.2 Enrol .32
7.4.3 GetDeleteResults . 33
7.4.4 GetEnrolResults . 33

© ISO/IEC 2026 – All rights reserved
iii
7.4.5 GetIdentifyResults . 34
7.4.6 GetUpdateResults . 34
7.4.7 GetVerifyResults . 35
7.4.8 Identify . 35
7.4.9 RetrieveData .37
7.4.10 Update .37
7.4.11 Verify . . 38
8 Data Elements and Data Types .39
8.1 Biographic Data. 39
8.1.1 Biographic Data Type . 39
8.1.2 Biographic Data Item Type . 40
8.1.3 Biographic Data Set Type . 40
8.1.4 Biographic Data List Type .41
8.2 Biometric Data .41
8.2.1 CBEFF BIR Type .41
8.2.2 CBEFF BIR List Type .42
8.2.3 Biometric Data Element Type .43
8.2.4 Biometric Data List Type .43
8.2.5 Candidate Lists . 44
8.2.6 Candidate List Type .45
8.3 Capabilities .45
8.3.1 General .45
8.3.2 Capability Type .45
8.3.3 Capability List Type . 50
8.4 Document Data . 50
8.4.1 Document Data Type . 50
8.4.2 Document Data List Type .51
8.5 Fusion Information .51
8.5.1 General .51
8.5.2 Fusion Information Type .51
8.5.3 Fusion Information List Type . .52
8.6 Other Data Types . 53
8.6.1 Encounter Category Type . 53
8.6.2 Encounter List Type . 53
8.6.3 Information Type . 53
8.6.4 List Filter Type . 54
8.6.5 Option Type . 54
8.6.6 Processing Options Type . 55
8.6.7 Token Type . 55
9 Error Handling and Notification .56
9.1 Overview . 56
9.2 Successful Service Calls . 56
9.3 Error Condition Codes . 56
10 Security .57
Annex A (normative) Conformance requirements .59
Annex B (informative) Sample biographic data format references .68
Annex C (informative) Example usage scenarios .69
Annex D (informative) Example Encounter Scenarios . 76
Bibliography .79

© ISO/IEC 2026 – All rights reserved
iv
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 37, Biometrics.
This second edition cancels and replaces the first edition (ISO/IEC 30108-1:2015), which has been technically
revised.
The main changes are as follows:
— Biometric Identity Assurance Services (BIAS) have been renamed to Identity Attributes Verification
Services (IAVS), including in the title of this document;
— the use of encounters has been clarified, and the encounter-based parameters in the services have been
debugged;
— fusion identity list type has been removed;
— the information about capabilities has been restructured;
— the lack of definition of namespaces related to the use of ISO/IEC 19785-3, has been resolved.
A list of all parts in the ISO/IEC 30108 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
v
Introduction
This document defines the architecture, operations, data elements, and basic requirements for Identity
Attributes Verification Services – a framework for the implementation of generic, biometric-based identity
services within a service-oriented environment. An identity in the context of IAVS comprises a subject,
biographic data, and biometric data. Other parts are intended to define specific IAVS implementations (or
bindings) within specific environments, for example, Simple Object Access Protocol (SOAP) Web services.
IAVS services are generic in nature, being modality neutral and not targeted at any particular business
application. These services include those related to identity data management, transformation, and
biometric comparison. Services are invoked by an IAVS requester and implemented by an IAVS service
provider (responder). This document does not prescribe the architecture or business logic of either the
requester or service provider.
Two categories of identity services are defined in this document – primitive and aggregate. Primitive
services are more atomic and well-defined, whereas the aggregated services tend to be higher level and
enable more flexibility on the part of the IAVS service provider.
Two identity models are also defined in this document – person-centric and encounter-based. Person-centric
systems maintain a single up-to-date record (set of data) for a given subject, whereas an encounter-based
system retains data related to each interaction the subject has with the system.
This document represents a version of IAVS subsequent to that previously standardized by INCITS and OASIS,
under the name "Biometric Identity Assurance Services (BIAS)". In this second edition of the document, it is
therefore denoted as Version 3.0.

© ISO/IEC 2026 – All rights reserved
vi
International Standard ISO/IEC 30108-1:2026(en)
Biometrics — Identity attributes verification services —
Part 1:
IAVS services
1 Scope
This document defines biometric services used for identity assurance that are invoked over a services-
based framework. It provides a generic set of biometric and identity-related functions and associated data
definitions to allow remote access to biometric services.
The binding of these services to specific frameworks is not included in this document but is the subject of
other parts of the ISO/IEC 30108 series.
Although focused on biometrics, this document includes support for other related identity assurance
mechanisms such as biographic and document capabilities. IAVS is intended to be compatible with and used
in conjunction with other biometric standards as described in Clause 6.
Specification of biometric functionality is limited to remote (backend) services. Services between a client-
side application and biometric capture devices are not within the scope of this document.
Integration of biometric services as part of an authentication service or protocol is not within the scope of
this document.
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 2382-37, Information technology — Vocabulary — Part 37: Biometrics
ISO/IEC 19785-1, Information technology — Common Biometric Exchange Formats Framework — Part 1: Data
element specification
ISO/IEC 19785-3, Information technology — Common Biometric Exchange Formats Framework — Part 3:
Patron format specifications
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO/IEC 2382-37 and the following
apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/

© ISO/IEC 2026 – All rights reserved
3.1
encounter
individual interaction within the system related to a specific subject, either for enrolment or for recognition
Note 1 to entry: The event may involve collection of biographic, biometric, document, contextual data (or a combination
of them) during an enrolment or recognition interaction.
3.2
encounter-centric system
system that supports encounter processing, maintaining a one-to-many relationship between subjects and
encounters, and which does not necessarily contain a single, unique set of information for each subject
3.3
gallery
group of subjects, related by a common purpose, designation, or status
EXAMPLE A watch list, or a set of subjects entitled to a certain benefit
3.4
identity assurance
process of establishing, determining, confirming, or any combination of those three actions, a subject
identity
3.5
merge
combination of biometric data during the process of updating an enrolment record
Note 1 to entry: The “merge” operation is implementation specific; however, it may include either adding a new sample
to a multi-sample record or performing some level of biometric fusion (e.g. sample or feature level fusion).
3.6
person-centric model
identity model in which a single primary record is maintained on a subject, which is updated over time
when additional, newer, or better biographic, biometric or document information becomes available (or
any combination of them), and which does not maintain separate historical data records for each system
encounter with the subject
3.7
subject
person who is known to an identity assurance system
Note 1 to entry: The person can also be a biometric capture subject or biometric data subject, but this is not the case
in all situations.
4 Symbols and abbreviated terms
ABIS automated biometric identification system
IAVS identity attributes verification services
BIR biometric information record
CBEFF common biometric exchange formats framework
ESB enterprise service bus
FBI Federal Bureau of Investigation
ID identity/identification/identifier
IDMS identity management system

© ISO/IEC 2026 – All rights reserved
NGI next generation identification
OASIS Organization for the Advancement of Structured Information Standards
SOA service-oriented architecture
SOAP messaging protocol specification for exchanging structured information in the implementation
of web services in computer networks (originally an acronym for simple object access protocol)
TWIC transport worker identification card
5 Conformance
In order for systems/components to claim conformance to this document, they shall fulfil the conformance
requirements specified in Annex A.
6 System Context
6.1 Service-Oriented Architectures
Clause 6 provides an overview of SOAs, the IAVS architecture, and IAVS implementation considerations.
SOAs are software architectures in which reusable services are deployed onto application servers and
then consumed by clients in different applications or business processes. They are intended to decouple
the implementation of a software service from the interface that calls that service. This allows clients of
a service to rely on a consistent interface regardless of the implementation technology of the service (see
Annex C).
Biometric services are one of the types of services that can be provided over such a remote interface in a
distributed information system across a collection of networks. This can occur in a 2-tier, 3-tier, or N-tier
environment. Figure 1 shows a simple 3-tier architecture.
Presentation layer
Client
Web browser Other
application
Services
Application logic layer
Resource management layer
Figure 1 — Simple 3-Tier Architecture
In Figure 1, IAVS services are defined between the application logic layer and the resource management
layer.
© ISO/IEC 2026 – All rights reserved
Examples of resources that are of interest include the following:
— a fingerprint verification server;
— a 1:N iris search engine;
— a facial biometric watch list;
— a criminal or civil ABIS;
— A name-based biographic identity database;
— An archive of biometric identifiers;
— A population of subjects.
In this document, a generic set of services is defined to allow clients to remotely access and manage these
capabilities. To the extent possible, domain specific implementations are to be avoided.
NOTE This document is intended to support a wide variety of application domains which can include government
(e.g. background checking, border management, and criminal justice), enterprise (e.g. logical access control), and
commercial biometric identity management implementations (e.g. employee databases).
Services are well defined, self-contained modules that provide standard business functionality and are
independent of the state or context of other services. Services can be easily assembled to form a collection of
autonomous and loosely-coupled business processes.
It is not the intention of this document that specific business logic be instantiated within the service
definitions – this logic is more appropriate within the application logic layer – either in the higher-level
system initiating the series of requests, or within the middleware (e.g. an enterprise service bus [ESB],
workflow manager, or biometric middleware) as appropriate. To do so would necessarily make the interface
less generic, modular, and flexible and require that the interface be updated each time the logic changed,
defeating one of the primary purposes of the services architecture.
The services to be defined are not targeted at a particular SOA implementation or framework. Instead, they
are defined in such a manner as to be able to be utilized within any such architecture. This is accomplished
by separately defining (in another standard) the bindings to that architecture/implementation. For example,
[7]
Web services bindings are defined in the OASIS BIAS Messaging Protocol, and RESTful implementation is
defined in ISO/IEC 30108-2.
6.2 IAVS architecture
The IAVS architecture consists of the following components:
— IAVS services (interface definition);
— IAVS data (schema definition);
— IAVS bindings (defined outside this document).
The IAVS services expose a common set of operations to external requesters of these operations. These
requesters may be an external system, a Web application, or an intermediary. The IAVS services themselves
are platform and language independent. The IAVS services may be implemented with differing technologies
on multiple platforms.
Figure 2 depicts the IAVS services within an application environment. IAVS services provide basic biometric
functionality as modular and independent operations which can be assembled in many different ways to
either perform or support, or both, a variety of business processes. IAVS services can be either publicly
exposed directly or utilized indirectly, or both, in support of a service-provider’s own public services.

© ISO/IEC 2026 – All rights reserved
Client user/system
Client
Service bindings/
Data
interfaces
Service provider
business application system
IAVS services
IAVS implementation component
IAVS
implementation
Vendor Vendor Vendor
adaptor adaptor adaptor
BioAPI framework
Identity Identity Identity Identity
assurance assurance assurance assurance
resource resource resource resource
#1 #2 #3 #4
Key
service provider wrapper (optional)
IAVS component
service
Figure 2 — IAVS Application Environment
6.3 Identity models
Some identity systems are person-centric and others are encounter-centric systems. That is, some base
transactions on a unique identifier associated with an individual human being while others track “biometric
encounters” which may or may not be linked through such an identifier. Figure 3 provides context to further
explain these concepts.
© ISO/IEC 2026 – All rights reserved
Timestamp X Encounter #4
subject ID:1 encounter ID: 4
Updated
Encounter #3
biographics
Timestamp X
encounter ID: 3
subject ID:1
Biographics
Encounter #2
Biographics
encounter ID: 2
Timestamp X
subject ID:1 Encounter #1
encounter ID: 1
Biographics
Biographics
Identity
Identity
assurance
assurance
resource
resource
Person-Centric Encounter-Centric
— One set of information for each subject — Encounters are grouped by the Subject ID
— New information updates and replaces any ex- — All encounter information is preserved
isting information
Figure 3 — Person-Centric and Encounter-Centric Views
In a person-centric model, as new data are received for a given subject, are either added (if they do not
already exist) or replace previous data (if they already exist). For example, referring to Figure 3, if the initial
enrolment contains biographic data and a set of fingerprints these are stored. If subsequently, a photo is
received, it is added to the person-centric record. If later new biographic data are received (e.g. new address),
they replace the originally stored data. In this way, the primary subject record is continuously updated
to contain the most accurate, current information with (in general, but not exclusively) no need to retain
historical data. This model is used, for example, in access control type systems.
An encounter-centric model, in comparison, retains all data received for every interaction with the subject.
Initially, the subject record is created and populated with enrolment data (for example, fingerprint, facial
photo, and biographic data as shown in Figure 3). Subsequently, if new fingerprint data are captured for that
subject (during an interaction event, or encounter), a new encounter is created containing all data obtained
during that encounter. The system now has two encounters for that subject. Later, in a third encounter,
fingerprint and biographic data are captured and stored, in addition to the data previously stored in
encounters one and two. Encounter IDs, unique to a subject, are assigned to each encounter. This model is
used, for example, in case management type systems.
EXAMPLE In a border entry/exit system, a person is enrolled in the system the first time they enter the country.
A subject is created and biometric and biographic data are set, following any required identification operation(s). This
represents the first encounter. Subsequently, when the person crosses the border in the future, their passport number
is used as a claim of identity, a verification of that identity is performed, as well as any identification operations.
Biometric and biographic data collected during this interaction is retained as another separately identified encounter
(see Annex C for additional use cases.).
Encounters can be classified as either enrolment or recognition encounters. Figure 4 depicts an example in
which both biographic and biometric data are submitted during different types of encounters. Diagrams for
additional scenarios are found in Annex D.

© ISO/IEC 2026 – All rights reserved
Time
Time
Set biographic data Set biometric data
Biographic Biometric data
Set biometric data
data 2 2
Biometric data
(Enrolment) (Enrolment)
Set biographic data 1
(Enrolment)
Biographic
data 1
(Enrolment)
Set biometric data
EncounterID
EncounterID
Biometric data
= 51
= 50
(Recognition)
EncounterID
= 52
Comparison- SubjectID
engine DB =10001
Figure 4 — Example of Encounter Types
NOTE Encounter type can be set using the CreateEncounter operation. In addition, the "Purpose" field within
the CBEFF header can be set to indicate this (See 8.2 for more information on biometric data).
6.4 Identity databases
Biometric systems frequently include both a primary database as well as a comparison engine database.
The former is used to store all identity information (including encounter information). The latter, however,
usually contains a single set of biometric reference data, even within an encounter-based system and
minimal, if any, biographic data. Systems use various schemes to determine which data to include within the
biometric engines and when that data are updated. Figure 5 provides an example of how these databases
may exist within a IAVS implementation. However, in some systems, the primary and comparison engine
databases may be one and the same.
Within this document, all services (with the exception of comparison services, such as IdentifySubject)
operate upon the primary database unless otherwise stated, with any associated updates to the comparison
engine databases (when separate) left to the policies of the IAVS service provider.

© ISO/IEC 2026 – All rights reserved
Figure 5 — Example Primary/Engine Database Implementation
EXAMPLE In the previous example for a border entry/exit system (6.3), fingerprint, face, and iris biometric data
is collected on the first encounter. All information is stored in the primary database. Additionally, selected fingerprint
and iris data are processed into templates and stored within the appropriate comparison engine database. During the
second encounter, only the data required for verification and identification are collected, and these data are stored
in the primary database. Templates are generated and used to perform the comparison operations. Based on service
provider policy, following successful verification, it is found that the left index and ring fingerprints are of better
quality than those collected during the first encounter and the engine database is updated with these fingerprints
(replacing the original templates).
6.5 IAVS Implementation Considerations
Biometric services and the applications which use them, particularly in an identity assurance context, have
unique characteristics which are summarised below:
— Some services can be performed very quickly while others (such as a 1:N identification within a large
population) can take considerable time (on the order of hours) to complete. Therefore, the interface
should support both synchronous and asynchronous operations;
— Biometric operations may be singular or multi-biometric.
Biometric data are in nearly all cases considered personal information and thus privacy protection is always
a consideration.
— Before a biometric, biographic or document (or any combination of them) data transaction occurs
between two different entities, the terms and conditions of the use of the data should be negotiated and
made transparent. The following questions may be addressed:
— Who will be the recipient of the data to be shared?
— For what purpose(s) can the recipient use these data?

© ISO/IEC 2026 – All rights reserved
— Who/what authorizes these data to be shared with the recipient for this purpose?
— For how long may the recipient retain the data?
— How is the data required to be destroyed at the end of a retention period?
— May the recipient share these data with other entities? If so, with whom? For what purpose(s)? For
how long may the third party retain the data?
— A recipient would later have to understand what they are accepting and the terms and conditions of the
agreement.
NOTE 1 Implementers can consider implementation of a Biometric Policy (BP) or Biometric Practice Statement
(BPS0 as defined
...