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

On 5/15/18 3:53 PM, =JeffH wrote:
> 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...

Naturally. I'm suggesting that might not get us where we want to go, but
I suppose it's all we've got.

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

Yes, I didn't mean to imply otherwise.

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

Agreed.

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

It does, thanks!

Peter

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