Identity provider selection invisible <iframe>: what's the motivation?

[domenic]

Hey guys,

The TAG is interested in helping get the Identity Provider Selection stuff on a bit firmer ground. It seems like the use of the invisible <iframe>-with-extra-restrictions is trying to grope at some deeper concept, and we'd like to be able to understand what the goal is and maybe make this concept reusable across specs or by developers directly, instead of having WebRTC kind of take an HTML element, grab some interesting behavior from it, modify that behavior in a few ways, and then say "effectively, do this" :)

So, just to get the conversation started, could you help us understand the motivation for this? For example, why would an invisible <iframe> be better than a simple HTTP request? (I can guess several reasons, but would be interested in which of them are applicable.)

Also, what is the group's current thoughts on this mechanism in general? (Especially any implementers who have looked in to it.) I noticed the "TODO: This is not sufficient unless...", which might indicate that you guys were planning to re-think it and replace it with something better?

[martinthomson]

@domenic I sent an email about this to the public webrtc mailing list recently. The feedback I've gotten is that the iframe is clunky as well. However, the view is that the facilities available from within the browser are still superior to an HTTP request. If you could look at what is proposed, I think that is better. http://lists.w3.org/Archives/Public/public-webrtc/2014Dec/0114.html

That still leaves this in somewhat new territory, as I have discovered in trying to implement it. I think that I can appreciate a desire to move to "just HTTP", particularly now that service workers are merely half-baked as opposed to totally non-existent. That said, I think that what I've proposed offers some significant usability advantages.

[domenic]

Oh wow, yes, that does look much better!

It would still be good to specify the exact execution model this is aiming for. As far as I can see, the two choices are:

• A special type of worker
• A "realm."

A "realm" is an ES6 concept; it means a separate global and execution environment, similar to what a same-origin iframe gets. But it runs in the same thread, and shares the same memory space. By default two realms (say, the web page's realm and the IdP script's realm) might be isolated, but if object references are shared in any way, there is no structured cloning or anything; you just operate on the object from the other realm.

I don't really have an opinion on which of these two models would be better; I imagine you guys, being much closer to the problem statement, would do so.

[martinthomson]

I have currently implemented it in Firefox as a "realm" (which map to what we call compartments, if I'm not wrong) because that turned out to be much easier. However, I don't think that this choice matters appreciably.

The key criteria are that there are certain facilities available in the context (i.e., where you can register as an IDP, which also serves as a good signal that the browser is who you are talking to), and that it executes your code. The API I've proposed is asynchronous and so doesn't rely on one form or other.

I'd like to keep that flexibility, if that makes sense. I don't see any reason to dictate implementation strategy and - from a user perspective - the only visible difference will be timing-related.

[stefhak]

Hi!
Could you move this discussion to the list (public-webrtc)? There are many WG participants that don't follow github very closely.
Stefan

[domenic]

Thinking about it from the perspective of being less restrictive to implementations, I think realm makes the most sense, since if you use a separate worker that will necessarily use a separate realm anyway. So cool, we should spec this to use ECMAScript realms.

Figuring out what's on the global will require some work, e.g. is everything that is [Exposed=Worker] in this? That's a good way to get fetch, web crypto, etc. Plus we'll want to add a few properties to the global directly as you say. Maybe use WorkerGlobalScope but derive from it and add your own properties?

[dontcallmedom]

I think the original question was answered, and that this issue can thus be closed.

[stefhak]

I agree to Dom's assessment, closing the issue.