Re: Needs to be more clearly described

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



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

-Ekr

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