See also: IRC log
Expressions of support from Google, Ripple, Worldpay, Mozilla, Klarna, Shopify, Digital Bazaar, Canton Consulting, and NACS
No Formal Objections
Proposed change to shortname based on feedback: "payment-handler"
Two new issues raised; propose we add flags to the FPWD.
Any objections to changing the shortname to payment-handler?
(We would update the repo accordingly)
Ian: We will change the short name!
<AdrianHB> +1 to name change
IJ: Propose we add 2 new issue flags
https://github.com/w3c/webpayments-payment-handler/issues/151
https://github.com/w3c/webpayments-payment-handler/issues/153
IJ: IS there a decision to go to FPWD?
RESOLUTION: Advance Payment Handler API to FPWD
<scribe> ACTION: Ian to close the CfC thread with a decision on behalf of the editors [recorded in http://www.w3.org/2017/05/11-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).
<scribe> ACTION: Ian to work with editors to send a transition request to the director for FPWD [recorded in http://www.w3.org/2017/05/11-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).
AdrianBA: The editors met
yesterday and went through the pending pull requests
... we merged a number of them
... a few questions posed on one or two of them where we
thought we needed to get answers before moving forward
... there are comments in PRs for those
... a few need tweaking; probably today
... there are still a few issues in the CR milestones issue
list that need to be resolved
... our assessment is that there is forward progress on
those
... when I met with Marcos last we discussed the timeline
... we thought we needed 2-3 more weeks to CfC
... so we think we are 6-7 weeks from the CR publication (as of
last week)
AdrianHB: Anything needed here?
<AdrianHB> https://github.com/w3c/browser-payment-api/pull/492
IJ: Did you have a chance to discuss Basic Card status?
Adrianba: Not yet
[AdrianBA reviews background of pull request 492]
AdrianBA: I think the feedback on the PR falls into two categories:
1) The need to declare "an extension point" here at all
scribe: thanks AdrianHB for the
explanation. I think my comment still stands, but I might amend
it to say
... I think it may not be necessary for the browser to
implement filtering logic...it depends on which payment apps
are integrated
... one option is for payment apps to do the matching
2) Second category of comments is about implementation of the extension point - how it appears in the mark-up/spec
scribe: and there was a sense that that was an unusual way to describe it.
<AdrianHB> ian: we reached a dead end on finding a way for payment apps to apply filters because of privacy
<AdrianHB> ... we then suggested that the payment app could provide lambda but there were technical issues with that
<AdrianHB> ... vendors then suggested doing in browser so we proposed a basic string based matching algo
<AdrianHB> ... when a generic algo was proposed this was pushed back by the browser vendors
<AdrianHB> ... current PR is result of that
<AdrianHB> ... agreement was for payment handler to define how apps inidicate their capapbilities
adrianba: I feel like the current
proposal is to be silent.
... The algorithm ought to explain the process it goes
through
... if we are talking about filtering, we ought to have a
description
... and where it happens
<AdrianHB> ian: don;t think text is silent, It says matching takes into account filters
<AdrianHB> ... haven't defined the algorithm because implementors have not liked that
<AdrianHB> ... do I hear you say that that would be preferrable?
<AdrianHB> ... rousal and I wrote out the algo but got no traction
AdrianHB: I think to get to cr we should consider adding matching algo or getting rid of matching
(IJ: I feel matching is essential for adding payment apps)
<adrianba> I think this is a primarily spec lawyering problem not a technical issue
<Zakim> AdrianHB, you wanted to suggest two possible routes forward
AdrianHB: I don't have strong feelings (with my chair hat off)
rouslan_: I don't understand the logic for saying we can't use an extension point here
AdrianHB: If you define it in the payment method specs, you create work for browser vendors for every payment method spec
Here is rouslan's original proposal => https://github.com/w3c/webpayments-payment-handler/issues/96#issuecomment-276423629
rouslan_: I think this will be a
long discussion again (like last time)
... to summarize my opinion, I would say that from an
engineering perspective it's fine to add a parameter where we
have only filters
adrianba: It seems strange to me that we would say "we do not want payment apps to be responsible for the filtering because of some privacy or other concerns"
(MAY I CLARIFY?)
scribe: and push to payment
method spec
... I think this is a spec issue not a practical implementation
issue
... what should be in PR API v other spec
... where we delegate to other specs, how specific we should be
about that delegation
... even if you decide that it's ok to delegate the
modifications to matching to the payment method specs, then I
still think we can be more specific about what is being
delegated
<AdrianHB> ian: let me clarify. PM specs would not define new matching algos but would define the names of the filters.
<AdrianHB> ... they wouldn't define how the matching takes place just the data
<AdrianHB> adrianba: that's not how the PR reads
<AdrianHB> ian: then that's a bug in the PR
<AdrianHB> ... we don't want elaborate algos. Basic string set matching seems to provide all the functions needed by the existing payment methods
IJ: The goal was just to let payment method specs provide static data (e.g., string sets)
AdrianHB: Part of the reason we have this complexity is that filters are mashed in with other data that might not be for filtering
(IJ thinks that's an orthogonal issue)
rouslan_: I think a compromise could be the following:
a) Leave matching logic in PR API as is. Add a Note that the information that is necessary from a payment method spec is the list of parameters that are filters.
scribe: so in Basic Card we could
state clearly which fields are filters
... that will enable us to not disturb deployments
... the logic in the browser, when adding new short string
payment method identifiers would be not just to add the
identifier of the new payment method, but also add a list of
params that should be treated as filters
AdrianHB: +1
adrianba: Sorry for jumping in the middle of things discussed at length during my absence. :)
<AdrianHB> AdrianHB: Not agreeing with rouslan's proposal, but I do understand it :)
adrianba: To Ian's point...he's
imagining that this will work on static data. The current pull
request does not match what has been discussed today. That's
the root of the issue with this pull request
... on rouslan's description, I think that's along the lines of
what I had in mind.
... something where we say that "this part of the matching is
more specific when it's basic card"...rather than having an
open-ended thing
... my impression from marcos is that one issue he has with the
PR is the open-ended nature of it
... we would typically define an anchor where there is more
processing at a point
... often what you want to do is say between steps 7 and 8 do
these additional things
... the problem in general with that is that when the spec you
are linking to changes and they renumber steps, it no longer
makes sense
... broken links are a spec problem
<Zakim> AdrianHB, you wanted to make a counter proposal to Rouslan
AdrianHB: I have a counter
proposal to Rouslan's....
... if your primary concern is around existing ecosystem,
perhaps a solution is to deprecate the data member and
introduce two new members
... method-data (replacing data) and method-filters
... which would be a set of filters
rouslan_: -1 to deprecating
"data"; seems like overkill
... I think we can accomplish what we want with the existing
API
<adrianba> +1 - this is a spec issue
<AdrianHB> ian: we have two other payment method specs in dev both of which use filters
<AdrianHB> ... we should not say all we know about is basic card
<AdrianHB> ... I like Rouslan's idea, it seems helpful
<AdrianHB> AdrianHB: How do vendors implement Rouslan's idea? It requires them to do explicit implementation of each payment method spec
<AdrianHB> .ian: Where in the merchant provided data the filters are described is muddying the waters
<AdrianHB> ... at this point in the algorithm the browser has the data and its underspecified what they do with it
<AdrianHB> ... this helps us get security feedback too
AdrianHB: I have two concerns
that we seem to be glossing over
... when we say what which fields are filters, browsers needs
to pick out of data those fields and that's an implementation
burden
... if browsers say "ok" that's fine, but that's an
implementation burden and makes the short string conversation
harder.
(IJ thinks it would be easier that way than it is under the current underspecifiation)
AdrianHB: Having filters separate from data reduces the implementation burden; browser vendors no longer have to modify code to determine what's a filter
adrianba: I think that at the
basic level, my proposal around how we might make this be an
extension point as written in the PR, that
... instead, we say there's a precise matching algorithm (what
is in the spec) that should be used..a.nd in practice what
happens is that when filtering is applied, it may remove things
further from the list.
... i'm saying that we should say that "this is the algo and in
the absence of filtering, this is what happening, and for
payment methods with filters, you will potentially reduce the
set further"
IJ: I'm ok
adrianba: The second part is that
we are sort of glossing over some things as AdrianHB said
... I don't think we can specify an open-ended filtering
mechanism that is going to necessarily going to be payment
method specific that doesn't require either browser to add
something in order to support those payment methods OR to
actually have the payment app be part of filtering
... because basic card is integrated into the browser, we don't
see the distinction between those things
... we can kid ourselves that the browser is doing the
filtering, but you could also say it's the payment apps
<AdrianHB> ian: I imagined that each time a browser added support for a payment method they'd do so thoughtfully. If there is a conscious decision to provide support for every short name then it should be as easy as possible.
<AdrianHB> .. I hear 2 axis to this @@@
<AdrianHB> ... when vendors choose to add support it could be just adding the short-string to an enum or also adding the filters too
<AdrianHB> ... I see the specificity as reducing implementation burden
IJ: My axes that I hear are (1)
reusable filtering algo (2) automatic identification of filter
fields
... those are separable
AdrianHB: I propose to close the
PR and add an issue; and ask the editors to add text (e.g.,
AdrianBA's text) they are comfortable with
... namely filtering against payment methods happen, then there
may be payment method specific filters may reduce the set
further
... I think the lambda option is elegant if we can find a way
to make it work; I think we've not explored deeply enough.
(UGH)
<Zakim> AdrianHB, you wanted to propose we look deeper at the idea of the lambda
<Zakim> adrianba, you wanted to talk about adding support for short strings and the decisions there and how it might impact filtering
adrianba: To Ian, I think that
when Zach is talking about the burden of adding support for a
new short string, that's more about avoiding arbitrary short
strings
... that's very different from there being an implication that
we have to make other coding changes
... so I think Zach's comment is just about the short
strings
Next meeting is in November
(M/T of TPAC)
IJ: I wanted to get more definitive info on whether or not to have a FTF meeting in July or Aug
AdrianHB: Please all give that some thought and we can return to this next week
18 May