Re: [Agenda] 22 January call for the task force of the Web Authentication and Web Payments Working Groups

Hi all,

Sorry for the late write-up! It looks like the scenario I wanted to
describe is
approximately captured by the new "Merchant is a pass-through between the
issuing bank's FIDO server and the client" section in the wiki, which I've
been
referring to as the "federated authentication" use case. I wanted to provide
some more color on this use case and suggest a few small tweaks:

 * As we discussed on the calls, reducing friction in the checkout flow is
   important to improve conversion rates. Ideally, when the customer clicks
the
   "Pay" button on the merchant site, the Web Authentication prompt would be
   triggered immediately with no extra UI or additional clicks.

   In today's world there's a lot of intermediate UI where the issuing bank
   opens up in an iframe and the user has to reorient themselves and click
   around a few times to complete authentication, which creates a poor user
   experience and a lot of loading spinners. Getting to a one-click checkout
   flow with Web Authentication would be a significant attraction.

  (I imagine it would actually be more like two clicks, one on the "Pay"
button
   plus a tap/biometric scan for Web Authentication's user presence check.
It
   would be interesting to explore if there's a way to consolidate these two
   actions and use the user presence check as the actual payment action,
but I
   don't know if that's too ambitious.)

 * On the merchant side, we've heard that some merchants are hesitant to
trust
   code and embedded resources from issuing banks. In today's world,
opening the
   3D Secure challenge iframe requires punching a hole in the merchant
origin's
   content security policy in order to embed the frame; an ideal solution
here
   would be fully compatible with CSP best practices.

   Concretely, where the wiki currently talks about "the ACS, via code
embedded
   in the merchant site", I'd like to suggest that this interaction be
handled
   by the browser, with the necessary Web Authentication parameters
(credentials
   list, etc.) passed on the back end via a payment network like 3DS or
   SRC. This would allow the merchant origin to avoid embedding resources
from
   the issuer origin.

 * Related to the above, making network requests to the issuer can be
   problematic in cases where the issuer has downtime or experiences network
   disruptions. Not all issuers are able to run highly-available
internet-facing
   services, and the way that banks present a large target for DDOS attacks
is
   always a concern. Further, because the payments use case involves
   coordinating between two parties (the merchant origin and the issuer
origin),
   it's very difficult to pinpoint these sorts of problems when they're
reported
   by customers.

   In contrast, the card networks are built around a store-and-forward model
   where messages can be queued if a component is unavailable. In an ideal
   world, Web Authentication would integrate with the card networks in a way
   that preserves this property, e.g.:

    - Merchant fetches Web Authentication parameters via a backend call to
the
      issuer (the results of which can be cached)

    - Merchant invokes the Web Authentication API from the merchant origin
and
      receives some sort of cryptogram in response; no network requests to
the
      issuer origin are required.

    - Merchant forwards the cryptogram to the issuer for validation via a
second
      backend call. (We might also consider having a mechanism for
merchants to
      check the cryptogram on their own in case the issuer is down, but it
seems
      like this might involve a privacy trade-off for the user).

  (As an aside: one interesting use case is businesses that operate paid
wi-fi
   hotspots, for coffee shops and the like. These merchants are running a
   captive portal that shows a payment page and allows outbound network
access
   to their payment provider. With 3D Secure this system breaks down because
   it's not really feasible to maintain a whitelist of issuing banks --
there
   are thousands and the list changes frequently. But this use case is an
   example of a constrained network environment where limiting requests to
the
   merchant origin only is particularly valuable.)

 * One more use case, this one on the issuing side: say an issuing bank
already
   supports Web Authentication for their online banking portal; we can
imagine
   that customers use it to log in, to confirm large transfers, and for
other
   sensitive account actions.

   If this bank wants to adopt Web Authentication for the payments use case,
   they would reasonably want to take the precaution of separating the
   credentials used for payments from the credentials used for online
banking.

   I know we've talked about having the issuer run code in the payment flow
that
   gates which merchant origins can request a signature, but I don't think
   that's quite the right mental model. Rather, we want to have two
identities:
   one used for online banking, which can *never* be accessed from a
third-party
   context and can *only* be used to mint online banking sessions, and
another
   which can *only* meaningfully be accessed from a third-party context
   (i.e. the bank won't let it be used to mint online banking sessions) and
is
   instead used to mint some kind of payment cryptograms (a signature over a
   transaction ID and amount and merchant origin, more or less). In this
world,
   the issuing bank doesn't care about gating access to certain merchant
   origins: from their perspective, any origin should be able to request a
   payment cryptogram from the issuer's payment key, and if the user taps
their
   authenticator then they're consenting to transact with that origin.

I hope these cases are clear and interesting; I'm happy to talk more on
tomorrow's call!

~Benjamin

On Mon, Jan 20, 2020 at 9:36 AM Ian Jacobs <ij@w3.org> wrote:

> Dear task force participants,
>
> Jonathan Grossar and I have made some edits to the payments use cases for
> Web Authentication:
>    https://github.com/w3c/webauthn-pay/wiki/Use-cases
>
> I am hoping we also have edits from Benjamin Tidor in time for the
> discussion.
>
> Call info:
>
>  - The call is from 10:30-11:00 ET
>  - WebEx: http://www.w3.org/2019/11/sectf.ics
>  - IRC: irc.w3.org #webauthn-pay
>
> Thank you,
>
> Ian
>
> --
> Ian Jacobs <ij@w3.org>
> https://www.w3.org/People/Jacobs/
> Tel: +1 718 260 9447
>
>
>
>
>