W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2013

Re: Draft text for identity-bound streams

From: Harald Alvestrand <harald@alvestrand.no>
Date: Wed, 12 Jun 2013 11:55:46 +0200
Message-ID: <51B845A2.5000909@alvestrand.no>
To: public-webrtc@w3.org
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 
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.
> 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.
> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:44 UTC