The deeper I get into e-commerce, the more confused everything seems to get. Sometimes it seems that the computer industry invents a new TLA (three-letter acronym) every other day.
It was all so easy when Netscape started the ball rolling with the first of our TLAs - the Secure Sockets Layer or SSL. Netscape tried to convince users that moving away from Mosaic, the original browser, was a very good idea, especially if you didn't want any crooks to run up bills using your credit card.
Well it's all history now: Netscape zapped Mosaic but unfortunately it also scared the rest of the burgeoning Internet community half to death.
Perfectly reasonable people still refuse to send encrypted credit card details over the Web but will still quite happily give their details to an anonymous waiter or petrol station attendant. For many people SSL, or indeed anything else, just isn't secure enough to persuade them to send credit card details over the Web.
In its most basic form, SSL uses digital certificates on the server (merchant) side. This certificate tells the client browser (customer) that the company that issues a certificate, for example Verisign, has done some checking that the merchants are who they claim to be. Having myself applied for a number of certs., I wouldn't put any faith in these checks. They are minimal to say the least.
SSL became SSL-v2 and SSLv3 and brought with it greater and greater degrees of security. Holes were plugged and it now became possible to issue client certificates as well as merchant certificates. But the underlying SSL mechanism is still the same: public and private encyption keys are used, with a 40-bit or 128-bit key doing the encryption. Under normal circumstances it's 128-bit inside the US and 40-bit everywhere else.
Whatever anyone may tell you, 40-bit keys are strong enough for most purchases. Yes I'd want 128-bit keys for business purposes but 40 bits is fine for ordering books or CDs on the Web. You still need a room full of computers working flat out for a whole afternoon to decode an SSL message. There are so many SSL packets flying around that it will take a lot of afternoons to find a single credit card number.
Of much greater concern to me is what happens to your credit card details after they reach the merchant. Is the data encrypted or is it kept in plain text on the server where someone else can get their hands on your numbers? In essence, is the merchant trustworthy?
Which brings us nicely to SET or the Secure Electronic Transaction that was born out of an agreement between Visa, Mastercard, Netscape and Microsoft after some initial bickering. This TLA is designed to streamline the transaction from the customer to the banks via the merchant and to keep all the information as secure as possible.
The customer enters details in an electronic wallet which is passed to the Web server on the merchant's machine. This is sent via a payment gateway to the appropriate banks which transfer the money from the customer's credit card into the merchant's account. At no time does the merchant get to see any credit card details.
Sounds great, so why has SET been so slow on the uptake. Well there are a number of reasons. Firstly SET is a huge and complex beast. The specification alone is hundreds of pages long. An SSL implementation on a Web server will take a few hours to set up and is within the grasp of most developers. SET on the other hand will take a group of highly-paid consultants a few weeks to implement a proprietary solution.
There are also some concerns about the complex algorithms creating web server bottlenecks. Not a problem if you're selling one book a week but definitely something to consider if you're shifting ten flower bouquets every second.
Not only is SET more expensive and slower but the existing option, SSL, has already been made to work in almost as secure a fashion as SET. CyberCash provides a similar SSL solution where the possibility for credit card fraud on both the client and server end is limited to say the least. By adding a few hidden fields to your SSL-enabled form, Internet shoppers and merchants can have the best of both worlds. Safety at both the client and server ends.
However one of the problems with CyberCash is that as yet it really isn't an international solution. If you have what is known as a merchant account in the US, an account that can accept payment from credit cards, then CyberCash is ideal. But, believe me, opening a merchant account is hard enough when you're resident in the country, so I wouldn't expect much success if you're outside the US borders.
CyberCash has some points of presence in the UK and Japan but what about the rest of the world? This may go some way to explain why so many SET pilots take place outside North America.
Set is likely to become the standard in the future, if only for the possible reason that Visa and MasterCard will mandate it like the hologram. Their logic is that nobody ever expected gangs of criminals to go after computer memory chips so they want to have a tight a ship as possible before organised crime targets the Web. SET will offer that security and the credit card companies are taking the long term view.
Their incentive is that credit card transactions will be used for the majority of Internet purchases outside the business world.
But don't expect SET to come online anytime soon, well not before the end of the millennium. SET 1.0 was finally agreed last December and we're now in the testing phase with so far only four vendors having any sort of SET 1.0 certification - GlobeSet, Spyrus/Terisa Systems, VeriFone and our own Trintech from Dublin. And for the most part we're only talking partial certification of the wallets rather than a complete product certification.
Which brings us back to our final ecommerce TLA, namely TLS or transport layer security. TLS brings us full circle right back to SSL. It's surprisingly similar to SSL-v3 and is seen as SSL's ultimate replacement. However it operates, as its name suggests, at the transport layer (middle layer of the OSI 7-layer hierarchy) rather than at the application (top) layer where SSL currently functions.
Because it works at a much lower packet level, all TCP/IP communication can be encrypted rather than just HTTP. As yet TLS hasn't been finialized but I'd expect to see systems running on TLS a lot quicker than any fully fledged SET solutions. For the moment it seems the only people who want SET are the credit card companies. For my own e-commerce, I'm going to stick with the SSL/CyberCash solution and possibly, just possibly, TLS.
Godfrey Nolan: godfrey@riis.com.
See also www.riis.com