WG3 report on Biometric Data Format and Related Standards

WG3 report on Biometric Data Format and Related Standards
Christoph Busch - ISO/IEC JTC1/SC37 WG3 Convenor - Darmstadt

Meetings Winchester 2013-04-22 to 2013-04-26
THANKS to the UK for hosting us Darmstadt to Christoph Busch 2

Agenda Context Need for standardization
Status of Biometric Data Formats Trends Christoph Busch 3

Context Christoph Busch 4

Biometric Standardisation
Joint Technical Committee One International Electrotechnical Commission International Civil Aviation Organization International Organization for Standardisation SC 17 Cards & Personal Identification TC 68 Banking, Securities Financial services SC 27 IT Security Techniques SC 37 Biometrics SC37 to TC68 SC 37 Formal Liaisons Christoph Busch 5

ISO/IEC SC37 Biometrics Established by JTC 1 in June 2002 to ensure
a high-priority, focused and comprehensive approach worldwide for the rapid development of formal generic biometric standards Scope of SC37 “Standardization of generic biometric technologies pertaining to human beings to support interoperability and data interchange among applications and systems. Generic human biometric standards include: common file frameworks; biometric application programming interfaces; biometric data interchange formats; related biometric profiles; application of evaluation criteria to biometric technologies; methodologies for performance testing and reporting and cross jurisdictional and societal aspects” Next meeting: July, 2014 registration: Christoph Busch 6

Working Group 3 Title: Biometric Data Interchange Terms of Reference:
Convenor: Christoph Busch (Germany) Terms of Reference: To consider the standardisation of the content, meaning, and representation of biometric data formats which are specific to a particular biometric technology. To ensure a common look and feel for Biometric Data Structure standards, with notation and transfer formats that provide platform independence and separation of transfer syntax from content definition “Getting equipment to understand each other” Christoph Busch 7

Onion Layers Layer 1: BDIR Digital representations of biometric characteristics Layer 2: LDS CBEFF Meta-data Layer 3+4: System properties Security Performance Layer 5: BioAPI, BIP System Integration SC37 WG3 SC37 WG2 CBEFF SC27 ( Availability, Integrity) SC Card based SC37 WG 2 BioAPI SC37 WG4 Biometric Profiles Security SC37 WG5 Performance SC37 WG6 Biometric Data Interchange Formats LDS / File Framework Security Attributes Biometric Interfaces Biometric System Properties Societal and Jurisdictional Issues Harmonized Biometric Vocabulary SC37 WG1 Christoph Busch 8

Onion Layers Layer 1: BDIR Biometric Data Interchange Record SC37 WG3 SC37 WG2 CBEFF SC27 ( Availability, Integrity) SC Card based SC37 WG 2 BioAPI SC37 WG4 Biometric Profiles Security SC37 WG5 Performance SC37 WG6 Biometric Data Interchange Formats LDS / File Framework Security Attributes Biometric Interfaces Biometric System Properties Societal and Jurisdictional Issues Harmonized Biometric Vocabulary SC37 WG1 Biometric Data Interchange Formats Christoph Busch 9

Levels of Development? Progression levels Issues to consider:
Working Draft (WD) Committee Draft (CD) Darft International Standard (DIS) Final Draft International Standard (FDIS) International Standard (IS) Issues to consider: Need for mature technology Decisions are made on consensus Commenting periods Potentially multiple loops at one level Need to progress Five year revision cycle Christoph Busch 10

Levels of Development? Technical Report Christoph Busch 11

Harmonized Biometric Vocabulary
ISO/IEC :2012 Information technology - Vocabulary -Part 37: Biometrics: Christoph Busch 12

Harmonized Biometric Vocabulary
ISO/IEC-Vocabulary: Christoph Busch 13

Need for Standardization
Christoph Busch 14

Deployment of Biometric Passports
489 million ePassports issued by 101 states (ICAO estimate as of February 2013) Source: ICAO Christoph Busch 15

