Re: Web Payment Request Spec Proposal

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'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/ ?

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.

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).


> 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>

Received on Saturday, 4 July 2015 05:32:05 UTC