Draft text for identity-bound streams

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