I'll answer these questions inbetween the original message the best that I
can.
>
> Hi,
>
> I have a few questions about PC/SC Part III
>
> In 3.1.1 they say: "The IFD Handler shall then notify the callin gprocess
> using an appropriate inter-rpocess signaling mechanism. The specific
> signaling mechanism to be implemented is OS dependent and is beyon dthe
> scope of this specification"
>
> How is this implemented in our PC/SC driver?? Are we using IPC functions??
>
> And another interesting thing is in 3.1.3 (ICC Events)
>
> "The IFD subsystem shall support the following ICC-related events:
>
> o Card insertion notification
> o Card removal notification
>
> When one of these events occurs, it is the responsibility of the IFD Handler
> to notify the ICC Resource Manager layer"
>
> How is this implemented in our drivers???
>
We will be using IPC communication to notify the Resource Manager of these
style events. Unfortunately, the specification doesn't go on to discuss
how one should handle these events at a higher level. I wouldn't worry
about implementing this quite yet - I think that 1.1 will discuss this
more ( it should be out in a couple of months )
This event helps the ICCSP tell when card in/out notifications occur.
This is useful when keeping track of the currently selected file on the
card. Because when a card is removed and put back in it is generally
selected the master file 3F00. We don't have to worry about this quite
yet since the ICCSP's that are currently written ( in fact most that are
written for MS PC/SC ) will select the absolute path before trying to
perform an operation. By this I mean they always assume the current path
is 3F00.
To check for Card Status in the meantime, an application will spawn off a
thread which will call the SCARDTRACK.GetStatusChange() function which
will block until a change of card state occurs. This is not too ideal,
but this is how many applications on Windows check this state. ( Plus it
was simple for me to implement : )
> 3.1.5.3 T=1 Protocol Support:
>
> "From the ICC Service Provider perspective, an IFD Subsystem shall accept
> APDU's, construct the necessary T=1 blocks to convey those APDU's and
> asynchronously return the response from the ICC. It is implicit that the ICC
> Service Provider has the right to transmit the first such block. The IFD
> Subsystem must at all times track whether it, or the ICC has the right to
> transmit, an IFD subsystem may return an error if an ICC Service Provider
> attempts to initiate a block transmission request."
>
> how do we track at all times who should be able to transmit blocks if we
> don't konw who has tranmsitted the last block because it's only impelmented
> in a shared object with functions...
>
> maybe I missed something important :)
>
> After reading this document I think that IFD Handlers should be implemented
> as RPC routines and a watching daemon which can notify the ICC Resource
> Manager if an event occurs... But I don't think if this is implemented at
> the moment or how you work around that and if it's compliant with the
> standard to work around that...
Again, this section is quite vague in how one should go about implementing
this. This should be addressed in this Spring's release of 1.1. By the
way, if any of you have suggestions for PC/SC 1.1 please send them to me
and I'll try to get them to the right person. You are right, we will have
to look into ways of communicating back from the IFD_Handler to the
Resource Manager eventually in order to support T=1.
>
> are there any later specifications than the ones at smartcardsys.com ??
> because they have been written in 1997 and 3.1.5.4 says: "... will be
> clearly specified in the 1.1 release of these specifications (in early
> 1998)..." and I think the early 1998's aren't future any more...
>
> Part 3 section 3.2 lists optional Functionality... But do we have to
> implement this returning an error code??? Or do we just don't implement
> them???
Look on page 18 of document 3. You should implement these functions but
return the error code IFD_ERROR_NOT_SUPPORTED.
>
> At the moment it returns an error code...
>
> RESPONSECODE IFD_Confiscate_ICC() {
>
> RESPONSECODE lRetVal;
> lRetVal = IFD_ERROR_NOT_SUPPORTED; // This is not supported.
> return lRetVal;
>
> }
>
> And can you please give me an example how to implement Vendor-specific
> features mentoined in 3.2.4 ???
This is a great question ! In part 5 they discuss the Control function
which allows you to send BYTE commands directly to the reader ( source
host, destination IFD ). This allows you to deal with Vendor Specific
functionality. You would then create a high level library that would use
this to communicate to the reader. Unfortunately, it is not mentioned how
you should implement this in the IFD_Handler. I was thinking maybe you
could send some flag to the Transmit function - but nothing is mentioned.
I will have to figure this one out soon since I will be writing an
IFD_Handler for the BioMouse fingerprint scanner. The Biometrics portion
will have to be implemented as a separate library at this point.
Any ideas ????
Dave
>
> I hope it's okay to ask these questions on this list because I think they
> are interesting to everyone :)
>
> Hopefully this was everything... maybe I have some other questions later...
>
> thanks for your time,
> gerhard
> ***************************************************************
> 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
> ***************************************************************
> --
> ******************************************************************
> David Corcoran Internet Security/Smartcards
>
> Work: School:
> 205 Industrial Blvd 2252 US Highway 52 West Apt C4
> Sugar Land, TX 77478 West Lafayette, IN 47906
>
> Quotes:
> If it's a hobby for us and a job for you, then why are you doing
> such a shoddy job (Microsoft) ? ~ Linus Torvalds
>
> If you can't make it work, at least make it look good.
> ~ Bill Gates
> ******************************************************************
>
***************************************************************
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
***************************************************************