Border Control in Frankfurt - EasyPASS
Source: BSI Christoph Busch 16

Border Control in Frankfurt - EasyPASS
Source: BSI Source: BSI Christoph Busch 17

Border Control in Europe
Source: BSI Christoph Busch 18

Biometric Data Interchange Formats
Christoph Busch 19

First Generation Format Standards
:2006 -2: 2005 -3: 2006 -4: 2005 -5: 2005 -6: 2005 -7: 2007 -8: 2006 -9: 2007 -10: 2007 All parts binary encoding The Family: Biometric data interchange formats Christoph Busch 20

19794-1 AMD1 Conformance testing methodology
Generation 2 of ISO/IEC 19794 G1 :2006 -2: 2005 -3: 2006 -4: 2005 -5: 2005 -6: 2005 -7: 2007 -8: 2006 -9: 2007 -10: 2007 All parts binary encoding G2 :2011 AMD2 XML Framework AMD1 Conformance testing methodology -2: 2011 -4: 2011 -5: 2011 -6: 2011 -7: 201x -8: 2011 -9: 2011 -11: 2013 -13: 201x -14: 2013 -2: 201x -4: 201x -5: 201x -6: 201x -7: 201x -9: 201x the semantic (i.e. general header / structure of representation header) equivalent for binary encoded and XML encoded parts in G2 Christoph Busch 21

Part 1: Framework ISO/IEC 19794-1:2011
Describes what is commonly applied for biom. data formats Specifies General aspects for the usage of biometric data records Processing levels and types of biometric data structures Naming convention for biometric data structures Coding scheme for format types 2nd edition (G2) revises ISO/IEC :2006 G1 not canceled but maintained in the ISO and IEC catalogue Clause 3 includes terms and definitions that are used in multiple parts of ISO/IEC 19794 Clause 12 is added to describe coding schemes for general headers and representation headers that are harmonized across all parts of ISO/IEC 19794 Christoph Busch 22

