W3C home > Mailing lists > Public > public-webappsec@w3.org > May 2018

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

From: =JeffH <Jeff.Hodges@KingsMountain.com>
Date: Tue, 15 May 2018 14:53:27 -0700
To: W3C WebAppSec WG <public-webappsec@w3.org>
Message-ID: <d633a586-eb93-5601-7159-607f292780e7@KingsMountain.com>
Peter St. Andre replied:> On 5/14/18 5:56 PM, =JeffH wrote:>
 >> 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.

well, the analysis is at a technical browser impl level for the most part...


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

aside: though note that a user may not yet have an established 
relationship with PMP(s) - cf:
<https://www.paypal.com/us/webapps/mpp/account-optional>


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

I am guessing that, wrt "relaxation", you are referring to where I wrote
(below) "...there ... is a desire to "relax" credman/webauthn's
stipulation that a nested browsing context ... MUST be same-origin with
its ancestors" ?

If so, then ok, at some high (but still important, see item 4) level,
the user needs to be informed regarding who the entities are that they
are interacting with, and have assurance that they are not being
phished/clickjacked (again, item 4 below).

However, what I was referring to wrt "desire to relax" is regarding the
currently imposed _technical_ restrictions, at spec and browser impl
levels, on cross-origin framed content.

If we do not figure out how to make such relaxations, then AFAICT the
desire to invoke the webauthn API in cross-origin iframes or service
workers, which it seems from [8] would be necessary, will not work,
given current credman/webauthn specification.

Does this clarify the conundrum ?

See also:
<https://lists.w3.org/Archives/Public/public-webauthn/2018May/0262.html>
  (where the claim "WebAuthn does not support iframe" is examined)


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

 >> 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.
Received on Tuesday, 15 May 2018 21:53:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 15 May 2018 21:53:58 UTC