Web Payments Working Group Teleconference

Agenda

DST

Next week's call one hour earlier for EU's

Payment Request API

(On filtering)

AdrianHB: Other than "where the data is specified" we want to understand whether it's possible to have filters that are not a predefined set of enums.
... can the ecosystem start to use a filter, or are browsers required to roll out filters as they emerge?
... that has impact on the card network list

<AdrianHB> ian: have had a few conversations on this

<AdrianHB> ... want to discuss the filtering in general and the networks list seperately

<AdrianHB> ... there is some value to the list beyond a hard coded list of filters

<AdrianHB> ... we want to allow apps to express capabilities and for browsers to consider these

<AdrianHB> ... part 1: providing capabilities from the payment app is being handled by the TF

<zkoch> O.O

<AdrianHB> ... part 2: proposal is a generic string based filtering that browsers apply to the filters and capapbilities

<AdrianHB> ... in conversation with zkoch he has said he believes the number of methods that will use filtering to be small

<AdrianHB> ... also Google will have work to do to implement any W3C defined methods so adding filters will be part of that

<AdrianHB> ... so it occurred to me that this may be an implementation detail

https://w3c.github.io/browser-payment-api/#show-method

For each paymentMethod in request.[[serializedMethodData]]:

<AdrianHB> ... this means that browsers should indicate if they support filters

"Consult the appropriate payment apps to see if they support any of the payment method identifiers given by the first element of the paymentMethod tuple, passing along the data string given by the second element of the tuple in order to help them determine their support. "

<AdrianHB> ... [reads from PR spec]

<AdrianHB> ... I believe this to be overly constraining. It should just say that filtering happens here.

<AdrianHB> ... AdrianHB suggested we should just make a decision

<adamR> +1 to describing filtering in PR API.

<AdrianHB> ... Concrete proposal is that we change PR spec to say "filters are taken into account"

<AdrianHB> ... This leaves browsers to decide how they interpret "taken into account"

adamR: Is the implication that we won't have a description anywhere of a reusable algorithm

<AdrianHB> ian: yes

<AdrianHB> ... we don't know yet how the apps will specify their capabilities. We could put guidance in the guidelines document.

IJ: Implication is no reusable string matching

AdamR: concern that for infrequently released browsers, this will put a damper on payment method deployment

