Re: [xcbf] Vendor Specific Formats

[Bancroft Scott <baos@oss.com>]

On Fri, 10 May 2002, Phil Griffin wrote:

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

Everyone that uses the BioAPI is going to use a 16-bit integer value,
for it is mandated by the BioAPI.  This being the case, it follows that
the information objects of all such companies would identify BIRint16.
Given this, I think it would make more sense to define a single
information object that everyone can use to identify 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.

What about the suggestion to create a 65535 relative OID for the above
BioAPI-BIR-BIOMETRIC-DATA-FORMAT?  I believe that that makes application
processing more straightforward.

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

I agree to all of the above.  I am not suggesting that we stick with the
BIR forever.  I am suggesting that we find a backward-compatible way of
introducing the X9.84 BiometricObject, for we are sure to meet stiff
resistance if we introduce interoperability problems.  Yes, BioAPI 1.0
and 1.1 are incompatible, but that does not mean that the industry will
tolerate a series of new BioAPI versions, each with no compatibility
with the previous version.

BTW, your point about ASN.1 allowing new versions of application standads
to be introduced with full backward-compatibility is a very good point.
This alone is good enough reason to want to have the BioAPI directly
support BiometricObject.  Does anyone have any ideas as to how it might
be possible to do this while preserving backward-compatibility?

Bancroft