Define (cross) origin relationship between controller and presentation about presentation-api

[schien]

This has also been discussed in Mozilla dev-webapi. We can learn from window.postMessage() and add additional targetOrigin parameter in PresentationSession.send().

void send( (DOMString or Blob or ArrayBuffer or ArrayBufferView) data, DOMString targetOrigin);

To send the message to the target regardless of origin, set the target origin to "*". To restrict the message to same-origin targets only, without needing to explicitly state the origin, set the target origin to "/".

[anssiko]

Thanks for the proposal, added to the F2F agenda.

[anssiko]

@schien Could you outline your proposal at the F2F and share your latest thinking? It seems you've hashed this out on dev-webapi somewhat. Also, provide couple of good use cases that require cross-origin for background.

The targetOrigin attribute seems like a feasible solution the group should explore further.

Actually, the origin attribute in the spec [1] would be redundant information without an ability to do cross-origin (we can get that information via window.location.origin). The prose around origin should be clarified once we resolve this issue.

@mfoltzgoogle What is Google's take on this issue?

[1] http://w3c.github.io/presentation-api/#receiving-a-message-through-presentationsession

[mfoltzgoogle]

For now, I don't really see the cross-origin restriction as applying to the Presentation API. The messaging channel is analogous to the device-to-device communication implemented in RTCDataChannel [1]; it's just a data channel and isn't responsible for authenticating either party.

If the presenting page wishes to authenticate the identity of the presentation page (or vice versa) the initial handshake between the pages could include the exchange of tokens that can be used to prove that identity. This minimizes the level of trust required in both the user agents rendering each side and the security requirements of the network transport.

However, let's assume that we trust both user agents and the network transport, so the origin of either party is conveyed truthfully.

• How would one side know to update the targetOrigin for messages as the other side navigated to a different origin and rejoined the same PresentationSession?
• If pages from different origins A and B wished to join the same PresentationSession simultaneously, what target origin would that presentation use to communicate?

This is a good topic to discuss further at the F2F; a more fully defined proposal for cross-origin messaging would be a good starting point.

A middle ground might be something like CORS as implemented by WebSockets [2], which would allow the device hosting the presented page to restrict which origins are allowed to connect; but would require some extensions to the API to make CORS work in a non-HTTP context.

[1] http://www.w3.org/TR/webrtc/#rtcdatachannel
[2] http://www.w3.org/TR/websockets/

[anssiko]

Thanks for the summary @mfoltzgoogle. I agree this is a good (and potentially complex) topic for the F2F. To that end, I think we should attempt to reuse the existing mechanisms where possible.

[tidoust]

PROPOSED RESOLUTION: drop step 3 in 6.3.2 Receiving a message through PresentationSession, the message origin will not be conveyed.

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

(note action in the minutes for remaining parts of the issue)

[anssiko]

ACTION: @schien to look to see if there is a chance to apply CORS origin check approaches to Firefox OS specific packaged app [recorded in http://www.w3.org/2015/05/19-webscreens-minutes.html#action11]

[mfoltzgoogle]

PR #88 implements the proposed resolution from the F2F meeting. @schien, perhaps you would like to report the results of your investigation into CORS to the mailing list, and we can open a different issue if any spec changes are proposed as a result.