The GET RESPONSE is not part of the T=0 protocol at all. The T=0 belongs to
the ISO 7816-3 standard, whereas the GET RESPONSE is at a higher level,
defined in the ISO 7816-4. The driver along with the (possibly intelligent)
hardware should only implement the ISO7816-3 stuff. According to the
vocabulary used in the 7816-4 standard, the driver should deal only with
TPDU:s (transmission level stuff) and not APDU:s (application level stuff)
and it should NOT try to interpret and act upon the SW1/SW2 responses that
possibly would lead to GET RESPONSE command.

The SCardTransmit typically gives TPDU data back, such as SW1/SW2 bytes, so
we are still at a fairly low protocol level. If the application wants to
support ISO7816-4 it must probably issue a GET RESPONSE itself on receipt
of a SW1/SW2=61XX. From what I can gather, the Windows smart card resource
manager does not send any GET RESPONSE automatically, and I think this is
correct behaviour. However, in the Calais spec it can be read that there
may be, at a higher level, smartcard service providers implementing both
the ISO7816-4 file system and the support for ISO7816-4 APDU:s, which in
that case should include the GET RESPONSE business. I don't know if such a
7816-4 service provider has been written, but maybe anyone from Microsoft
can enlight us on that.

Mats Hansson

At 06:26 2002-05-15 -0400, you wrote:
>Do you really think I should issue GET RESPONSE inside reader driver???
>I can do it some other way specific to the type of the device, passing the
>length and pointer for the receive buffer which are parameters in
>SCardTransmit!
>
>In my case for USB device I just build URB and call IoCallDriver.
>Everything works just great.
>
>Stanley

Mats Hansson
Intertex Data AB
Rissneleden 45
174 44 Sundbyberg
Sweden

Tel +46-8-6282828 Fax +46-8-6286414 www: http://www.intertex.se

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]