And here, once again, we hit the problem of identifying a card from its ATR.
I well remember a vending equipment manufacturer telling me that a South
American e-purse card was being identified as a Proton card by his equipment
(the Sth Am card was a local design). You cannot rely on the ATR to ID the
card, and the problem gets even worse when the card is a multi-app platform.
Here in the UK, a group known as ITSO (www.itso.org.uk) has been trying to
develop a general application spec for public transport ticketing and
related functions. They expect their app to be capable of being hosted on
many card platforms. So they decided to define a classification system for
card type, security scheme type, and security key set. Then they have to
work out how to implement this. So they have decided to ask ISO to create a
new object type in an ISO-structured ATR, and this object will contain the
class info for the ITSO application and associated security mechanisms. How
many card platforms have an ATR that has an ISO structure? How many card
platform providers are willing to let an app shove something into the ATR?
While investigating ITSO's ideas for a citizen card scheme, and after some
discussion with two major card platform providers, I proposed that the card
platform must be capable of supporting Select File with direct AID
addressing of a DF, and that the card platform's security scheme must allow
read access to the ITSO DF without any prior security exchange (i.e. prior
knowledge of the card's security mechanism is not available in the terminal,
because it doesn't know what the card is), and that the ITSO class info must
then be freely readable from the DF. After that the terminal can configure
itself (from info stored in the terminal or in a SAM) and carry out any
mutual authentication procedure deemed necessary by the scheme owners and/or
card issuers.
This, of course, presupposes that the card supports ISO file structures and
the requisite form of Select File. Not all card platforms support that form
of Select File, and Javacard has made ISO file system support optional...
Peter T
----- Original Message -----
From: "Gunnar Osterode" <[EMAIL PROTECTED]>
To: "Marc Palmer" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, January 31, 2001 8:58 AM
Subject: Re: [OCF] Argh! getSmartCard hassles
> Hi Marc,
>
> the CardRequest-object is not "senseless". The CardRequest-object
specifies
> the CardService which is required for the purposes of the application. For
> one card there can be many available CardServices. For instance
> FileAccessCardService or SignatureCardService.
>
> If a card is inserted, the ATR is passed to all CardServiceFactories that
> are registered in the opencard.properties file. Now the factory has to
> decide if the ATR specifies an available cardtype and if for this cardtype
> the required CardService is available. If the card doesn't match your
> requirements you can't use it for the purposes of your application and
need
> not to create a SmartCard object.
>
> Nevertheless I'm also not completely happy with the current mechanism. In
> my oppinion it would be helpful in some cases if I could ask for an
> Enumeration of available CardServices for an inserted CardType.
>
> Kind regards
> Gunnar
>
>
> >Hi,
> >
> >I'm trying to use SmartCard.getSmartCard to get a SmartCard reference
> >when a new card is inserted (i.e. I'm doing this in cardInserted)
> >
> >However, many of the method signatures have been deprecated as of OCF 1.2
> >and the one I am supposed to use is:
> >
> >getSmartCard( CardTerminalEvent, CardRequest)
> >
> >Now this seems really stupid to me, as I have to create a CardRequest
> >object using values taken from the even I'm passing to getSmartCard! As
> >far as I can see the only difference is the int value for
> >ANYCARD/NEWCARD, which is all I really need to specify (the rest can be
> >gleaned from the event).
> >
> >Does anyone know why this is?! Surely it would make sense to have:
> >
> >getSmartCard( CardTerminalEvent, int reqCardType)
> >
> >Where the value of the second parameter is CardRequest.ANYCARD or
> >CardRequest.NEWCARD. This saves the hassle of creating another
> >"senseless" object.
> >
> >Oh well...
> >
> >Cheers
> >
> >
> >
> >
> >---
> > > 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.
>
>
>
> ---
> > 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.
>
>
---
> 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.
