Define security requirements for messaging channel between secure origins

[mfoltzgoogle]

public-secondscreen thread:

While discussing the Hbb 2.0 TV standard, the issue of how WebSockets would be used to communicate between the controlling Web application and the presenting TV Web application.

If these Web applications are provided on secure (https://) origins, some guarantees of message confidentiality and authenticity of either party should be made to meet the standards set out by the Mixed Content proposal.

This issue will be addressed by a spec change to spell out the security requirements for the messaging channel as part of the Security and Privacy sections of the spec.

[anssiko]

Tagged this for F2F discussion. @mfoltzgoogle mentioned having had "preliminary discussions in Chrome about this, but nothing firm enough to propose, so I'm glad to have an opportunity to discuss this in the group."

So let's discuss at F2F latest :-)

[tidoust]

PROPOSED RESOLUTION: keep issue 80 open while we gather more implementation experience. Highlight issue asking for feedback when getting in touch with PING / Web security IG

See relevant discussion during first day of Berlin F2F:
http://www.w3.org/2015/05/19-webscreens-minutes.html#item09

[mfoltzgoogle]

Re-adding F2F tag so that we can review feedback from PING/TAG and reports from implementations in October.

[mwatson2]

We would like to propose some ideas for discussion on this topic at the F2F (actually, more leaning towards possible solutions than just requirements). Might also be worth a session in the Unconference part of TPAC to get wider visibility of the problem. So, I support Mark's addition of the F2F tag.

Btw, has there been any TAG discussion of this ?

[tidoust]

The TAG prepared a draft review of the Presentation API. The relevant part appears more descriptive than prescriptive:

[[
The spec describes launching a new browsing context to the presentation display. Given the spec as written, it does not appear as if this is a client/server channel, but rather a client/client (peer) channel. The back-channel, maintained by the user agent for client/client browsing context communications (like those of window.open ) is currently not defined other than to say that a message passing system (like postMessage ) must guarantee in-order delivery. If the presentation on the second screen communicates with its server (it is loaded via the presentationURL ), then the send() API is unnecessary to the feature, as pre-existing client/server communication API fill this gap ( WebSocket , XMLHttpRequest , etc.)
]]
https://github.com/w3ctag/spec-reviews/blob/master/2015/presentation-api.md

[tidoust]

See relevant discussion at TPAC F2F:
http://www.w3.org/2015/10/29-webscreens-minutes.html#item06

RESOLUTION: For issue #80, close issue as out of scope, and focus on informative guidelines in security section.

[mfoltzgoogle]

Before closing this, we need to update the spec to take account of https://www.w3.org/2015/10/29-webscreens-minutes.html#action07

mfoltzgoogle to propose wording to prevent mixing HTTP and HTTPS

As well as polish the text in the security section.

[mfoltzgoogle]

I think the spec reflects the current thinking about cross-origin connection in the working group. We'll probably revisit this as we make progress on network-level specification, but I'm closing this for now.