Hello, Jason and Mark ... Here are my answers to Jason's quesions:
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? >>> The American Express Blue and Fleet Fusion cards can be used >>> in virtually any smart card reader, PC/SC or not. Of course >>> you have to know what commands the card supports and what the >>> file hierarchy stored on the card is. You also have to have >>> authorization (the keys) to do what you want to do. As I understand it, and please correct me if I'm wrong, part of the FinRead specification was designed to overcome this interoperability issue. >>> FinRead does not overcome any interoperability issue. Suppose >>> you put a reader applet between the PC application and the card. >>> The PC application still has to know what commands the applet >>> accepts and what data model the applet supports. You haven't >>> solved the problem. You have only moved it from the edge of >>> the card into the reader. >>> >>> The FinRead model hardwires the card to the reader thereby >>> defeating the portabilty of the card and putting the entity >>> that controls the reader in control of the card. 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. >>> There's plenty of room on cards for payments and authentication >>> and cryptographic algorithms and lots more. On another note, don't the EMV readers also rely on this embedded co-processor architecture? >>> Mark has to address this, but on purely technical grounds you >>> can use an EMV card in a dumb, $5, pass-through reader. 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. >>> So I carry my FinRead reader with me everywhere I go? And why do >>> I want to buy multiple $100 readers to reduce the cost of one $10 >> card? >>> >>> I want my private keys and my biometric templates with me in an >>> easy-to-use, tamper-resistant, PIN-protected carrier. They >>> are of no use sitting at home embedded in a FinRead reader >>> on my desk. Is the FinRead specification working toward EMV compliance? >>> FinRead encourages the issuance of non-interoperable cards and >>> therefore works against the goals of EMV. > 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. --- > 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.
