Hello,
in case of two different cards, the host application would be able to
enumerate then select and read the right card appl. (based on right AID
selection); it does need to read both cards.
in case of several cards of same type (several ePassports at border
control), the host appl. want to read all of them but reading each card
one by one or reading several with interlaced APDU will require exactly
the same time (AFAIK the reader won't send multiplexed command, it's not
able to receive several response simultaneously), so there is also no
needs to exchange APDU with several cards simultaneously.
for these 2 use cases, the issue is the possibility for the host appl.
to know how many chips are in the field and to select one of them -
right now (using only PC/SC API) the reader chooses itself one (and only
one) chip.
rgds,
Sylvain.
Le 31/01/2011 09:11, Alexei Soloview a écrit :
Hello!
Look at the following situation.
A citizen has driver license and social card. Both are based on
RFID-cards. He stores them together in purse.
In case of reader with capability of reading of two cards there is a
possibility to develop device that find and read document that it needs.
The citizen just places purse with documents in the reader’s field and
it will read needed document.
Sincerelly, Alexei.
*From:*[email protected]
[mailto:[email protected]] *On Behalf Of *Sebastien
Lorquet
*Sent:* Friday, January 28, 2011 5:32 PM
*To:* MUSCLE
*Subject:* Re: [Muscle] Access to multiple contactless cards using PCSC-Lite
Hi,
I sincerely can't think of a real-world, largely deployable one.
I'm just aware of a specific demo where two cards in the same fields
exchanged value.
I didn't even see the demo, a colleague described it to me.
Given the relatively small reading distance (5 cm) of a normal 13.56 MHz
reader, reading more than one card at once does not really makes sense.
Moreover, I can think of lots of technical problems with such a reader,
for example field strength problems.
Regards
Sebastien
On Fri, Jan 28, 2011 at 1:50 PM, Alexei Soloview
<[email protected] <mailto:[email protected]>>
wrote:
Hello, Sebastien!
I’m working in reader’s manufacturer company J
At this time I try to build a list of requirements to upgrading of
functionality of driver to our RFID-reader.
At this time we think that simple consecutive reading of all present
chips in the field are enough.
Do you know use cases where reader should work with more than one card
and capability of consecutive reading is not enough(for example, use
case with reading first card, reading second card, processing data on
terminal, writing something on first card)?
Sincerelly, Alexei.
*From:*[email protected]
<mailto:[email protected]>
[mailto:[email protected]
<mailto:[email protected]>] *On Behalf Of *Sebastien
Lorquet
*Sent:* Friday, January 28, 2011 12:04 PM
*To:* MUSCLE
*Subject:* Re: [Muscle] Access to multiple contactless cards using PCSC-Lite
I was affirmative because I'm working in a contactless card company ;-)
Apart from that, I'm totally OK with your advice: avoid it, because of
reliability (but cards advertising CID support shall work as expected),
but also availability on cards, and availability via pcsc/ccid.
This is a possible, but low level feature, and far from supported by all
cards and readers.
Sebastien
On Thu, Jan 27, 2011 at 11:41 PM, s.ferey <[email protected]
<mailto:[email protected]>> wrote:
Hi,
To be honest I hesitated a bit before being so affirmative :)
You are right, "if the card supports CID" and reader firmware /
middleware let you manage the full frame building, you should be able to
talk to different chips (identified by their CID) w/o halting them.
But (based on experience) some chips do not support CID (or NAD) and
reader SDKs won't always let you manage the CID (ie the targeted chip).
So my advice was actually: try to avoid it because of the leak of
reliability.
Sylvain.
Le 27/01/2011 15:31, Sébastien Lorquet a écrit :
Hi,
are you sure the CID function is not usable to keep a live context in
more than one card (in the same field of course)? Only the card with the
targeted CID value will reply to a command that contains this CID. At
least, IIUC... it means that with CID support, you don't need to halt
the cards you're not talking to...
Sebastien
On Thu, Jan 27, 2011 at 2:57 PM, s.ferey <[email protected]
<mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
Hi,
As Ludovic yet answered you can manage that sequence (ie card
requests, tag/chip enumeration, selection of one of them) yourself
as long as some API give you access to such functions; but for most
of readers the PC/SC driver is opaque to these operations -- in
short PC/SC manages APDU exchanges as per ISO 7816/14443-4 but hide
details of protocol stack as per ISO 7816/14443-3; or other way to
explain the reader firmware implements 14443-3 while the reader
driver implements 14443-4 with PC/SC syntax.
That said, some readers manufacturer provide proprietary API
offering direct access to the protocol - this includes (and is not
limited to) Integrated Engineering (SmartID), ID3 semiconductors
(CL1356), Pro-Active (SpringCard), certainly also OmniKey or DUALi
that offers a valuable SDK.
Last point, your sequence: "Select one of them and read it; Select
another and read it" is valid but do not expect to read several
chips simultaneously (it's certainly not required); indeed some
several chips are in the field the reader shall "select" one and
"halt" the other ones, from the chip point of view the "halt" is
(more or less) a soft reset (it will keep its UID but will lose its
context) and thus it is not possible to suspend and then resume the
exchange of APDUs.
Sylvain.
_______________________________________________
Muscle mailing list
[email protected] <mailto:[email protected]>
http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
