RE: questions about direct assignment

I agree with Martin's explanation of how origin will work, with one small exception:  are we sure that equal origin (= full access) should be the default?  Could a user set a different default?  I'd set mine to no-access as soon as I could figure out how to do it.  If we provide a constraint language that lets the JS specify any of the three options, we could even let the default be platform-specific.  That would force apps to make it clear to the user which origin/set of permissions they were requesting.

- Jim 

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Wednesday, June 05, 2013 12:17 PM
To: Stefan Håkansson LK
Cc: Robert O'Callahan; Adam Bergkvist; Jim Barnett; public-media-capture@w3.org
Subject: Re: questions about direct assignment

On 5 June 2013 04:19, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> wrote:
> (cc'ng the public-webrtc list): I may well have missed something, but 
> I don't think there currently is a way to carry origin of 
> MediaStream(Tracks) over a PeerConnection. And adding it to the 
> signaling would not help because the apps has full access.
>
> It would have to be transported in the actual media (RTP/RTCP) I guess.

Actually, this could be a bad idea.  Origin of a track needs to be subjective.  In practice, the origin that a track is assigned is a value that is chosen based on the desired security properties.

As I understand it:

Tracks acquired locally through getUserMedia are assigned an origin equal to the origin of the page by default.  Access control constraints can be applied to change this, which also enables origin restrictions. The origin of the peerIdentity constraint sets the origin explicitly.  The noaccess constraint sets the origin to a non-specific "other" origin, which prevents access from the page JavaScript, but enables transmission to any authenticated peer.

Tracks that originate from the network are also assigned an origin equal to the origin of the page by default.  However, if those tracks originate from an RTCPeerConnection that has a valid identity assertion, (and that assertion indicates that tracks are constrained to noaccess or peerIdentity[1]), the origin is set to the asserted and validated peer identity[2].  Prior to validating an identity assertion, the origin has to be set to a non-specific "other" to prevent access in the case where site origin == peer identity[3].

In the most restrictive case - that is, where peerIdentity constraints are used - the origin of a track is the identity of the remote peer in both browsers.  That renders it inaccessible to the site on both sides.

--Martin

[1] This is something that we haven't agreed, but I believe it to be necessary.  The alternative is to mark all authenticated tracks with the asserted peer identity regardless of what the identity assertion says.

[2] Note that peer identities are not in the form of origins, which might cause some implementations heartburn.  They are either in the form of a domain - "example.com" - or a user at a domain - "username@example.com".

[3] As in [2], we don't have a way to assert identity that is in the form of an origin, so this isn't possible, though a domain-based identity for "example.com" should probably be considered equivalent to all "https://example.com:*" origins for the purposes of granting access to content.

Received on Wednesday, 5 June 2013 23:05:10 UTC