Web Payments Working Group Teleconference

06 Apr 2017


See also: IRC log


Ian, Mathieu, Alan, Michel, Andre, Dezell, molly, Christian, AdamR, Max, zkoch, Roy, rouslan, Ken, Wonsuk
oyiptong, NickTR, AdrianHB


Structure of this meeting

IJ: Chairs not here; I want to formalize any decisions with them next week


PR API Issues


<scribe> scribe: Ian

zkoch: The editors triaged yesterday....
... we marked most of MattS's messages as editorial
... we think there are only a few substantive issues

(e.g., 486)

scribe: so the list is essentially what it was at the end of FTF meeting
... this will be what we will target over the next 2-6 weeks

IJ: Expectation is issue management, then spec update, then CfC
... Any to discuss today?

zkoch: We want to discuss issue 481 https://github.com/w3c/browser-payment-api/issues/481
... I'd like to get closure on it
... My inclination is to remove it because it does not materially affect conformance.

IJ: I also note text elsewhere in the spec: ""The methodData supplied to the PaymentRequest constructor SHOULD be in the order of preference of the caller. "

Ken: I haven't thought about that one. As a general policy my view is that if we can remove any language that provides an unintended bias or preference it's better for the health of the spec to neutralize it.

dezell: At the meeting I commented on this point. Removing any non-normative text is ok. Simplifying it is ok, and not entangling the spec with marketing elements is also fine
... I'm ok with the change

mweksler: I think that this thing that we are trying to do is facilitate merchants using the spec. Merchants today have full control over what they do. The language in the spec already "limits their control"

(Spec says "MAY respect their preference)

scribe: I agree that removing the language doesn't materially change anything, but I think the intent is important

<alyver> +1 to Michel's comments.

scribe: I think that we should think about the opposite direction: the user agent MUST respect the merchant prefs

<dezell> clarifying - I am worried about any changes that go against the original intents of the group as chartered. So far I don't see any of those.

Ken: I agree that we want to make things better for the merchant. We may want to look back at the intent in the charter.

WG Charter

scribe: was the goal to get interop or support preferences?
... merchants, brands, issuers may not all be adequately represented here

alyver: I want to add a concern that if the experience is not consistent...if the merchant cannot specify the ordering, that means that payment methods may appear in different order in different browsers.
... that would be one concern we would have...Shopify can control order exactly today

zkoch: The Spec does not today guarantee that

alyver: I realize that.

Proposal: Neutralize language regarding payment method ordering

<rouslan> +0

<adamR> +0

<Ken> +1

<dezell> +1

zkoch: weak +1

<mweksler> -1

<alyver> -1

zkoch: As I understood it, this was identified as a big issue (potentially for networks) so if it's non-normative and can increase support, I'm ok to take it out

<dezell> I agree with Zack's characterization.

Alan: What does neutralize mean exactly?
... it's the merchant's web site...merchant's need to have maximum guidance for controlling what they do
... and if there are separate contractual obligations, it's their responsibility to meet those

<Zakim> dezell, you wanted to bring up another aspect.

dezell: I agree with Zach's characterization...I see this as mechanical.
... I think as long as we can agree to the mechanical change, that's probably a good thing.
... even talking about ordering is fraught
... so that's one reason I'm in favor of saying less

Ken: I want to take exception to the prospect that what the merchant wants trumps other preferences.
... we would generally seek balance in a payment environment....costs and benefits to various stakeholders in the ecosystem.
... there are other stakeholders to balance as well such as issuers, card networks, etc.
... I believe that changing the language does not change the merchant's ability functionally

IJ: Would it be useful to include informative text about superior user experience in goal, taking into account information from the environment (including PR API data, user prefs and history, e tc.)

<alyver> +1

Michel: I think that's fine. It seems like it's the direction things are going in; I'm fine with that and adding that language will help a bit

(Add to my list: security considerations)

Michel: The concern I have is that we are weakening the spec and making it less likely for merchants to accept it.
... so I'm ok with this change, but want to remain cognizant of the risk

Ken: Voice of the merchant is important to us. I note the concern. Separately I've been participating in the merchant adoption task force; please get involved to help drive adoption

PMI Spec issues for CR


Ian: I see none

IJ: Any for CR?

Roy: We only reviewed PR API yesterday

[Zach back]

IJ: what is expectation about resolving them for CR?

zkoch: I will triage the PMI list. I did not see new issues filed.

<scribe> ACTION: Zkoch to triage the PMI list of issues and send to the WG [recorded in http://www.w3.org/2017/04/06-wpwg-minutes.html#action01]

<trackbot> Created ACTION-55 - Triage the pmi list of issues and send to the wg [on Zach Koch - due 2017-04-13].

Basic Card

Zkoch: It's a small list; some minor modifications to make....
... I don't think anything material will change

MattS: I thought there were some issues around basic card.
... the one that springs to mind is the "notRequiredFields" for Basic Card


IJ: Did editors review that?

zkoch: I will bring this up with the editors. But I think we've had this discussion before. I don't think the arguments have changed even if the discussion has been reraised.
... I don't think we should use "SHOULD"
... I buy the desired functionality (and have heard from merchants as well)
... so I'd rather acknowledge the functionality and postpone.

MattS: there's a related issue about ambiguity about optional parameters (issue 26)
... BasicCard only requires PAN. Others are optional.

[There are different rules for different schemes]

zkoch: Some schemes require fields, others do not
... I don't know how to enforce "MUST return data"
... I will comment on the issue thread

MattS: Ian has captured it...this is not about changing implementations. I think chrome meets the requirements. But the spec is ambiguous
... today a compliant app could decide to return only PAN
... therefore someone could comply and be useless
... to me it makes sense that the spec capture the intent.

zkoch: My general point is that I agree on what is being said...I don't have a strong objection to the language, but we can't enforce this or compliance test for this
... we can add text but hard to enforce.

MattS: I am talking about intent rather than testing
... I think it's useful to capture the intent
... if the group as a whole feels it's not useful, that's fine, but I think that the spec today doesn't capture the behavior of the card networks today

zkoch: When we wrote this it was under the expectation that whoever was returning the information would return all the info necessary to complete the transaction
... I'm ok to add text knowing that we can't enforce it

see also editorial suggestion in => https://github.com/w3c/webpayments-methods-card/issues/26#issuecomment-290087157

zkoch: I will look at issue 26 and look at appropriate langauge.

Payment Handler API

MattS: I've also made some editorial comments ... would like to see in CR

zkoch: We will also fix those

Things we plan to mark as issues in the spec


<zkoch> ::jazz hands::

(No comments)

IJ: My expectation is FPWD before CR
... which allows reference to FPWD
... from PR API



<zkoch> 2-6!

<zkoch> (more like 6)

<zkoch> Let’s say 4-6

IJ: Any process questions?

Next meeting

13 April

Summary of Action Items

[NEW] ACTION: Zkoch to triage the PMI list of issues and send to the WG [recorded in http://www.w3.org/2017/04/06-wpwg-minutes.html#action01]

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/04/06 15:16:18 $