Refer to IntersectionObserver from the Security Considerations

[jcjones]

IntersectionObserver1 and/or IntersectionObserver2 could be valuable to relying parties to determine whether an iframe they are utilizing for WebAuthn is being clearly shown to the user as intended. We should consider adding text to the Security Considerations section referring to the appropriate (final) version(s) of this.

[jcjones]

See also: https://docs.google.com/presentation/d/1sK9hhI0y25iioyLGMKwdhtpe-sVRV7Ln4pMHR2JXApw/edit#slide=id.g3ad57c9b5b_0_13

[jcjones]

Per discussion on 31 July call: J.C. was thinking we should try and write an example, but Jeff argued that we could write verbiage saying something akin to: "When WebAuthn is being rendered in an embedded frame, IntersectionObserver should be used to ensure that the intended UI is displayed by the user agent and is not obscured or occluded in any way."

[jcjones]

On 30 Oct 2019 call, decided to close this one per the argument at TPAC that practically, iframes can always be obscured or made not-credibly-visible.

[rlin1]

IntersectionObserver v2 seems to be here: https://szager-chromium.github.io/IntersectionObserver/

--
update by @equalsJeffH on 1-Nov-2019:

The another current link to IntersectionObserver v2 Editors' Draft spec (but without the diff highlighting): https://w3c.github.io/IntersectionObserver/v2/ ("IOv2")

A google blog post wrt IOv2: https://developers.google.com/web/updates/2019/02/intersectionobserver-v2

IOv2 Explainer (the above blog post was based in part on this):
https://github.com/w3c/IntersectionObserver/blob/v2/explainer.md

ChromeStatus on Intersection Observer v2:
https://www.chromestatus.com/feature/5878481493688320

[equalsJeffH]

@jcjones:

per the argument at TPAC that practically, iframes can always be obscured or made not-credibly-visible

hm, I cannot find that discussion/argument in the webauthn TPAC 2019 minutes -- did we have it during a regular concall? my search-fu is failing me at the moment... re-opening this because I think we oiught to point to the discussion or summarize it in more detail if we can.

[equalsJeffH]

The "argument at TPAC" was (also?) after TPAC and on the webauthn concall on 2019-10-09 (minutes). The referred-to github issue comment of AGL's is: https://github.com/w3c/webauthn/issues/1303#issuecomment-540154092 and it says:

since the cross-origin case is disabled by default without an allow blessing, I'm not sure about the utility of this. If we force an iframe to be visible, it can still be white on a white background, so I couldn't use that in a security argument either I suspect. Thus I hope that disabled-by-default is a good safeguard and, if not, would be interested to know others' motivations. [Emphasis added]

[ I am doing some further research wrt the capabilities and status of IOv2 ]

[szager-chromium]

On 30 Oct 2019 call, decided to close this one per the argument at TPAC that practically, iframes can always be obscured or made not-credibly-visible.

Could you expand on this? Yes, an iframe can be obscured or made not-credibly-visible. IntersectionObserver V2 cannot prevent that, but it can notify the iframe's context of the fact.

It seems to me that the more pertinent question is: can IntersectionObserver V2 be defeated in some way, such that an iframe is effectively obscured while IntersectionObserver V2 reports it to be visible? To which I reply: not in any way that I'm aware of; and if such an exploit exists, I would really like to know about it.

[jcjones]

I thought it was at TPAC, but I could be mistaken.

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?

I believe Ricky from Apple (I don't know their Github nick) then asked about the iframe being large enough to permit the user to interact with it, and thus trigger WebAuthn that way. (Which is, to note, one possible answer to issue #1293, but per the lessons WebPush in #1336, Firefox is also speculating as to requiring that the user have interacted with the content at all.)

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?

[rmondello]

Ricky is @rmondello. 👋🏼

[kenrb]

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.

[jcjones]

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.

Thanks for the pull-back to the big picture, @kenrb. You're right, and this is specifically about adding to the Security Considerations section.

I'm in agreement, we should note for RPs' sake that they should consider using IOv2 to confirm that their WebAuthn UI is visible. I am not sure how to wordsmith that from the top of my head, as we also know that it appears most WebAuthn RPs would prefer to remain invisible and keep the branding to the top level context, but nudging the community toward using IOv2 where applicable is a good idea.

But I don't know how to use IOv2 to enforce things at the user agent, so I feel we should keep references, for now, in the Security Considerations section.

Anyone want to take a quick stab at wordsmithing what an RP would want to know about use of IOv2? "Relying parties being embedded within a frame can use IOv2 to confirm that their WebAuthn user experience is visible to the user and compliant with their authentication guidelines..." or some such?

[equalsJeffH]

Anyone want to take a quick stab at wordsmithing what an RP would want to know about use of IOv2? "Relying parties being embedded within a frame can use IOv2 to confirm that their WebAuthn user experience is visible to the user and compliant with their authentication guidelines..." or some such?

heh, note that the above suggestion is essentially what I was suggesting on the 31-Jul call

I'll craft a PR to address this :)

[jcjones]

If anyone wants to volunteer to write the PR, @equalsJeffH has amassed some advice on using IO2 with WebAuthn that he can brain-dump to the PR-author.

[equalsJeffH]

i think we ought to address this (as far as I presently know), tho it can be addressed in a milestone later than wd-03