> > 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 understand this completely. However, we managed to get Dalsemi to add
support for applet management card services in the last year. Some
companies are more forward-thinking than others ;-)
> I think the card vendors just see PC/SC and Win32 as the target
> platforms, so why bother with Opencard ?
Yes, exactly.
> 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.
Yes, but for serious applications I'm not sure that hacked APDU sequences
can really be said to be 100% reliable. Intercepting APDUs isn't much
fun, and could be very difficult with contactless cards.
Official specs are not publicly available for many of the cards as I'm
sure you know.
Example: We hope to add support for some cards in this way, from docs
gleaned from existing users who have the relevant SDK. However, it's a
big job and relies on a lot of people's good faith and time devoted to
testing (as we don't have all the cards).
> > 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.
Yes, it's not bad. It's not perfect though.
> 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.
Yes, but will they provide them at all when it is not OCC property? There
are currently card services of one kind or another from Gemplus, Dalsemi,
SLB and probably some others. It would be interesting to know if these
companies would still produce and maintain such code if OCF became open
source and little to do with the vendors.
> 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.
That's good news. I hope Sun is trying to offer incentives to the card
vendors to keep supporting and improve OCF. That would be the most
desirable route I think, but maybe it's too late.
> > 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 :
Ah, well I'm a Java optimist :-)
> 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 ?
Well from the perspective of application developers, it gives platform
neutrality. Of course if you are in the business of purely providing a
smartcard solution, Java may not be your first choice. But
platform-independent Java applications (which are growing in number �
ICEmail, Jabber etc.) can easily add card support using OCF instead of
using some horrible JNI layer to PC/SC which will only work on Windows
systems.
> 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?
Haha, yes too true.
> 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 ?
Yep. :(
> > 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.
Yes I know it sucks. That was my point. It would appear people have given
up on OCF because the browsers support cards, but it's actually a "bad"
solution.
> 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.
Yes, perhaps. It would be nice to know if any vendors at all would help.
For example, Gemplus are pretty keen on Java it seems. Would they still
produce card services and free tech info to the project?
I just think that it's a very tall order for an open source project given
the reliance on hard-to-obtain technical data. Without any help from
vendors, it's going to be seriously time consuming.
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.
