W3C home > Mailing lists > Public > public-secondscreen@w3.org > May 2015

Re: [presentation-api] Define (cross) origin relationship between opener and presenting page

From: Mark Foltz via GitHub <sysbot+gh@w3.org>
Date: Mon, 11 May 2015 21:01:21 +0000
To: public-secondscreen@w3.org
Message-ID: <issue_comment.created-101045487-1431378081-sysbot+gh@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 

- 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 

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 

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

GitHub Notif of comment by mfoltzgoogle
Received on Monday, 11 May 2015 21:01:22 UTC

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