stephenmcgruer
commented
1 year ago This was discussed at today's WPWG (minutes). The main concerns I heard were about the countdown-to-active button and whether it would add user friction. From discussion, the main takeaways (for me) were:
- Folks would prefer this countdown to be nearer 1s than 3s.
- Folks would prefer to not have it countdown at all if there is a user gesture present at time of calling.
We do believe on the Chrome side that the user should be taking some time to read the dialog, and if they are clicking Verify too quickly that may actually be concerning to us. That said, we hear the above feedback and will take it into account internally.
We also continue to be open to any additional suggestions for security or privacy concerns, but have not heard them yet.
I expect that we will be looking to Origin Trial this with interested parties around mid-Q1; but we'll confirm after the holidays once our plans and available resourcing are firmer :)
Please note that this proposal is not final inside of Google Chrome, though has been through an initial security review. We are sharing it here to gather feedback/input from the WG.
Background
Currently, SPC authentication requires a transient user activation (i.e., the user must click/tap/drag/etc on something on the web content) to be triggered. This was done for two main reasons I am aware of:
However, we have heard from multiple partners piloting SPC that the user activation requirement has been a problem for them. This has come up in both redirect-authentication based flows, but also in iframe-authentication based flows where capability delegation was considered difficult to utilize (notably, it may require merchant changes and thus may not be scalable).
The impact of this has ranged from SPC simply failing for partners in certain scenarios, to partners having to build awkward UIs just to collect a user activation (e.g. click) to trigger SPC.
Notably, WebAuthn does not require a user activation to trigger.
Proposal
We propose removing the user activation requirement for SPC. This would allow a website to trigger the SPC experience without the user first clicking/tapping on the page, to support redirect flows. Iframes would also be able to do this, but only if the top-level page gives them permission via the "payment" permission policy.
As an anti-clickjacking mechanic (see Security & Privacy below), in the Chrome implementation we are additionally proposing that the Verify button not be enabled until a short 'cooldown period' has passed after the UX has been shown, and we may additionally impose a cooldown period between calls to SPC. These are technically implementer-internal details, but is worth noting in any spec change for this proposal as a risk and defence.
There is some risk to this proposal, so we expect that the spec would be changed to make it user-agent dependent whether they enforce this or not. We intent to monitor for malicious usage out of this and take action as necessary. We would also be looking for partners to experiment with us and confirm whether removing the user activation requirement significantly increased the success of their products.
NOTE: We are not proposing any change to the user activation requirement for credential creation in a cross-origin iframe. That scenario does have security implications where a user may be tricked, and thus we need to keep the user activation requirement. Additionally, we believe that any good actor should be presenting the user with some dialog to interact with before attempting credential creation.
Security & Privacy Considerations
We consulted carefully with our security team over this change, as it could have security/privacy implications. Diving into why we require user activation for certain Web APIs, we identified the following scenarios (not necessarily exhaustive):
It is important to note that user activation is a very low bar for an attacker to clear in general - it takes only a single click/tap on the screen and the attacking website has an activation.
For the former case (spam), it does not appear to us that SPC can cause this to happen. A website may only have a single SPC window open at once (unlike, e.g., pop-up windows), and (on Chrome), the SPC dialog does not stop the user interacting with the browser UX (so the user may choose to just close the tab). On Android it is slightly more painful for the user to close the tab, so we may implement a cooldown period after a successful show() call within Chrome.
For the latter case (tricking the user), the most likely threat we identified was click-jacking the user. An attacker would entice the user to click in a particular spot on the page, and then attempt to trigger SPC right before the user clicks. If successful, the user might click on the 'Verify' button without actually reading the Transaction UX. They would still have to complete a subsequent WebAuthn transaction, so the risk is fairly low here, but as a defence our security team suggested that we make the 'Verify' button not clickable for a few seconds after the dialog shows, to defeat this attack.
We welcome any additional suggestions for security or privacy concerns with this proposal!