> If the card vendors are not enthusiastic enough to continue now, and many > of them don't offer free docs/utilities, it is going to be very difficult > to retain compatibility with the majority of cards. It will be hard to > implement CardService(s) for those cards, as the vendors will probably > not produce them any longer if OCF is not "their" project.
But they're not producing them now, so I don't see why they suddenly will. I think the card vendors just see PC/SC and Win32 as the target platforms, so why bother with Opencard ? All you need to implement card services are the APDUs the card needs. In the past I've helped develop card services for Visa Open Platform (which, BTW, most JavaCards are supporting) and the Schlumberger Cyberflex to load apps. These were devloped with a combination of official specs and (in the case of VOP) intercepted APDUs. > Option (1) is of no interest to me frankly, as it does not offer card > independence for applications, and can be written from scratch in a > simpler API than OCF. Well, you *could* write your own API, but who is going to write the drivers for all the terminals ? Also, the resource management in OCF is very good. Option (2) is the only sensible approach, but even > now there are few CardService(s) available from vendors, and there would > almost certainly be less if OCF disbanded. I don't see why. Card vendors would not provide services if Opencard is seen as not developing, which seems to be the case for now. The SunBlade 100 from Sun has an integrated card reader, and ships with openCard in Solaris 8. The card management app is a Java app using OpenCard. > I think what we really need is for the OCF consortium members to wake up > and support Java rather than give up on it. Mass-market smartcard-aware > Java applications will never come if OCF disbands, unless there is some > support from vendors. They may never come anyway, at least not on the PC. If you're waiting for the card vendors to provide them they never will. I think there are at least 2 reasons for this : 1. The vast majority of clients are Win32 which already have PC/SC installed (at least Win2000, which for corporate use is the target). The PCs almost certainly do not have a Java VM and OpenCard installed. Why bother with Opencard ? What extra does it give ? 2. The smartcard industry has a lot of people who cut thier teeth on sending bytes down serial ports. They don't understand or care about design patterns / abstraction etc. If they can speak to the card using Visual Basic and PC/SC, well, why not? 3. Vendor lock in exists in the industry to an extent that it is dominated by 3 or 4 major players. Who cares about open standards ? > > I'm guessing, but I think that perhaps they only supported Java because > of the potential use in Applets on web sites (The "e-Wallet" hype) - > because browsers did not have support for smartcards as a cert store in > the past. Now that most browsers have this built in using PC/SC, they > don't see a need for OCF. Perhaps I'm wrong... > Most browsers use either PKCS11 or the MS CSP to provide generic crypto services from a card. More specific apps tend to be written as ActiveX controls. There are at least 2 problems with this : 1. Win32 specific 2. Many corporate firewalls block ActiveX as a matter of course. This has seriously impacted a project I've been involved with in the past. It seems to me open sourcing it will subject Opencard to a Darwinian process : if people want it it will be devloped, and if not it will just stay as it is, which is pretty good anyway. Jon. --- > 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.
