- From: Mark Foltz via GitHub <sysbot+gh@w3.org>
- Date: Mon, 11 May 2015 21:01:21 +0000
- To: public-secondscreen@w3.org
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/ -- GitHub Notif of comment by mfoltzgoogle See https://github.com/w3c/presentation-api/issues/63#issuecomment-101045487
Received on Monday, 11 May 2015 21:01:22 UTC