Hi Marc & all,
may be you are right, but I'm not that sure. My personal experience is somewaht different - I see a chance in open source. I work with OCF for say 3 Month now. Before, my only experience with smart card was in theory and by posessing a credit card. Although my main task was writing a health care application, I created "on the fly" - a Card service for the German KVK (health insurance card), implemented as file access service - a TerminalService for Orga Reader which sits on top of CT-API, by using (but finally rewriting 80 %) an existing CT-API based service CT-API is a "must" for every reader for everyone who wants to sell in the German Health Care. And CT-API is at the base of MUSCLE (as I have read) - the evolving Linux Smart-Card Standard. Guess you get it for 80 % of the readers out there. It's much simpler than PC-SC (one object with 3 functions) and well documented. Of course, the quality of my solution is not the best, but as usual in Open Source, one guy starts a "Quick Hack", the next one casts it to a form that it can be reused (instead of reinventing the wheel) and relied upon, the third writes some basic documentation and the fourth one makes a decent product out of that all. The point I want to make: there is a chance to get it done without having it done by the reader manufacturers. I got a CardService from G+D (unfortunately, only under non-disclosure-conditions), and this was the main reason why we will go with G+D-Cards in our Project although planned the other way initially. Think - if you don't want to lock out all non-MS-Browser-Users (there is a saying that there are still some around), the only way to use cards in the web is JAVA. So ask a Card supplier for a bid and put OCF as a "must" in the spec's (not because you are a missionaire, but because it eases your job) - they will listen. And even if they don't - you will need a SDK for the card you are going to work with anyway (even if there never had been any OCF), so you have all the APDU's and documentation you need. I find it much easier to do any job on top of a PassThruCardService than handling plain APDU'S. And there is nothing in a card that is not handled by an APDU. So the question is: what effort is required for implementing the high level services (file access, security and so on). I haven't tried (since OCF worked fine :-) but I have planned, and I can say that ISO 7816 does quite some good here. I think that the OCF reference implementatiuon for the IBM cards is more complicated than it would be necessary - or that there is a lack of documentation - a missing red thread - in it. But there was one graceful man offering his generic card service implementation for ISO-cards already in this list - that's more than half the way, I think. Consider: we don't need services for 100 % of the cards in the market, but only enough that you can find 2 or three different vendors, where Card Services are available, for every project. A last thing - more emotional than rational, but based on business experience and intuition: When I first encounterd OCF, I liked the idea. When I realized then, that it was an IBM thing (at least initially), I considered not using it - I had too much bad experience with being dependent on their strategic movements (as you may see, I work with Lotus Notes - the reason why I can't simply quote with > ). Maybe that more people think like me - they don't want to contribute to an open source project where a giant leads the way. So, maybe, OCF gets momentum once it is considered to be "free and poor". Yours Wolfgang Rosner ___________________________________________________ IP-Web GmbH IT Service & Training Oskar-von-Miller-Stra�e 21 D-92442 Wackersdorf Tel.: +49 (0) 94 31 / 79 05 07 Home Office: +49 (0) 96 33 / 91 97 74 Cell: +49 (0) 170 312 68 52 Fax.: +49 (0) 94 31 / 79 05 08 http://www.ip-web.de [EMAIL PROTECTED] Marc Palmer <marc@anyware To: [EMAIL PROTECTED] .co.uk> cc: Subject: Re: [OCF] Motion to immediately close and dissolve the 11.10.01 OpenCard 17:35 Please respond to marc > oops, > I'm quite new on OCF - just closed the first project with this. > I didn't realize the severeness of the issue from the header until today. > My vote: don't let OCF die! > As a small company, we cannot put too much into a missionary project (which > IBM and others can't support....), but what we maybe could do: > - some hosting - maybe not only static pages, but also Lotus Notes based > Groupware (eg. team room for moderating discussions) > - whatever can be done on a Linux box (Mailing List ?) > - some modest contribution, like some card services and terminal > implementations and adaptations we produced so far Personally, I do not think that OCF will survive as an open source project. Most of us have written applications that use OCF for a specific card type or a set of readers. The whole point of OCF is that it is flexible and is not tied to any one of these. However, achieving that goal and testing code does require help from the card companies. If they cannot dedicate resources to OCF now, I doubt they will in the future when/if it is open source. True, many readers use PC/SC now, but that is not really the future us Java developers would like is it? "Pure" java solutions ? barring comms speed issues ? should be sought wherever possible because of the portability and stability it affords us. Also, OCF is not without its problems ? in terms of bugs and architecture issues. It's a bit of a mess in places. Turning it to open source could just worsen this situation... I hope not. However not many of use really want to hack through all the strange legacy code that is there to solve bugs and at the same time perhaps kill support for some hardware we don't have ourselves. That's why the consortium is important. All the hardware guys are sitting around the table and can test everything and contribute code for their own devices. Frankly, I can't believe that Sun will let this important part of Smartcard development die. They have invested a lot in Javacard and to have no standard reliable and "live and kicking" API for writing host applications seems insane. It's the bridge between the Javacards and J2SE. $0.02 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.
