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

Re: NASCAR - A two-dimensional issue

From: Michael Williams <michael.williams35@gmail.com>
Date: Sat, 2 Aug 2014 05:40:00 +0000
Message-ID: <CA+VkC+1dZYhV--yUM=f4GfgEydX2qXDTx8rH_j5q6LMRLTCQKg@mail.gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: Web Payments CG <public-webpayments@w3.org>
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.

cheers,
Michael


On Sat, Aug 2, 2014 at 5:07 AM, Anders Rundgren <
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 05:40:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:38 UTC