Re: [xcbf] Vendor Specific Formats

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

Ed Day wrote:
> 
> If the goal is to get those in the BioAPI group to "buy-in" to this new
> standard, then I think the goal should not only be 100% backward
> compatibility, but ease-of-use as well.  My initial impression of the BioAPI
> document was that it was an easy-to-follow document and I had a relatively
> good understanding of the structure of the data.  When I then went to the
> ASN.1 document, I had a hard time relating what was in the BioAPI C
> structures to the ASN.1 specification.

Me too, and I was there when it was written. I
worked closely with folks involved in the BIR
design in trying to align it with the ASN.1 in
X9.84 and this should not be difficult for me. 

I have argued that the most logical starting 
point for the XCBF work is in making this mapping
easy to understand. And the experience that you
describe is why I have asked that XCBF produce
clear and simple text that shows how each of the
BioAPI structures maps to a specific ASN.1 type.

This is where I will start work on the document
for discussion next week.

> So it would seem to me like the suggestion to use record types like the
> following makes the most sense:
> 
> > > >      BioAPI-BIR-BIOMETRIC-DATA-FORMAT ::= SEQUENCE {
> > > >         formatOwner     INTEGER (0..65535),
> > > >         formatID        INTEGER (0..65535)
> 
> It should be possible to create almost a one-to-one mapping of fields in the
> BioAPI structure to fields in an ASN.1 type.  This could be done at the
> beginning of the specification with all of the more complex stuff concerning
> information objects and the like pushed down to where it would of be out of
> the way of the casual reader.

I agree completely. 
 
> The other advantage is ease-of-use.  Using an ASN.1 compiler, one could
> create the BIOAPI structure format directly from the ASN.1 source, making it
> possible to read a header directly into a variable of the generated header
> structure.  With a few more lines of code, one could then create the XML
> document corresponding to the BIR.

Actually, this mapping and the structures involved
make this simple enough to do by hand if you are 
familiar enough with ASN.1 encoding rules. And some
of the cryptographic enhancements are just about as
simple and the processing requirements are the same
for DER as XML encodings.

> This is just my initial impression from looking through the information that
> is out there and I'm not sure what other factors are in play here.  Is there
> other data in X9.84 format that has to be integrated into this mix or are we
> basically starting from scratch?

I have an opportunity to feed minor adjustments
and additions needed to properly align the X9.84
ASN.1 as published in that standard into the X9F4
working group as errata to be considered for the 
next release of that standard. I've been trying
there to garner support for publishing these in
a public portion of the X9 web site - I am still 
working on this.

If you look at the places in our schema where my
initials appear, you can see what I've suggested
so far. But I will try to post an update to this
schema that has a little less impact on the X9.84
ASN.1 module, and which includes the missing CMS
module later this evening or tomorrow morning.

Phil

> ----- Original Message -----
> From: "Bancroft Scott" <baos@oss.com>
> To: "Phil Griffin" <phil.griffin@asn-1.com>
> Cc: "xcbf" <xcbf@lists.oasis-open.org>
> Sent: Friday, May 10, 2002 1:41 PM
> Subject: Re: [xcbf] Vendor Specific Formats
> 
> > 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
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>