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 Monday, 17 September 2012 22:05:56 UTC