(Follow-on to #911 for enabling Feature Policy)

During an internal threat-modeling exercise about cross-origin use of WebAuthn, we were led to question if the utility of permitting the creation of WebAuthn credentials in an iframe was worth the usefulness to a tracker. I believe it is, but that it's simple to raise the difficulty on a tracker without dramatically altering the current processing model. I would like to propose that we specify WebAuthn's Create Credential operation be only callable from browsing contexts that are top-level or same-origin with their ancestors.

Scenario
https://example.com/ directly embeds a script from https://website.tracker/ . The script from website.tracker appends to the DOM an invisible iframe with allow=”publickey-credentials:*”. The embedded script’s origin is https://worldwide.panopticon.tracker/ .

On load, https://worldwide.panopticon.tracker/ uses its database of tracking information to ascertain a finite list of probable WebAuthn credentials, both resident and not-resident, one of which it hopes will correspond to the user. They simultaneously consider the question of whether to attempt to create a new credential, if the probable success is low.

For optimum likelihood of success, https://worldwide.panopticon.tracker/ ‘s script waits for the user to appear to log-in at https://example.com/ , as sites are doing with Push now, then interrupts that flow to start WebAuthn, hoping to confuse the user into following the prompts.

https://worldwide.panopticon.tracker/ ‘s script makes its choice then: attempt a Get Assertion operation, either with an allow list of probable credentials or hoping for resident credentials; or attempt a Create Credential for future use.

Thoughts

If https://worldwide.panopticon.tracker/ doesn't have an opportunity to create credentials in the first place -- at least without becoming a top-level context -- this scenario doesn't provide a mechanism for tracking.

Obviously there are legitimate reasons to permit cross-origin Create Credential, but legitimate sites are likely less concerned with prompting a top-level load than https://worldwide.panopticon.tracker/ would be.

Under this scenario, https://worldwide.panopticon.tracker/ would need to open a pop-up, or cause a navigation, in order to do a WebAuthn enrollment. With pop-ups we have some reasonable controls around requiring interaction. Both of these add more friction than a direct invocation, and as they change the window in some way, they have a stronger likelihood of signalling to the user that the website is different than simply popping over-top of what the user was actually trying to accomplish.