RE: Checking out using 3D and not 3D
On Monday, July 01, 2002 11:48 PM, Anders Rundgren wrote: > Does anybody have an idea on how a merchant is going to separate > customers being "3D-enabled" from those who are not? > > Automatically by checking the directory for a PAN-match or by > having an explicit 3D logotype to click on? A merchant verifies the enrollment of the cardholder by sending a verify enrollment request (VEReq) to the Directory. _ Tony Lewis ([EMAIL PROTECTED]) Chief Systems Architect, Application Architecture & Standards Visa International Service Association
Re: 3D Secure Protocol Oddity
Thanx Lynn, But I don't understand if you are supporting my view or not :-) In case it was against, I think you should take a deep look on 3D to verify that it is as far from end-to-end that is technically possible. The widely used method I suggested, is definitely end-to-end in my opinion (although not in X9.59 that requires local signatures which is not a part of the 3D protocol). Anders - Original Message - From: <[EMAIL PROTECTED]> To: "Anders Rundgren" <[EMAIL PROTECTED]> Cc: "internet-payments" <[EMAIL PROTECTED]> Sent: Tuesday, July 02, 2002 11:32 Subject: Re: 3D Secure Protocol Oddity I think one of the analysis done by the x9a10 comittee was about end-to-end security with flow thru transaction protocols effectively the current web, POS, non-web, etc message path sequence but with the transaction carrying end-to-end consumer authentication of the message (aka the x9.59 standard). I think that it is fairly standard fault, integrity and security analysis that an end-to-end flow-thru authenticated message is always significantly better than any multi-legged message protocol. Anders Rundgren <[EMAIL PROTECTED]> cc: 07/02/2002 02:38 Subject: 3D Secure Protocol Oddity AM List, An oddity in the 3D Secure protocol is in my opinion that the "final" and "critical" transaction is routed through the user's browser. Working for years with systems like OBI, Punchout, OCI where the final message is a purchase order, I note that these system are characterized by sending the final transaction server-to-server. This is based on the idea that your purchasing system (or in the case of 3D your bank) is a "business system" helping, and monitoring your business processes which means that it should now about problems before the you do (If a 3D transaction fails, your bank will know nothing, and since a failure can occurr anywhere, there are situations were no one will know what's happened). Interactivity is by no means hampered by this arrangement, it just means one [optional] step more communication-wise but with greatly improved tracibility. Cheers, Anders If you want, you can try out https://buyer.x-obi.com/BuyerASP/buyer and verify that ending a shopping-session in the business-system-end is not at all bad, rather the contrary. Takes some 10-15 minutes to perform.
Re: 3D Secure Protocol Oddity
I think one of the analysis done by the x9a10 comittee was about end-to-end security with flow thru transaction protocols effectively the current web, POS, non-web, etc message path sequence but with the transaction carrying end-to-end consumer authentication of the message (aka the x9.59 standard). I think that it is fairly standard fault, integrity and security analysis that an end-to-end flow-thru authenticated message is always significantly better than any multi-legged message protocol. Anders Rundgren <[EMAIL PROTECTED]> cc: 07/02/2002 02:38 Subject: 3D Secure Protocol Oddity AM List, An oddity in the 3D Secure protocol is in my opinion that the "final" and "critical" transaction is routed through the user's browser. Working for years with systems like OBI, Punchout, OCI where the final message is a purchase order, I note that these system are characterized by sending the final transaction server-to-server. This is based on the idea that your purchasing system (or in the case of 3D your bank) is a "business system" helping, and monitoring your business processes which means that it should now about problems before the you do (If a 3D transaction fails, your bank will know nothing, and since a failure can occurr anywhere, there are situations were no one will know what's happened). Interactivity is by no means hampered by this arrangement, it just means one [optional] step more communication-wise but with greatly improved tracibility. Cheers, Anders If you want, you can try out https://buyer.x-obi.com/BuyerASP/buyer and verify that ending a shopping-session in the business-system-end is not at all bad, rather the contrary. Takes some 10-15 minutes to perform.
3D Secure Protocol Oddity
List, An oddity in the 3D Secure protocol is in my opinion that the "final" and "critical" transaction is routed through the user's browser. Working for years with systems like OBI, Punchout, OCI where the final message is a purchase order, I note that these system are characterized by sending the final transaction server-to-server. This is based on the idea that your purchasing system (or in the case of 3D your bank) is a "business system" helping, and monitoring your business processes which means that it should now about problems before the you do (If a 3D transaction fails, your bank will know nothing, and since a failure can occurr anywhere, there are situations were no one will know what's happened). Interactivity is by no means hampered by this arrangement, it just means one [optional] step more communication-wise but with greatly improved tracibility. Cheers, Anders If you want, you can try out https://buyer.x-obi.com/BuyerASP/buyer and verify that ending a shopping-session in the business-system-end is not at all bad, rather the contrary. Takes some 10-15 minutes to perform.
