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]

Reply via email to