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

On 5/14/18 5:56 PM, =JeffH wrote:
> Hi WebAppSec folk,

Hi Jeff!

> 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), 

It might help to look at the entities and relationships involved.
Ideally, the user has a relationship with the payment method provider,
which (depending on the W3C-registered or URL-based payment method)
might be a credit card issuer or credit card network (e.g., for the
basic-card or tokenized-card methods), a bank (e.g., for a SEPA-like
direct debit transfer method), a wallet provider (e.g., for methods like
Apple Pay or PayPal), etc. That relationship might be strong enough to
involve prior enrollment (e.g., the user might have installed a browser
add-on or a mobile app), and the user might have more trust in the
payment method provider origin than in the merchant origin (after all,
if I have a dispute with the merchant I might contact my payment method
provider to seek a resolution). Because the trust story is not clear
cut, saying that whatever we're doing here is a relaxation of security
strictures might be off the mark.

> 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.

I need to ponder all those epicycles before replying further. ;-) What
I'm suggesting above is that when it comes to web payments the merchants
orbit the sun of the banks and card networks, so a heliocentric model
might be more appropriate in this instance. Unfortunately, we're stuck
with a geocentric view of the universe...

Peter

> 
> 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>
> 
>