Re: Web Payment Request Spec Proposal

On 2015-07-06 11:13, Adrian Hope-Bailie wrote:
>
>
> On 4 July 2015 at 07:31, Anders Rundgren <anders.rundgren.net@gmail.com <mailto: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.

Couldn't this piece of hardware (payment terminal) be an ordinary computer?

However, secure PIN entry is only a part of the problem, you also need a
"Trusted UI" showing (at least) how much money you are supposed to pay.

How do you achieve the latter using existing Web-tech?  Redirecting + logging
in to your trusted payment provider?  OK, how do you do that [conveniently]
using existing Web-tech given constraints like SOP?

Anyway, EMV-cards remain unusable since all efforts exposing conventional
smart card APIs in the Open Web have failed including two recent projects ran by
the W3C.  "Apps" doesn't have this problem which is one of the many reasons why
recent commercial payment initiatives with very few exceptions are App-based.


> EMVCo's answer to this challenge is tokenisation.

Although I'm *not* an EMV expert, I believe tokenization has another goal,
which is making user payment authorizations and static card data less useful
for attackers.

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

I'm sure about that, I just don't see any blueprints on how that would work.


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

Betting on specific browser-standards for payments (in contrast to finding "primitives"
that have a more general appeal), will probably make the evolving painfully slow.

Anders

>
>
>         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> <mailto: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> <http://ripple.com>
>
>
>
>
>
>         --
>         Evan Schwartz | Software Architect | Ripple Labs
>         ripple.com <http://ripple.com> <http://ripple.com>
>
>
>
>

Received on Tuesday, 7 July 2015 07:02:55 UTC