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

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.

- Jim

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Monday, September 17, 2012 6:06 PM
To: Eric Rescorla
Cc: public-webrtc@w3.org
Subject: Re: IdP issues (was: Needs to be more clearly described)

On 17 September 2012 13:16, Eric Rescorla <ekr@rtfm.com> wrote:
> On Mon, Sep 17, 2012 at 10:59 AM, Martin Thomson 
> <martin.thomson@gmail.com> wrote:
> My view is that you should be able to continue in the face of invalid 
> identity assertions. Analysis: since we do not *require* identity 
> assertions at all, it is generally possible for an attacker who can 
> inject a bogus assertion to also inject no assertion at all, so we 
> should treat these similarly. I suppose it might be useful to have 
> some way of generating a JS level error for debugging, but that 
> doesn't seem to be our modus operandi with respect to other errors. 
> For instance, what happens if you provide an SDP with a bunch of 
> malformed ICE candidates? AFAICT nothing.

I reached the same conclusion, sans analysis, hence the caution.  That means that I also conclude that we must provide an oversight function for applications to be able to deny access to a session.  Obviously, this isn't a security guarantee, since it's running in uncontrolled territory, but it does fall under the auspices of things that the application can do to protect their users (and their own reputation).

For instance, my application might require authentication for all calls that it arbitrates.  It might do so for users on arbitrary sites.  I might then also carefully screen identity providers.  All in the interest of building a reputation.

> I would be happy to add some more text. Do you have a suggestion?
> Do you think we should have an accessor for this?

It's unclear how the application would gain the information necessary to make the above decision (allow/disallow) without some additional information.

 - What is the certificate from the peer?  fingerprint or full DER, don't know yet.
 - What identity is being asserted here? subject or IdP-asserted identifier, perhaps.
 - What validation has been performed on this information?  RFC 5280, IdP, (probably not with varying detail like OCSP etc...)
 - Did any validation fail?  (i.e. was an assertion made that was found to be baseless)

With this information an application can make a decision.

> I was envisioning a number of scenarios, ranging from it already 
> knowing because you registered with that IdP (e.g., Facebook Connect) 
> to you pressing a button. I think it would also be useful to have a 
> way for users to directly register this with the browser (a la Web 
> Intents) but I'm not totally sure if we want to standardize that here. 
> Comments welcome.

I don't think that it is sufficient to have built-in only.  The extension mechanism might not be standardized immediately, but it might be worthwhile including.

If you have multiple providers, do you gain one from each?  Can the application provide "hints" as to which might be accepted?  (I can imagine a contact centre application that only accepts a subset of identity providers for the purpose of authenticating calls.)

>> I always imagined an OAuth-like arrangement for the acquisition of 
>> identity assertions, but it seems that Eric has a more direct model 
>> in mind.  That probably needs resolution.
>
> I'm not sure I am clear on the distinction here, cause I think of this 
> as quite OAuthy.

Not so much if you imagine that the resource in question is the identity assertion.

Let's say that I operate a site example.com.  I operate a calling service.  You sign in to my service using identity provider example.idp (gTLD for sale!).  This is the only identity provider that I know of.  I can request (using OAuth) an identity assertion, bound to a particular call, that asserts my identity toward a particular user during a particular time period, with all the constraints you can imagine.  As a user, the experience you see is a redirect to example.idp, with a dialog stating that "example.com wants to impersonate you on a call, y/n" and you can permit that action to proceed or not.  No need then to build an API for requesting identity assertions.


As a separate IdP issue, I didn't see a proposal for how this is tied to getusermedia.  That is the crux of the matter.  After all, you want to make sure that you are only sending your highly sensitive and private video stream to a particular person, not the site.  If this were part of the navigator.getUserMedia argument list, then you could make that binding very clear (as well as surfacing the constrained scope in chrome).

--Martin

Received on Tuesday, 18 September 2012 13:19:43 UTC