-
Notifications
You must be signed in to change notification settings - Fork 115
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Identity provider selection invisible <iframe>: what's the motivation? #172
Comments
@domenic I sent an email about this to the public webrtc mailing list recently. The feedback I've gotten is that the 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. |
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 "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. |
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. |
Hi! |
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 |
I think the original question was answered, and that this issue can thus be closed. |
I agree to Dom's assessment, closing the issue. |
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?
The text was updated successfully, but these errors were encountered: