- From: Eric Rescorla <ekr@rtfm.com>
- Date: Mon, 17 Sep 2012 13:16:04 -0700
- 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 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