Re: [webauthn] Allow for credential creation in a cross-origin iframe (#1801)

This pull request was discussed at the Sept 21st, 2022 WebAuthn WG meeting. During that meeting, we heard the following concerns from Apple (and please @pascoej , correct me if I am misrepresenting your comments!)

1. If a user registers a passkey in a payment flow, and later sees it in the password manager, they may be confused.
2. If a user registers a passkey in a payment flow, but then later the bank asks them to use that passkey to sign-in with, they may be confused.
3. If an iframe can trigger passkey creation, the user will not know what site it is for.
4. This enables the tracking concern as [described here](https://github.com/w3c/webauthn/issues/1656#issuecomment-1219682589).

I'd like to start by repeating (as we said in the meeting) that these concerns are not invalid and we appreciate where you are coming from.

For #1 and #2; it is already the case today that a Relying Party could register a passkey for a purpose other than sign-in, and utilize it as so. Taking payment as an example; when visiting bank.com I could be asked to 'enroll a passkey to validate future payments when making online purchases'. Even though I was told by the Relying Party that it was for future payments only, that passkey would still show up in the password manager, and the bank could use it to do sign-in. This PR does not change that status quo.

(There is also a deeper purpose discussion here; should WebAuthn be confined to sign-in and attempt - as much as it can[0] - to force Relying Parties down that road. Or, should WebAuthn take the view that passkeys are a verification method only, and what they are verifying is out of scope.)

For #3, it is already possible today to produce a flow with pop-ups that is very close to what this PR enables. An iframe can, with user activation: open a pop-up window, immediately trigger credential.create() in that pop-up, and then close the pop-up instantly after completion. On desktop the pop-up can be made to be almost completely hidden, and on mobile the 'greying' of the screen for the passkey UX obscures the new origin in the URL bar. This [demo site](https://output.jsbin.com/hiyejej/quiet) should demonstrate this—it has been tested on Chrome 105 and Safari 16.0 on MacOS, Chrome 105 on Android, and Safari on iOS 16.0. Given the existing situation and the ability of the browser to display additional UX for the iframe case if it wishes (see below), we do not think this PR significantly changes the status quo.

Finally, for #4, as [per the issue comment](https://github.com/w3c/webauthn/issues/1656#issuecomment-1219682589) we acknowledge the slight increase in risk here, but believe that a combination of:

1. Requiring a permission policy,
1. Requiring a user activation, and
1. The friction of a WebAuthn operation (tracking is usually near silent - WebAuthn is not!)

provides adequate defence. A browser could also, if it wished, add additional or clearer UX to warn the user that the create is occurring in an iframe.

[0] I think the only real mechanism for this is the client/authenticator UI, incidentally. I don't believe there is a feasible way at the API level to constrain to sign-in.


-- 
GitHub Notification of comment by stephenmcgruer
Please view or discuss this issue at https://github.com/w3c/webauthn/pull/1801#issuecomment-1261222538 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 28 September 2022 17:20:13 UTC