Hello,
Karl Scheibelhofer wrote:
>
> we have the problem that card reader that we access via the PC/SC
> wrapper do not behave like "native" opencard drivers (like the one
> from gemplus). as far as i know this is a problem with the response
> packets. it seems that one of these drivers is not compliant to the
> opencard card terminal specification. i think that card services that
> base on opencard should operate with any opencard compliant card
> reader.
In fact the problem came from the fact that originally, there
was a lack of specification on this issue of APDU chaining in
case 4 for CardTerminal, i.e., OCF did not specify if it was the
responsibility of the CardTerminal layer, the CardService layer,
or the application...
PC/SC clearly specifies that the drivers should not do the
chaining automatically, while OCF did not specify anything..
(which was the worst :-).
And so we cannot say that one or the other of the two CardTerminals
is bugged, that was more a problem that they have both chosen a
different way..
Now, in an OCF Technical Committee meeting in May 99, it was
decided that T=0 handling, as specified in ISO 7816-4 Annex A,
was the responsibility of the CardTerminal. And also that a
supplementary API should be added to OCF in order to allow
bypassing of this feature. See the corresponding RFP at:
http://www.opencard.org/work/rfp-1/rfp-1.txt
for more details.
Now the CardTerminal previously designed did not automatically
by magic complied to this new spec :-) and so this is the case
for the PC/SC wrapper. IBM has released the sources of this
CardTerminal with OCF1.2 and Gemplus has been working on this
functionality. We need to finish a few tests here and I will
send the proposed modifications to IBM for approval (we also
added a few more functionality like the ability of returning
by warm reset the first of second ATR depending on the power
status, the implementation of PowerManagement interface, and
a possibility to select SHARED or EXCLUSIVE per reader from
the property file). If we agree on the propose changes, I will
be posting more information on how to get the new version and
it will be integrated into the distribution.
> i wondered, if someone maintains the PC/SC wrapper and keeps
> it up to date?
Yes, IBM is still doing this, as far as I know, but was not
interested in the T=0 chaining issue because all IBM cards use T=1!
This is why Gemplus will be proposing an update.
Otherwise, the PCSC wrapper is now under the same liberal BSD-style
license than the rest of the framework, i.e., purely free software,
and could then be modified by everybody. I think that you would have
to convince the maintener (i.e., currently IBM) to get your changes
to be included into the official distribution, but nothing prevents
you from enhancing the component for your own needs (that's what we
did).
> i think the PC/SC wrapper is by now the only way to access PCMCIA
> readers. isn't it?
I think you are right. I actually have some code from Rinaldo
Di Giorgio, from Sun, who has written, a GPR400 CardTerminal that
uses JNI to access the Gemplus API4 C driver, but as it is actually
doing the same as the PCSC wrapper, I suggest to use this last
one instead, which means you will be using the latest PCSC drivers
as well.
In fact, since there is no standard API for Java, it's not possible
to talk about "pure Java" in this case, we would need some kind of
javax.comm for PCMCIA communications. The same goes for USB, although
a USB standard API is currently defined by a JCP working group, so it
will be possible to get pure Java CardTerminals for USB readers in the
future.
Hope this helps to clarify some points. I will post here as
soon as I have news about the version that does T=0 chaining.
Cheers,
Christophe.
= "The best way to predict the future is to invent it." --Alan Kay =
--
-------------------------------------------------------------
[EMAIL PROTECTED] - Gemplus Research Lab
Phone: +33 4-42-36-57-83 | Disclaimer: I don't speak for Gemplus
Gemplus doesn't speak for me... it is better that way!
-------------------------------------------------------------
---
> Visit the OpenCard web site at http://www.opencard.org/ for more
> information on OpenCard---binaries, source code, documents.
> This list is being archived at http://www.opencard.org/archive/opencard/
! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
! to
! [EMAIL PROTECTED]
! containing the word
! unsubscribe
! in the body.