Mark, Perhaps you can help me here then.
At PC/SC there are a number of readers (currently) that can not serve as interoperable readers across that matrix. http://www.pcscworkgroup.com/CompatibleProducts/CardReaders.ht ml Can an American Express Blue card work in any of the readers other than the GCR415 that is explicitally shipped with that card? i.e, can I use the GCR415 for a Visa Card from Fusion or Fleet? How about with a reader from another vendor? As I understand it, and please correct me if I'm wrong, part of the FinRead specification was designed to overcome this interoperability issue. If the card is capable of carrying all of the applets (in a number of years as you stated) then is certainly isn't that big of an issue (then). However, there is still the security and authentication issues. As I understand it, there is not, currently, enough inexpensive memory on the card to handle the applets for payments AND authentication and/or security cryptographic alogrithms. On another note, don't the EMV readers also rely on this embedded co-processor architecture? As I understand it, the North American market is rather fragmented with these non-multiapplicational cards. How much information, at least for conducting eCommerce transactions, does the user want on the card? I submit to you that any biometric or cryptographic components will probably be better off embedded off the card. This reduces the cost of the card. Is the FinRead specification working toward EMV compliance? Best Regards! jb > From: "Mark Kamers" <[EMAIL PROTECTED]> > Date: 2002/03/01 Fri AM 08:49:15 EST > To: "Jason Barkeloo" <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > CC: <[EMAIL PROTECTED]> > Subject: RE: [OCF] Smart card application > > > Jason, Anne, > > I do not agree with the example given by Jason on the MasterCard "reader" > and the Visa chip "reader". > Quote: > "For example, say you have two different cards - a Visa and MasterCard. > You > want to make a purchase using the Visa card. The reader plugged in is > the > one with your MasterCard. Now you must unplug the MasterCard reader and > plug in the Visa reader. The wrinkle? Both readers are the same model > number from the same vendor! No interoperability." > > All the financial sector card comply or will by 2005 at latest ALL comply > to the EMV chip card specifications (see http://www.emvco.com) and as such > can be read on any terminal complying to the EMV specifications. This > compliance is guaranteed by a mandatory EMVCo Level 1 type approval > (ensuring the application independent parts of a chip environment are OK) > for all terminals to be used for financial transaction. Also for the > terminals, the financial industry has set-out specific migration dates > (2005 as end date). > > For information on these, you can also visit the payment schemes web pages. > So, I do not understand WHY Jason is stating one would need to switch > readers .... > > As a second point the only interoperability guaranteed outside the Telecom > sector ETSI specs is withe the EMV specifications, who's exact aim is to > ensure all cards complying to spec can be used on any terminal complying to > the spec. > > Back to your basic question on multi-application: within the financial > sector, there are at least some 100 million multi-applicatoion cards in > usage. These cards hold more than one financial application e.g. an > international and a domestic debit application next to a purse or an > access application etc or even multiple sector applications e.g. payment, > transport and PKI etc. So, there do exist real multiplication cards in > the field. > > Hope this kills some mis-understandings about multi-application and > interoperability. > Mark Kamers > > > *************************************************************************** *************************************************************************** *********************************** > > If the reader of this message is not the intended recipient, or the > employee responsible for delivering this communication to the intended > recipient, you are hereby notified that any disclosure, distribution or > copying of this communication is strictly prohibited. If you have received > this communication in error, please notify us immediately by telephone to > arrange for its return. > Thank you. > *************************************************************************** *************************************************************************** *********************************** > > > > > "Jason > > Barkeloo" To: <[EMAIL PROTECTED]> > > <barkeloo@fus cc: > > e.net> Subject: RE: [OCF] Smart card application > > > 01/03/02 > > 12:53 > > > > > > > > > > Anne, > > You might want to check out what the French Banks are doing through Cartes > Bancaires with the new FinRead (Financial Reader) specifications being > promoted by the EU/EC. The specs are at: http://www.finread.com. > > Multiple applets are embedded in the reader, keyboard, or motherboard on a > co-processor. In this way, no matter what card is used it can be read and > accepted. It basically brings ATM functionality to the PC, PDA, Mobile > phone, STB, NIC, etc., anywhere the co-processor resides. > > This approach will bring down the price of the SCs, a rather large > impediment to deployment in North America. It also brings > interoperability, > which is grossly lacking today (one-to-one relationship between the reader > and the card). Imagine a consumer needing to plug in a different reader > each time he/she wants to use a different card. > > For example, say you have two different cards - a Visa and MasterCard. You > want to make a purchase using the Visa card. The reader plugged in is the > one with your MasterCard. Now you must unplug the MasterCard reader and > plug in the Visa reader. The wrinkle? Both readers are the same model > number from the same vendor! No interoperability. With FinRead, it is one > reader for any card. The match occurs within the embedded co-processor. > For each card there is an applet, not a separate reader. This is the ATM > functionality. > > I might add that if the PC OEMs deploy this solution, the movement of > movies, music, and other digital contents can be secured. Imagine an > applet > in the co-processor that "meters" the movement of digital content like a > utility. The artist gets paid, the PC OEM gets a micropayment for > facilitating the transaction, and card issuer still gets its micropayment > too. > > Regards, > jb > > > > > -----Original Message----- > From: GHOSHAL,Biswajit [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 28, 2002 11:42 PM > To: [EMAIL PROTECTED] > Subject: RE: [OCF] Smart card application > > > Hi Anne, > > Whatever said and done, till now smart-cards are yet to become "smart" > (i.e. > - use a single card to access various kind of applications). Card vendors, > in collaboration with financial institutes in different countries are > implementing single-application smart-cards only. Some intellegent people > are developing web-apps that can interact with smart-cards. But I don't > know of any implementation where using a single-card one can interact with > different kind of applications...if anyone else in this mailing-list know > of > such implementation - please let others know... > > Best Regards, > Biswajit > > > -----Original Message----- > > From: Anne Kwong [SMTP:[EMAIL PROTECTED]] > > Sent: Friday, March 01, 2002 12:55 AM > > To: [EMAIL PROTECTED] > > Subject: [OCF] Smart card application > > > > Hello. > > > > Could anyone let me know if there are any websites or books out there > that > > talks about how people use smartcard today and what kind of application > > people are developing? > > > > Thanks for any info that you can provide. > > > > Anne > > > > > > --- > > > Visit the OpenCard web site at http://www.opencard.org/ for more > > > information on OpenCard---binaries, source code, documents. > > > This list is being archived at > http://www.opencard.org/archive/opencard/ > > > > ! To unsubscribe from the [EMAIL PROTECTED] mailing list send an > email > > ! to > > ! [EMAIL PROTECTED] > > ! containing the word > > ! unsubscribe > > ! in the body. > > > --- > > Visit the OpenCard web site at http://www.opencard.org/ for more > > information on OpenCard---binaries, source code, documents. > > This list is being archived at http://www.opencard.org/archive/opencard/ > > ! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email > ! to > ! [EMAIL PROTECTED] > ! containing the word > ! unsubscribe > ! in the body. > > > > --- > > Visit the OpenCard web site at http://www.opencard.org/ for more > > information on OpenCard---binaries, source code, documents. > > This list is being archived at http://www.opencard.org/archive/opencard/ > > ! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email > ! to > ! [EMAIL PROTECTED] > ! containing the word > ! unsubscribe > ! in the body. > > > > > > > > ********************************************************************** > This e-mail and any attachments to it may contain confidential information which is strictly intended for the use of the authorised recipient. If you have received this e-mail in error, please delete it and notify the sender by replying to this e-mail. > Thank you for your co-operation. > ********************************************************************** > > > --- > > Visit the OpenCard web site at http://www.opencard.org/ for more > > information on OpenCard---binaries, source code, documents. > > This list is being archived at http://www.opencard.org/archive/opencard/ > > ! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email > ! to > ! [EMAIL PROTECTED] > ! containing the word > ! unsubscribe > ! in the body. > > --- > Visit the OpenCard web site at http://www.opencard.org/ for more > information on OpenCard---binaries, source code, documents. > This list is being archived at http://www.opencard.org/archive/opencard/ ! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email ! to ! [EMAIL PROTECTED] ! containing the word ! unsubscribe ! in the body.
