October 31, 2002
Results of Ballot M1/02-0222
|
Organization |
YES |
NO |
ABSTAIN |
No Response |
Comments |
|
3M/AiT |
X |
|
|
|
|
|
AAMVA |
|
X |
|
|
1. |
|
Apple Computer Inc. |
|
|
|
X |
|
|
Assa Abloy ITG |
X |
|
|
|
|
|
Authenti-Corp |
X |
|
|
|
|
|
Bioscrypt Inc. |
X |
|
|
|
|
|
Business Solutions |
X |
|
|
|
|
|
Datacard Group |
|
X |
|
|
2. |
|
Fall Hill Associates, LLC |
X |
|
|
|
|
|
Farance Inc. |
|
|
|
X |
|
|
Identix |
X |
|
|
|
|
|
ID Technology Partners, Inc. |
X |
|
|
|
|
|
Infineon Technologies |
|
|
|
X |
|
|
International Biometric Group |
X |
|
|
|
|
|
International Biometrics Industry Association |
|
|
|
X |
|
|
Iridian Technologies |
X |
|
|
|
|
|
LaserCard Systems Corp. |
X |
|
|
|
|
|
Mississippi Valley State University |
X |
|
|
|
|
|
Mitretek Systems |
X |
|
|
|
|
|
Motorola Inc. |
|
|
|
X |
|
|
National Security Agency |
X |
|
|
|
|
|
NIST |
X |
|
|
|
|
|
Niteo Partners, NEC Solutions |
X |
|
|
|
|
|
OSS Nokalva |
|
|
|
X |
|
|
Purdue University |
X |
|
|
|
|
|
Q.E.D. Systems |
X |
|
|
|
|
|
Saflink Corp. |
X |
|
|
|
|
|
Sagem Morpho Inc. |
X |
|
|
|
|
|
Security Industry Association |
X |
|
|
|
|
|
Sony Electronics Inc. |
X |
|
|
|
|
|
Symbol Technologies, Inc. |
X |
|
|
|
|
|
Transaction Security, Inc. |
X |
|
|
|
|
|
Unisys Corp. |
X |
|
|
|
|
|
US Department of Defense – DISA |
X |
|
|
|
|
|
US Department of Justice |
|
|
|
X |
|
|
US Department of State |
X |
|
|
|
|
|
US Department of Transportation |
X |
|
|
|
|
|
West Virginia High Technology Consortium Foundation |
|
|
|
X |
|
|
TOTALS |
28 |
2 |
|
8 |
|
Comments Received:
1. AAMVA
I have the unique perspective of both representing a voting member of M1, but I am also the Convenor of ISO IEC / JTC1 SC17 / WG10 – ISO compliant driving licenses. The third phase of work for WG10 will address the use of biometrics on, or in conjunction, with ISO compliant driving licenses.
I object to the Proposed Technical Contribution (M1/02-0221) not because I believe it is flawed, but because I believe it is misplaced in SC37. I have privately debated what types of standards projects belong in M1 and SC37, versus whether they belong in B10 or SC17. The dueling scopes of B10 & M1 and SC17 & SC37 have drawn interesting parallels. In the past I have approved ballots for the development of APIs for the TWIC and border crossing cards out of a desire to support the immediate needs of U.S. government agencies. It is also tempting to simply approve such ballots because there is so much biometric expertise gathered under the umbrella of M1, and the same will likely be true for SC37. However, I have understood that biometrics were explicitly separated from B10 (and SC17) because they are a new breed of identification standards development that are not specific to card technologies – they are "generic biometric standards." I have also understood that B10 (and SC17) may continue to have work items that include biometric standards development as long as they are specific to identification cards and the like.
The NP in question is
written entirely for development of an application that performs on-card
biometric matching. By definition, this application is very specific to
identification cards / cards that perform identification functions. The work
should reside with SC17. In the future, I recommend that voting members look
closely at the proposed work items to insure they rest in the scope of M1 and
SC37 or if they represent a conflict with the scope of B10 and SC17. Until the
borders of the conflicting scopes are more clearly resolved, standardization
efforts of the two groups that are closely related will run the risk of
continued challenge and delay.
2. Datacard
Group
Nathan Root (ed. AAMVA) raises excellent
points. I too find my self in a
quandary. We need to rapidly
proceed on this matter. The
technical content of the proposal appears sound; however, it is smart card
focused. Smart card specific
applications, especially those addressing software interfaces, commands, etc
should be the responsibility of SC17/WG4.
Still, we need to proceed.
Suggestion: What if the scope were elevated to a higher level - a
generic JAVA API. Generic applications
are the responsibility of SC17.
Card based JAVA implementations could then evolve based upon this
generic specification.