W3C home > Mailing lists > Public > public-webpayments-ig@w3.org > September 2015

RE: FAQ question: Relation of proposed Web Payments WG to Secure Electronic Transaction (SET)?

From: David Jackson <david.dj.jackson@oracle.com>
Date: Sun, 13 Sep 2015 15:33:19 -0700 (PDT)
Message-ID: <3dfd75fa-2b0a-4d8f-817d-95348cc607b0@default>
To: Adrian Hope-Bailie <adrian@hopebailie.com>, Dan Schutzer <cyberdan250@gmail.com>
Cc: David Ezell <David_E3@verifone.com>, Ian Jacobs <ij@w3.org>, Web Payments IG <public-webpayments-ig@w3.org>
I have personally implemented two variations of SET protocol in the US and EU – if there is anything of interest from the actual vendor implementations of this former protocol and the couple of variants I worked previously – I am very glad to chat about this on a future call. But the issue with respect to SET and it’s complexity was related to the hierarchy of trust and less to do with the actual management of the protocol itself.  Please also note, that SET was developed prior to common acceptance of ssl. So it addressed several issue concurrently that are not required in today’s environment.

 

-- 
David Jackson | Senior Director Financial Services
Mobile: HYPERLINK "tel:+16145601237"+16145601237 | VOIP: HYPERLINK "tel:+16144656654"+16144656654 
Oracle Global Industry Solutions Group
New York City | Columbus, Ohio

MySig

 

From: Adrian Hope-Bailie [mailto:adrian@hopebailie.com] 
Sent: Sunday, September 13, 2015 3:45 PM
To: Dan Schutzer
Cc: David Ezell; Ian Jacobs; Web Payments IG
Subject: Re: FAQ question: Relation of proposed Web Payments WG to Secure Electronic Transaction (SET)?

 

As far as I know SET depended on client certificates issued to card holders by their banks and as has been the case with anything based on client certs adoption was very poor. (Speaks to the complexity issue already raised)

 

On 13 September 2015 at 14:04, Dan Schutzer <HYPERLINK "mailto:cyberdan250@gmail.com"cyberdan250@gmail.com> wrote:

I generally agree with David's observations regarding SET. 

 

An interesting article on SET and its failure is provided below:

http://www.cnet.com/news/visa-mastercard-try-to-revive-set/

 

Some other distinctions between SET and what this group is trying to do is worth noting

 

1. SET was only concerned with securing credit card transactions. There were lots of new innovative payment start-ups during that time but SET was not interested in enabling interoperability with any of them

2. SET was not only complex to implement and operate, but it took way too long to process a transaction.

3. SET operated in a much more restricted processing environment - much less computational and communication processing power and bandwidth than today. 

4. Security was not the overarching issue then that it is now - fraud over the Internet was very minimal

5. There was no mobile - Internet payment and POS payment were separate problems  

6. Actually there was effort to provide for merchants the data they said they needed. There was also an effort to protect sensitive cardholder data needed by the issuing bank from the merchants, and to portect the sensitive retail data needed by the merchants from the issuing banks, but the technical solution for doing this only added to the complexity and processing time.

 

Dan

 

On Sat, Sep 12, 2015 at 10:26 AM, David Ezell <HYPERLINK "mailto:David_E3@verifone.com"David_E3@verifone.com> wrote:

Hi Ian:

The short answer is that SET attempted to do some of the things that Web Payments considers important.

The longer answer is that the technology had two drawbacks that kept it from catching on:
1) it was complex to implement
2) it rendered the customer data opaque to the merchant

I have a friend from Ireland who was part of the Trintech effort to implement SET (Trintech is now part of Verifone) with a lot of hands-on and I daresay bitter experience with the effort:
        Trintech "made world's first secure Internet purchase using their 1.0 version of the Secure Electronic
        Transaction (SET) standard."
        http://www.irishtimes.com/business/trintech-a-leader-in-internet-buys-1.116342

In my opinion, what Web Payments is trying to do differs from SET in the following important ways:
1) we have an aspect of our work which addresses the UI and developer capabilities
2) we have a sensitivity (which SET did not have) that merchants have a need for KYC, and we know that
     KYC capability need not >necessarily< introduce privacy concerns.
3) we have more widespread access to standard cryptography than they did in 1997 (OpenSSL, etc.)
4) web services have matured and will play a role in exchange of data

Was SET a bad idea? No.  Was it ahead of its time? Maybe, but that's hard to quantify.  Did it have flaws that stunted its adoption?  Yes, and I've mentioned at least two.  There may be other reasons.

HTH.

Best regards,
David


-----Original Message-----
From: Ian Jacobs [mailto:HYPERLINK "mailto:ij@w3.org"ij@w3.org]
Sent: Friday, September 11, 2015 6:18 PM
To: Web Payments IG
Subject: FAQ question: Relation of proposed Web Payments WG to Secure Electronic Transaction (SET)?

Hi Interest Group,

This week I was asked:

 Q. What is the relation of this work to Secure Electronic Transaction
      https://en.wikipedia.org/wiki/Secure_Electronic_Transaction

Being new to this space, I did not know the answer.

Would someone knowledgable about that work be able to compare and contrast the efforts?

Thank you,

Ian

--
Ian Jacobs <HYPERLINK "mailto:ij@w3.org"ij@w3.org>      http://www.w3.org/People/Jacobs
Tel:                       HYPERLINK "tel:%2B1%20718%20260%209447"+1 718 260 9447




________________________________
This electronic message, including attachments, is intended only for the use of the individual or company named above or to which it is addressed. The information contained in this message shall be considered confidential and proprietary, and may include confidential work product. If you are not the intended recipient, please be aware that any unauthorized use, dissemination, distribution or copying of this message is strictly prohibited. If you have received this email in error, please notify the sender by replying to this message and deleting this email immediately.

 

 
Received on Sunday, 13 September 2015 22:34:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:08:44 UTC