On 08/01/2010 01:51 PM, Jeffrey I. Schiller wrote:
I remember them well. Indeed these protocols, presumably you are talking about Secure Electronic Transactions (SET), were a major improvement over SSL, but adoption was killed by not only failing the give the merchants a break on the fraud surcharge, but also requiring the merchants to pick up the up-front cost of upgrading all of their systems to use these new protocols. And there was the risk that it would turn off consumers because it required the consumers setup credentials ahead of time. So if a customer arrived at my SET protected store-front, they might not be able to make a purchase if they had not already setup their credentials. Many would just go to a competitor that doesn't require SET rather then establish the credentials.
SET specification predated these (as also internet specific, from the mid-90s, went on currently with x9a10 financial standards work ... which had requirement to preserve the integrity for *ALL* retail payments) ... the decade past efforts were later were much simpler and practical ... and tended to be various kinds of "something you have" authentication. I'm unaware of any publicity and/or knowledge about these payment products (from a decade ago) outside the payment industry and select high volume merchants. The mid-90s, PKI/certificate-based specifications tended to hide behind a large amount of complexity ... and provide no effective additional benefit over & above SSL (aka with all the additional complexity ... did little more than hide the transaction during transit on the internet). They also would strip all the PKI gorp off at the Internet boundary (because of the 100 times payload size and processing bloat that the certificate processing represented) and send the transaction thru the payment network with just a flag indicating that certificate processing had occurred (end-to-end security was not feasible). Various past posts mentioning the 100 times payload size and processing bloat that certificates added to typical payment transactions http://www.garlic.com/~lynn/subpubkey.html#bloat In the time-frame of some of the pilots, there were then presentation by payment network business people at ISO standards meetings that they were seeing transactions come thru the network with the "certificate processed" flag on ... but could prove that no certificate processing actually occurred (there was financial motivation to lie since turning the flag on lowered the interchange fee). The certificate processing overhead also further increased the merchant processing overhead ... in large part responsible for the low uptake ... even with some benefit of lowered interchange fee. The associations looked at providing additional incentive (somewhat similar to more recent point-of-sale, hardware token incentives in europe), effectively changing the burden of proof in dispute (rather than the merchant having to prove the consumer was at fault, the consumer would have to prove they weren't at fault; of course this would have met with some difficulty in the US with regard to regulation-E). Old past thread interchange with members of that specification team regarding the specification was (effectively) never intended to do more than hide the transaction during transnmission: http://www.garlic.com/~lynn/aepay7.htm#norep5 non-repudiation, was re: crypto flaw in secure mail standards aka high-overhead and convoluted, complex processing of the specification provided little practical added benefit over and above what was already being provided by SSL. oblique reference to that specification in recent post in this thread regarding having done both a PKI-operation benchmark (using BSAFE library) profile as well as business benefit profile of the specification (when it was initially published ... before any operational pilots): http://www.garlic.com/~lynn/2010l.html#59 A mighty fortress is our PKI with regard specifically to BSAFE processing bloat referenced in the above ... there is folklore that one of the people, working on the specification, admitted to a adding a huge number of additional PKI-operations (and message interchanges) to the specification ... effectively for no other reason than the added complexity and use of PKI-operations. -- virtualization experience starting Jan1968, online at home since Mar1970 --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
