the limits of crypto and authentication

Aram Perez aramperez at mac.com
Fri Jul 15 00:38:46 EDT 2005


On Jul 14, 2005, at 8:13 PM, Rich Salz wrote:

>> 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?
>
> I was told that one of the reasons SSL took off was because Visa  
> and/or MC
> told merchants they would "for the time being" treat SSL as card- 
> present,
> in terms of fraud penalties, etc.  If this is true (anyone here  
> verify?
> My source is on the list if s/he wants to name themselves), then  
> SSL/SET
> is an interesting example of betting on both sides.

On the contrary, merchants were (and maybe still are) being charged  
MOTO (mail order/telephone order) rates for using SSL. Even SET was  
going to charge MOTO rates until just before it was finalized. The  
payment card companies weren't getting enough interest for SET and  
decided to offer card-present rates to get more interest in SET. SSL  
took off because it was free, in over 90% of the browsers (Netscape  
own the browser market then), and it was easy to integrate into  
shopping carts. As a merchant, basically your only cost was your  
VeriSign cert.

But you are correct in that the payment card companies were in an  
interesting position: on one hand they charge higher rates for using  
SSL but on the other hand, the "perception" was that something more  
secure than SSL was needed.

One other point, SET did NOT require certs for the consumers. The  
client-merchant protocol supported clients without certs.

Respectfully,
Aram Perez


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list