Daon ‐ your trusted Identity Partner

Workshop on Biometrics US-India Standards & Conformance Cooperation Program

How to Use Standards Effectively

Catherine J. Tilton 22 July 2010

Adoption

2

What does “standards adoption” really mean?Willingness of vendors to build products/systems to the spec

BSPs/SDKs, applications, tools, middleware, devicesCustomer demand

Reflected in procurementsReferences in other standards/documentsIncorporation into larger architecturesVisibility/awareness

Goals

3

What is the purpose of incorporating standards?What does on “open, standards-based” system buy you?

For any given technology, industry standards assure the availability in the marketplace of multiple sources for comparable productsThey foster wide spread utilization of the technologyThey reduce time-to-marketThey facilitate interchange and /or interoperabilityThey reduce risk to integrators and end usersThey reduce vendor “lock-in” effectThey are a sign of industry maturity

The wrong way

4

Inserting “laundry lists” of standards within an RFP to “cover all the bases”Copying lists of standards from other procurement specificationsNo clear goals – “sounds good”Broadly applied – untargeted, untailoredAssumption that standards alone will ensure interoperabilityFailure to appreciate the associated trade-offs

The right way

5

Understand what you are trying to achieve and determine if/how standards can help do soApply standards thoughtfully – consider:

Which standards apply to what part of the systemWhich parts of the standard apply and to what extentUnderstand costs/benefitsTailor as appropriateHow to verify conformance/interoperability

Applicability

Client Component

Client Application

Biometric Software(Capture/Assessment/Processing) 

Server Component(Central system)

BackendApplicationNetwork

BiometricMatcher

Biometric Software(Processing, Fusion, Decision) 

EFTS App F

ISO/INCITSANSI/NISTData Fmts

BioAPI / CBEFF

BIAS, BIP, ITU‐TEFTS/EBTS, NIEM

Sample QualityNFIQ, WSQ

Applic. Profiles,Cross Juris./Soc.

BioAPI / CBEFF

Perf. TestingSC17, ICAO

BiometricSensor(Device)

Smartcard/MRTDReader

Fusion TR, Fmt

BiometricDB

ISO/INCITSANSI/NISTData Fmts

SC27/TC68 security 

Standards ‘overlaps’

7

Law EnforcementANSI/NIST-ITL 1-2000 /2007XML version (2-2008)FBI EFTS/EBTSDoD EBTSInterpol INT-INIEM

Commercial/CivilANSI INCITS

Technical interfacesData formatsPerformance testing

ISO/IECe.g., 19794-x

OASISBIAS

Understand the domain of use

Tailoring

8

Many standards contain “options”Sometimes leads to interoperability problems

Within a particular application/domain, these options can be narrowed through “tailoring” or “profiling”

Further constrain the implementation spaceIdentify which options shall always/never be usedSpecify valid values/range of valuesWhen certain options/values should be usedCommon interpretations of ambiguous requirementsAny domain specific extensions

Examples:EBTS & Interpol Implementation are “application profiles” of ANSI/NIST-ITL 1-2000/7INCITS & ISO profiles for specific application domainsProgram specific system specifications

Trade-offs

Standards sometimes criticized as being the “lowest common denominator”

Some validity to thisInteroperability is not always free

Cost: possible loss/degradation of performance, low level control, etc.

Flexibility Optimization

it is almost always possible to build a “hardwired”, highly customized implementation that is faster & more efficient

than a standard, interoperable one

Program considerations

10

AwarenessWhat standards exist, are the engineers familiar

RequirementsWhen to require which standard and why

AnalysisTailoring, allocationCompatibility/integration with system architecture

AlternativesProduct availability, trade-offs

ModificationsLegacy subsystems

SchedulePhase in, builds/increments

System documentation

Use of standards should be part of the overall systems engineering process

Barriers & challenges

11

Lagging/hesitant standards adoptionGovernance issuesLegacy, mission critical, operational systemsMigration path not always clean“Too many” standardsInterface scalability“Rice bowl” issuesPrivacy & security considerationsEducation/awareness/terminologyAddressing multiple levels of interoperabilityAppreciation of importanceData quality issuesSyntactic vs semantic compatibilityLack of conformance testing

Example of ‘doing it right’

12

USG ‘Personal Identification Verification’ (PIV) programIssues biometric credentials to all federal employeesImplementation of HSPD-12 (Homeland Security Presidential Directive)

NIST tasked with developing technical specificationsFIPS 201, “Personal Identity Verification (PIV) of Federal Employees and Contractors”

Companion documentsSP 800-73, Interfaces for Personal Identify VerificationSP 800-76, Biometric Data Specification for Personal Identity VerificationSP 800-78, Cryptographic Algorithms and Key Sizes for Personal Identity Verification

Conformance program

NIST SP 800-76

13

Biometric “profile” for PIVEnrollment:

NIST ITL1-2000 fingerprint images (tenprint, flat/rolled), EFTS records, App G sensorsNFIQ quality metricsBackground checksFacial photo (required): INCITS 385, JPEG 2000 compression (<= 15:1)

On-card biometricsCBEFF structure/patron formatFingerprints: 2 INCITS 378 minutiae templatesFacial photo (optional): INCITS 385, JPEG2000 compression (ROI, <= 24:1)Digital signature specified

Finger image archive: INCITS 381

PIV Fingerprint Data Flow

Ten-print Fingerprint Acquisition (Table 1)

Quality Control(Table 2)

Fingerprint Images

INCITS 378 Generator(Sec. 3.3)

INCITS 381 Generator(Sec. 3.4)

ANSI-NISTType 4 or Type 14

Generator(Sec. 3.5)

PIV Card(800-73)

Re-acquire

Registration Authority or Agency

FBIBackground CheckTransmit

Retain

Pre-PIV Practice

Store

Segmentation PIV Card Re-issuance[FIPS, 5.3.2.1]

Fail

Pass

Conclusion

15

Standards can be of great value in achieving a programs interoperability and interchangeability goals, if …

they are thoughtfully and consistently applied.

Thank You !

16