Re: [xcbf] Vendor Specific Formats

[Bancroft Scott <baos@oss.com>]

On Fri, 10 May 2002, Phil Griffin wrote:

> 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)

A problem with this solution is that it locks the OID for SecuGen into
using an INTEGER forever.  Given that the BIR defines format identifier as
an unsigned 16-bit integer value, it seems very likely that every company
that uses the BIR will have the OID associated with their company identify
a BIRint16 type.  Given this, I question how good the above change is.  I
would much prefer see a more general solution.

One solution that comes to mind is to introduce a new field of type
BIRint16 within "Format".  It could be either:

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

or:

    Format ::= SEQUENCE {
       formatOwner  BIOMETRIC.&name({Owner}),
       ident CHOICE {
           formatId     INTEGER (0..65535),
           formatType
              BIOMETRIC.&Type({Owner}{@formatOwner})  OPTIONAL
       }
    }

The benefit with the above is that it provides a solution that is
easy to comprehend, for it directly relates the BIR's formatId
to that in the X9.84 biometric record.  The drawback is that it
requires a change to the existing X9.84 Format type.

Another alternative would be to create a record similar to the 00 id
record, perhaps with a relative OID value of 65535, where the associated
type is INTEGER (0..65535).  The benefit of this is that it does not
require a change to the X9.84 Format type.  The drawback is that the
relationship with the BIR's format identifier will not be as easily
identifiable.

Yet another alternative is similar to the last one mentioned above, but
instead of INTEGER (0..65535), we would have a SEQUENCE that contains
the plain and simple type:

     BioAPI-BIR-BIOMETRIC-DATA-FORMAT ::= SEQUENCE {
        formatOwner	INTEGER (0..65535),
        formatID	INTEGER (0..65535)
     }

Here the relative OID value of 65535 would identify the type as
BioAPI-BIR-BIOMETRIC-DATA-FORMAT.  The benefit of this is that it
immediately makes clear what the mapping from the BIR to the X9.84 record
format is, it does not require a change to the existing X9.84 Format
type, and it uses a single relative OID value to identify the INTEGER
type, as opposed to the solution which you propose which would result
in each BioAPI vendor using their OID to identify type INTEGER.

Hmmm ..., it might actually be best to put
BioAPI-BIR-BIOMETRIC-DATA-FORMAT directly into type Format as an optional
field.  This recognizes that the X9.84 record has more bredth, while at
the same time making it easier for implementors to map from the BIR to
X9.84.

> 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.

I don't see how this would be a good thing.  Why have a whole bunch of
OID's identifying the same type?

> 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.

I agree with all the above.  However, I am quite certain that the BioAPI
Consortium will not entertain the thought of replacing the BIR record at
this time.  Their focus now is on stability of the BioAPI 1.1 standard.
The only chance I see for them adopting the X9.84 BiometricObject is if we
made this 100% backward compatible with implementations that are underway.

> 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.

See my comments above on this matter.  If we are going to use an open type
at all for the format type it makes no sense to have a whole bunch of
OID's knowingly mapping to the same type.

>   - 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

Not sure what you mean here.  I'd have to see this with more ASN.1
to give clearer context.

> 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?

I prefer to work with the various organizations involved, instead
of taking on their responsibility.  So, to answer your question, no.

> 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.

See above.

Bancroft