Web Payments Working Group Teleconference

Payment Method Manifest

IJ: Max took an action to work with Zach to put together a plan for advancing this specification.
... any progress?

zkoch: Max and I will speak this week
... let's return to this in a week

Alan: Regarding payment method manifest file, we support the structure of the file.

Payment Method Identifiers

AdrianHB: Haven't made progress on my action item

Ian: Here is draft text for initial consideration.

• Syntax: " When URLs are used for payment method identifiers they MUST be absolute URLs including only the schema, authority, and path parts."
• Fetching: "Publishers of payment method manifests must make them available in a secure manner. This may involve, for example, identifying them with HTTPS URLs and user agents fetching them using secure protocols.
• Matching: When matching, user agents must ignore any URLs that include query string parameters or fragment identifiers.

<zkoch> right, these seem fine to me

<adamR> Adrian, for your updates, you may want to look at secure contexts (and section 3.3 in particular) and citing that from the spec.

HTTP Link Headers

Alan:From Samsung: Ok to use HTTP Link headers to get from payment method identifier to payment method manifest file

PROPOSE: Close issue 19 with solution of HTTP Link headers

<AdrianHB> +1

<adamR> \o/

<adamR> +1

<scribe> ACTION: Ian to close issue 19 with solution of HTTP Link Header [recorded in http://www.w3.org/2017/02/02-wpwg-minutes.html#action01]

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

https://w3c.github.io/webpayments-method-identifiers/

IJ: What is the right home for mention of HTTP Link headers?

a) PMI spec

b) Payment method manifest spec

<zkoch> probably b

+1 to b

<adamR> Me too: b

<AdrianHB> +1 to b

<zkoch> such consensus. amaze.

