Le 07/06/2012 09:55, Ludovic Rousseau a écrit :
2012/6/7 Sébastien Lorquet<[email protected]>:
do you really need the "contactless" part of the information?
if I had to do that, I would proceed in 2 steps
-find readers that contain a card (already doable)
-send a specific command that is recognized by the card application,
-same idea is usable to find the reader that contains the sam.
[...]
and that's all, you do not have contacts or radio waves in the equation.
I would also suggest something like that.
[...]
On the other hand it is possible to propose something to the PC/SC
workgroup. If I am correct you need a service to know what are the
specificity of a reader. It could be something from the (non
exhaustive) list:
- contact
- T=0
- T=1
- contactless
- type A
- type B
- type C
- other?
- communication speeds ?
- biometric ?
It will be difficult (and time consuming) to setup the list of all
possible features within the PC/SC workgroup. I do not plan to get any
results before 5 years :-)
Sébastien, Ludovic, thank for your feedback, your advices are useful and
they could solve the issue in a lot of cases.
however yes a specific service, or the definition of a new constant for
the SCardGetStatusChange function (afaik only 11 over 32 bits of the
dwCurrentState field are used), or a tag for the SCardGetAttrib
function, could be an easy & efficient way to know if the communication
is over-the-air or not.
also, thank to note that "over-the-air" can be present "in the equation"
- for some kind os applications that require confidentiality (but can't
rely on the systematic availability of a SAM or HSM) some exchanges can
be managed in plain with contact reader but require encryption when
managed over-the-air.
regarding provided information, I wasn't thinking about a long list that
will never approved; I only dealt with contact or contactless.
from my point of view (and my needs too) the details of the
communication (and all points relevant at the "-3 level", including
speed, RF type, and so on) don't need any new services / reporting.
regarding features like biometric sensors, some providers (iD3) did
provide some proprietary API and they weren't that nice, some (Sagem)
define proprietary APDU to trigger scans, other (Zvetco) exhibit the
biometric device w/o any privileged communication with the card
reader(s) - a biometric chapter could / would be a great addition to the
PC/SC standard but it wasn't my point :)
Sylvain.
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
