Re: [xcbf] Vendor Specific Formats

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

Bancroft Scott wrote:
> 
> 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.  

That is not a problem for three reasons. One is that they
are already locked into whatever can be expressed in the
BIR uint16 FormatType field. Two is that they can always
get a new OID from the IBIA to use for extended products.

The third is that if they decide to rely on the ASN.1
schema in X9.84, they can reuse their FormatOwner in
a different context without introducing any ambiguity.
They can use their registered identifier in the built
in information object 

   { BIOMETRIC id : x984BioInfo  DATA BiometricInfo } |

since the BiometricInfo is a series of one or more values
of BioInformation, defined in X9.84 as

   BioInformation ::= SEQUENCE {
      processingInfo  ProcessingInfo  OPTIONAL,
      matchingInfo    MatchingInfo  OPTIONAL
   }

and each of these optional components can be used to
carry an identifier and an arbitrary type. Use of this
type is really where we need to be headed. And note 
Bancroft, that if this option is used, folks that 
already manage their own OID arcs can use this 
mechanism without needing to purchase an OID from 
the IBIA.
 
> 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

I don't follow this at all. If you believe that every
company is tied to a 16-bit integer value then the best
solution would seem to be one that makes our schema as
tight as possible and minimizes bits on the line changes
to the X9.84 ASN.1. This would simply be to change all of
the information object to refer to BIRint16.

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

The second solution is not too bad. But the required
change to the Format type is a show stopper for me,
particularly if there's a reasonable work around. 
 
> 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.

Agree. I very much like identifying the company names
and the registry by use of individual OIDs. 
 
> 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)
>      }

This would be better than the proposal just above, as
it would allow an application to preserve all of the BIR
information needed to do a BIR->BiometricObject->BIR 
transform.
  
> 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.

I see this again as a show stopper because of the impact
to type Format. And all of these suggestions I think makes
application processing more complex. 
 
> > 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.

I think that we are very early in the game to call a
halt to change. The recent history of development of the
BioAPI format indicates that there has been no backwards
compatibility demonstrated to date. The tendency of bit map
specifications is to fail to weather change, which is why
ASN.1 solutions are generally favored by standards groups
such as X9. And as both X9.84 and BioAPI move forward in
the standardization process into a more international arena, 
I'd tend to bet on change rather than none.
 
> > 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.

If OIDs were only and always to be used in a BIR 
setting I might tend to agree at first. Then I would
consider that putting them in the ASN.1 schema where 
they are available for implementors is a very important
reason to define them. And giving the vendor companies
publicity in the standard is also a benefit.

But the best reason to define and publish these values
is that it makes possible their use in the context of
the BioInformation types ProcessingInfo and MatchingInfo
types. 

Right now, I've only got the relative OIDs defined as
they are needed to document the mapping from BIR to
X9.84. But I will also propose defining the full blown
OID that these relative OIDs relate to. This is how
X9.84 views these IBIA FormatOwner values, as relative
to an X9.84 based OID.

This is how they will be hooked to LDAP or X.509 or 
X9.68 use. And recognizing in print that the IBIA 
values in fact implicitly defined OIDs makes possible
arc management by the owners who move ahead into use
of the BioInformation 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.

I see documenting in XCBF that the IBIA hex 000A value is 
the same as <formatOwner> 10 </formatOwner> in XCBF, not
as taking on the responsibility of the registrar, but 
simply as a requirement for our specification. And I see
usefulness in feeding such back into the next X9.84 
revision.

But I would not at all oppose some initiative to IBIA or
CBEFF through the XCBF Liaison SC. 

Phil
 
> > 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
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>