Re: Draft text for identity-bound streams

Finally getting a round tuit.... picking up this thread from May 7.

I think this proposal is fine, and we should just add it.

One question I have is about the value of "noaccess" in the context of 
PeerConnection.
Given that any page can set up two PeerConnections and connect them to 
each other, it seems to me a bit strange that one has a stream that can 
be easily "whitewashed" by the application marked "noaccess"; a 
restriction that can be easily bypassed seems like either a false sense 
of security or just additional baggage.

It would make more sense to me if "noaccess" permitted addition to NO 
PeerConnection, just display; it would chiefly be useful for debugging 
the access control and in local applications.
(Perhaps it could allow recording?)




On 05/07/2013 04:58 PM, Eric Rescorla wrote:
> Given that the document is still in flux, I am providing raw
> text and I leave it to the editors to figure out how to
> integrate the text. I'd be happy to help with that if the
> editors want.
>
> Martin and I have been discussing
> privately what the best UX is for the relevant identity
> indications. I've tried to capture the normative requirements
> below. Seeing as we're having trouble converging on the
> gUM UI, I think it's best if we don't provide too much
> non-normative guidance for now.
>
>
> TEXT I BELIEVE BELONGS IN MEDIASTREAMS
> When either the "noaccess" or "peerIdentity" constraints is
> applied to a MediaStreamTrack, the track shall be isolated so that its
> content is not accessible to the content JS. An isolated media stream
> may be used for two purposes:
>
> - Displayed in an appropriate tag (e.g., a video or audio element).
>   The video element MUST have a unique origin so that it is
>   inaccessible to the content JS. This is the same security mechanism
>   as is used with an ordinary audio or video element which has
>   a src= property from a separate origin.
>
> - Used as the argument to addStream() for a PeerConnection, subject
>   to the restrictions detailed in the WebRTC document.
>
>
> When the noaccess=true constraint applies to a track, that track
> may be added to any PeerConnection.
>
> When the peerIdentity=<foo> constraint applies to a track, then
> that track may be added only to PeerConnections with compatible
> peer identities as described in Section XXX of [REF].
>
> Both the noaccess and peerIdentity constraints must be mandatory.
> Any use of them in the optional block must trigger an error.
>
>
> TEXT I BELIEVE BELONGS IN WEBRTC
> Tracks which are tagged with the peerIdentity constraint must be
> handled as follows:
>
> 1. If the track is added to a PeerConnection which is in a
>    disconnected state, the track is added successfully
>    (subject to other restrictions).
>
> 2. If the track is added to a PeerConnection which is in
>    a connected state:
>
>    (a) If the connected peer has no identity or has an
>        identity which is inconsistent with the peerIdentity
>        constraint, then the error callback must be called
>        with a TBD error.
>
>    (b) If the connected peer has an identity which is equal
>        to the peerIdentity constraint, then the track is
>        added successfully (subject to other restrictions).
>
> 3. When a PeerConnection transitions from an disconnected
>    state to a connected state or changes the peer identity,
>    then the following checks must be performed:
>
>    If any tracks on the PeerConnection have a peerIdentity
>    constraint and either the PeerConnection connection has
>    no peer identity or that identity is not equal to the specified
>    peerIdentity, then the connection must be terminated
>    with an error of [TBD: when we actually specify some
>    run-time errors.] Media must not be transmitted to the
>    other side in this case.
>
> 4. The identity mechanism MUST provide an indication to the remote
>    side of the type of stream (ordinary, peerIdentity, noaccess) it is
>    associated with. This is a requirement on the IETF specification.
>    Implementations MUST display different identity UI in these
>    cases.
>
> 5. If an incoming stream is associated with an identity assertion,
>    implementations SHOULD still allow sites access to the stream
>    (i.e., they should not taint it) but MUST NOT display the browser
>    chrome identity indications if the site maps it onto a modifiable
>    or viewable object. If the site performs such a mapping after
>    the chrome indications have been displayed, the browser
>    MUST change the identity indicators appropriately and MAY wish
>    to ask for user consent prior to allowing the mapping.
> -Ekr
>
>

Received on Wednesday, 12 June 2013 09:56:14 UTC