cross-origin framing of webauthn-wielding origins (WebAuthn + Web Payments)

Hi WebAppSec folk,

In the context of Web Payments, a "payee", aka "merchant", webapp
("payee origin") may utilize "payment handler(s)" [6] associated with
"payment method provider(s)" (PMP) [7], which may be sourced from an 
origin (PMP origin) _distinct from the payee origin_. See also [8].

It is within the context of the payment handler(s) that the user will 
need to authenticate with the payment method provider(s), and for UX 
friction-reduction reasons, there is a desire to "frame" [1] the payment 
handler's responsible browsing context [2] rather than perform a
top-level navigation (ie load an entire new page).

Thus, there apparently is a desire to "relax" credman/webauthn's [0] 
stipulation that a "nested browsing context" [1] invoking the webauthn 
API methods [2] MUST be "same-origin with its ancestors" [3].

Now, in my casting about to see how to secure cross-origin frames that 
wield "powerful features" (such as webauthn and webpayments), it seems 
that we might be getting close to being able to make it happen (tho 
caveats apply):

1. Relax the "same-origin with its ancestors" stipulation in credman 
(spec-editing-wise, this is a simple change), and

2. Make authorization for use of webauthn be a policy-stated permission 
in Feature Policy [9], similar to allowpaymentrequest [10], and

3. Payment Handlers should/must (?) use Site Isolation [11]. This is 
because Payment Handlers are cross-origin from the payee, have a framed 
component, and have a service worker component. The latter spec would 
likely need updating to accommodate having `very-important.example` 
being cross-origin framed because that is presently disallowed by 
default [12].

4. AND, find some solution for the "Origin Confusion" conundrum [13] 
(this may be the most severe obstacle to address) and any other relevant 
security considerations in both credman & webauthn [0], such as 
clickjacking. The latter is a major concern for such "powerful" framed 
content. It seems Intersection Observer v2 [14] with its 
"trackVisibility" attribute which reports [16] whether whether an 
element is unoccluded, untransformed, unfiltered, and opaque (i.e., 
_visible_) may (drum roll) offer the needed solution here.


Thus the assertion being proposed/questioned here is that if one 
addresses 1 thru 4 above, then one ought to be able to deploy relatively 
secure cross-origin Payment Handlers wielding Web Authentication.

WDYT?

thanks, =JeffH


[0] https://w3c.github.io/webappsec-credential-management +
      https://www.w3.org/TR/webauthn/

[1] https://html.spec.whatwg.org/#nested-browsing-context

[2] https://html.spec.whatwg.org/#responsible-browsing-context

[3] 
<https://w3c.github.io/webappsec-credential-management/#same-origin-with-its-ancestors>

[4] https://html.spec.whatwg.org/#same-origin

[5] https://html.spec.whatwg.org/#parent-browsing-context

[6] https://w3c.github.io/payment-handler/#dfn-payment-handler

[7] https://www.w3.org/TR/payment-request/#dfn-payment-methods

[8] https://w3c.github.io/payment-handler/#handling-a-payment-request

[9] https://wicg.github.io/feature-policy/

[10] 
<https://wicg.github.io/feature-policy/#iframe-allowpaymentrequest-attribute>

[11] https://wicg.github.io/isolation/

[12] https://wicg.github.io/isolation/#strategy

[13] 
<https://w3c.github.io/webappsec-credential-management/#security-origin-confusion>

[14] https://szager-chromium.github.io/io-v2/

[15] 
<https://szager-chromium.github.io/io-v2/#dom-intersectionobserver-trackvisibility>

[16] <https://szager-chromium.github.io/io-v2/#calculate-visibility-algo>

Received on Monday, 14 May 2018 23:57:05 UTC