W3C home > Mailing lists > Public > public-webpayments@w3.org > August 2014

Re: NASCAR - A two-dimensional issue

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Sat, 02 Aug 2014 08:42:26 +0200
Message-ID: <53DC8852.9000907@gmail.com>
To: Michael Williams <michael.williams35@gmail.com>
CC: Web Payments CG <public-webpayments@w3.org>
On 2014-08-02 07:40, Michael Williams wrote:
> why not switch the order?
> 1. Select provider
> 2. (maybe) Select method
> you are putting your trust in your provider, so it makes sense
  > to immediately choose the provider and then how you interact with
  > your provider is up to you and your provider. additionally, many
  > of the "methods" you are describing are just providers in disguise,
  > so it makes more sense for your trusted provider to delegate to those
  > methods instead of the other way around. it is also possible for a
  > provider to list what methods they have for you on the selection page,
  > but then there is the open question for how not to leak that information.

Thank you very much for the input!

The idea is that the service through a discovery phase indicates
which methods ("providers in disguise") it can deal with.  Only the
methods that matches the user's "wallet" would be shown.

If there is only one method per provider your suggestion would work fine.
If some providers support multiple methods it will (IMHO) be slightly
quirky since method selection will then be performed on different levels.
If you have a moderate set of resources, a flattened-out selection
like BankA.VISA, BankB.VISA, BankB.ACH could also be an alternative.

Regarding information leakage, my take on this (FWIW) is that the
discovery, selection and execution of the payment operation is performed
in dedicated "trusted chrome" but that the execution code still is managed
by the providers since they shouldn't have to rely on browser vendors
supplying payment code.

An unsolved problem is presenting a transaction request in a unified way.
I would (at this stage...) leave this to the execution code with the hope
that the providers would long-term normalize this part on their own.
Trusting the "chrome" is not an option since there's no way the payment
provider can know that the request is inside of trusted chrome or not.


> cheers,
> Michael
> On Sat, Aug 2, 2014 at 5:07 AM, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>     1. Select method (CC, PayPal, BitCoin, ACH, etc.)
>     2. Select provider
>     For proprietary provider schemes like PayPal, 1 usually implies 2.
>     Although it would be nice integrating both steps in one blow, I believe that would
>     be too inflexible since the different methods may be quite complex and potentially
>     updated every now and then.
>     It is probably better that the Platform/UA/Wallet/Whatever remember the last selection
>     (if applicable for the service in question) while still giving the user an option to switch.
>     If we OTOH believe that integration of method and provider selection is crucial,
>     we will end-up with a scheme requiring multiple owners of a single UI (Window)
>     since it must always be possible to back-paddle to the method selector.
>     A thing that I find a bit cumbersome is establishing trust in the software for
>     competing providers sharing the same method such as VISA and MasterCard.
>     I don't really see any other solution than treating them as separate methods
>     and associated provider code modules.  The method selector should be able
>     to optionally unify these methods with respect to the user-interface anyway.
>     There must of course be an initial discovery phase as well.  The only problem
>     I see is that it must not leak data user-data.  A possible solution/workaround
>     is that discovery always brings up the method selection window but doesn't
>     emit any data until the user performs a selection.  Cancel is one of the choices.
>     Yes, this mechanism MUST be an integral part of the browser otherwise it
>     won't work.
>     Thoughts?
>     Anders
Received on Saturday, 2 August 2014 06:42:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:33 UTC