See also: IRC log
https://github.com/w3c/webpayments-method-identifiers/pull/21/files
https://github.com/w3c/webpayments-method-identifiers/pull/21/files
PROPOSED: Adopt AHB's pull request for PMI => https://github.com/w3c/webpayments-method-identifiers/pull/21/files
AdrianHB: No longer requires HTTPS ; instead refers to URL spec and secure contexts and use concept that is more general
"potentially trustworthy URL"
AdrianHB: I added info to the matching algorithm to throw out query string/fragments
s/throw out query string/fragments/throw out URL if it contains query string or fragment id
AdamR: Looks good in general. One additional fix is "will be ignored" still there on line 136
AdrianHB: Thanks, I will fix that
IJ: Any other comments on the changes?
<nicktr> +1
<rouslan> +1
+1
<adamR> +1
<pascal_bazin> +1
{No Objections}
RESOLUTION: Adopt pull request 21 for PMI spec with AdamR's fix
https://github.com/w3c/webpayments-method-identifiers/issues
https://github.com/w3c/browser-payment-api/pull/420
IJ: This is a PR for simple browser-based comparison of filters / capabilities
rouslan: The proposal says: when
payment method specific data that has a list of strings, the
browser treats them like potential filter
... when a payment app registers it will specify
capabilities
... the capabilities are payment method specific
... the PR is about how to do matching between merchant filter
and payment app capabilities
... the difference between my proposal and AdamR's proposal on
this is that Adam proposes a specific label for filters.
... I prefer not labeling filters; easier for backwards
compability
(IJ: But labeling filters gives you better forwards-compatibility I think)
rouslan: We could use a shim for
older uses of API to newer uses, but I'd rather avoid
... I've asked AdamR and Domenic to review the proposal
... Domenic has been helping to make the spec more explicit (to
foster interop)
... they have made comments on the thread and I've not
addressed them yet
AdamR: There is one comment that merits discussion here - where we want filters to be separated out from request data or mixed in
<AdrianHB> +1 to have them outside the payment method data
AdamR: while I am sympathetic to
existing implementation, my concern here is that for
yet-to-be-defined payment methods, there may come a time when a
payment method wants to define a list of string, and they could
accidentally be treated as filters
... I prefer the slight hit today of calling out filters today
in favor of an easier future
https://github.com/w3c/webpayments-payment-apps-api/issues/96#issuecomment-276416457
AdamR approach:
const methodData = [{
supportedMethods: ["basic-card"],
filters: {
supportedNetworks: ['visa', 'mastercard'],
supportedTypes: ['credit']
},
data: {
// Any payment-method-specific fields go here.
}
}];
Rouslan approach:
hypothetical.api.register(
"basic-card",
"MyBank's Debit Card",
data: {
supportedNetworks: "visa",
supportedTypes: "debit"
});
====
We could special case the existing names and say "those are treated as filters for backwards compatibility; so avoid them"
rouslan: +1 to that compromise - recommend people use filters, but for basic card the two filters are treated specially
AdamR: I can live with that
Rouslan: I propose to update the pull request and bring back to the group
AdrianHB: This would still mean a change to PR API to add a filters member.
Rouslan: Google implementation will still look for filters in data
IJ: Do we want to treat BC specially?
AdamR: I would hesitate to have
BC remain an exception
... would prefer "filters" as the primary mechanism and
deprecate in the long term having filters in data
<AdrianHB> +1 to AdamR
rouslan: I think what we'll do in chrome is print a console warning when BC is used with data instead of filters. We'll deprecate over time in favor filters
nicktr: Let's also check in with other implementers
<nicktr> ack
rouslan: You mentioned Molly...we should definitely check with MS
<scribe> ACTION: Rouslan to check with Molly about this proposal re: filters [recorded in http://www.w3.org/2017/02/23-wpwg-minutes.html#action01]
<trackbot> Created ACTION-52 - Check with molly about this proposal re: filters [on Rouslan Solomakhin - due 2017-03-02].
<Zakim> Ian, you wanted to ask about basic card spec change
Ian: Do we also need to update BC to reflect the filtering?
(this affects the credit transfer and tokenization specs)
Rouslan: Yes, that's correct.
IJ: Do you want to augment your pull request with changes to BC?
Rouslan: I would need a new one?
AdamR: If you just make changes to your repo and click on the PR button, it will pile the new commitments on top
Rouslan: But it's two repos
... so I need a new pull request
... I propose to wait to hear from MS first, then proceed
nicktr: This has highlighted for
me what we need to get to by FTF meeting - inbound changes to
PR API
... that's going to to be part of the conversation to get to
CR
https://github.com/w3c/webpayments/wiki/FTF-March2017
nicktr: I have started with a detailed agenda...got as far as day 1
https://github.com/w3c/webpayments/wiki/FTF-March2017#proposed-agenda-times-are-local
IJ: I think testing as "separate"
from PR API
... let's ask for clarification
... Can we have more time on payment app
Nick: that will be continued on day 2
IJ: We will have 2 more payment
method specs
... suggest 30 mins each
+30 mins merchant adoption
IJ: Any demo commitments?
Nick: I want to demo Conor's work
IJ: Would love to see Microsoft implementation
Let's review the next draft in a week
Nick: Will there be remote access?
<scribe> ACTION: Ian to set up WebEx for the 2-day meeting [recorded in http://www.w3.org/2017/02/23-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).
<adamR> +1 to having significantly more time on day 2 for Payment Apps.
nicktr: Should we spend the entire morning on payment apps?
AdamR: I think it's
possible
... there are a number of open issues...we are converging on a
few of them but I think some are suffering from lack of input
from broader group
nicktr: Would be prepared to lead that session
AdamR: Yes
https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130
Ian: I updated that yesterday. We are making progress and at a minimum we should share where we've arrived
adrianhB: Regarding the agenda, let's leave time on both days for things that come up in discussion
<adamR> +1 to beer
Max: We made some progress and
updated the draft
... but not yet on GitHub
... hope to have that by FTF meeting
IJ: How much time on FTF agenda for it?
Max: I'd like to finish it soon
for people to review it
... before the meeting
+1 to 30 minutes on payment app manifest to start
<nicktr> notes another 30 minutes for manifest
nicktr: What about breakout sessions?
<AdrianHB> propose we only do breakouts if we are time limited
IJ: Logistically, it's feasible
AdamR: I don't object in principle but I would not want to treat payment apps as a breakout session
+1
<nicktr> +1 to payment apps being in the main group
AdrianHB: I propose that if we don't have enough time for topics, we breakout to optimize
Nick: I want to put the "get to CR" conversation early afternoon on Day 2
+1
IJ: How is testing going?
Stan: I am iterating; adding a
few tests
... my first goal is to build a mock version of the payment
request that I inject in a page, so that I can progress on
running the test suite
... I hope to show you something next week
IJ: Maybe have something to show
at FTF?
... or issues riased
Stan: I won't be at the FTF but could present over WebEx
2 March
Nick: Please send regrets/issues to the chairs
<AdrianHB> Regrets for 2 March
AdrianHB: Regrets for me for next week; but will be at chairs meeting