> We (the industry) should turn this problem around. If I develop an
> application that needs to read and write a file, I don't also have to
> bring along the filesystem code and the disk drivers as well, yet
> that's where we are in today's world with respect to smartcards! Why
> do you, as an application developer of an application that uses
> smartcards need to worry about reader drivers, EXE files, ocf.jar,
> pcsc.dll, etc...? Why don't operating systems have native (in the
> "included by default" meaning of that word) smartcard support?
I agree completely. However, all "new" categories of devices go through a
transitional period where their drivers / libraries are not shipped with
an O/S.
As far as I know, the smart card base components are shipped with Win2K.
All that's needed in the driver, I imagine.
> My opinion is that the market for smartcards on computers is just
> not big enough (and will it ever be) compared to devices like
> telephones, cell phones and mass transit applications. There is not
> yet enough customer pull for smartcards on the desktop. Witness
> for example Microsoft's recent exodus from the smartcard arena.
> One has to scratch their head when one sees Microsoft leave any
> area of technology!
Maybe they've left the area because the vast majority of smartcards use
Java and they have publicly rejected Java. They're beaten in this arena.
To suggest that smartcards will not succeed as a technology ignores what
is happening every day when we use cards. On the desktop, they are not
yet proven, except in enterprises where they are used for time and
attendance / entry control / user authentication etc.
The killer desktop app for smartcards is not there yet.
> So, what do we see customers deploying in the real world? We see
> them deploying proprietary solutions from ActivCard, Gemplus,
> Schlumberger, Bull, etc..., solutions for which a high level
> framework like OCF or even PC/SC is not really necessary.
True, but we hope this will change.
We have developed a framework called DynamicCardServiceFactory. We intend
this to be used by ISVs (like ourselves, that's why we wrote it) who do
not issue cards themselves but would like to add card support to their
applications. i.e. The applications may not be 100% card-centric. It may
be that cards just add value to the application (think adding PKCS#11
smartcard support to a java mail reader).
It is an OCF CardServiceFactory that detects card types (using an XML
definition file) and once detected, implements the OCF
AppletAccessCardService and AppletManagerCardService interfaces for that
card, using information taken from the XML file. i.e. There is no
card-vendor java code on the machine – just XML that lets the application
developer install their applet if necessary. [ Note: Of course you still
need code to access the reader, which may be vendor specific, but we are
looking at providing links / producing a bundle that ISVs can ship which
includes OCF and all the common reader drivers]
In addition, it will download and cache .jar(s) containing the code
necessary to implement standard card services, if they are requested by
the application.
The goal is to allow applications to be written to work with almost any
smartcard reader and smartcard (where the two are compatible of course).
Just request the CardService you want, and DCSF will work out if it
supports it, and whether it needs to download code for you to use it.
We will be releasing this free code shortly, along with an ANT build
process that will build javacard applets and produce the output file
format for as many card types as we can get info about. (initially JC21
.CAP and .JIB for DalSemi ibuttons)
We think you CAN make general solutions like this now with the technology
available today, when you bring our solution (or one like it) into the arena.
That's our plan. Our own core project will use DCSF to do just that –
allow end-users to insert any card and see if they can use it with our
application. If a bank has allowed unrestricted post-issuance (unlikely!)
they could end up using their bank card with our application.
The really cool part is that if a card is not recognised (no info about
it in the XML file) it will check with a central web server to see if
there is a new XML file, and if so, get it and search again. If it's
still not found we post the details up to a web server (after asking the
user for info) so that we have a chance of discovering more about the
card so we can add it to the XML definition file in future.
So, dynamically updating smartcard applications will be a no-brainer soon
:-)
> Customers are surely interested in "open standards" until they
> see that the "open standards" on one platform do not play with
> the "open standards" on another. So, what is their response? They
> go to a vendor that provides them with a proprietary smartcard stack,
> APIs and complete application integration. Sure it's proprietary,
> but it works the same way on their UNIX platforms as it does on
> their WinTel platforms as it does on their PDAs as it does on
> their cell phones, and usually the top level of that stack provides
> the real APIs that the customer needs such as PKCS#11, free-form
> data store, e-purse, etc...
Yes, but that's where OCF and Java are well positioned. There's an
"embedded" version of OCF available from IBM too.
OCF + VOP + our DCSF should make for a very versatile environment.
> What does this say for frameworks like OCF and PC/SC? In my
> experience it says that currently what's needed is a solid
> reader abstraction layer, but that we're not yet ready for
> putting a card abstraction into a generic framework like
> OCF or PC/SC.
> I hope this isn't hearasey :-).
Heresy? Well, not to me, but I personally don't see the problem with
using OCF. Yeah it is a bit of a mess, some of the edges are very rough –
i.e. AppletManagerCardService – but while we wait for the standards to
catch up, we can all be writing real world applications that work using
OCF 1.2
i.e. In DCSF we have derived our own DCSFAppletCode from OCF's empty
AppletCode class, to which you pass a byte[] containing the applet code,
and an AppletInfo containing the AID etc. The XML scripting takes this
info and installs the applet in a card-specific fashion.
This is after you've used DCSF to work out what format of applet file is
expected.
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.
