Hi Ludovic,
BTW, none of this work is meant to provide a mechanism for PC/SC-lite
to work across a network boundary, i.e. between two machines on the
network. All of this is restricted to the local machine only. Getting
something to work securely over a network is a much bigger challenge,
and as I've said in the past, providing a network pipe for APDUs is
probably not a good idea.
The Sun Ray has the smart card reader. The smart card applications are
running on the server. So you already have a "network pipe for APDUs".
:-)
The difference with Sun Ray is that the DTU is only available to
the specific Sun Ray session and Sun Ray server that it's bound to,
and the DTU is just using the network as a way to transport I/O
between the server and the DTU. There is no specific X display or
fixed IP address assigned to a DTU as you might find with having
several fat clients on a network, each one running an X server and
applications on it.
So, while the DTU is on a network, the network is just being used
as a very long "extension cord" to extend the DTU's devices from a
session on the server out to the user's physical desktop.
My point was that we are not trying to solve the problem of an
application on one fat client setting their $DISPLAY to another
fat client and then expecting that the far-end fat client will
proxy APDUs between its reader and the local fat client's app.
I guess it is using the (proprietary?) communication protocol between
the Sun Ray and server. Do you have some security mechanisms here?
Yes, and yes.
mike
--
[EMAIL PROTECTED] Sun Ray Product Engineering
I don't speak for my employer. My opinions are not necessarily those of
Sun Microsystems, Inc. or any of its wholly-owned subsidiaries.
_______________________________________________
Muscle mailing list
Muscle@lists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle
