Re: Rethinking Apps Payments API, Re: Payment App API: updated flow description

On January 24, 2017 at 9:30:20 AM, Adam Roach (abr@mozilla.com) wrote:
> There are a lot of words here, but when I look closely, I see a very
> small number of issues here that Marcos is raising. On close inspection,
> it seems to me that these can be fixed in the current spec with fairly
> minor changes.

I guess, as the existing proposal is pretty thin. However, there are
parts that require a significant rework... and there are parts that I
hold strongly that need to be elevated to the TAG for resolution.

The spec is also unnecessarily verbose - so after all is said and
done, there won't be much of the original left because I'm literally
proposing to change ~95% of it.

> Rather than trying to discuss all of these in this email
> thread, I think we'll make more rapid progress if we break them down
> into separate issues. To that end, I've filed a number of issues on the
> Payment App spec:
>
> 1. Add explicit call to request user permission:
> https://github.com/w3c/webpayments-payment-apps-api/issues/94
> 2. Replace setManifest()/getManifest() with
> set()/get()/keys()/has()/delete():
> https://github.com/w3c/webpayments-payment-apps-api/issues/95
> 3. Handling of filtering (currently, canHandle()):
> https://github.com/w3c/webpayments-payment-apps-api/issues/96
> 4. Different approaches to opening windows:
> https://github.com/w3c/webpayments-payment-apps-api/issues/97
> 5. Limit of one-payment-app-per-origin:
> https://github.com/w3c/webpayments-payment-apps-api/issues/98

This description not quite correct - but can discuss there.

6. Use PaymentRequest and PaymentResponse
https://github.com/w3c/webpayments-payment-apps-api/issues/99



> The one flipping-over-the-apple-cart suggestion in here is an implied
> proposal to remove the vast majority of the browser behavior (e.g.
> shipping address collection), and to simply pass the raw payment request
> object to payment apps unchanged. I believe this reads more squarely on
> the Payment Request spec, since it has several baked-in notions of how
> this is supposed to work. That said, it's not clear how Marcos' proposal
> intends for these things to hang together (e.g., payment matching,
> filtering), so I think we need some level of clarification before I can
> even file an issue that captures it sensible. Marcos: I'm sure you
> understand your objection here better than I do; can you please file an
> issue that captures the core issue?

I understand.

See it this way: if we (browser engineers) can implement it/solve-it
in the browser, then web developers MUST be able to solve it/implement
it in the Service Worker. The browsers and the developers MUST use the
same primitives to implement the a feature (bar some privacy
restrictions where it makes sense). There must not be any magic (i.e.,
no autofilling of addresses, or whatever): the developer MUST be given
as much control as possible - same control that browser vendors have.
If we don't do that, we are in violation of the extensible web
manifesto and we are doing ourselves and developers a disservice.

Received on Tuesday, 24 January 2017 04:24:13 UTC