Re: Web Payment Request Spec Proposal

On 4 July 2015 at 07:31, Anders Rundgren <anders.rundgren.net@gmail.com>
wrote:

> On 2015-07-02 19:43, Evan Schwartz wrote:
>
>> This proposed standard is indeed meant to be very generic.
>>
>
> I understand.  W3C have also set the bar very high which differs from most
> other
> efforts in this space which are rather about "Doing one thing, but doing
> it Good".
>
> FWIW, I started with the "simpler" question: How come the BILLIONs of
> secure
> and convenient EMV-cards aren't usable on the Web?  As it turns out, this
> is
> [technically] due to *fundamental limitations in the Web architecture*
> which
> IMHO is a more logical area for exploration by SDOs than applications.
>
>
I disagree with this assertion.

EMV is predicated on the chip card being insrted into a piece of hardware
that can securely communicate with the chip. In the case of countries that
have adopted chip and PIN it is also dependant on a tamper proof PIN entry
device. The absence of this hardware in the majority of Internet enabled
devices use to access the Web is the reason you can't use EMV on the Web.

EMVCo's answer to this challenge is tokenisation.


>  I'd argue that standards should focus primarily on the interactions
>> between
>>
>  > different, independently controlled systems (e.g. the browser and a
> merchant website).
>  > Many of the details should be left to the component vendors themselves.
>
> At the 50000 ft altitude everything feels OK :)
>
>
>  Browser vendors have an incentive to make the experience as good as
>> possible
>>
>  > (this was heavily inspired by a presentation Zach Koch from the Chrome
> team gave).
>  > I don't think we need to figure out exactly how this type of request
> would be handled
>  > by the browser
>
> Wouldn't a payment request have to be handled by the
> browser/agent/wallet/whatever
> with the same "precision" as for example:
> http://www.w3.org/TR/WebCryptoAPI/ ?
>

This is dependant on the payment scheme


> That payments also involve (for the browser vendors) unprecedented amounts
> of UX issues,
> contributes making implementations quite challenging, which is why I
> advocate a
> scheme where [externally supplied] payment agents rather are called by the
> browser.
>
>
This is exactly what this standard will allow except the "external" system
could be native or cloud-based or built into the browser.


> The difference in development speed between these approaches may very well
> be 10-to-1.
> Manu's emphasis on "polyfill" [indirectly] strengthens my argument that
> building on
> the browser vendors' engagement is not going to be easy (if even possible).
>
>
Why does this have to be an all or nothing scenario. The Web doesn't
suddenly go from vx to vx+1.
Things evolve over time.


>
>  unless it involves making calls out to other apps, in which case
>> standards would help
>>
>  > increase interoperability.
>
> AFAICT, the interoperability requirements should be the same regardless of
> which sub-system
> that actually processes a call.
>
> Anders
>
>
>> On Thu, Jul 2, 2015 at 1:08 AM, Anders Rundgren <
>> anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>
>> wrote:
>>
>>     On 2015-06-18 20:31, Evan Schwartz wrote:
>>     > Here is a rough prototype for what a Web Payment Request standard
>> could look like.
>>     > This is a spec that the browsers or user agents would implement,
>> and websites could call.
>>
>>     I haven't seen any comments on this but the proposal do high-lite
>> some of the issues
>>     around a potential "Payment API":
>>
>> https://github.com/emschwartz/web-payment-request-chrome#windowrequestpayment
>>
>>     The described API appears to be very high-level (abstract) and is
>> supposed to hook
>>     into some browser underpinnings that does the actual work, right?
>>
>>     However, this kind of API (which probably is the only way to achieve
>> consensus...),
>>     doesn't really buy you anything since the underpinnings still aren't
>> addressed.
>>
>>     Maybe the idea is that the Web Payment Architecture WG should perform
>> core R&D?
>>     "WebIDL" doesn't say anything except that "there's something in the
>> browser".
>>     I would add 12+ months for doing basic research/testing but it still
>> feels like
>>     something belonging to an incubator since the outcome "by definition"
>> is unknown.
>>
>>     As I have shown, there's another, and much more flexible route for
>> energizing
>>     Secure, Convenient, and Distributed payments on the Web. That it
>> builds on technology
>>     [partially] already available in "Chrome" doesn't seem like a
>> disadvantage.
>>
>>     Just my 2 centimes.
>>
>>     thanx,
>>     Anders
>>
>>
>>     On 2015-06-18 20:31, Evan Schwartz wrote:
>>
>>         Here is a rough prototype for what a Web Payment Request standard
>> could look like. This is a spec that the browsers or user agents would
>> implement, and websites could call. Importantly it is a standard that could
>> support all types of payment schemes without the schemes having to change
>> or implement anything.
>>
>>         https://github.com/emschwartz/web-payment-request-chrome
>>         (It is implemented as a Chrome extension now but ideally some of
>> that functionality would be handled by the web browser natively)
>>
>>         This is a small subset of what the IG has been discussing but it
>> is a very simple spec that could address some of the problems the group is
>> interested in solving. Its scope is intentionally small and restricted to a
>> retail use case on the Web.
>>
>>         Comments, issues, questions, and pull requests are very welcome!
>>
>>         Looking forward to hearing your feedback,
>>         Evan
>>
>>         PS This was the written proposal that underlies the thinking that
>> went into this prototype:
>> https://docs.google.com/document/d/10T3z25zzBoorOaOUuQiJCu7gZXQeSvUSqYpJmsqrE6Y
>>
>>         --
>>         Evan Schwartz | Software Architect | Ripple Labs
>>         ripple.com <http://ripple.com> <http://ripple.com>
>>
>>
>>
>>
>>
>> --
>> Evan Schwartz | Software Architect | Ripple Labs
>> ripple.com <http://ripple.com>
>>
>
>
>