Re: Decision [Was: CfC to publish documents as FPWD of the Web Payments WG]

On 2016-04-18 10:57, Adrian Hope-Bailie wrote:
>
>
> On 15 April 2016 at 08:11, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>     On 2016-04-14 19:27, Ian Jacobs wrote:
>
>         Dear WPWG,
>
>         As discussed on the teleconference today [1], on behalf of the Chairs I’m pleased to record the decision to publish
>         three specifications as FPWDs based on your feedback [2]:
>
>             * Payment Request API
>             * Payment Method Identifiers
>             * Basic Card Payment
>
>         If all goes well, these will be published on 21 April.
>
>
>     I wonder how many of the members who supported the publication realized that the
>     Web Payment API core concept (orchestrating payment method selection and execution),
>     effectively requires a *complete rewrite* of these parts of a Web shop, in addition
>     to introducing a new registration step for legacy payment systems.
>
>
> That's not true at all. Using the API is a) entirely optional and b) can be added as
 > a first step with a fallback to the traditional payments page.
>
> For a merchant or PSP it is very easy to phase this in as failure will be invisible
 > to the user so a fallback is graceful.

That there is a graceful/invisible fallback is great but doesn't remove the initial
hurdle I mentioned.


> Further, the payment method specs being written by the WG will bootstrap the
 > process of defining payment methods by setting standards for the most commonly
 > used payment methods from the outset.
>
> Finally, we expect browsers to offer "built-in" payment apps initially that will
 > leverage the stored credit card details they already hold for their users
 > bootstrapping the process even further.

I'm just unconvinced that the gain is sufficient to motivate such a big change.
The UI may get (slightly) better but that's all.  There's no proof of any work
on security for example.


>     I perfectly well understand the motives for this rather extreme measure, but all
>     approaches have downsides and those haven't been discussed much.
>
>
> What would you say the downsides are that have been under-discussed?

The one I mentioned.

I'm also unconvinced that mixing payment request data from N number of payment
systems is a really great idea.


>     IMO, it had been wiser targeting "low-hanging fruit" like being able calling the
>     countless number of custom "App"-based [payment] schemes out there, from the Web.
>     This would also tap into an existing, pretty big source of payment innovation money.
>     Practically "everybody" wants to have a Wallet...
>
>
> Except that's exactly what we have done. The API is intended to be a mechanism to bridge
 > from the Web to a payment app which may be another web based app or may be a native app
 > or even a headless service.

To me this part of the specification is pretty unclear and probably needs considerable
testing before being committed to.

BTW, you have for example repeatedly mentioned that the scheme I advocate (an application-
neutral bridge from the Web to the App world), would introduce unknown (maybe unsolvable)
security and privacy issues.

Apparently Google and Microsoft have solved these issues. My question is then: How?

IMO, the Android intent scheme is insufficient (it was created for invoking media applications).
Microsoft's assertion that this part of spec also is entirely platform-dependent is somewhat
puzzling. Which part of what specification?

I better hold my horses for now and rather wait for the announcement of Apple "Web" Pay
which I with 99.9% certainty believe won't need any changes in existing Web payment code;
it will be just a new cool payment option (for iOS users) with it own unique support code.

thanx,
Anders
>
>
>     thanx,
>     Anders
>
>
>
>
>         We will continue to work as a group to increase support for the architecture specification before proposing
>         it again as a FPWD.
>
>         Thank you for responding to the Call for Consensus and congratulations on your progress as a Working Group,
>
>         On behalf of the Co-Chairs,
>         Ian Jacobs, Team Contact
>
>
>         [1] https://www.w3.org/2016/04/14-wpwg-minutes#item01
>         [2] https://github.com/w3c/webpayments/wiki/CFC_20140412
>
>
>             On Apr 5, 2016, at 2:29 PM, Adrian Hope-Bailie <adrian@hopebailie.com <mailto:adrian@hopebailie.com>> wrote:
>
>             This is a Call for Consensus (CfC) to publish one or more documents as First Public Working Drafts (FPWD) of the Web Payments Working Group.
>
>                      • Proposal 1: Publish "Payment Request API" as a FPWD
>                              • https://cdn.rawgit.com/w3c/browser-payment-api/0d1d5d7ff0f1bb7b37970994f1eb719101aaccbc/fpwd/paymentrequest.html
>                      • Proposal 2: Publish "Payment Request API Architecture" as a FPWD
>                              • https://cdn.rawgit.com/w3c/browser-payment-api/0d1d5d7ff0f1bb7b37970994f1eb719101aaccbc/fpwd/architecture.html
>                      • Proposal 3: Publish "Payment Method Identifiers" as a FPWD
>                              • https://cdn.rawgit.com/w3c/browser-payment-api/0d1d5d7ff0f1bb7b37970994f1eb719101aaccbc/fpwd/method-identifiers.html
>                      • Proposal 4: Publish "Basic Card Payment" as a FPWD
>                              • https://cdn.rawgit.com/w3c/browser-payment-api/0d1d5d7ff0f1bb7b37970994f1eb719101aaccbc/fpwd/basic-card-payment.html
>             For each proposal:
>
>                      • We invite responses on this thread to each of the proposals.
>                      • Silence will be taken to mean there is no Formal Objection [1], but positive responses are encouraged. Publication as a FPWD does NOT indicate that a document is complete or represent Working Group consensus.
>                      • If there are no Formal Objections by 12 April 2016 (1pm EDT), the proposal will carry and the Chairs will request that the Director approve publication as FPWD(s).
>             The W3C Director takes Formal Objections seriously, and therefore they typically require significant time and effort to address. Therefore, please limit any Formal Objections to issues related to the scope of these documents rather than technical content where the Working Group has not yet made a decision. Please include substantive arguments or rationale for consideration by the Director.
>
>             If there are Formal Objections, the Chairs plan to contact the individual(s) who made the Formal Objection to see whether there are changes that would address the concern and increase consensus to publish. Depending on the number and nature of the Formal Objections, the Chairs will either make a decision either to pursue FPWD and report the Formal Objections to the Director (as required by W3C Process), or to postpone publication until there is greater consensus to publish.
>
>             If there is a decision not to publish a document, we will adjust our communications to let people know about the Editor's Drafts and the decision to delay their publication as FPWDs.
>
>             NOTES:
>
>                      • Publication of a FPWD is a signal to the broader community that we are seeking review of the specification(s) in their early stages. To frame that discussion, we plan to publish a blog post with the publication:
>                              • https://www.w3.org/2016/03/15-wpwg-blog.txt
>                      • Publication of a FPWD triggers an event under the W3C Patent Policy.
>                      • The Working Group discussed this Call for Consensus at its 17 March 2016 teleconference
>                              • https://www.w3.org/2016/03/17-wpwg-minutes
>             For the Chairs, Adrian Hope-Bailie
>
>             [1] https://www.w3.org/2015/Process-20150901/#Consensus
>
>
>         --
>         Ian Jacobs <ij@w3.org <mailto:ij@w3.org>> http://www.w3.org/People/Jacobs
>         Tel: +1 718 260 9447 <tel:%2B1%20718%20260%209447>
>
>
>
>
>

Received on Monday, 18 April 2016 09:48:36 UTC