- From: Adam Langley via GitHub <sysbot+gh@w3.org>
- Date: Wed, 28 Jul 2021 18:51:17 +0000
- To: public-webauthn@w3.org
> If they have to implement FIDO for their own users to interact with them directly, why would they not simply require that the Consumer register with them first 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". > Can an RP say that it does not want any other website to be able to invoke create command for them? It's not another website invoking it for them, it's the site itself invoking it in an iframe. If the site has lost origin integrity (e.g. due to an XSS) then, ignoring the probably worse things that result, the create() call could be made, but the clientDataJSON would indicate that it was done in a cross-origin context. The backend could then reject it. (But note that, if the site can be XSSed then an attacker can trigger a top-level navigation and likely to the same thing _today_, and in a same-origin context.) -- GitHub Notification of comment by agl Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1656#issuecomment-888540828 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 28 July 2021 18:51:18 UTC