Re: questions about direct assignment

On 2013-06-05 18:17, Martin Thomson wrote:
> 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.

To follow up on my other mail [a] send an hour or so ago: The proposed 
text [b] does not say anything about "authenticated peer"; what is said 
is that "When the noaccess=true constraint applies to a track, that 
track may be added to any PeerConnection."


[a] http://lists.w3.org/Archives/Public/public-webrtc/2013Jun/0078.html
[b] http://lists.w3.org/Archives/Public/public-webrtc/2013May/0017.html

>
> 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 Thursday, 13 June 2013 07:41:25 UTC