webauthn
webauthn copied to clipboard
w3c
Allow for credential creation in a cross-origin iframe
See https://github.com/w3c/webauthn/issues/1656
This PR adds the ability to call navigator.credentials.create() in a cross-origin iframe (more exactly, a frame that is not same-origin with its ancestor chain), as long as the following conditions are met:
- The iframe has a publickey-credentials-create-feature permission policy
- The iframe has a user activation
It has a corresponding PR on the credential management spec; see https://github.com/w3c/webappsec-credential-management/pull/209
cc @ve7jtb , who I believe wished to make sure that this was compatible with the previous L2 discussion on what create() in a cross-origin iframe would look like (particularly the permission policy name, I believe).
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!)
- If a user registers a passkey in a payment flow, and later sees it in the password manager, they may be confused.
- 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.
- If an iframe can trigger passkey creation, the user will not know what site it is for.
- This enables the tracking concern as described here.
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 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 we acknowledge the slight increase in risk here, but believe that a combination of:
- Requiring a permission policy,
- Requiring a user activation, and
- 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.
Hi folks; I had hoped to bring this PR up on today's call, but since it is cancelled pinging here instead. We are still waiting on a response here from Apple, and I would love to have that for next WebAuthn WG meeting if possible (2022/11/16). If there is no answer by the 16th (or during the call), I will be interested to know how the WebAuthn WG wants to proceed at that time (i.e., what the method is to resolve this PR one way or another).
I might even skip the TODO. I'm not sure that we'll be in a better place to resolve it in the future and it's clear that implementations have managed to figure out user activation in these contexts already.
Ack - done, removed the TODO in https://github.com/w3c/webauthn/pull/1801/commits/eb32a68f2a3088aa573f03ce20858f0bfe43d4db
Post-vacations ping to @akshayku @timcappalli @ve7jtb - could you review this before this week's WebAuthn sync? (I.e. before the 11th). I'd like to get this merged.
Post-vacations ping to @akshayku @timcappalli @ve7jtb - could you review this before this week's WebAuthn sync? (I.e. before the 11th). I'd like to get this merged.
@stephenmcgruer, we may need one more WG meeting cycle due to holidays and vacations. Sorry for the delay.
(This PR was discussed in the Jan 11 WebAuthn WG meeting. Overall it seems good, but @timcappalli intends to add a comment to request two changes to the PR - one in line with @ve7jtb's suggestion and one additional UX 'should' advisory.)
@timcappalli @ve7jtb - I've gone ahead and pushed two commits to this PR that add a note on the client making it clear to the user if the credential creation is in a cross-origin iframe, and also added a topOrigin member to convey some sense of the containing page info (though one could have a chain of different origins of course, and this wouldn't be represented).
Hope this is somewhat along the lines of what you were each thinking - but if not no worries, happy to revise to whatever feedback you have :)
Thanks @emlun - you're definitely right and I was uncomfortable with my changes to the limited verification algorithm as-is. I'm going to address the easier errors you pointed out first, and then come back and think harder about the overall structure!
Ping @emlun - your review is still considered outstanding by Github which blocks merging. If you can either re-review or just clear your requested change, that would be great thanks!
(Merging as this is all green & blocking https://github.com/w3c/webappsec-credential-management/pull/209 and some other work, feel free to open an issue for outstanding issues)
