Hi, I'm by no means an OCF expert but I think I have identified something that would be really useful, and I may even be implementing some of it myself anyway, so here's the rough outline of the idea. If people think there is mileage in this, please let me know. Perhaps I can turn it into an OpenCard RFP and see what happens (do you have to be a member for that?). Here goes... ---- start proposal ------ OpenCard DynamicServiceFactory Proposal The problem: Java application developers who want to add "any card" smart card functionality to their applications are not as well served by the work done on OCF as those developers working in a single-card vendor environment. In future it is likely that users will want to use the same smartcard for many different applications, so making it easier for developers to use any card presented to them (within reason) is obviously desirable. The following problems are immediately apparent: 1) Few of the common CardServices are actually implemented in the OCF distributions for any cards. 2) Without a BasicAppletCardService factory for generic multi-applet smartcards, applications must hog the SlotChannel, preventing multi-OCF-application access to the card. This severely impairs developers who develop custom card applets but do not want to write a custom CardService and CardServiceFactory (which still has the problem of card identification). 3) Applications that use OCF cannot use the services of cards for which there is no CardServiceFactory that recognises their ATR, even if the card supports the well-known service the application is trying to use. 4) There is no standard way to identify the capabilities of a smart card, so a developer cannot even make their code detect card features. As a result there is a higher investment in time and money required, where you must get one of each card you want to support, get the ATRs, modify your service factory etc. - and still you only support the cards known at the time of writing the application. The proposed solution: OCF is a Java solution, so it makes sense to make use of Java's dynamic class loading and internet download features, so that application developers ship only OCF plus DynamicServiceFactory. Their applications will be able to use any card that can support their required CardService, as long as somebody somewhere has implemented the code and notified a central "registry" (i.e. The OpenCard web site) DynamicServiceFactory would use an XML file to list information about known card types, and how to identify them. The Xml data also includes information about the services available for the cards, and where to download the code if it is not available locally on the classpath. Such code could be saved in a local cache. Example (with dummy values): <base url="http://www.opencard.org/download/dynamicregistry.xml" /> <newcard url="http://www.opencard.org/cgi-bin/newcardpost" method="POST" /> <atr expected="0xFF00FF00FF00FF00FF00FF00FF00FF00FF00"> <cardtype name="Dallas Semiconductor Java powered iButton 1.11" url="http://www.dalsemi.com/ibutton/ocf/ib_ocf.jar" > <service classname="opencard.opt.service.FileAccessCardService" implementation="com.dalsemi.oc.opt.VirtualFileAccessCardAccess" url="http://www.dalsemi.com/ibutton/ocf/ib_ocf.jar" /> <service classname="opencard.opt.applet.AppletManagerCardService" implementation="com.dalsemi.oc.opt.AppletManagerImpl" url="http://www.dalsemi.com/ibutton/ocf/ib_ocf.jar" /> <selector implementation="opencard.opt.applet.ISOAppletSelector" url="http://www.opencard.org/download/ocf_opt.jar" /> </cardtype> <cardtype name="Dallas Semiconductor Java powered iButton 2.2" url="http://www.dalsemi.com/ibutton/ocf/ib_ocf.jar" > <distinguishing-feature cla=0xD0 ins=0x34 p1=0 p2=0 data="*Firmware 2.2*" sw=0x9000 /> <service classname="opencard.opt.service.FileAccessCardService" implementation="com.dalsemi.oc.opt.VirtualFileAccessCardAccess" url="http://www.dalsemi.com/ibutton/ocf/ib_ocf.jar" /> <service classname="opencard.opt.applet.AppletManagerCardService" implementation="com.dalsemi.oc.opt.AppletManagerImpl" url="http://www.dalsemi.com/ibutton/ocf/ib_ocf.jar" /> <selector implementation="opencard.opt.applet.ISOAppletSelector" url="http://www.opencard.org/download/ocf_opt.jar" /> </cardtype> </atr> <atr expected="0xEFA0FF00FF00FF00FF00FF00FF00FF00FF00"> <cardtype name="Gemplus Expresso" url="http://www.gemplus.fr/ocf/expresso_ocf.jar" > <service classname="opencard.opt.service.FileAccessCardService" implementation="fr.gemplus.oc.opt.VirtualFileAccessCardAccess" /> <service classname="opencard.opt.applet.AppletManagerCardService" implementation="fr.gemplus.oc.opt.AppletManagerImpl" /> <selector implementation="opencard.opt.applet.ISOAppletSelector" /> </cardtype> </atr> When OCF asks this service registry for a service, it will do the following: 1) If it has not done so already for the current card, it gets the ATR, and caches it in the SmartCard or relevant object. This removes the need to query ATR again for further card service requests on the same card. 2) Next, it scans the XML document for a matching ATR. 3) If none is found, it prompts the user to ask them if they want to download the latest XML config file from the internet. If they do, it downloads it and replaces the local file. If it is still not found in this file, it will prompt the user for info to help identify the card, and will post the data and the card ATR to a CGI script at the "newcard" URL. 4) Once a matching ATR entry is found, the list of cardtype nodes is loaded. If there is more than one cardtype node, it will look for "distinguishing-feature" definitions, which define APDUs that can be used to probe the card for more clues. If there is still no unique cardtype that applies, the user must be prompted to confirm which card (from the list of possibilities) they have. 5) If there is only one match, it is assumed this cardtype is the correct one, so the requested CardService class is looked up in "service" tags and the implementation loaded. 6) If class loading fails, the software will prompt the user to see if they want to download code for their smartcard. If so, the URL is retrieved and cached on disk (if applicable). 7) The implementation is handed back to OCF, perhaps with some caching of details to eliminate such lookups on the same card in the same session. ------ end proposal ------- There you have it. That should give you an idea of what I'm thinking of. It looks like we will need something like this for our application, so I may be writing it anyway. However it would be nice to get something like this in the core OCF distribution and have them partake in the web-serving of the XML document and also updating the document when new cards are "discovered". 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.
