W3C home > Mailing lists > Public > public-web-security@w3.org > September 2015

Re: A Somewhat Critical View of SOP (Same Origin Policy)

From: Rigo Wenning <rigo@w3.org>
Date: Sat, 26 Sep 2015 12:48:48 +0200
To: ANDREAE Philip <P.Andreae@oberthur.com>
Cc: Anders Rundgren <anders.rundgren.net@gmail.com>, Brad Hill <hillbrad@gmail.com>, Alex Russell <slightlyoff@google.com>, "public-web-security@w3.org" <public-web-security@w3.org>, Tony Arcieri <bascule@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
Message-ID: <1564667.Jkex2KdVQ2@hegel>
On Friday 25 September 2015 0:52:05 ANDREAE Philip wrote:
> 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.

Two of them are out of the Origin and currently need a partner to participate 
in the same origin. "Pay with your xyz-account" is different from "pay now". 
> To offer this guarantee, issuers want to know that the consumer shopping on
> a merchant site is who they claim to be.  

Not even. You only want to know whether the person on the other side is 
willing and able to make the payment. This can be the case even if the person 
is not the person she claims to be. Shared accounts exist. You want to have 
valid credentials. Nothing to do with a a person. 

> They want to distribute a
> mechanism, token, card or unique identifier that is used to identify the
> Issuer and the associated financial account.  

Yes, you don't care about the consumer :). All you need is an issuer telling 
you that the credentials are sufficient for the liability. 

> They then want to deploy /
> employ a mechanism to authenticate the consumer presenting the credential
> is the rightful user.  

No, I only care for the credential. When my bank started to apply those 
"suspicious behavior" profiles to my credit card, they blocked it several 
times unduly exposing themselves to a high risk of liability if I'm stuck 
> In the physical store this is a card / phone / fob
> enabled with the necessary security features.

Card/phone/usb/NFC are one side, the merchant's website the other side. The 
conduit isn't there. 
> 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 is the identity management part which is not linked to the security part 
in FIDO, but it may be in other cases. We should distinguish them in our 
> 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.  

The universal identifier argument is missing the entire context of our 
> 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.  

All I want is peace on earth :) Making the missing conduit is difficult and 
will need a lot of brainwork IMHO.. 

Received on Saturday, 26 September 2015 10:49:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:09:38 UTC