<scribe> ACTION: Zkoch to include mention of HTTP Linkers for addressing payment manifest files (in that spec) [recorded in http://www.w3.org/2017/02/02-wpwg-minutes.html#action02]

<trackbot> Created ACTION-49 - Include mention of http linkers for addressing payment manifest files (in that spec) [on Zach Koch - due 2017-02-09].

<Zakim> AdrianHB, you wanted to clarify final resolution

adrianhb: We are saying that in the payment method manifest spec, we will define a mechanism for discovering the manifest file.

<zkoch> that is my understanding

adrianhb: the algorithm will involve doing a HEAD given the PMI, and there will be a rel value pointing to the manifest.

IJ: I assume that once we define the rel value we will register it with IANA

<adamR> +1 to not defining

IJ: We also need to change this in PMI spec:

"When the party responsible for a payment method wishes to publish machine-readable information associated with the payment method, it does so with a URL. "

<zkoch> Yes. I think we should just reference the other spec

IJ: I think PMI sets an expectation about how the method lives in the ecosystem, and we'll define the mechanism separately

<zkoch> Sounds like Adrian is volunteering to submit a PR with that phrase

AdrianHB: So PMI says "The PMI can be used to discover machine readable information, which is defined elsewhere."

<scribe> ACTION: AdrianHB to do a pull request to tweak intro to section 3 of PMI spec to clarify how PMI is used [recorded in http://www.w3.org/2017/02/02-wpwg-minutes.html#action03]

<trackbot> Created ACTION-50 - Do a pull request to tweak intro to section 3 of pmi spec to clarify how pmi is used [on Adrian Hope-Bailie - due 2017-02-09].

Test suite check-in

Shane: No update to report

Ian: I will contact Mike, Shane, Roy, and Stan this week to find out how to make progress.

Payment App update

adrianhb: There's been a lot discussion in the payment app task force (including via GitHub)

<zkoch> I’ve been watching the threads -> http://i.imgur.com/5s4kkZ1.gif

adrianhb: some of the topics relate to long ago decisions
... one includes where filtering happens: in the browser or payment app

[Adrian summarizes filtering discussion]

<adamR> Context on this topic: https://github.com/w3c/webpayments-payment-apps-api/issues/96

AdrianHB: Some discussion of "configuration-based approach" where the payment app declares to the browser what it can do, and then the browser does the filtering

<adamR> Adam's proposal regarding filtering

See also Rouslan's follow-up filtering proposal.

<Zakim> adamR, you wanted to mention address collection and filtering

AdamR: I want to highlight one piece related to PR API - if we go down the configuration-based approach, we need to determine which fields in the payment request are intended to be used for filters
... my proposal was to move filters into a new "filters" structure
... Rouslan has an alternative proposal (that IMO is more fragile)
... Rouslan's proposal preserves backwards compatibility

rouslan: I think the API is not functionally frozen. But I feel that adding more parameters to the API is cumbersome
... the point of my proposal was to consider "data items that are lists of strings" are considered filters
... I did not intend to say "if a payment app does not match all the filters then show it"....I agree instead with Adam's approach

<Zakim> adamR, you wanted to reply to rouslan

adamR: The major concern I have with deducing that arrays of strings are filters....that prevents other payment methods from using arrays of strings
... so I prefer to mark filters clearly in some way

zkoch: the idea of a separate filter type came up previous....my recollection was that filters were limited to basic cards

IJ: That is no longer true

zkoch: each payment method spec defines filters

IJ: Yes

<AdrianHB> IJ: There are now 2 more PM specs that would use filters

<AdrianHB> ... we have some simple cases where the computation by the browser of the intersection of sets of strings would solve the use case

<AdrianHB> ... we had been taking an approach of the apps doing the work but we couldn't find a solution without privacy implications or network delays

<AdrianHB> ... for example, we proposed the app would provide a lambda to the browser but this proved to have implementation challenges

<AdrianHB> ... we should continue discussion in the TF; we don't yet have consensus there.

<AdrianHB> zkoch: are filters only from those defined in known specs?

<adamR> I can see a payment method of “cryptocurrency” and a filter of “network: [‘bitcoin’,’dogecoin’]”

<AdrianHB> ij: we could define a simple generic mechanism; need to see if browsers will support it.

<AdrianHB> zkoch: the goal is not requiring UA changes for new PMs that have filtering reqs

<AdrianHB> ij: yes, zach

<AdrianHB> zkoch: q for me is how valuable this feature is

<adamR> or “targetcreditcard” and “type: [‘red’,’gold’]”

<AdrianHB> ij: we increase likelihood of rich ecosystem if apps are required to implement less

adamR: We don't want to have to update browsers for each new payment method
... i think that we are likely to have closed payment methods where they may want some filtering
... but not published by W3C

zkoch: I do think that there's a solid argument to be made that we might not support payment methods without client changes

<zkoch> Got it!

<AdrianHB> ij: we're moving the canMakePayment logic from app to browser

adamR: If you want to have a more curated experience in the browser, this does not preclude that. Browsers can still whitelist payment methods

Ian: People who want to get more involved in payment apps discussions should check out the synthesis proposal.

<AdrianHB> IJ: proposal not yet updated based on TF discussion on tues.

<AdrianHB> ... this is a synthesis of some extensive discussion last few weeks

<AdrianHB> ... process is to work through this within TF and come up with proposals to address

Meetings

Next call: 9 Feb

WPWG FTF

- Confirmed IG meeting on 22 March (IG meeting page)

- 22 March improv show

- Thank Zach for enabling us to meet!!

- Dinner on 23 March at local french restaurant

Currently about 25 registered; I expect to hit 35...please register

AdrianHB: On the agenda:

AdrianHB: What are our goals for the call?
... it's easiest perhaps to speak in terms of deliverables and milestones
... so I would like to get to a place where we are confident that PR API is ready for CR, and payment app api is ready for FPWD

IJ: Similarly credit transfer and tokenization to FPWD (headed to Notes)

AdrianHB: What about PMI? (to CR?)
... Regarding payment method manifest, PR API depends on it, so we want that to move forward soon
... I'd like to see payment request API and PMI + Manifest to advance together.

<zkoch> seems reasonable

zkoch: +1 to trying to achieve the above

<zkoch> Really just...achieve

AdrianHB: So editors should come back to us with issues that we need to resolve (either before or during FTF)

adamR: The only thing I would throw in there....we should not freeze payment request API until we are comfortable with the basic shape of the payment app API

IJ: CR means "please implement to learn more....and possibly change the spec"

<zkoch> "No more learn. Just achieve."

<Ian> Let's get shirts!