I have some misunderstanding in case of two different cards. We have in the reader's field at least two RFID-cards. Let's one of them is driver license. We need to read it. As I think for this purpose the host application must be able to perform the following sequence of operations: 1. Select one of the card. 2. Check if it's driver license (based on right AID). If True then work with it. 3. Repeat steps 1-2 for next card.
Also I think that there is no need to know how many chips are in the field. It's enough of capability to select one of the untreated cards. Sincerelly, Alexei. -----Original Message----- From: s.ferey [mailto:[email protected]] Sent: Monday, January 31, 2011 12:04 PM To: MUSCLE Cc: Alexei Soloview Subject: Re: [Muscle] Access to multiple contactless cards using PCSC-Lite 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 readers 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! > > Im working in readers 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
