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 16:17:56 UTC