Everyone,

Things, as of now, are pretty much imperfect...e.g. - the interoperability
issue - I think, that is what this OCF tries to address.  Though I didn't
know of the Finnish and French revolutions (on smart-cards :-)) - but they
seems to be good for the business, but not so good from the user-standpoint.

Also, we must not forget that, the latest smart-cards - like, Javacard, have
their own small processing ability.  The storage-cards may be the slaves of
the applications - which helps the card-issuer, acquirer etc to take contol.
But using Javacards, there exists opportunities, at least conceptually to
hand over better percentage of control to the user.  I think, in future, the
success of applications and hence businesses, will depend upon the factor as
who can give more control to the user, instead of retaining it.

Best Regards,
Biswajit

> -----Original Message-----
> From: Jason Barkeloo [SMTP:[EMAIL PROTECTED]]
> Sent: Saturday, March 02, 2002 6:04 AM
> To:   [EMAIL PROTECTED]
> Subject:      RE: [OCF]  RE: An Alternative Look at the FinRead Reader
> 
> Scott,
> 
> I'm not sure of the root of your venom.  Did I say something?
> 
> Are you saying that artists aren't entitled to the rights of their
> products
> and it should be free?  A new idea...starving artists!
> 
> I believe in placing trust in transactions with the users.  Would you walk
> into a retail store and hand them your wallet?  In the current eCommerce
> model that is what happens.  I believe in democratizing the eCommerce
> structure and putting control of transactions into the hands of the
> consumers, not into a centralized database to be hacked.  You might be a
> systems administrator, eh?  That is a centralized governing system with no
> trust or power of control given to the consumers.
> 
> Prior to the French Revolution, everything was centralized, if even on a
> micro level.
> 
> SCs bring part of the control to the consumer.  Embedded "vaults" allow
> the
> consumer to trust the system.  They are complimentary, not contrarian.
> I'm
> not sure where we disagree.  Are you against laws that protect the
> intellectual property of creators?
> 
> The beauty of decentralizing control is that the transaction is trustable
> by
> the consumer.  The centralized authority (systems administrators, etc.)
> are
> never a part of it.  That is what I prefer.  I believe that the people
> should be in control and not the centralized authority like it is now.
> 
> Best Regards,
> jb
> 
> 
> 
> 
> -----Original Message-----
> From: Scott Guthery [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 01, 2002 5:12 PM
> To: 'Jason Barkeloo'; [EMAIL PROTECTED]
> Subject: RE: [OCF] RE: An Alternative Look at the FinRead Reader
> 
> 
> Jason, et al ...
> 
> "Be careful what you ask for because you
> just might get it."
> 
> The various digital rights dicta in circulation
> both in the US and the EU would require all
> devices capable of carrying media content to
> have hardware locks and keys to prevent copyright
> violations. Essentially, these laws will turn
> all computers into closed, set-top boxes controlled
> by and from Hollywood.
> 
> This is the trusted platform you are wishing for.
> It is trusted by NatWest, France Telecom and Vivendi.
> You see it is YOU that is not trusted and therefore
> it is YOU that needs to be neutralized.
> 
> The one thing that the entertainment industry, the
> banking industry and the telecommunications industry
> all heartily agree on is that the user shall not be
> in control of the end-user device.
> 
> The tragedy here is that the smart card was a really
> Good Idea.  However the constant effort to weld it to a
> bigger box so you can make money off selling the
> bigger box kills the goose that lays the golden egg.
> 
> The value of the card doesn't transfer to the box nor
> does the value of the card justify the cost of the box.
> The value of the simply card vanishes because the
> value was premised on universal use which the welding
> denies.
> 
> Cheers, Scott
> 
> -----Original Message-----
> From: Jason Barkeloo [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 01, 2002 4:21 PM
> To: [EMAIL PROTECTED]
> Subject: [OCF] RE: An Alternative Look at the FinRead Reader
> 
> 
> Scott,
> 
> What about such a processor included on every motherboard?  Wouldn't that
> make it a bit different in the implementation model?
> 
> Microsoft is considering promoting it through the TCPA
> (http://www.trustedpc.org)
> and
> 
> http://research.microsoft.com/crypto/ (last one under "Project").
> 
> I know it seems like a wild stretch, but I think it is being heavily
> considered by everyone if this holds true:
> 
> http://yuan.ecom.cmu.edu/trust/cd/
> 
> Perhaps I'm not the swiftest arrow in the quiver, but if there were a
> unhackable vault built into the PC, keyboards, readers, then the
> portability
> issue that you spoke of might not be such a big deal?
> 
> Of course this would require a ubiquitous solution.
> 
> National Semiconductor seems to embrace it as of this week:
> 
> http://www.national.com/news/item/0,1735,733,00.html
> 
> the specs:
> 
> http://www.national.com/pf/PC/PC21100.html
> 
> I see this as a complimentary technology for SCs, particularly in N.
> America.  The SC can become a critical component of a trusted PC.
> 
> This study released on the unfortunately day of 11Sept01 seems to indicate
> this:
> 
> "Hart Poll Finds 72 percent of PC Owners Would Purchase a More Secure
> Computer If Available"
> 
> http://www.itsecurity.com/tecsnews/sep2001/sep149.htm
> 
> 
> Best Regards,
> jb
> 
> 
> -----Original Message-----
> From: Scott Guthery [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 01, 2002 8:07 AM
> To: 'Jason Barkeloo '; '[EMAIL PROTECTED] '
> Subject: An Alternative Look at the FinRead Reader
> 
> 
> 1) Replacing one $10 portable card many $100 stationary
> readers is not a compelling offer for either cardholders
> or smart card application developers.
> 
> 2) The approach assumes that there is a FinRead reader
> wherever you want to use your card AND that it has
> been loaded with the applet that goes with your card.
> 
> 3) And who holds the keys for the FinRead reader?  The
> keys that say what applets get loaded and therefore what
> cards can be used with the reader.  Neither the cardholder
> nor the application provider.  It's the bank.
> 
> 4) And who does the smart card application programmer
> have to go to to roll out their new application?  They
> have to ask permission of and pay fees to the holder
> of the keys to the FinRead reader.  Again the bank.
> 
> The bank's FinRead offer to cardholders is as follows:
> 
> "You pay me $100 for each computer on which you want
> to use your card and give me control of which card
> applications you can use.  In return, I will let you
> use my banking application ... for which I will charge
> you another fee."
> 
> The bank's FinRead offer to smart card application
> providers is as follows:
> 
> "You pay me an installation fee for each card you issue and
> pay me a transaction fee for every time your card is used.
> In return, I will allow your customers to use the reader
> they purchased from me with your cards."
> 
> The reason we have this problem is because card manufacturers
> only pay lip service to smart card standards.  Why do we think
> they will behave any different when they manufacture FinRead
> readers?  Just having a specification on paper is meaningless
> unless there is incentive to abide by it.  There is no more
> incentive to manufacture standard compliant readers than there
> is to manufacturer compliant smart cards.
> 
> Even if the FinRead readers were all electrically and
> physically inter-operable, the keys that they contain
> will not be.  An applet approved by CitiBank will not
> be able to be loaded into a FinRead reader controlled by
> NatWest.  FinRead in essence not only institutionalizes
> incompatibility, it monetizes it.  The cardholder and the
> smart card application provider will actually have to pay
> a fee for the privilege of using a non-interoperable system.
> 
> The alternative of course is to have a FinRead reader
> connected to your computer for each smart card application
> you want to use.
> 
> I must admit it's a brilliant business plan on the bank's part.
> Get the customer to pay to reduce the bank's risk and at the
> same time take control of who the customer does business with.
> 
> Only a clueless fool would connect a FinRead reader to their
> computer or PDA.
> 
> IMHO as always.
> 
> Cheers, Scott
> 
> -----Original Message-----
> From: Jason Barkeloo
> To: [EMAIL PROTECTED]
> Sent: 3/1/02 6:50 AM
> Subject: RE: [OCF]  Smart card application
> 
> 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.

Reply via email to