As someone who has been around payments for my entire life and as a member of the Board of FIDO, I ponder this whole discussion and the intensity of the dialogue and the combativeness of the participants.
When eh email below offered the following as the root cause of the discussion I felt an education in Payments is required. >> Since payment resources regardless if they reside in the browser, platform, >> or in the cloud do not have any a priori relation with merchants it seems >> that SOP isn't really applicable to Web Payments? >> It would be great if the yet to be launched Web Payment WG which is supposed >> to produce a Browser Payment API in the coming 6-18 months got some input in >> advance on this matter from the Web Architecture community. The world of payments is simple and often times miss understood. There is a consumer (buyer) sitting at home on a browser, browsing, shopping and ultimately being asked to pay for whatever they decided to buy or procure. There is a merchant (seller) and their supporting technology partners, presenting good and services for sale and ultimately, wanting to make a profit for their efforts. There is an acquirer or merchant bank and their supporting technology partners, who are willing to process payments received from these consumers and to be paid towards the merchant. They often times are willing to take on certain risks associated with the receipt of the moneys the consumer has committed to pay. Finally there is the consumers bank, credit union of other intermediary e.g. PayPal, often called the Issuer, who is either holding the consumer funds on deposit or is extending secured or unsecured credit to the consumer. These four actors and their technology partners ultimately must agree to a set of rules and operating principles that consider risk, address the guarantee of payment and ultimately settle funds between accounts in multiple institutions. To offer this guarantee, issuers want to know that the consumer shopping on a merchant site is who they claim to be. They want to distribute a mechanism, token, card or unique identifier that is used to identify the Issuer and the associated financial account. They then want to deploy / employ a mechanism to authenticate the consumer presenting the credential is the rightful user. In the physical store this is a card / phone / fob enabled with the necessary security features. Merchants sometimes care that they consumer is a loyal repeat customer and may build alternate methods of affecting payment, possibly by storing the consumers preferred payment credentials. Most often times they simply want anyone interested in shopping, and most importantly paying; to be able to visit their site, browse and present something that will assure a guarantee of payment. This guarantee of payment is exactly what International Standards Organization ISO created with publication of the ISO 8583 authorization request and related authorization response. It is exactly why the current ACH model is not effective. There is not a guarantee of "good Funds" available to the merchant at the time the buyer offers their bank account details or requests their FI to push funds at the merchants bank account. All of the SOP stuff and the discussion of a universal identifier misses the point. All the payments industry is asked the browser community to provide are the tools that will allow, the existing parties to the payment process, a means of extending that guarantee of payment in cyber space. Bottom line the consumer wants to be able to use the services attached to their prepaid account, checking account, saving account or "Line of Credit" their Financial Institution is offering. They want these services to offer a guarantee of payment to the merchant and more importantly to be accepted at a large variety of merchants. The merchant simply wants to accept the method of payment consumers currently have and their bank says will offer a guarantee of payment. Nothing more. We are not here to design a new payment system, we are here to enable the existing. The dialogue above intentionally excludes consideration for mechanism that resemble the payment of goods and services through the exchange of real value e.g. Cash, Gold, Bit coins.. I am only attempted to discuss the payment process associated with an accounted system billions of people are familiarly with and comfortable using. Philip Andreae 9640 -----Original Message----- From: Anders Rundgren [mailto:anders.rundgren....@gmail.com] Sent: Thursday, September 24, 2015 2:27 AM To: Brad Hill; Alex Russell Cc: public-web-security@w3.org; Tony Arcieri; public-webapp...@w3.org; Rigo Wenning Subject: Re: A Somewhat Critical View of SOP (Same Origin Policy) Would it be possible taking a step back and return to the question which unfortunately created this tornado of moderately entertaining e-mails? https://lists.w3.org/Archives/Public/public-webappsec/2015Sep/0166.html Since payment resources regardless if they reside in the browser, platform, or in the cloud do not have any a priori relation with merchants it seems that SOP isn't really applicable to Web Payments? It would be great if the yet to be launched Web Payment WG which is supposed to produce a Browser Payment API in the coming 6-18 months got some input in advance on this matter from the Web Architecture community. - Anders
