Aram Perez wrote: > While the SET protocol was complicated, it's failure had nothing to do > with that fact or the lack of USB on PCs. You could buy libraries that > implemented the protocol and the protocol did not require USB. IMO, the > failure had to do with time-to-market factors. In the late 90s, when > ecommerce was just at it's infancy and you took the risk of setting up > a web store, were you going to wait you could integrate a SET toolkit > into you web site and until your customers had SET wallets installed on > their PCs before selling a product? Or were you going to sell to anyone > who used a web browser that supported SSL? It was very simple > economics, even if you had to pay VeriSign $400 for your SSL > certificate and pay Visa/MasterCard a higher fee.
can you say that that processing overhead was on the order of 20-30 seconds (on completely unloaded infrastrucutre ... demos at shows and conferences ... can you imagine what a little bit of queuing load would do to it?) ... if merchants thot SSL was onerous ... just imagine what SET did to the infrastructure .... and it provided effectively no additional improvement over fraud vis-a-vis effectively only addressing the confidentiality of account numbers as data-in-flight. SSL was the encumbant, was significantly less complex and significantly lighter weight (even tho most merchants decided that it was too heavy except for the credit card portion) and provided effectively the same amount of anti-fraud as SET. If you had two products ... both effectively performing the same function, one you already had deployed, which was significantly cheaper, significantly simpler, and significantly faster, which one would you choose? --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]