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

Martin,
  I'm trying to understand how the restrictions you mention below are enforced (e.g. "The media can only be added to an RtcPeerConnection where the remote end presents a domain certificate for "example.net".)  getUserMedia doesn't know anything about the PeerConnection object, and in general doesn't know how the MediaStream it returns will be used.  Could the information be added to the MediaStream object?  In your example a, the MediaSteam would be marked for unrestricted local use.  In b, it would be marked 'send to example.net' only, and in c 'send to authenticated user@example.net' only.  

We would need a language to express these restrictions inside MediaStream, and some way for the MediaStream's consumers (which could include any number of objects other than PeerConnection) to signal that they respect the restrictions.  

I'm not saying that this can't be done, just that it hasn't been...

- Jim

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Tuesday, September 18, 2012 12:06 PM
To: Jim Barnett
Cc: Eric Rescorla; public-webrtc@w3.org
Subject: 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 17:02:41 UTC