(IJ notes that we can add "suggested payment method filter syntax" to => https://w3c.github.io/webpayments/proposals/method-practice/)

adamR: I understand we don't yet have filter use cases for custom payment methods, but I think that's short-sited.
... I expect they will arise in the future.
... cutting off at this time, especially something that is extremely likely to work, is short-sited

<MattS> +1

<scribe> chair: AdrianHB

adrianHB: I want to add to AdamR's comment. We are effectively saying that we don't expect this aspect of the API to be interoperable
... the only way I see this panning out if we say "browser implement this however they like"...then other browsers will need to implement generic string matching otherwise they will no longer interoperate

zkoch: A few comments. The first thing is that we discussed this yesterday among the PR API editors/implementers. There was unanimity that given where we are (nearing CR) and with small number of use cases, it was not priority to implement generic filter matching today
... that did not mean "never" it just meant "not yet"
... this is one of a number of issues that we feel are not for V1
... we have 2 implementations in the wild, and the priority is interop between them.
... we can add this in the future.
... just because Chrome is making a choice to implement W3C spec short strings a particular way, does not imply everyone has to do so
... note also that an alternative to an abstract payment method spec is N payment method specs
... also, I don't see an interop risk here.
... suppose firefox implements something generic...that's not an interop problem; we will match on what we identify and effectively drop what we don't recognize

adamR: I want to agree with the third point...I don't see the interop issue (agree with Zach)
... but I have concerns with the first point that we should go based on what is currently implemented

<AdrianHB> ian: my attempt to address was to write this in the payment apps spec. The re-usable matching algo was then a bonus

<Zakim> AdrianHB, you wanted to ask to clarify the browser will behave if it encounters filters it doesn't understand

AdrianHB: Zach can you clarify the last point you made about dropping filters...Suppose I introduce a payment method spec and want to filter based on system (e.g., values are bitcoin, ether, dashcoin)
... proprietary method, so I use payment method manifest....what would Chrome do?

[Payment method identifier is a URL]

zkoch: At the current time we would not do any filtering. If it's a URL, we just pass over the entire blob; no filtering
... I would say, don't make a generic one...make a specific one per system
... I don't see evidence of the real world use cases

IJ: I agree that if we bring an abstraction spec forward, we should be able to provide evidence that there is a common set of data fields

<adamR> +1 to AdrianHB’s point

AdrianHB: I think the ability to filter or not is a material difference between w3c and non-w3c payment method specs

<AdrianHB> ian: there are other differences

<AdrianHB> ... we support features in the manifest for example

mattPi: To be quite frank, we are still indeterminate on the payment app spec. That spec is crisper than it has been, so we are absolutely looking at it and working with our partners
... we are 100% committed to payment request API
... our release cycle is such that we want to minimize change to the PR API spec
... +1 to zkoch's comment that we are not seeing a big demand at this time...we might see the demand grow once PR API takes off

MattS: Would Ian's proposal mean that payment apps cannot do filtering?

<AdrianHB> ian: the goal is an optimal user experience. Only apps that are most likely to work appear in the list

<AdrianHB> ... so some filtering is required before the list is show

<AdrianHB> matts: I had thought we still had canMakePayments() in the app

<AdrianHB> ian: no this is a replacement because of issues with making canMakePayment() work

<AdrianHB> ... keen to hear your opinion on this matts

MattS: Regarding zkoch's point - SEPA needs a country filter...even though it's a specific payment method.
... you don't want one URL per country

http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/

adrianHB: Let's try to document the argument and take to the FTF meeting

adamR: Ian said something a few moments ago that works relatively well - having a specific step in PR API that says "this is where filters and capabilities are matched"
... and make clear that this is an extension point
... and we can talk about it at the payment app spec
... I think that's a reasonable compromise

(Ian is hearing +1 to Ian's notino)

MattS: Yes, seems like a reasonable compromise

<zkoch> def: notino (a tiny notion)

<AdrianHB> [RRSAgent can't find "def" on the attendees list]

<zkoch> sgtm, +1

IJ: I'd be happy to work with Zkoch on a proposal

AdrianHB: So the proposal is to clarify in PR API where payment app capabilities are evaluated
... I am hearing AdamR say that let's call it an extension point

<adamR> Thanks, AdrianHB — that’s a very precise summary.

<scribe> ACTION: Ian to work with zkoch on a change to PR API to ensure payment app capabilities taken into account and details will be handled outside the spec [recorded in http://www.w3.org/2017/03/09-wpwg-minutes.html#action01]

<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs, ijmad).

Addition of Carte Bancaire to list of approved networks

https://www.w3.org/Payments/card-network-ids

Proposed:

We adopt a procedure for validating requests to be added to the list (cf proposal to add Carte Bancaire). Validation will consist of avoiding duplication.

We update the explanation in the network id list to make clear that approval does not imply interoperable implementation in browsers.

We add a statement that merchants may use Payment Request API for a card network that is not yet in the list; the list is only used for further filtering.

<AdrianHB> ian: Nick raised concerns about anti-competitive issues if there are limits to joining

<AdrianHB> ... (missed 2nd point)

<pascal_bazin> "cb" means "carte bancaire"

<AdrianHB> ... one way to mitigate the concern is that this doesn't prevent cards from unlisted networks being used it just gives some UI optimization

<pascal_bazin> "carte bleue" is a brand for specific bank

MattS: It was my expectation that supported network list could be short strings or URLs...has this been debated?
... the problem with this list is that it was put therefore for bootstrapping purposes
... it seems to me that implementing your own supported network string would be same issue

<AdrianHB> ian: At least Google have said they won't implement matching based on arbitrary strings so a distributed filtering system is not feasible

IJ: My understanding is that at least google will only implement known strings, so no need for distributed naming.

zkoch: That's correct, but I had not thought about network values being URLs...we had assumed that the list of card networks would be finite

MattS: There is a similar list to this list...effectively the list of EMV card providers
... it's 100s and 100s long
... there are some issues with that list (e.g., duplication)
... same company appears multiple times
... but it shows me that the list is not small

<zkoch> It would be useful to see and/or review that list :)

<zkoch> If possible

<AdrianHB> ian: short string vs URL is immaterial if the issue is security

IJ: Zach could you look into that?
... could help us avoid registry...but we hear that there are string issues...would URLs be any better?

AdrianHB: I suggest we shelve this until we address filter issue

<MattS> Registered Provider Identifier list https://eftlab.co.uk/index.php/site-map/knowledge-base/212-emv-rid

PROPOSED: Update network identifier list per IJ's proposal in the agenda (modulo editorial changes)

<adamR> +1

<zkoch> +1

<scribe> ACTION: Ian to update the network identifier policy and add CB [recorded in http://www.w3.org/2017/03/09-wpwg-minutes.html#action02]

<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs, ijmad).

RESOLUTION: To adopt network id policy change and carte bancaire

AdrianHB: It's worth noting that there was not resounding consensus there.

MattS: I am concerned about this list growing in size

AdrianHB: I think many of us share this concern
... but I propose we put this aside until we do the filtering issue

Payment app demos

AdrianHB: This is just a request to know which browser implementations we could use to do payment app demos; please share on the list

Testing

Stan: I sent an email last week at the end of the call with state of testing

<zkoch> Note that at first glance at this list, most of these are not CC networks @matts

<spolu> https://github.com/stan-stripe/js-payment-request

<spolu> https://github.com/w3c/web-platform-tests/pull/4768

<spolu> http://i.imgur.com/OeSdfxS.png

stan: What's promising can be seen in that image
... I think we have a framework to test constructor and show() implementation

<zkoch> cool!

stan: how much do we want to test?
... during the test task force call we talked about creating a mock payment method service through the w3c testing framework
... I'm not sure how much we will test payment request v payment apps
... that's my ask for the group - how far do we want to go?

<zkoch> Chrome has a desktop version in development behind a flag. We can see how it performs :)

\o/

<zkoch> Edge also has an implementation on Insider Preview builds

AdrianHB: I know there are sandboxes and simulators...can we try hooking one of those up as a payment method mock?

Stan: I am open to anything....
... nice thing about a mock payment method is you can call show() and drive the behavior of the implementation
... test error handling, etc.
... it has proven pretty useful

AdrianHB: Any thoughts on making this easier?

rouslan: we have a desktop implementation behind a flag; not quite functional yet
... but as soon as it more or less works we'll let you know and you can start to test

https://github.com/w3c/payment-request-info/wiki/ImplementationStatus

<rouslan> chrome://flags/#enable-experimental-web-platform-features and chrome://flags/#web-payments

<zkoch> Download chrome dev, though

<zkoch> Or canary

<spolu> ack

IJ: What do we need to know at the FTF meeting as far as test suites (for the "getting to CR" discussion)

next meeting

- 16 march call (time zone change!)

- 23-24 March FTF meeting

IJ: We are at capacity for the FTF meeting

<zkoch> I suspect there will be mutliation

<zkoch> and literal cutting off at knees

we have a payment app effigy

for that purpose

<zkoch> good, seems safer

<zkoch> see ya