On 6/7/00 Sam wrote
>
Hi,
From looking at the BusinessCard example provided by OCF, the application
compares the ATR response returned by the card to check whether the
application/AppletProxy can support this card. It seems to me that ATR
response can be different from card to card because the ATR returned from
my
Cyberflex card is different from the one hard-coded in the sample. Is it
normal in real life that terminal applications always check for a
particular
or a list of ATR responses in can support? It doesn't seem practical for
me.
Especially in the Internet environment that we might not know what cards
users might be using when accesing our web site (assuming the users have a
reader and OCF for our applets to access the card).
So, in summary, what are you really looking for when checking the ATR
response? Are you indirectly checking whether the card is a JavaCard that
you can use? If so, is there a better way to check beside checking the ATR
response? Or this is a non-issue because there is a standard on ATR
response
smartcard can return to indicate what card it is.
thanks and regards...
Sam
<
No, for contact cards, the application should not be looking for a
particular ATR. The ATR should be processed by the card reader or its
device driver. That is not to say that the app should not be able to
retrieve the ATR (see below).
Most of the ATR is concerned with low level features and parameters for the
communication between card and terminal, and these should be handled by the
reader and its device driver in order to decide whether this reader and
driver can properly handle the card offered. As some projects have found,
sometimes the reader and driver have to refer decisions about handling the
card further up the chain, but the decisions should then be handled by a
user intervention layer.
At the end of the ATR there is usually a string called the historical
bytes. ISO gives a suggested structure for these bytes, but (a) there is no
way that the reader can find out if that structure has been used, and (b)
many card implementors have used a private structure in the historical
bytes (e.g. Mondex returns the cash balance in the previously selected
pocket (currency)). It is in case (b) that the app will need to retrieve
the ATR, because there is likely to be application-specific information in
the ATR - but once the card app is installed in a multi-app card, only one
of the apps can use the ATR in this way (which produces a battle between
app providers)! One vending machine card interface developer has tried very
hard to decode ATRs from a variety of e-purse cards, and is now certain
that this is not a reliable way to find out what card is present. The
proper thing to do is to look inside the card for the application that you
want to use - here there are two types of application selection in use, ISO
and EMV - and use should be made of the application ID (AID) registration
scheme operated under the control of ISO.
I believe that there are two proposals around for a free access data area
in a multi-app card: one emanating from the ISO camp, and another
(DISTINCT, which is now the subject of a CEN/ISSS standardisation project)
coming from a group of citizen's card developers (including Newcastle
University in England). There is quite a lot of information that a card
scheme developer would like to be able retrieve from a card (OS version,
card issuer, even (if the GCA proposal for the NIM takes hold) a web host
address for the OS provider and for each app in the card).
And another point about EMV: developers of large retail store networked
systems want the 'user intervention layer' mentioned above to be fully
integrated into their operator interface software, and have proposed to EMV
a terminal software architecture which differs from the EMV specs. EMV has
a strict divide between level 1 (the card handler) and level 2 (the
applications), and retail store systems want to move some level 1 functions
into an intermediate operator interface layer - EMV's V4 draft ('EMV 2000')
grants no recognition of this requirement, even though long discussions
about it have taken place.
Peter Tomlinson
Iosis, Bristol, UK
---
> 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.
