- From: Evan Schwartz <evan@ripple.com>
- Date: Thu, 2 Jul 2015 10:43:49 -0700
- To: Anders Rundgren <anders.rundgren.net@gmail.com>
- Cc: Web Payments IG <public-webpayments-ig@w3.org>, Doug Schepers <schepers@w3.org>
- Message-ID: <CAONA2jWySTpnox38inX__-eiiBH6Of437k5Evw4e5CVZjctJbw@mail.gmail.com>
This proposed standard is indeed meant to be very generic. 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. 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, unless it involves making calls out to other apps, in which case standards would help increase interoperability. On Thu, Jul 2, 2015 at 1:08 AM, Anders Rundgren < 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> >> > > -- Evan Schwartz | Software Architect | Ripple Labs [image: ripple.com] <http://ripple.com>
Received on Thursday, 2 July 2015 17:44:37 UTC