Part 2: Finger minutiae data
ISO/IEC :2011 Ridges and valleys, core and delta Ridge bifurcation and ridge endings finger minutiae Encoded information Minutia point (coordinates x,y) Minutia direction (angle θ) How many finger minutiae, and how many ridges between each pair of them? A very mature technology This Standard defines a data structure (called a Biometric Data Block format) that contains a digital record of the features that can be identified and extracted from from a digitised fingerprint, and recorded. These features are called finger minutiae. Most people are aware that I you examine finger you will a pattern of ridges and values, with points where a single ridge splits into two ridges, creating a new value (ridge bifurcation) or where a ridge ends, with the valleys on either side merging into a single value. The points where this occurs are called finger minutiae. The slide shows a typical fingerprint: By identifying these minutiae, and then recording their position relative to each other, particularly a count of the number of ridges between pairs of them, a very compact digital representation can be obtained which can be used to compare two fingerprints to see if they are virtually certain to have been produced by the same individual. The use of finger minutiae is a very mature technique for matching fingerprints. The Standard specifies how the minutiae are to be identified, and their relative positions recorded, but most importantly the data format to be used to record this information. (Note that this is not a full digital image of the finger-print, merely a record of the relative positions of its minutiae, but it is sufficient for very accurate matching. This Standard enables equipment from one vendor to produce a finger minutiae data block format that can be compared directly with a finger minutiae data block produced by equipment from a different vendor without any collaboration between the two vendors (open interworking). Associated matching algorithms are not standardised, but there are examples and guidelines for matching algorithms in an Annex.. Normally a BDB would be "captured" (produced) when a human subject (a person) is "enrolled" (registered with an organization), and archived (stored) with some additional meta-data about the time of capture, the equipment used, and so on. It might be (only) archived on a smart-card to be carried by the human subject, or it might be (only) archived on a central database, or it might be archived on both. These options for archiving are subject to privacy concerns that might be expressed by the individual or in national legislation, and to the need to maintain backups. This international standard has two main data formats. The first provides rapid and easy matching, the second is a more compressed format that is more suitable where the BDB is stored on a smart card (and the matching is perhaps performed by the card – MOC). Source: ISO/IEC Christoph Busch 23

Further information that is encoded Number of finger representations in one record Capture device (to identify the equipment and its certification) Size of the scanned image (in pixel) Horizontal and vertical spatial sampling rate (resolution) Finger header: Finger position, Impression type The finger position shall be recorded in one byte. The codes for this byte shall be as defined in Table 2 (imported from ANSI/NIST-ITL , see Bibliography). The view number shall be recorded in four bits. If more than one finger minutiae record in a general record is from the same finger, each minutiae record shall have a unique view number. The combination of finger location and view number shall uniquely identify a particular minutiae record within a general record. Multiple finger minutiae records from the same finger shall be numbered with increasing view numbers, beginning with zero. Where only one finger minutiae record is taken from each finger, this field shall be set to 0. The impression type of the finger images that the minutiae data was derived from shall be recorded in four bits. The codes for this byte are shown in Table 3. These codes are compatible with Table 4 of ANSI/NIST-ITL 12000, “Data Format for the Interchange of Fingerprint Information”, with the addition of the “swipe” type. The “swipe” type identifies data records derived from image streams generated by sliding the finger across a small sensor. Only codes 0 through 3 and 8 shall be used; the “latent” codes are not relevant for this standard. The quality of the overall finger minutiae data shall be between 0 and 100 and recorded in one byte. This quality number is an overall expression of the quality of the finger record, and represents quality of the original image, of the minutia extraction and any additional operations that may affect the minutiae record. A value of 0 shall represent the lowest possible quality and the value 100 shall represent the higher possible quality. The numeric values in this field will be set in accordance with the general guidelines contained in Section of ISO/IEC FCD 19784, “BioAPI Specification”. The matcher may use this value to determine its certainty of verification. Source: ISO/IEC Christoph Busch 24

New in the 2011 revision (this is version 3.0) Reduction of format types: From 10 to 2 format types a Record format and a On-Card-Comparison format Record format type Minutiae record format for 5 or 6 byte (quality) minutia descriptions On-card biometric comparison format type a revised 0x0005, which is ridge ending as „ridge valley bifurcation“ a revised 0x0006, which is ridge ending as „ridge skeleton end points“ Fields added for length of representation, time of capture, ridge ending type, minutiae field length, etc. Expanded quality & device certification information blocks Annex containing three image quality specifications Image quality specification for AFIS systems („FBI“) Image quality specification for personal verification („PIV“) Requirements and test procedures for optical fingerprint scanners („BSI“) Christoph Busch 25

Extended data Open to placing additional data that may be used by the comparison equipment. Ridge count data, Core and delta data (position and angle) or Zonal quality information (quality within a cell) Vendor-defined extended data While the extended data area allows for inclusion of proprietary data within the minutiae format, this is not intended to allow for alternate representations of data that can be represented in open manner. The extended data section of the finger minutiae record is open to placing additional data that may be used by the matching equipment. The size of this section shall be kept as small as possible, augmenting the data stored in the standard minutiae section. The extended data for each finger view shall immediately follow the standard minutiae data for that finger view and shall begin with the Extended Data Block Length field. More than one extended data area may be present for each finger and the extended data block length field will be the summation of the lengths of each extended data segment. The data block length is used as a signal for the existence of the extended data while the individual extended data length fields are used as indices to parse the extended data. Note that the extended data area cannot be used alone, without the standard portion of the minutiae record. While the extended data area allows for inclusion of proprietary data within the minutiae format, this is not intended to allow for alternate representations of data that can be represented in open manner as defined in this standard. In particular, ridge count data, core and delta data or zonal quality information shall not be represented in proprietary manner to the exclusion of the publicly defined formats in this standard. Additional ridge count, core and delta or zonal quality information may be placed in a proprietary extended data area if the standard fioperability. Performance with proprietary data should not be less than with open data. Used for speed up Christoph Busch 26

Part 4: Finger image data
ISO/IEC This part specifies image based encoding of one or more finger images or palm image areas Maximum retention of information from the biometric source Highest level of interoperability No dependability on the comparison algorithm The information consists of a variety of mandatory and optional items, including scanning parameters, compressed or uncompressed images and vendor-specific information Encoded information Images (JPEG, JPEG2000, WSQ) This format is in use in EU-passports This Standard defines a data structure (called a Biometric Data Block format) that contains a digital record of the image of one or more fingers (or of a palm). It specifies how the image is to be acquired, and how it is to be converted to a digital representation, with a full specification of the digital format. This Standard enables equipment from one vendor to produce a finger image data block format that can be compared directly with a finger image data block produced by equipment from a different vendor without any collaboration between the two vendors (open interworking). Associated matching algorithms are not standardised, and are generally company confidential. Normally a BDB would be "captured" (produced) when a human subject (a person) is "enrolled" (registered with an organization), and archived (stored) with some additional meta-data about the time of capture, the equipment used, and so on. It might be (only) archived on a smart-card to be carried by the human subject, or it might be (only) archived on a central database, or it might be archived on both. These options for archiving are subject to privacy concerns that might be expressed by the individual or in national legislation, and to the need to maintain backups. Christoph Busch 27

Part 5: Face image data ISO/IEC 19794-5:2011
Tec Corr 1 and 2 as well as AMD 1 and 2 integrated 3D Face Image Data Interchange Format Conditions for taking photographs for face image data New in G2 for records from video sequences for biometric records at higher spatial sampling rate levels for specification of post acquisition steps cropping, down-sampling, in-plan rotation, adjusting white balance not requiring new image types vs. interpolation, pose correction, age processing etc. requiring a new “post-processed” image type Support for lossless compression (PNG, JPEG 2000 lossless) Christoph Busch 28

Iris Exchange and Interoperability: test reports 2009, 2010
Part 6: Iris image data ISO/IEC :2011 4 new iris image formats, compressible to as little as 2,000 bytes Iris formats are now highly empirically based, thanks to NIST IREX testing results Recommended target record sizes for different applications Recommended compression for different applications Formats differ in their required amount of image pre-processing Original :2005 raw image format retained as one case Iris sample quality ( ) will become normative Annex 2005 Standard Academic papers: critique and proposals for new data formats (2006 – 2008) NIST: IREX-1 Iris Exchange and Interoperability: test reports 2009, 2010 2011 Standard Christoph Busch 29

Part 6: Iris image data One new data format in 19794-6:2011
highly compact iris image, compressed to 2,000 bytes Cropping, and masking non-iris regions, preserves the coding budget Pixels outside the ROI fixed to constant values, for normal segmentation Softening the mask boundaries also preserves the coding budget Interoperability of this vendor-neutral format confirmed by IREX results At only 2,000 bytes, iris images are now much more compact than fingerprints Source: ISO/IEC Christoph Busch 30

Part 6: Iris image data Recommended compression protocols for different applications Source: ISO/IEC Christoph Busch 31

Part 7: Signature/Sign Times Series Data
Revision of ISO/IEC currently at FDIS stage Now 3 binary formats Full format: For general use Compression format (new!): Same amount of information as in full format, but compressed Compact format: For use with smart cards and other tokens; no compression/decompression needed, but less information than in full format Full and compression format contain the harmonized General Header and Representation Headers Source: ISO/IEC Christoph Busch 32

Part 14: DNA Data ISO/IEC 19794-14 Christoph Busch 33 Legend
DNA Record BDIR Representation#1 (Mandatory) DNA Record General Header Header Type Header Direction Version Sending Party (Party Type) Receiving Entity Type Batch ID Kit ID Number of Representation Certification Flag Representation Header DNA Typing Data DNA Profile Sample Category Cellular Type Typing Technology Sample Source Indicator Collection Method Date Location Date and Time Result DNA Type ID Lab Certification DNA Typing Data Data Type STR DNA Type Y-STR DNA Type mtDNA Data Legend Record Block Field Representation #2…#N (Optional) Format Identifier Request Type Geo-Location Error Message Supplement User Defined Electrophero-gram data Party Type Nationality Code Name of the Agency Name of the Sender Source: ISO/IEC Christoph Busch 33

Part 15: Palm crease image data
ISO/IEC A standard image interchange format for biometric systems that utilize human palm crease pattern images (alias palm lines) The format will contain detailed pixel information, units of measurement, description of imaging area of body, and imaging methods such as transparency or reflectance image Christoph Busch 34

Part 15: Palm crease image data
Darmstadt Decisions The title will be aligned with ANSI/NIST term „palm crease“ Draft must be aligned with Seeking for revised draft Christoph Busch 35

Framework for XML Encoding
FDAM ISO/IEC :2011 AMD2 XML encoding Binary and XML encoding schemes in parallel Clause 12 coding schemes for binary format txpes Clause 13 coding schemes for xml format type Will define common data types (accross several parts) and element names and refer to elements that apply to other SC37 project, which may be promoted to SD16 Mapping between data elements and those of ANSI/NIST ITL standard may be included as informative annex as an aid for translation Conventions on harmonization of ElementTypes Conformance testing of XML-records with schema validation Christoph Busch 36

ISO/IEC :2011 AMD2 XML encoding The XML data type and element names shall be mapped to corresponding elements and data types in the binary format specified in the same part of ISO/IEC 19794, if any All parts of ISO/IEC shall identify optional and mandatory elements An element is optional if the value of the minOccurs attribute is 0 An element is required to appear if the value of the minOccurs attribute is 1 or more. Christoph Busch 37

ISO/IEC :2011 AMD2 XML encoding Mapping from common XML elements to binary elements Source: ISO/IEC AMD2: Framework XML Encoding Christoph Busch 38

XML Encoding Darmstadt Decisions
ISO/IEC :2011 AMD2 - progress: FDAM ISO/IEC :2011 AMD2 - progress: DAM ISO/IEC :2011 AMD2 - progress: DAM ISO/IEC :2011 AMD2 - progress: PDAM ISO/IEC :2011 AMD2 - progress: 2nd PDAM ISO/IEC :2011 AMD2 - progress: DAM ISO/IEC :2011 AMD2 - progress: DAM Christoph Busch 39

Conformance Testing Methodology
G x Part 1, 2, 4, 5, 6, 7, 8. 9 and 10 published 5th WD AMD1 Level 3 Conformance Testing seeking for empirical studiess 2nd rev to cover defect reports this revision will NOT cover the 3D-Face amendment G x:2011 AMD1 Part 1, 2 4 and 9 are published Part 5 and 11 are FDAM Part 6 is DAM Part 14 is PDAM tables addressed testing of Binary Encoded Records only adaptation for XML- will be done in AMD2 Christoph Busch 40

Conformance Testing Vendor A Vendor B Vendor C
Minutiae Detection Deficiency Vendor A Vendor B Vendor C Left upper: minutiae not detected by B and C Right upper: spurious minutiae at image border! Right lower: minutiae misplacement Christoph Busch 41

Conformance Testing ISO/IEC 29109 - Part2: Finger minutiae data
ISO/IEC AMD1: Semantic conformance testing - Part2: Finger minutiae data Scope: tests of semantic assertions Type A Level 3 as defined in ISO/IEC :2009 Christoph Busch 42

Related Standards and Trends
Christoph Busch 43

Biometric Sample Quality
Revision running for ISO/IEC Part 1: framework ISO/IEC Part 4: finger image data upgrade from TR to IS to incorporate NFIQ2.0 findings see: 2nd DIS ISO/IEC Part 6: iris image data Christoph Busch 44

Previous edition ISO/IEC IS :2009 "Information technology - Biometrics sample quality Part 1: Framework" Definitions quality: "the degree to which a biometric sample fulfils specified requirements for a targeted application" quality score: "a quantitative expression of quality" utility: "the observed performance of a biometric sample or set of samples in one or more biometric systems" Quality score from 0 to 100 Source: ISO/IEC Christoph Busch 45

Revision ISO/IEC :201x Definitions Same as before, but allow for a vector of quality components Goal: Actionable quality Each element of quality vector has a score from 0 to 100. Source: ISO/IEC Christoph Busch 46

Revision ISO/IEC :201x Darmstadt Decisions shall support both BIN and XML No 250 multi-QualityBlock encoding A QualityVector must be transcoded to n-quality blocks, in order to maintain compatibility with :2011 QualityVector in a container structure should be supported do not progress: 2nd CD Christoph Busch 47

Biometric Sample Quality - Iris
DIS ISO/IEC iris image data Scope: methods used to quantify the quality of iris images, normative requirements on software and hardware producing iris images, normative requirements on software and hardware measuring the utility of iris images, terms and definitions for quantifying iris image quality, and a standardized encoded iris image quality data record. Christoph Busch 48

DIS ISO/IEC :201x Sample quality - Iris image Metrics based on an empirical study Iris Quality Calibration and Evaluation (IQCE): E. Tabassi, P. Grother, and W. Salamon, “Performance of Iris Image Quality Assessment Algorithms”, NIST Interagency Report 7820, September 30, 2011 14 elements proposed for quality vector Metrics: Usable iris area, Iris-sclera contrast, Iris-pupil contrast, Pupil boundary circularity, Grey scale utilisation, Iris radius, Pupil to iris ratio, Iris pupil concentricity, Margin adequacy, Sharpness, Frontal gaze – elevation, Frontal gaze - azimuth, Motion blur Enumerated flag for presence of anomalies Christoph Busch 49

Revision ISO/IEC :201x Darmstadt Decisions Computational method for PUPIL_BOUNDARY_CIRCULARITY is fixed clarification on human iris sizes introduce measures from PL to calcurlate sharpness do not progress: 2nd DIS Christoph Busch 50

Biometric Sample Quality - Finger
Revision ISO/IEC :201x Darmstadt Decisions Limit to one single Gabor method More examples will be included Not compute area of overlap for image-pairs due to lack of quantative measure do not progress: 3rd WD Christoph Busch 51

Liveness Detection CD ISO/IEC 30107-1 Presentation Attack Detection
Attacks on Biometric Systems Source: ISO/IEC inspired by N.K. Ratha, J.H. Connell, R.M. Bolle, “Enhancing security and privacy in biometrics-based authentication systems,” IBM Systems Journal, Vol 40. NO 3, 2001. Christoph Busch 52

Presentation Attack Detection
ISO/IEC Scope terms and definitions that are useful in the specification, characterization and evaluation of presentation attack detection methods; a common data format for conveying the type of approach used and the assessment of presentation attack in data formats; principles and methods for performance assessment of presentation attack detection algorithms or mechanisms; and a classification of known attacks types (in an informative annex). Outside the scope are standardization of specific PAD detection methods; detailed information about countermeasures (i.e. anti-spoofing techniques), algorithms, or sensors; overall system-level security or vulnerability assessment. Christoph Busch 53

ISO/IEC Definitions artefact: „artificial object or representation presenting a copy of biometric characteristics or synthetic biometric patterns“ spoof: „to subvert a system by presentation of an artefact.“ change of term: Suspicios presentation detection became biometric Presentation Attack Detection (bPAD) Types of presentation attacks Source: ISO/IEC 30107 Christoph Busch 54

ISO/IEC 30107 Suspicious versus Subversive Presentation The grey box covers bPAD Source: ISO/IEC rd WD (not contained any longer) Christoph Busch 55

ISO/IEC Examples of Artificial and Human Attack Presentation Source: ISO/IEC 30107 Christoph Busch 56

Error Rates in ISO/IEC 30107 Detection might result in errors presentation attack detection rate (PADR) „proportion of presentation attacks with a defined level of difficulty detected by a system.“ presentation attack non-detection rate (PA-NDR) „proportion of presentation attacks with a defined level of difficulty not detected by a system.“ Note of caution: For security assessment rates are irrelevant, if there exists a single artefact that can break the system presentation attack detection-power level: „level of difficulty of biometric presentation attacks above which the biometric system is not able to detect them.“ Christoph Busch 57

Darmstadt Decisions Encoding of PAD data is not depended on G2-G3 discussion. A PAD data record will be agnostic about in which structure it is incorporated PAD sub-results should be collected in a vector - thus extended data will be included in a PAD record extended data can be either proprietary or standardized (i.e. vendor-ID = 0101, which is „ISO/IEC JTC 1 SC 37-Biometrics“) PAD data record definition Tags are defined starting with 8 indicating a compund data New PAD metrics 3-part split as some parts are ready to move to CD Christoph Busch 58

Darmstadt Decisions on New parts Part 1 (IS) - Framework Elaine Newton Cl. 1 -6 progress: CD Part 2 (IS) - Data formats Olaf Henniger Cl. 7 do not progress: WD Part 3 (IS) Testing, Reporting and Classification of Attacks (Michael Thieme) Annex A+C Annex C will be promoted to a Clause Christoph Busch 59

WG3 Roadmap Generation 3:
:201x Generation 3: - The common semantics amongst all parts will continue to form the Framework of Generation 3 - All parts will exist in a XML and/or binary version with a (revised) harmonized semantic - PAD data will be encoded - Again Conformance testing will be included in Annex A of each part Christoph Busch 60

New project CCTV DRAFT RESOLUTION G.6 – Work on CCTV As Australia has changed its vote on SC 37 N5630, the Proposal for a New Work Item on Use of operator-assisted automated face recognition in CCTV systems – Part 1: Recommendations on design and specification and Part 2: Recommendations on testing and reporting practice has now passed and will be added to the SC 37 program of work. SC 37 reviewed ... As a result of this review, SC 37 resolves that SC 37 N5629 and N5630 be merged into one multipart project (30137) with the following structure and placement: Part 1, Design and specification (WG 4) Part 2, Performance testing and reporting (WG 5) Part 3, Data formats (WG 3) Christoph Busch 61

G3 road Data Interchange Format
Widely adopted and deployed in large number Reflecting need for distributed systems with XML encoding Reflecting need for actionalbe feedback wtih quality vectors Reflecting need for secure system with PAD encoding Preliminary Discussion with SC17 WG3 Definition on transition period from G1 to G2 in ICAO 9393 Suitable revision cycles for definition in ICAO 9303 Forward and backwards compatibility Transcodability from XML to BIN and vice versa Working on concepts in a Special group Christoph Busch 62

Conclusion Thank you for your support Christoph Busch 63

Conclusion Thank you for your support Christoph Busch 64

References Web Convenors website with latest news and slides ISO/IEC JTC SC37 ion=browse&sort=name Published ISO/IEC Standards browse.htm?commid=313770&published=on Christoph Busch 65

References Information on WG3 status and a ppt-copy of theses slides
are available at: Christoph Busch 66

References List of projects and a ppt-copy of theses slides
are available at: Christoph Busch 67

Prof. Dr. Christoph Busch
Contact Prof. Dr. Christoph Busch Department Security Technology Fraunhoferstrasse 5 64283 Darmstadt, Germany Phone: Christoph Busch Christoph Busch 68

WG3 report on Biometric Data Format and Related Standards

Similar presentations

Presentation on theme: "WG3 report on Biometric Data Format and Related Standards"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

WG3 report on Biometric Data Format and Related Standards

Similar presentations

Presentation on theme: "WG3 report on Biometric Data Format and Related Standards"— Presentation transcript:

Similar presentations

About project

Feedback