1997-11-13 - Re: SET

Header Data

From: Jeremey Barrett <jeremey@bluemoney.com>
To: John Deters <jad@dsddhc.com>
Message Hash: c155ee7e781ecde89dd63b8bd29af2ab93682d496d913afc2302a540d91684a4
Message ID: <199711122359.PAA21389@einstein.bluemoney.com>
Reply To: <3.0.5.32.19971112165216.00990790@labg30>
UTC Datetime: 1997-11-13 00:03:39 UTC
Raw Date: Thu, 13 Nov 1997 08:03:39 +0800

Raw message

From: Jeremey Barrett <jeremey@bluemoney.com>
Date: Thu, 13 Nov 1997 08:03:39 +0800
To: John Deters <jad@dsddhc.com>
Subject: Re: SET
In-Reply-To: <3.0.5.32.19971112165216.00990790@labg30>
Message-ID: <199711122359.PAA21389@einstein.bluemoney.com>
MIME-Version: 1.0
Content-Type: text/plain



-----BEGIN PGP SIGNED MESSAGE-----

John Deters writes:
 > At 11:18 AM 11/12/97 -0800, Jeremey Barrett you wrote:
 > >Perhaps... OTOH, SET is SO bad that it will be impossible to deploy,
 > >probably forcing everyone away from it anyway.
 > 
 > Having spent the last ten years at this retail outfit, I can assure you
 > that "impossible to deploy" != "won't be deployed".  If Mastercard tells us
 > that they will jack our rates by 0.5% for every transaction processed
 > without SET, then management will demand SET be rolled out.  Function be
 > damned, security be damned, as long as some bookkeeper somewhere is
 > satisfied that SET happens, then we avoid a huge rate increase.

I don't doubt that... but when they get zero orders because _noone_
has a SET wallet much less SET certs for their cards, that decision
will get re-evaluated pretty quickly (I would think). If the consumer 
has to get out of their chair to use SET, it's dead. And they have to 
do considerably more than that IMO.

The infrastructure required for SET to actually be used is outrageous,
especially for the consumer. All IMHO of course.

 > 
 > If the security of SET is questioned in the trade rags, our management's
 > approach will be to assume that Mastercard will fix it in the future, but
 > roll it out now anyway.  OTOH, it's obvious (even to them) that SET
 > couldn't possibly be any *less* secure than current authorizing techniques.
 > 

True enough...

Regards,
Jeremey.
- -- 
Jeremey Barrett                                BlueMoney Software Corp.
Crypto, Ecash, Commerce Systems               http://www.bluemoney.com/
PGP key fingerprint =  3B 42 1E D4 4B 17 0D 80  DC 59 6F 59 04 C3 83 64

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBNGpC+C/fy+vkqMxNAQHrUAP9Hes9evGvVtIHXkf/STd61cO/biAFX/kf
prAIvveGtdjPId2OHldv3ws4jAZU9swTArcG5/7QYf+pmes/Yyu+pfswEMQp/y64
w0Nk9TA8ojSvQBAy7Mf6i23jcyoocISozh8yqNdG7E5LcL2qeW6K4eUxEQZmd+Nb
HSTj/ExeH/s=
=un1A
-----END PGP SIGNATURE-----






Thread