Hello,
DAVID SIMS 1 281 285 7792 wrote:
>
> Hi,
>
> There is a good web page at <http://www.seis.se> regarding identity
> tokens (and the spec's for them)....
Huh! I tried but I do not read swedish yet.. (shame on me.. :-).
> It seems pretty obvious to me that
> in order to have *any* application level interoperability (via PKCS 11 or
> PC/SC or OCF or CDSA or any of these device specific 'standards') that
> there will need to be a consistent file system (and contents) specified
> for the card itself independent of the mechanism through which the data
> is accessed and which cuts across all of the device connection
> mechanisms...
>
> Anyone have thoughts about that???
You might want to register to the CardService working group at OCF
(I think Tim Jurgensen is currently representing slb), because
we are working on such issues (i.e., we would like to extend the current
framework, that mostly deals with APDU sending (like PC/SC) with
application level interoperability in mind). Actually, I would not place
the four acronyms on the same line: PC/SC is a platform specific
middleware for card access. It includes a "module", CAPI, based on a
proprietary crypto API. Likewise (almost), OCF is a platform independent
framework that will include one or several modules offering
cryptographic
APIs to applications.
Both PKCS#11 and CDSA has been mentionned, and the former is likely to
be
implemented first. We can also think of providing packages to JCA that
deals with sc-based cryptographic implementations. It seems to me that
interoperability can only be achieved if, on the contrary, the
application does not know exactly where the information is stored, or
even using what kind of data structure (e.g., some cards may be
file-system based, but other will be object-based, and a third kind will
be table-based, like DBs). We are trying in OCF to hide these
differences under Java abstract classes and to prevent the data location
features from being too much bound to the file-system-based services..
Now if the data location, what IBM is calling the card layout, has to
be manipulated by the application, we can provide some kind of symbolic
names translation, each card provider will also provide the software
module that does the naming services.
Anyway, if the first set of middleware (PC/SC, first OCF) has ensured
the independence of card terminals, the future generation will also
ensure the independence of cards, but there is much more work to be
done.. :-)
Cheers,
Christophe.
= Bloody typical, they've gone back to metric without telling us. =
= -- Charlie, Department of Works (Brazil) =
***************************************************************
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***************************************************************
