Thanks Paul, Actually, there are two other aspcts of this that may alter your assessment, First, I am looking to set up a prior arrangement with a processing bank (a potential ally in any dispute with an issuing bank - establishing a trust relationship between me and the bank, and this would be the bank that processes the transaction for the merchant - it only works for those merchants who can get an account with a bank with which I have established such a relationship), and second, I am not the merchant, but rather, providing services to merchants (including use of OFBiz's back office functionality), so the data actually never touches a machine in the merchant's hands. I would provide an interface to my RA (so they never touch the machines either, just an interface, suitably hardened (using my Perl talents), that lets them enter the data they need to provide), as well as a web interface to the customers (again the only interaction I have with them). I would agree that this is not the sort of thing a merchant could effectively do on his own; but it becomes feasible if a third party, like myself, makes it happen with the aide of a prior relationship with one or more processing banks (it would be even more effective, though, if the issuing banks themselves became registration authorities (assuming they do the due diligence to verify the identities of the people to whom they issue credit cards ;-) ).
And note, this only deals with one of the many kinds of fraud, but the most frequent cause of ecommerce merchant bankruptcies I have seen. Cheers Ted On Tue, May 28, 2013 at 2:16 AM, Paul Foxworthy <[email protected]> wrote: > Hi Ted, > > OK, I understand your goals better now. > > For Tomcat, see http://tomcat.apache.org/tomcat-7.0-doc/config/http.html and > search for the clientAuth setting. > > Are you envisaging that the registration authority you mention will be your > own server or a third party? If the RA receives valid authentication > information and issues the customer with a certificate containing a private > key, you should be able to demonstrate that you don't know the key, and > therefore you are not in a position to forge an order from the customer. > > I doubt that a bank, faced with a chargeback request from a customer, will > set any store on a document that you claim has been signed with a private > key known only to the customer. Their choices are: > > 1. Audit your application to verify your claim that the customer must have > signed and approved the contract. Verify the encrypted document is > tamper-proof. Verify that the customer is indeed the owner of the relevant > client certificate, and nobody else could possible know the key. Evaluate > the veracity of the customer's claim that the key "must have been pinched by > somebody else". Cost: weeks of time and thousands of dollars > 2. Just repay the customer and claw the money back from the merchant's bank > account. Cost: almost zero. > > If you haven't ahead of time negotiated with every bank that any customer > might use, they would, I think, be on the customer's side and not yours in > the case of any dispute. > > Have you considered one of the e-signature services like Echosign > (www.echosign.adobe.com), Secured Signing (www.securedsigning.com), Docusign > (www.docusign.com/) or SignNow (signnow.com)? I see SignNow talks about an > API so you can integrate their service into applications. I presume others > do a similar thing. The bank may have heard of them before, and you have an > audit trail provided by an independent third party. You could receive an > order via a shopping cart in the usual way, and say to the customer the > contract will be sent via one of these services, and the order will be > filled once they sign the contract. > > If part of the point is that a customer or the bank can independently verify > that the transaction was done and hasn't been altered by you, why should > they believe anything that comes from your web site? While you could deliver > a document with a signature created with your private key, the software that > verifies that signature would need to be from a third party and not you to > give the customer any confidence no tampering was done. > > And one more thing I'd consider: bricks and mortar retailers need to factor > "shrinkage" like pilfering and shoplifting into their pricing. If you think > that a minority of customers might repudiate a transaction, would you be > better off self-insuring for the risk? You could set your prices to cover > the risk, make provision for it as part of every sale's proceeds, and live > with it when the bad thing happens. That might be more cost-effective than > investing in an elaborate non-repudiation scheme. > > One of our clients had a situation where the goods were delivered and the > courier had a record of the deliveree's name and a signature which appeared > to be the right name. The customer said it wasn't them, somebody else was > pretending to be them, don't know who. Short of suing, our client could only > refund their credit card and refuse to do business with them again. So a > customer can conceivably repudiate a sale even when the sales contract is > agreed by everyone. > > I haven't done it, but I agree it should be possible to map from a client > certificate to a user's identity. Similar things are discussed here > http://www.servlets.com/archive/servlet/ReadMsg?msgId=518530&listName=tomcat-user > and here (for Spring) > http://static.springsource.org/spring-security/site/docs/3.0.x/reference/x509.html > > Cheers > > Paul Foxworthy > > > > > ----- > -- > Coherent Software Australia Pty Ltd > http://www.coherentsoftware.com.au/ > > Bonsai ERP, the all-inclusive ERP system > http://www.bonsaierp.com.au/ > > -- > View this message in context: > http://ofbiz.135035.n4.nabble.com/Improving-OFBiz-security-tp4641462p4641563.html > Sent from the OFBiz - User mailing list archive at Nabble.com. -- R.E.(Ted) Byers, Ph.D.,Ed.D. [email protected] CTO Merchant Services Corp. 17665 Leslie st., unit 30 Newmarket , Ontario L3Y 3E3
