Re: [w3c/webpayments-payment-apps-api] Revisiting payment app filtering (#96)

Hi all,

I'd like to summarize where I think we are on the filtering topic and
propose a way forward.

Summary:

 * For the smoothest user experience, we want the user agent to show
   only those payment apps for selection that have a good chance of
   success.

 * One mechanism we have come up with to increase the chances for
   success for merchants to declare under what conditions they accept
   a given payment method. We have been calling the data that the
   merchant provides to the user agent a "filter." Lately there was
   a suggestion that a better word might be "capability". In this
   summary I use "capability". 

 * Capability data is thus payment method specific.

 * For basic card v1 we have settled on the capability supporting two
   pieces of information: supported networks and card type.

 * We also see the usefulness of capabilities in two other draft
   payment method specifications: tokenized card, credit transfer.
   Thus, we know of three specifications where capability matching
   would be useful.

 * Payment apps also need to be able to declare their capabilities in
   a manner consistent with the merchant's expressions.

 * When are these capabilities taken into consideration? Who compares
   merchant and payment app capabilities?  There seem to be two
   operations where capabilities need to be taken into consideration:

    * show() (section 3.2 of PR API)
    * canMakePayment() (section 3.4 of PR API)

 * Originally the payment apps task force proposed that the user agent
   (mediator) compare the merchant and payment app capabilities.  We cited
   several advantages to this approach, such as:

    - Reducing the cost of payment app development
    - Reducing the cost of payment method development (since
      payment methods could define their own capabilities using a generic
      capability expression language).

 * However, the browser makers indicated they would not likely support
   a generic capability expression language, so the payment apps task
   force resolved to figure out how to have the payment apps take the
   merchant capabilities as input and provide a boolean response back
   to the user agent.

 * For what follows, it's useful to write down the payment app
   flow that I think is generally agreed upon:

     - Merchant calls PR API
     - UA computes payment method intersection
     - UA displays matching payment apps
     - User selects a payment app
     - UA hands data to the selected payment app

   Notice in this flow that no payment app has knowledge that a
   transaction is taking place (and no access to transaction data)
   prior to user selection.

 * For capability matching, one idea was to include it at the
   phase of computing payment method intersection:
 
     - Merchant calls PR API
     - UA computes payment method intersection, in part
       by calling each payment app with merchant capability data
       and selecting only those that respond "true"
     - UA displays matching payment apps
     - User selects a payment app
     - UA hands data to the selected payment app

   However, this raised privacy issues since every payment app would
   wake up at every transaction, prior to selection by the user.

 * To address this privacy issue, the payment app task force
   contemplated an approach where each payment app could register a
   capability matching function to the user agent (we called this
   "canHandle()). That function would be executed without payment app
   knowledge in some constrained environment (e.g., no network
   access).

 * Marcos (and I think others) indicated that providing a function
   would be problematic. (Detailed rationale omitted here.)

 * Since then discussion on this thread has returned to the idea that
   the user agent could perhaps do the capability matching. AdamR and
   Rouslan both wrote proposals ([1], [2]). Each one amounts to
   limited string set matching.

 * Discussion has also included this question: during canMakePayment()
   and show(), why not query the payment app and let the payment app
   do more powerful things (e.g., make network calls)? My understanding
   of the primary reason not to allow this has to do with the privacy
   concern noted above: we do not want every payment app to know about
   every payment request prior to selection by the user.

 * Note that, once selected by the user, a payment app can do powerful
   things and elect to handle or not handle a payment request. This is
   how we responded to Roy's question about whether payment apps could
   elect to not accept payment requests from some origins. Nick
   Shearer wrote, "it's a very real case that some payment apps will
   need to perform asynchronous work to establish whether they're
   available or not."
   
Given what I've heard so far, here's my proposal:

 * To achieve an improved user experience in some common cases, we
   will define a small, generic expression language for basic
   capabilities. The expression language will support string set
   matching. (Details to be worked out; see below.) The expression
   language could be used in any payment method.

 * It is a privacy requirement that payment apps not be invoked for
   basic capability matching prior to selection by the user.

 * For more powerful capability checking (e.g., requiring
   asynchronous network calls), payment apps can do so after
   selection by the user.

 * We ask Rouslan and AdamR to work together and bring a combined
   proposal back to the task force.

 * We seek browser maker support for the combined proposal.

 * We ask AdamR to spec out what changes would be needed in PR API
   to support basic capability matching. This would likely include:
      - The capability expression language and a matching algorithm.
      - How the constructor changes to allow the merchant
        to provide capability matching data.
      - Where in the algorithms to mention application of the
        capability matching algorithm

 * I propose that initially this information be written in a new
   document, and that we will then make a decision how (and whether)
   to incorporate into PR API and reference from payment method
   specifications and the payment app API.
 

Ian

[1] https://github.com/w3c/webpayments-payment-apps-api/issues/96#issuecomment-276416457
[2] https://github.com/w3c/webpayments-payment-apps-api/issues/96#issuecomment-276423629


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments-payment-apps-api/issues/96#issuecomment-278754087