Re: IdP issues (was: Needs to be more clearly described)

On 18 September 2012 06:20, Jim Barnett <Jim.Barnett@genesyslab.com> wrote:
> getUserMedia has only the concept of local media.  It's PeerConnection that knows about remote endpoints.   The current definition of getUserMedia has no information about who is asking for access, and that's a pretty big gap.  At the very least the user would want to know which application is asking for access.  Is it sufficient to identify the application by URI?  I don't  see any method for even this most basic form of identification, let alone a way for the app to reliably inform the user about what it intends to do with the media. This seems like a pretty big gap in the current spec.

The current idea is that getUserMedia permission is tied to the origin
of the page.  This is sufficient for non-RtcPeerConnection uses.  As a
default mode of operation, it gives the site complete access to media
produced by the media source (camera, microphone).

Imagine a page at https://example.com/ requesting access in the three
following ways (strawman API):

a. navigator.getUserMedia({ audio: true, video: false })
b. navigator.getUserMedia({ audio: true, video: false, peer: 'example.net' })
c. navigator.getUserMedia({ audio: true, video: false, peer:
'user@example.net' })

The first implies that "https://example.com" is requesting access to
your microphone.  What they consequently do with it is up to the
application.

In the second, the media cannot be accessed by the page.  The media
can only be added to an RtcPeerConnection where the remote end
presents a domain certificate for "example.net".  In the final
example, the media can only be added to an RtcPeerConnection where the
remote end is an IdP-authenticated "user@example.net".

In the latter two cases, we also need some assurance from the peer
that they too are not allowing the site they are visiting to access
the media.  I believe that the current idea was to tie this assurance
to the existence of an identity assertion, but that might not be
sufficient for the domain-authenticated case because that operates
without identity assertions.

--Martin

Received on Tuesday, 18 September 2012 16:06:11 UTC