Hello, Sincerely, I find this extra complex. If you do not define a public, open way to do that, you will end up with a proprietary way of enumerating the cards, opening the channels, etc
If some other manufacturer tries to do the same, chances are that he will use a different, incompatible way, and we'll have no benefit at all, just like the forest of all mifare access methods. This method will also obviously not be able to read ISO14443-A and ISO14443-B cards at the same time. Let alone felica and friends. Since you don't know in advance the type of a card, presenting 2 random cards at once will result in one of them not being detected in a huge number of cases. this thing shall be led by a pcsc workgroup, or at least someone that will be able to establish interoperable specs. or let alone completely, as did EMV. Sebastien On Mon, Jan 31, 2011 at 10:03 AM, s.ferey <[email protected]> wrote: > 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 > _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
