Mention Intersection Observer v2 in sec considerations

fixes #1105 by describing threat of UI redressing aka clickjacking and pointing to (experimental) https://w3c.github.io/IntersectionObserver/v2/.

index.bs

@@ -6498,20 +6498,6 @@ See also the related security consideration for [=[RPS]=] in [[#sctn-revoked-att
 
 ## Security considerations for [=[RPS]=] ## {#sctn-security-considerations-rp}
 
-### Cryptographic Challenges ### {#sctn-cryptographic-challenges}
-
-As a cryptographic protocol, Web Authentication is dependent upon randomized challenges
-to avoid replay attacks. Therefore, the values of both {{PublicKeyCredentialCreationOptions}}.{{PublicKeyCredentialCreationOptions/challenge}} and {{PublicKeyCredentialRequestOptions}}.{{PublicKeyCredentialRequestOptions/challenge}} MUST be randomly generated
-by [=[RPS]=] in an environment they trust (e.g., on the server-side), and the
-returned {{CollectedClientData/challenge}} value in the client's
-response MUST match what was generated. This SHOULD be done in a fashion that does not rely
-upon a client's behavior, e.g., the Relying Party SHOULD store the challenge temporarily
-until the operation is complete. Tolerating a mismatch will compromise the security
-of the protocol.
-
-In order to prevent replay attacks, the challenges MUST contain enough entropy to make guessing them infeasible. Challenges SHOULD
-therefore be at least 16 bytes long.
-
 ### Security Benefits for [WRPS] ### {#sctn-rp-benefits}
 
 The main benefits offered to [=[WRPS]=] by this specification include:
@@ -6529,8 +6515,30 @@ The main benefits offered to [=[WRPS]=] by this specification include:
 1. The [=[RP]=] does not need to store additional secrets in order to gain the above benefits.
 
 As stated in the [[#sctn-conforming-relying-parties|Conformance]] section, the [=[RP]=] MUST behave as described in [[#sctn-rp-operations]]
-to obtain all of the above security benefits. However, one notable use case that departs slightly from this is described in the
-next section.
+to obtain all of the above security benefits. However, one notable use case that departs slightly from this is described below in [[#sctn-attestation-limitations]].
+
+
+### Visibility Considerations for Embedded Usage ### {#sctn-seccons-visibility}
+
+Simplistic use of WebAuthn in an embedded context, e.g., within <{iframe}>s as described in [[#sctn-iframe-guidance]], may make one's users vulnerable to <dfn>UI Redressing</dfn> attacks, also know as "[Clickjacking](https://en.wikipedia.org/wiki/Clickjacking)". This is where an attacker overlays their own UI on top of a [=[RP]=]'s intended UI and attempt to trick the user into performing unintended actions with the [=[RP]=]. For example, using these techniques, an attacker might be able to serreptitiously trick users into unintended actions such as purchasing item(s), transferring money, etc.
+
+Therefore, it is important for an [=[RP]=] having embedded WebAuthn-wielding content to ensure that their content's UI is visible to the user. An emerging means to do so is by observing the status of the experimental [Intersection Observer v2](https://w3c.github.io/IntersectionObserver/v2/)'s `isVisible` attribute.
+
+
+
+### Cryptographic Challenges ### {#sctn-cryptographic-challenges}
+
+As a cryptographic protocol, Web Authentication is dependent upon randomized challenges
+to avoid replay attacks. Therefore, the values of both {{PublicKeyCredentialCreationOptions}}.{{PublicKeyCredentialCreationOptions/challenge}} and {{PublicKeyCredentialRequestOptions}}.{{PublicKeyCredentialRequestOptions/challenge}} MUST be randomly generated
+by [=[RPS]=] in an environment they trust (e.g., on the server-side), and the
+returned {{CollectedClientData/challenge}} value in the client's
+response MUST match what was generated. This SHOULD be done in a fashion that does not rely
+upon a client's behavior, e.g., the Relying Party SHOULD store the challenge temporarily
+until the operation is complete. Tolerating a mismatch will compromise the security
+of the protocol.
+
+In order to prevent replay attacks, the challenges MUST contain enough entropy to make guessing them infeasible. Challenges SHOULD
+therefore be at least 16 bytes long.
 
 
 ### Attestation Limitations ### {#sctn-attestation-limitations}