> Hi All,
>
> Does anybody here use Cyberflex Access cards with OCF?
>
> If so, could you help me with the doubt below?
>
> In the Cyberflex Access card we have the idea of identity such as AUT0,
> AUT1, etc. In OCF to verify a Card Holder we must use the sendVerifyCommand.
> Now w
Most readers wont handle this response code. Some POS terminals will.
You should send the get response/data command to retrieve the data.
John
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of Naomaru Itoi
Sent: Monday, July 30, 2001 6:43 PM
To:
Hello,
Most of the drivers pass the 61 XX back to the application to handle. I
think it is bad practice to handle this in the driver since it is a card
specific ISO function. This should happen above the reader abstraction
where the card abstraction layer occurs. BTW - has anyone done an OSI
l
Hi Naomaru
Our driver for the ORGA ECO 5000 automatically sends GET_RESPONSE; if the
card returns '61 xx' or '9F xx' and the application passed a case 4 command
APDU to the reader. The class byte for GET_RESPONSE is copied from the class
byte used for the original command.
IMHO this is the way i
> Most of the drivers pass the 61 XX back to the application to handle. I
> think it is bad practice to handle this in the driver since it is a card
> specific ISO function.
GET RESPONSE is a transport level command. It should therefore be invisible
for the application. The problem arises if you
Hi Emiliano,
Thanks by your tip.
But, what I want to know is: The idea of Identities (AUT0, AUT1, etc)
that exists en Cyberflex is also valid in the OCF context? Are there others
cards that have the same concept the identities?
For example, to download a Cardlet to my card I need befo
When a card returns 61.xx, it means that the card has xx byte to
return to host.
Does a smartcard reader driver handle this, usually?
My Todos driver does. It seemed useful at the time. I would like to know
whether this is correct or not. Most other reader drivers I have looked at
do n
Hi,
I completly agree with Andreas. Get Response is
dependant on T=0 transport protocol and must not be
handled at application level. This is at least what
ISO 7816 says.
Towitoko driver 2.0.X handles authomatically the Get
Response when the command is Case 3 or Case 4. Also
the issues athomatic
I agree that the application should not have to deal with this. But I don't
think the driver should either. Anything that every driver must do in the
same way really belongs at a higher level, in pc/sc.
***
Linux Smart Card Developers -
I think you should handle the Get Response if your APDU looks like the
following:
CLA INS p1 p2 p3 lentx xx xx xx xx xx lenrx
Is this correct ?
Dave
***
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards i
David Corcoran wrote:
>I think you should handle the Get Response if your APDU looks like the
>following:
>
>CLA INS p1 p2 p3 lentx xx xx xx xx xx lenrx
>
>Is this correct ?
>
In the perfect world yes ! but, sadly, people sometimes doesn't follow
correctly the ISO7816 or misunderstood it. I hav
11 matches
Mail list logo
