<?xml version="1.0" encoding="utf-8"?>
<?xml-stylesheet type="text/css" href="http://commons.oreilly.com/wiki/skins/common/feed.css?97"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
	<channel>
		<title>Beautiful Trade/Secure Electronic Transaction - Revision history</title>
		<link>http://commons.oreilly.com/wiki/index.php?title=Beautiful_Trade/Secure_Electronic_Transaction&amp;action=history</link>
		<description>Revision history for this page on the wiki</description>
		<language>en</language>
		<generator>MediaWiki 1.11.0</generator>
		<lastBuildDate>Thu, 23 May 2013 02:46:03 GMT</lastBuildDate>
		<item>
			<title>Ebellis: New page: '''Secure Electronic Transaction'''   Secure Electronic Transaction (SET) is a protocol Visa and MasterCard developed in 1996 for  securing credit card transactions over insecure networks ...</title>
			<link>http://commons.oreilly.com/wiki/index.php?title=Beautiful_Trade/Secure_Electronic_Transaction&amp;diff=24536&amp;oldid=prev</link>
			<description>&lt;p&gt;New page: '''Secure Electronic Transaction'''   Secure Electronic Transaction (SET) is a protocol Visa and MasterCard developed in 1996 for  securing credit card transactions over insecure networks ...&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;'''Secure Electronic Transaction''' &lt;br /&gt;
&lt;br /&gt;
Secure Electronic Transaction (SET) is a protocol Visa and MasterCard developed in 1996 for &lt;br /&gt;
securing credit card transactions over insecure networks such as the Internet. SET utilizes &lt;br /&gt;
X.509 certificates and extensions, along with public key cryptography to identify each party &lt;br /&gt;
within the e-commerce transaction and transmit the data while maintaining confidentiality. &lt;br /&gt;
SET’s unique binding algorithm substitutes a temporary certificate for the consumer’s account &lt;br /&gt;
number, so that the online merchant never needs access to this sensitive information. Each &lt;br /&gt;
party is required to preregister with the certificate authority (CA), allowing the card issuer to &lt;br /&gt;
perform due diligence before it allows the merchant to perform e-commerce transactions, and &lt;br /&gt;
then authenticating all parties in the transaction. &lt;br /&gt;
&lt;br /&gt;
On the consumer end, SET creates a hash value of the order information together with the &lt;br /&gt;
payment information. The payment information is sent to the bank along with the signed hash &lt;br /&gt;
of the order information. The consumer-side software also sends the order information to the &lt;br /&gt;
merchant with the signed hash of the payment information. Both the cardholder and the &lt;br /&gt;
merchant create equivalent hashes, compared when they are received by the bank or payment &lt;br /&gt;
gateway. &lt;br /&gt;
&lt;br /&gt;
This protocol offers a number of different protections for the transaction: &lt;br /&gt;
&lt;br /&gt;
• It authenticates all parties in the initial transaction at time of registration with the CA. &lt;br /&gt;
• It performs additional authentication at transaction time through the exchange of &lt;br /&gt;
certificates with the consumer, merchant, and payment gateway. &lt;br /&gt;
• Sensitive data such as the account number is shared only between the consumer and the &lt;br /&gt;
bank and kept on a “need to know” basis, freeing the merchant from the need to store or &lt;br /&gt;
transmit this information. &lt;br /&gt;
&lt;br /&gt;
SET transactions &lt;br /&gt;
&lt;br /&gt;
The sequence of events required for a transaction follow: &lt;br /&gt;
&lt;br /&gt;
1. The customer obtains a credit card account with a bank that supports electronic payment &lt;br /&gt;
and SET. &lt;br /&gt;
&lt;br /&gt;
2. The customer receives an X.509 v3 digital certificate signed by the bank. &lt;br /&gt;
&lt;br /&gt;
3. The customer places an order. &lt;br /&gt;
&lt;br /&gt;
4. Each merchant has its own certificate, which it sends to the customer so his software can &lt;br /&gt;
verify that it’s a valid store. &lt;br /&gt;
&lt;br /&gt;
5. The order and payment are sent. &lt;br /&gt;
&lt;br /&gt;
6. The merchant requests payment authorization from the issuing bank. &lt;br /&gt;
&lt;br /&gt;
7. The merchant confirms the order. &lt;br /&gt;
&lt;br /&gt;
8. The merchant ships the goods or provides the service to the customer. &lt;br /&gt;
&lt;br /&gt;
9. The merchant requests payment. &lt;br /&gt;
&lt;br /&gt;
'''Evaluation of SET''' &lt;br /&gt;
&lt;br /&gt;
Unfortunately, due to the amount of overhead involved in the massive Public Key &lt;br /&gt;
Infrastructure (PKI) and registration process required by SET, it will never be widely adopted. &lt;br /&gt;
The complexities with managing it become unbearable given the size of the e-commerce &lt;br /&gt;
market.&lt;/div&gt;</description>
			<pubDate>Tue, 30 Jun 2009 02:22:10 GMT</pubDate>			<dc:creator>Ebellis</dc:creator>			<comments>http://commons.oreilly.com/wiki/index.php/Talk:Beautiful_Trade/Secure_Electronic_Transaction</comments>		</item>
	</channel>
</rss>