W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2012

Re: Needs to be more clearly described

From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 17 Sep 2012 13:16:04 -0700
Message-ID: <CABcZeBNUrFso6H3BEoOKzU7odjQ4wRA62x9hHJWpHo17DG2yTA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: public-webrtc@w3.org
On Mon, Sep 17, 2012 at 10:59 AM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> I hope that this (and the followup discussion) helps clarify things a little.
> * Control connection establishment based on certificate
> This item actually covers a range of topics related to identity.  To
> some extent, this crosses over into IETF territory, but the first part
> of this item is especially relevant to the API.  (I'll also concede
> that it presupposes something about the solution.)
> It is desirable for applications to be able to control (permit or
> deny) communication with peers based on their identity.  An
> application might have its own idea about what identity a particular
> session participant is providing.  Identity assertions alone are not
> sufficient to determine whether to allow access to the session.  In
> some applications, access to media might need to be controlled based
> on identity.
> If an identity assertion is found to be invalid, can the session
> continue?  Is it a case of identity or bust, or are we just using
> identity to provide source attribution?  The former choice simplifies
> things greatly, but it may be a little restrictive.  The latter option
> implies that we need to give the application control to allow it to
> perform session-level access control.

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.

> The current work on identity does not permit the presentation of a
> domain certificate for the termination of a media stream.  This is a
> case that I raised a couple of times in discussions in the IETF, with
> what I perceived to be a favourable response.  This enables basic
> contact centre applications without the need for additional
> infrastructure.  Being able to talk to "example.com" also has specific
> meaning over simply talking to "service@example.com", which -
> depending on example.com name registration policies - could just be
> some dude with an account.

I'm totally in favor of this and I thought I had accomodated this in
the IETF draft with the following:

      *  If the far endpoint was directly verified, either via a third-
         party verifiable X.509 certificate or via a Web IdP mechanism
         (see Section 5.6) the "security characteristics" MUST include
         the verified information.

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

> * Related identity issues
> In the same area, it's also unclear how an application learns of the
> set of available identity providers that are able to assert a user's
> identity.  And how does an identity provider "install" itself?

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

> 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.

Received on Monday, 17 September 2012 20:17:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:30 UTC