Re: [webauthn] Cross-origin credential creation in iframes (#1656)

> Copied over from #1336. Thanks to @emlun for the link to this issues. 

I'm a bit saddened by this decision to not allow credential enrolment from the context of an iframe. I'm the CTO of a new payments company (https://stitch.money), which is aiming to improve the payments experience of account to account payments in our markets.

As @btidor-stripe and @jcemer-stripe mentioned, 3d Secure is a good example of where allowing iframe credential enrolment would be hugely advantageous for the security of the payments ecosystem, but it goes beyond just 3d Secure.

For many of our clients, Stitch offering a more integrated experience, rather than forcing users to do a redirect is an important product feature. Our clients are generally already trusted e-commerce brands/fintech services, and they wish to leverage their brand equity as much as possible in the payment process. 

In order to prevent our customers from having to shoulder a large part of the PCI, compliance, and general infosec burden, we deliver the embedded version of our interface via an iframe so that our customers do not have the ability to handle the credentials themselves. I'd venture to say that this is quite a common approach in the industry at large.

For our product, we perform tokenisation of user credentials to streamline subsequent checkouts, and currently have to store this single use token in localStorage. This isn't the best as this value could conceivably be exfiltrated from local storage and used on another device. It'd be greatly preferable if we could use Web Authn as an alternative to these tokens.

I'm a little unclear as to why the enrolment is considered a significant privacy threat in the model (privacy seemed like the original motivation for restricting this functionality), does both retrieval and enrolment not require user interaction? If that is indeed the case, surely this would not be a particularly attractive fingerprinting method? Or is it because some of the associated parts of the API increase the available entropy that could be used in general fingerprinting methods?
--- 

With regards to GDRP, the approach I described above actually is to my understanding friendlier to GDPR and GDPR equivalent data protection regimes, as it means our clients don't need to store a token/identifier on their side to allow repeated payments. 

We of course design our flow and mandate that our customers do the same to make sure that the appropriate disclosures and consents are made.

Out of necessity, we need to store certain pieces of PII as is to provide our services, and this would not change regardless of whether we enrolled credentials or not. 



-- 
GitHub Notification of comment by ncthbrt
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1656#issuecomment-892592436 using your GitHub account


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

Received on Wednesday, 4 August 2021 11:48:48 UTC