[xcbf] Vendor Specific Formats

[Phil Griffin <phil.griffin@asn-1.com>]

Clause 2.1.6 "BioAPI_BIR_BIOMETRIC_DATA_FORMAT" of the BioAPI 
specification states that the IBIA is the registrar for the 
valid values of FormatOwner. Any associated type paired with
this registered format owner identifier is defined by the 
owner and may optionally be registered by the IBIA.

The BioAPI specification assumes that value of FormatOwner
and the associated value of FormatType are always 16 bit 
integers, as shown in the following definition:

   typedef struct bioapi_bir_biometric_data_format {
      uint16 FormatOwner;
      uint16 FormatID;
   } BioAPI_BIR_BIOMETRIC_DATA_FORMAT,
*BioAPI_BIR_BIOMETRIC_DATA_FORMAT_PTR;

   NOTE: FormatOwner values are assigned and registered by the 
   International Biometric Industry Association (IBIA). FormatType
   is assigned by the Format Owner and may optionally be registered
   by the IBIA. Contact information for the IBIA is located in 
   Section 1.5 of this specification.

Though the IBIA registry currently shows that there have been
no format types registered by their list of format owners, a
look at the example BIR records reveals that the SecuGen data
carries an associated integer value. So, to reflect that reality
I've changed the schema definition for the information object
set Owner object 

   { BIOMETRIC id : ibia-SecuGen                    } |

to the following

   { BIOMETRIC id : ibia-SecuGen  DATA BIRint16     } |

and added a new constrained integer type 

   BIRint16 ::= INTEGER (0..65535)

This raises the question (below) of whether all of the other
IBIA format owner objects in the Owner information object 
set should also be changed to use BIRint16. 

A cursory look at the IBIA registry web page reveals that
the registrar fails to mention any relationship between 
their registered FormatOwner values and the OIDs and 
relative OIDs in X9.84. There is no no indication there 
that X9 assumes these hex values are relative OIDs that
are registered under the OID arc in X9.84 as relative OIDs
by agreement between X9 and the IBIA - noted in X9.84. 
This raises a second question (below) of the need in XCBF
for more detailed accompanying registry information that
describes these values in an X9.84 and XCBF context.

Note that the BIR FormatOwner and FormatType fields can be
mapped to the following X9.84 ASN.1 type:

   Format ::= SEQUENCE {
      formatOwner  BIOMETRIC.&name({Owner}),
      formatType   
         BIOMETRIC.&Type({Owner}{@formatOwner})  OPTIONAL
   } 

Both components of this type are based on the &name and
&Type fields of the BIOMETRIC information object class:

   BIOMETRIC ::= CLASS {
      &name  BIOMETRIC-IDENTIFIER  UNIQUE,
      &Type  OPTIONAL
   }
      WITH SYNTAX { BIOMETRIC &name [ DATA &Type ] }

   BIOMETRIC-IDENTIFIER ::= CHOICE {
      oid  OBJECT IDENTIFIER,  -- complete object identifier
      id   RELATIVE-OID        -- object identifier fragment
   }

This class definition gives X9.84 format owner and type
values much greater flexibility of type and range of values
than those that can be specified in the simple BIR bit map
defintion of BioAPI.

In X9.84 a BIR FormatOwner can be carried by the relative
OID choice alternative, "id", of the formatOwner component
of type Format, and any ASN.1 type can be associated with 
the formatOwner value using the formatType component of 
type Format. And it is possible to map any valid BIR values
into the components of the X9.84 Format type.

But since the X9.84 formatOwner component is defined to be 
either a complete object identifier or a relative object
identifier (a fragment of an OID), it is possible to 
specify valid format owner values using the ASN.1 defined
in our X9.84 schema that can not be mapped to a BIR record.

And since the X9.84 formatType component is defined as an
'open type', which can be any ASN.1 type, it it is possible
to specify valid format types using the ASN.1 defined in 
our X9.84 schema that can not be mapped to a BIR record.

Generally, this is not a problem, since we always perform
cryptographic enhancements on values of type BiometricObject.
It is not important whether these initial BiometricObject
values were created based purely on the X9.84 ASN.1 schema,
or whether they were mapped from a BIR record to form a
value of type BiometricObject.

But this does mean that not all values of the X9.84 type
BiometricObject can be represented as BioAPI BIR records.
And it indicates to me that replacing the BIR bit map
in the BioAPI with the X9.84 BiometricObject would improve
that standard and simplify applying security to biometric
objects. These issues need to be thoroughly addressed 
somewhere in the XCBF documentation.

One problem that we must find a way to deal with is how
to best define the associated type, if any, in the Owner
information objects:

  - Should they all be assumed to be type BIRint16? This
    is one approach we could take and not an illogical
    one since all of the current format owners seem to be
    BioAPI Consortium members and the IBIA registry seems
    only to support BioAPI BIR requirements and ignores
    X9.84 capabilities.

  - Should they all be defined as some open type so that
    the format owners are left free to define their own
    ASN.1 types? For example, 
  
       BIRopen ::= TYPE-IDENTIFIER.&Type

A second problem is the need to expand on the IBIA registry
information. Should XCBF take on the task of defining it's 
own version of the information found in the IBIA registry
augmented by what we can find out about associated FormatType
usage? 

This would seem necessary, as this would give us the 
opportunity to show how these format owner and format type
values are specified using the ASN.1 XML Value Notation or
as DER or XER encodings. It would also serve as a point of
reference for XCBF implementors. 

Comments? Ideas?

Phil