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

> We are thinking in terms of the world outlined in #1637: consider a person who has their banking app on their phone and thus has a WebAuthn credential on their phone. When performing a transaction on their desktop the bank can request an assertion and, with the existing support for cross-origin assertions and phone support coming to browsers soon, will be able to confirm on their phone. But the bank can't offer to register the local computer for future transactions because there's no cross-origin registration. Using the platform authenticator on the desktop is preferable to having to pull out a phone each time, but the guideance would have to be something like "Go to bank.com and figure out how to add an authenticator in settings".

There are 3 problems with this use-case that do not make it compelling enough to complicate FIDO, Adam:

1. If someone already has a FIDO credential on their phone registered to their bank, 99.99% of people will initiate and complete whatever transaction they want to do, on their phone;
2. Given Microsofts and Apple's direction wrt FIDO, and given Google's support for FIDO since Android 8, in less than 2 years, I anticipate the vast majority - if not all - of consumer devices will be FIDO ready/enabled;
3. The last bridge that makes FIDO universal is the problem this cross-credential creation issue is trying to solve: enabling someone who has FIDO on one device to register another platform device with the same RP. IMHO, based on what I've seen in SE Asia, I agree with @cyberphone, QR codes are the simplest, easiest way to solve this problem:
- Consumer registers "_genesis_" FIDO credential on phone with Bank;
- Consumer requests Bank app for a QR code to register another platform - say a desktop PC;
- Bank app generates and displays encrypted, digitally signed QR code on phone, with whatever the Bank needs to assure itself of the [authenticity, confidentiality and integrity](https://www.forbes.com/sites/forbestechcouncil/2020/03/06/disruptive-defenses-are-the-key-to-preventing-data-breaches/) of information in QR code;
- Consumer uses desktop browser to go to Bank website;
- Consumer clicks on a button on the **Bank's home-page** that says "Register your device with QR code";
- Camera on desktop is activated by browser and prompts for QR code;
- Consumer displays QR code on phone to desktop;
- Desktop reads, decrypts and verifies QR code;
- Browser prompts Consumer for "gesture" to register desktop with Consumer's account.

To unnecessarily complicate the FIDO ecosystem for something as simple as this with iframes, caBLE, syncing, etc. seems like taking a sledge-hammer to a swat a fly. If the QR code scheme I've outlined is too complicated for banks to handle, perhaps they can start giving out FIDO _Security Keys_ to customers (reprising the "toasters" of a bygone era) to those who are QR code-challenged.

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


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

Received on Thursday, 29 July 2021 11:47:37 UTC