callerOrigin isn't actually the origin of the caller; it's the origin of the callee

[bzbarsky]

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.

[bzbarsky]

This applies to https://w3c.github.io/webauthn/#getAssertion as well.

[AngeloKai]

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?

[bzbarsky]

That would be a simple example, yes.

[equalsJeffH]

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.

OK, I have been looking into this and have a question for @bzbarsky and @domenic: in our particular case of crafting the makeCredential() and getAssertion() algorithms, is this the (or "a") correct way to obtain the "caller's origin":

• let |callerOrigin| be the incumbent settings object's origin.

..?

The overall apparently applicable section of HTML is: https://html.spec.whatwg.org/#realms-settings-objects-global-objects -- yes?

[domenic]

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.

[equalsJeffH]

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.

[domenic]

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.

[equalsJeffH]

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?

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 makeCredential() and getAssertion() algorithms more along the lines of the window.postMessage() algorithm which also obtains its caller's origin and performs an origin check (and also handles going async).

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.

[domenic]

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 window3.Promise, not a window1.Promise.

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.

[equalsJeffH]

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

Set callerOrigin to the current settings object’s origin. ...

..to be..

Set callerOrigin to the relevant settings object’s origin. ...

..?

[domenic]

ok, so in your example above, window1, window2, window3 all need to be same origin, yes?

I believe same origin-domain, but yeah, basically :).

If so, then it is sounding like we can ought to change makeCredential() step 3 from..

"relevant settings object of this WebAuthentication object" to be precise, but yep!

[AngeloKai]

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?

[equalsJeffH]

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

Actually, AIUI, makeCredential() and getAssertion() algs will need to be able to determine their caller's origin, regardless.

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 WebAuthentication object". Note that the first step of both the "Request a Cred" and "Store a Cred" algs in the Credentials management spec is to obtain the incumbent settings object (should probably be to obtain the relevant settings object but that's not terribly relevant to this discussion).

[equalsJeffH]

I split @AngeloKai's comment above wrt top-level browsing context over to issue #374