
for this purpose must be captured (or attempted to be
captured) from all participants – otherwise, the pur-
pose of such checking is defeated. Another impor tant
consideration for credential-based schemes is which
biometrics will be stored on the credential itself, espe-
cially considering space limitations and data transfer
rates of the card. This may constrain the number,
types, and formats of biometric data to be held. For
example, some image data (even compressed) may be
too large to be feasibly considered, or if used, may
further limit the inclusion of other biometr ics. If
fingerprint data are to be included, the number and
selection of fingers must be determined.
Most registered traveler systems use 1:1 biometric
verification; however, it is possible to use a 1:N identi-
fication technology (e.g., iris recognition). In this case,
no claim of identity is made. The participant merely
presents his or her iris(es) at the kiosk and this is
matched against all other participants’ records, result-
ing in an identification (identity returned as a result of
a match) or a no-match. This is usually performed
using a central server model to avoid the need to
duplicate the datab ase and protect all copies.
Today’s systems are generally built around service-
oriented architectures (SOA) taking advantage of the
internet, existing SOA tools, and the many benefits of
this architecture. These include service requester/pro-
vider decoupling, modularity, scalability, and compo-
nent reuse. It is the basis of most large enterprise
architectures and supports business process orchestra-
tion (BPO) workflow implementation, usually as part
of an enterprise service bus (ESB).
Interoperability
In a nonfederated, single operator, closed RT system,
interoperability is not generally an issue. However, in a
federated system, this is critical as the various system
components must be able to properly function and
interact with one another. Areas in which interopera-
bility are most critical include:
Intrasystem (inter-subsystem) interfaces
Card edge and data model
Security
Examples of intersubsystem interfaces include
those between an enrollment station/system and the
central Identity Management System (IDMS), between
the IDMS and the STA/adjudication agency, and
between the ID MS and the verification station/system.
The enrollment system must transmit collected ‘‘en-
rollment packages’’ to the IDMS for processing. The
data and messaging formats as well as the communica-
tion protocols must therefore be defined. This includes
the format of the biometric data. It is preferred that the
submitted biometric information be in raw image for-
mat with minimal compression; however, some pre-
processing and compression are usually required. For
example, fingerprint data are normally transferred as
three ‘‘slap’’ images in ANSI/NIST ITL1–2000/7 Type-
14 record format using WSQ compression [5]. Mes-
saging protocols are often Web services based, using a
‘‘SOAP over HTTP’’ XML-based implementation. In
addition to the basic set of messages required to per-
form an enrollment, additional messaging is required
to handle a host of error conditions and administrative
needs. These include those related to updates, fees, and
revocation.
With respect to an interoperable credential, the
challenge in a federated system is that a credential
produced by one service provider can be reliably and
securely read and verified by a different provider. This
generally requires a common form factor (e.g., ISO
card), a common ‘‘card edge’’ or card interface/com-
mand set, and a common data model. The card appli-
cation must be accessible and the security mechanisms
usable by all authorized entities. A good model for this
is the US PIV program already mentioned and the
associated technical guidance, most notably NIST
SP800–73 [6]. As an alternative, systems can leverage
the e-Passport as an inte roperable, biometrically-en-
abled credential, w ithout the lost and logistics of issu-
ing another. Common biometric data formats are also
critical for interoperable use across multip le airport
kiosks. For example , fingerprint data may be stored
as ISO/IEC 19794–2 minutiae templates [7]. See also
the chapter on Standardization for more information
on biometric data interchange formats and technical
interfaces.
Security is important in all RT systems, but
becomes a bit trickier in federated systems due to the
key management challenges. The intersubsystem mes-
sages should be signed and either encrypted or passed
via an encrypted channel (i.e., SSL/TLS) using stan-
dard cryptographic protocols. Biometrics on a creden-
tial can be protected by one of the following means:
PIN protection, biometric data encry ption, and (card/
reader) mutual authentication. In all the cases, the
biometrics should be digitally signed either directly or
Registered Traveler
R
1115
R