-
Notifications
You must be signed in to change notification settings - Fork 170
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
callerOrigin isn't actually the origin of the caller; it's the origin of the callee #271
Comments
This applies to https://w3c.github.io/webauthn/#getAssertion as well. |
When you mention the origins of the callee function and the caller function may not match, are you talking about the cases, such as the situation where a site calls into its iframe's makeCredential function? |
That would be a simple example, yes. |
OK, I have been looking into this and have a question for @bzbarsky and @domenic: in our particular case of crafting the
..? The overall apparently applicable section of HTML is: https://html.spec.whatwg.org/#realms-settings-objects-global-objects -- yes? |
In general as noted in that section of the spec, the incumbent concept should not be used by new specifications going forward. Can you explain what you are actually trying to accomplish here? In general any behavior that depends on the callstack is surprising and not something we want to include in the platform. |
FWIW, I note that HTML has a goal of "Minimize the usage of the incumbent concept". However, I have not otherwise been able to discern another straightforward way to obtain one's caller's origin. |
Yes; the idea is to minimize the number of places one ever checks the caller's anything (especially origin). Why does this spec want to introduce a new way of doing so? It's generally a very confusing programming model for developers with some security drawbacks as well. |
Rather than "a new way of doing so", it is a "new occurrence of doing so". Webapp programmers (nee authors) would not themselves be performing this check. From what I have been able to figure out in investigating this issue, as well as others, such as #253 #254 #272 #276, we need to think about structuring the The rationale behind performing a (caller's) origin check is documented in (closed) issue #241 which also references our discussion with the TAG regarding this. thanks for your interest and help. |
Issue #241 was not helpful in figuring out why the caller's origin check is appropriate. Stated another way, given // inside <script> running inside window1's document
window2.navigator.webAuthentication.makeCredential.call(window3.navigator.webAuthentication, ...); why is window1 the window whose origin matters? In general in the platform we would check the origin of window3 here. (That of the relevant settings object of the WebAuthentication object on which the method is being called.) Furthermore we would base any global-specific or origin-specific processing off of window3. It's bizarre that you call a method on window3, but then something happens in window1! That's exactly what we want to avoid! Especially since, per Web IDL, the promise returned is a postMessage() is a special case since its entire purpose is communicating across origins. Even so, its checking of the incumbent settings object is a legacy special case that we would eliminate if we could, and some browsers still have hopes of doing so eventually. |
ok, so in your example above, window1, window2, window3 all need to be same origin, yes? If so, then it is sounding like we ought to change makeCredential() step 3 from..
..to be..
..? |
I believe same origin-domain, but yeah, basically :).
"relevant settings object of this |
One possible way of resolving this issue and many other related corner cases would be to restrict the API to only top level browsing context, i.e. not in iframes. As far as I can recall, I haven't seen a web page that puts login flow inside a iframe. Earlier in discussions over whether we should give developers option to relax the same origin restrictions, some proposed a workaround for sites like Google to put login flow inside a iframe. But since we do give the developers such ability, I can't see the benefit of giving developers such capability. Such restriction was done before too. The credential management API, another API to improve the login flow and manage credentials, is only available on top level browsing context. @equalsJeffH what do you think? |
Actually, AIUI, So, yes, AIUI, we can align the web authn API in terms of requiring the above algs to be called from only top-level browsing contexts, but we will still need to assess the "origin of the relevant settings object of this |
I split @AngeloKai's comment above wrt top-level browsing context over to issue #374 |
callerOrigin in https://w3c.github.io/webauthn/#dom-webauthentication-makecredential step 3 is defined as the "current settings origin". That means it's the origin of the callee function, which may or may not match the origin of the caller. And either one of those two might or might not match the origin of the WebAuthentication object itself, of course.
At the very least, this should be named more clearly.
The text was updated successfully, but these errors were encountered: