Of course, ATR cannot be used to get information about the functionality of
applications residing on the card, but the ATR has to give information
about the used COS and that's all you need at the level of OCF-CardServices.
As you mentioned, furthermore there has to be a standardisation of
applications. I think a good approach is the PKCS#15 published by RSA
Security. What do you think about it?
Regards
Gunnar
>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.
