Isolated Media Streams requires modification on permission algorithms in GUM and Permissions specs

[dontcallmedom]

Initially raised by @soareschen at w3c/webrtc-pc#1646

Section 10.4 Isolated Media Streams introduces a new peerIdentity field in MediaStreamConstraints, which may affect user interaction with the permission prompt:

A user that is prompted to provide consent for access to a camera or microphone can be shown the value of the peerIdentity parameter, so that they can be informed that the consent is more narrowly restricted.

The statement above seems to be optional, but implementing it could affect the algorithms in mediacapture-main and w3c/permissions. Here are few examples:

• A new field for peerIdentity needs to be added to DevicePermissionDescriptor.

• Permission query/request algorithms need to take into account peerIdentity.

• In statement 6.6 of getUserMedia(), call to request permission requires proper construction of a DevicePermissionDescriptor object.

• The statement "considering all devices attached to a live MediaStreamTrack in the current browsing context to have permission status "granted"" no longer applies, since permission for a device may be granted to specific peerIdentity only.

[dontcallmedom]

Comment by @alvestrand

is this the best way to solve this problem?
Seeking comments from @ekr @jan-ivar - pushing the problem of prompting for identity into the permissions definiton (together with device ID, so it's not completely novel) seems tempting, but may not be the only way to do it.

[dontcallmedom]

Comment by @aboba

@soareschen Can you produce a PR?

[dontcallmedom]

Comment by @alvestrand

This seems to be a refinement of GUM's permission done by the WebRTC spec, and will have to be documented as such, methinks.

[dontcallmedom]

Comment by @alvestrand

The attack scenario is this:

• JS asks for a stream, with the reassurance that this will only be sent to GoodGuy (isolated)
• JS covertly asks for a stream again; with the current language, he will be granted access to the camera without any isolation.
  This is likely not what the user wants if the user cares about isolated streams.

[dontcallmedom]

Comment by @soareschen

The consensus in TPAC is that I will submit PR to modify mediacapture-main and permissions to accept additional peerIdentity parameter when requesting permission, then modify webrtc-pc to pass the on the peerIdentiy attribute.

[dontcallmedom]

Comment by @jan-ivar

We also need to exclude isolated tracks in the following sentence (e.g.):

"..., request permission for use of the devices, while considering all devices attached to a live non-isolated MediaStreamTrack in the current browsing context to have permission status "granted""

[dontcallmedom]

Comment by @jan-ivar

@dontcallmedom Was there a conclusion?

[dontcallmedom]

Comment by @jan-ivar

I've moved my concern in w3c/webrtc-pc#1646 (comment) to w3c/mediacapture-main#534, so I'm good.

[dontcallmedom]

Comment by @dontcallmedom

it was supposed to have been copied over to https://github.com/w3c/webrtc-identity/issues but hasn't, so re-opening for now while investigating it