W3C home > Mailing lists > Public > public-webappsec@w3.org > March 2017

Single Trust and Same-Origin Policy v2

From: John Wilander <wilander@apple.com>
Date: Fri, 24 Mar 2017 12:25:03 -0700
Message-id: <CFCFB01E-7268-4502-A4DD-B817D80D79E0@apple.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
Hi WebAppSec!

I’m long overdue sending you details on the discussion we started at the face-to-face meeting last spring. Here goes …

# Single Trust

Users have a few interface signals to decide if they trust a site. There’s the URL bar which may show the full URL, the origin, just the host, or the name of the organization for sites with EV certificates. The URL bar also conveys TLS status with padlocks, warnings, and colors. Recently, Chrome and Firefox started to warn about insecure password fields so that’s another great signal. Then there's the very subtle mixed passive content indicators. I’m sure there’s more.

We argue that in addition to the above, websites should have the ability to tell users that only first party resources are involved in a web page. We call this Single Trust – pages where there’s just one entity the user has to trust. This makes a lot of sense on pages with password fields and credit card fields but I personally would also like the inbox and message form where I interact with my physician to be single trust. Pages where you submit confidential news tips should also be single trust. And single trust would be great for pages where I’m supposed to interact through a plugin such as a bridge to a smart card reader.

Single trust can currently be achieved through a strict CSP but users have no way to tell that a site is under such a policy. Ideally, single trust should be possible for multiple domains belonging to the same organization which is not possible through CSP alone. This leads us to …

# Same-Origin Policy v2

Good TLS and the same-origin policy are the cornerstones of web security and for a single domain it works just fine. But we end up with tradeoffs since the SOP considers apple.com <http://apple.com/> and icloud.com as different as apple.com <http://apple.com/> and europa.eu <http://europa.eu/>. The most well-known tradeoff is third-party cookies but there are tradeoffs for third-party frames, Fetch, workers, and storage. If we apply strict rules on third parties we hamper cross-site ecosystems such as single sign-on and site integration. If we instead loosen up the rules we get cross-site security breakdown and/or third-party tracking.

We would like to discuss how to technically implement a secure SOP v2 that takes domain control/ownership into account. This would allow:
Seamless single sign-on across domains with one owner.
Seamless integration across domains with one owner, such as messaging between frames and access to storage.
Much better transparency and rules around third-party resources.
Support for cross-domain Single Trust as per the discussion above.

Let me know what you think. Thanks!

   Regards, John
Received on Friday, 24 March 2017 19:25:37 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:55:00 UTC