Hi Karl, Chris and Tom,
> i have the same problem. it seems that there is really no other vendor
> supplying usable CardServices for its smart cards than IBM. i have heard
> that GemPlus is working on CardServices for its GPK8000 card, but i
> haven't
> seen any yet.
> the support for CardServices of the vendors is really bad. without
> CardServices OCF isn't worth the half it could be. and i'm not interested
> to
> write all CardServices for my own since there are almost always the
> standard
> card services defined in OCF. and these are up to the vendor to make. even
> if you write them using JavaCard you can not use them on every JavaCard
> since every JavaCard has a different capabilities.
>
Actually, if you are considering a card-based signature solution you have 2
options:
a] Get a proprietary vendor OS-based solution (in this case a specific
signature card f.e. G&D's Starcos SPK 2.3) and try to obtain a signature
CardService for that card. (This will not be a JavaCard). Many manufacturers
provide this type of cards - some of them are working on this type of OCF
solution.
b] If you want it to be a Javacard-based solution you have 2 choices:
1) You want to develop your own applet
2) You want to obtain a manufacturer's applet (plus card service)
In the case 1), no manufacturer will be able to provide you with a
CardService, as the APDU interface to the signer applet will be defined by
you. As an advantage, you will have to write the CardService only once no
matter how many Javacards you wish to support, as long as the APDU interface
to your applet remains the same. The Javacard applet implementation may
differ, alas, due to immature standarisation (although this should get much
better with all manufacturers properly supporting Javacard 2.1). Therefore
some porting of the Javacard applet may be needed, but the CardService
*doesn't change*!!!
In the case 2), I really don't thing this is happening yet, but things may
change when card vendors (or third parties) decide to develop and sell their
"pure Java" (Javacard-applet/OCF-service) solutions.
> >
> > I guess this really isn't a question for OCF (as it provides a framework
> for
> > writing card and terminal independent applications), but more for vendor
> > support of OCF.
>
> yes it sould be. but it seems to me that most vendors think: we support
> JavaCard now - so write your CardServices for your own dear developer.
> i really consider to write a SignatureService using JavaCard and for
> example
> iButton. but i saw that not all functionality is accessible from JavaCard
> applets. e.g. a random number generator, prim testing, key generation, ...
> but these functions seem to be accessible from outside sending APDUs to
> the
> iButton.
>
No manufacturer will write CardServices for your own applet, unless under
some customer order.
In the future, manufacturers might want to provide you with both applet +
cardservice.
Don't forget CardService comes together with APDU interface to your
application. If the latter is fixed in different ports of your applet, the
CardService need never change. CardService is tied to application provider,
which is not necessarily the same as card provider, especially in the
Javacard world.
Cheers,
C A R L E S
---
Carles Barrob�s i Meix
Marketing & Development
GyD Ib�rica - Giesecke & Devrient
Ind�stria 5
E-08970 St. Joan Desp�
Tel +34 - 93 480 8303 Fax +34 - 93 477 1142
mailto:[EMAIL PROTECTED] http://www.gyd.com/
---
> 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.
