- From: kenrb via GitHub <sysbot+gh@w3.org>
- Date: Thu, 14 Nov 2019 00:02:41 +0000
- To: public-webauthn@w3.org
> I've no doubts as to the capabilities of IOv2 of notifying us of the conditions of the iframe, but someone - @agl maybe? - asked the question of how many pixels in area we needed an iframe to present on screen to permit WebAuthn. Could they be all white on a white background? Is there a limit to the aspect ratio? > The embedded document is made aware of the area rect that is visible to the user through IOv2. It is also provided assurances that it is fully opaque, not occluded by other elements, and not subject to filters or transformations. For clickjacking considerations we assume the embedded document intends to be visible to the user, so it wouldn't draw as all-white. > IOv2 gives us the power to make decisions here, but I haven't a real notion of how to answer these raised questions, which leads me to question the utility of IOv2 for WebAuthn's use case at all, simply because what's good enough? Use of IOv2 leaves that decision to the relying party. It gives them the ability to define the area of the authentication widget in their document and gain assurance that it has been fully visible to the user for a given threshold of time. If we are thinking about having the user agent mandate visibility of cross-origin iframes that want to use WebAuthn then we have the problems you are describing. But it seems like a very good idea for RPs to use IOv2 as a guard against clickjacking. In some cases I think it might be essential for user security. -- GitHub Notification of comment by kenrb Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1105#issuecomment-553661578 using your GitHub account
Received on Thursday, 14 November 2019 00:02:42 UTC