The Internet Encyclopedia (Volume 3)

P1: JDV

Merkow WL040/Bidgolio-Vol I WL040-Sample.cls June 20, 2003 12:46 Char Count= 0

248 SECUREELECTRONICTRANSACTIONS(SET)

MasterCard Web site for a public comment period. Mas-

terCard had hoped that SEPP could be in use for Internet

transactions as early as April 1996.

Incompatible Payment Card Standards

STT and SEPP generated such heated debate and finger

pointing between the two opposing factions that the entire

industry was at odds. Both sides claimed their standards

were defined with “openness in mind” and was designed

in cooperation with the Internet standards-setting bodies,

the W3 Consortium, the Internet Engineering Task Force

(IETF), CommerceNet, and the Financial Services Tech-

nology Consortium.

Industry and financial services observers at the time

believed that STT and SEPP were similar, yet different

enough to render them incompatible. This meant that

separate implementation efforts were required, and all

parties desiring to support Visa and MasterCard products

needed separate processing systems to meet the unique

requirements of each protocol.

Not So Different After All

In fact, STT and SEPP both attempted to achieve the same

objectives, but did so from different directions. These ob-

jectives included

Changing Internet-based credit card transactions from

the riskycard-not-presentscenario (such as mail or-

der/telephone order transactions) to the less riskycard-

presentsituation (such as retail shopping and eateries)

to reduce the chances of fraud and increase the po-

tential to lower the fees that merchants must pay for

maintaining merchant accounts.

Requiring all parties in a transaction (customer, mer-

chant, credit card processor, or bank) to possess dig-

ital certificates that establish their identities and their

authority to conduct transactions.

Requiring that public-key certification agencies (Certifi-

cate Authorities) manage the certificate distribution

processes on behalf of the card associations or member

banks.

Using industry-standard public-key cryptography tech-

niques, as developed by Ron Rivest, Adi Shamir, and

Leonard Adelman (RSA Data Security).

Encrypting only credit card numbers and transactional

data rather than encrypting the entire browser and

shopping sessions.

Concealing credit card data from all merchants to prevent

merchant-initiated fraud and reduce the risk of oper-

ating a merchant commerce server.

Enabling use ofanytype of credit card product, regardless

of issuer. The card associations however, reserved the

right to specify that onlytheirprotocols be permitted

for transactions with their cards.

By the end of 1995, banks that issued both Visa and

MasterCard were up in arms against the attempt to force

two separate standards that accomplished the same task.

The banks persisted and finally forced Visa and Master-

Card to work together on asinglestandard, because sup-

porting two separate ones appeared unachievable.

In February 1996, an announcement rocked the Inter-

net community:

Visa & MasterCard Combine Secure Specifica-

tions for Card Transactions on the Internet Into

One Standard.

SET Consortium Established

According to the agreement, Visa and MasterCard, along

with GTE, IBM, Microsoft, Netscape Communications

Corp., SAIC, Terisa Systems, Verisign, and RSA Data Se-

curity formed the SET Consortium. Its goal was to resolve

the differences and conflicts between STT and SEPP and

develop a new unified standard.

The development of SET arose not so much from a

spirit of mutual cooperation as from the intervention of

major banks that saw the industry giants, Visa and Mas-

terCard, heading in separate, nonintersecting directions.

Obviously, for any pragmatic solution to the problems of

electronic commerce, a single, standard approach, both

flexible and platform-independent, was needed.

SET is designed to eliminate most problems of credit

card usage and data management on the Internet, adding

the following elements:

Message authenticationto assure entities involved in a

credit card transaction that they are dealing with

whom they think they are dealing

Data integrityto prevent spoofed messages

Confidentialityto prevent eavesdropping

The first version of SET, based on the work of the SET

Consortium, was released to software developers in draft

form on June 24, 1996. The draft release, embodied in

three separate electronic books, was intended to be used

for testing and to elicit comments from outside experts.

These books contained preliminary specifications suffi-

cient for developers to build components that would “bolt

on” to existing cardholder browsers, merchant commerce

servers, and financial institution credit authorization sys-

tems. SET Version 0.0 appeared as follows:

Book 1—The business description containing background

information and processing flows. It was intended as a

primer on software that interfaces with payment sys-

tems and employs public-key cryptography.

Book 2—The programmer’s guide containing the techni-

cal specifications for the protocol, intended for use by

software developers who wished to build cardholder

and merchant software components.

Book 3—The formal protocol definition, intended for use

by cryptographers analyzing SET’s security aspects,

writers producing programming guides for toolkits

or components, and system programmers developing

cryptographic and messaging primitives. The formal

protocol is cast in Abstract Syntax Notation (ASN.1).

With the initial release, SET Version 0.0 was placed un-

der change control with a January 1997 deadline for en-

hancement requests to Version 1.0, and March 1997 for

proposed corrections to the testing version. On April 21,