See also: IRC log
Reminder about registration for FTF meeting -> https://www.w3.org/2002/09/wbs/83744/wpwgftf-201607/
<scribe> scribe: Ian
<CyrilV> +present Cyril Vignet
-> https://github.com/w3c/webpayments/wiki/Agenda-20160616
draft agenda -> https://github.com/w3c/webpayments/wiki/Web-Payments-Working-Group-FTF-Meeting-%28July-2016%29#draft-agenda
https://www.w3.org/2002/09/wbs/83744/wpwgftf-201607/
<nicktr> I note that another member of my team will attend (Conor Hackett)
IJ: thanks Brian for seamless organization!
nicktr: Do we have capacity limit?
BrianS: I checked that today with Ian...it's about 45
<manu> Ian: anyone that wants to invite people - check with me, please.
IJ: Please check with me for invitations as I'm coordinating attendance
CyrilV: I will send someone your way Ian.
Ian: +1
Cyril: I will put you in touch with them
Ian: Thanks!
nicktr: Adrian(s) have been working to triage the issues list notably around payment request API
<Zakim> manu, you wanted to note that we're closing issues w/o having resolutions by the group or noting what the decision was.
Manu: I am noting that we are
starting to close issues without saying why (e.g., resolution,
or how we are addressing)
... other issues were closed by saying "we plan to address the
issue"
... I think those are fairly bad ways to work
<dlongley> +1 to manu
Manu: if the group decides to
address the issue, we expect to see a pull request on a
spec...before closing it.
... my concern is that we are not following a very good process
at this moment.
Nicktr: From a process perspective, I think we should be more explicit about why.
<dlongley> +1 for issues to only be closed when there is a clear resolution that is noted in the issue
+1 to clear statements of rationale and pointers (which I endeavored to provide where I was aware of them)
<manu> +1 to clear statements of rationale and pointers
nicktr: I am hearing an action for chairs and staff contacts to review some issues and document rationale for closing
<dlongley> +1 to getting consensus from the group
<manu> We should also ping the initial person that submitted the issue to see if they understand the rational for why the issue is being closed (they're okay with it)
<manu> (just for the record)
IJ: I think that a minimum is to document rationale; I don't know that I would require official WG consensus as a prerequisite for closure.
issue 215
<manu> https://github.com/w3c/browser-payment-api/issues/215
(Quick review of the issue)
IJ: There are three options on the table:
Leave the spec as is; or
Remove totalAmount from PaymentResponse; or
Leave totalAmount but remove the text that requires that the value be one of the provided totals.
IJ: IJ and AHB support option 3
nicktr: Manu raised a question
about tampering
... that's a concern we also see on other architectures.
zkoch: The tempering problem is
independent of this issue. It's a larger issue to discuss. I
think we should focus the discussion on whether total amount
should be in the response.
... I think we should remove total amount from the
response.
... I think we'd be better off without it.
... and weird wrt authorizations
Manu: I agree in general that the
problems are a bit orthogonal, but the issue comes down to "how
useful is total amount". it's not useful if the merchant can't
trust it.
... in the payment request API we have said that we support
data signing, but not at the top level.
(IJ thinks the payment response overall can be signed)
<Zakim> manu, you wanted to elaborate on the security concerns
Manu: So problem is MITM attack.
<Zakim> Ian, you wanted to ask why the payment response cannot be signed.
IJ: what in payment request API
prevents the payment app from signing the payment
response?
... What in basic card, for instance, prevents signing?
MattS: My understanding of the
spec is that it does not support signatures.
... for interop you would need to specify how signatures
work
BrianS: Isn't there a separate issue about this: should there be a defined way of signing data?
MattS: There is, but right now
the view is payment-method specific approach.
... You could need a "card signed" payment method
rouslan: I think Matt's interpretation is correct - does not support signatures
<dlongley> there are multiple layers here -- any layer you want to be able to trust will need a signature (or some other mechanism)
rouslan: I'm open to pull requests on signing basic card responses
<zkoch> We’ve drifted far from the initial topic...
<Zakim> manu, you wanted to note that we're talking about PaymentResponse and to note that there is misinterpretation going on here.
<manu> https://w3c.github.io/browser-payment-api/#dom-paymentresponse
Manu: I think we are talking
about payment response and "Total" in payment response.
... there is no mechanism for signing a payment response as it
stands
... my understanding right now is that if you want to do
payment method specific signing, it goes in the "Details"...and
anything not in the details is susceptible to attack.
<Laurent> Nothing prevents signing those data too in the details right?
Manu: so Matt is correct - you
can write a payment method to sign the DETAILS
... our concern is tampering with other data that is not in
details
<dlongley> Laurent: Yes, but it goes in detail, merchants should not trust the other data (or should understand its level of trustworthiness)
MattS_: I agree what MattS is saying...you could also hack a payment method to sign the non-details
zkoch: I think we have drifted
far from the issue at hand.
... for the current issue, I suggest we remove payment total
from the response.
... we can raise a separate issue on signing non-details of
payment response
<MattS_> +1
PROPOSED: Remove TOTAL from payment response
<MattS_> +1
<dlongley> +1
<manu> +1
<zkoch> +1
+1
<ShaneM> +1
<Laurent> +1
<maheshk> +1
<dezell> +1
<marta> I absolutely agree with ian +1
<ShaneM> I also want to talk about signing paymentResponse though (in a separate issue)
SO RESOLVED: to remove Total
Manu: Are we removing the Total
because it cannot be trusted, then the same goes for other
parts of the payment response.
... I would have supported keeping it in there if we were able
to sign the entirety of the response.
zkoch: My desire to remove it has
existed long before the signatures. I am not sure it's entirely
relevant for a lot of situations (e.g., hotel authorizations
where the amount of the registration is different from what is
ultimately charted...or in credit card payments)...so I think
the field itself is not valuable
... I think we can remove it without thinking about the digital
signature problem.
Manu: Ok
<Zakim> manu, you wanted to note that this is why the community group specs were structured the way they were. and to PROPOSE remove everything else because it can't be trusted :P and to
Manu: sounds reasonable to me to remove for that reason
nicktr: So believe this means it's incumbent on the merchant to validate data
Should it be possible to provide amounts in more than one currency #3
https://github.com/w3c/browser-payment-api/issues/3
<Zakim> zkoch, you wanted to start
zkoch: To check - this is the question about multiple currency in request, right?
IJ: That is my understanding.
zkoch: Last week we agreed to support multiple prices per payment, and we proposed not to handle multi-currency
PROPOSED: Do not support multiple currencies per total
zkoch: Reasons include (1) adds a lot of complexity
(2) I view this largely as a dark pattern...I think that oftentimes there are things that are not transparent that can happen
(3) the merchant can do this anyway
<marta> would bitcoin be viewed as a different currency or a different payment method in this case?
(4) does not seem common case for v1
multiple totals (price/currency pairs) per payment instrument
<manu> Ian: After discussions w/ Rouslan and Shopify, I concluded that we don't need to support specifically multiple totals - price/currency pairs per payment instrument.
<manu> Ian: per payment instrument pricing - to answer Marta's question on IRC, this means merchant can say it costs $100 or 3 Satoshi.
https://github.com/w3c/webpayments/wiki/Support-for-multi-price-and-currency
<manu> Ian: One piece of the answer to why it's not necessary is that we solved some use cases per payment method pricing, the second is that Shopify did a nice job of writing up all of the ways that multiple currencies are handled in nature.
<manu> Ian: The conclusion was, payment request supports standard and multi-currency processing approaches... happening on merchant side. We get a lot already both in terms of multi-currency and in terms of multi-pricing, we wanted to leave multi-currency out of v1.
PROPOSED: Leave multi-total per payment method out of v1
<manu> Ian: One of the ways that Rouslan wanted was a totals proposal - price currency pairs, would be a new feature that browsers would implement.
IJ: Rouslan came up with a way to do multi-totals per payment instrument in the future; so we do not box ourselves into a corner
<zkoch> Yes, spec is up to date
MattS: We are closing the use case of a payment method that supports multiple currencies
---> https://github.com/w3c/webpayments/wiki/Support-for-multi-price-and-currency
IJ: We are not preventing the ecosystem from doing currency conversions...just not supporting it explicitly in the API
<dlongley> might be unpleasant user experience if you see the price in currency X in the browser UI ... and then pay with something else entirely in the payment app
<ShaneM> "It is not clear to me that we have any control over anything through the api." My new favorite phrase.
NickTR: Yes, so this is like previous case of needing to check
<Zakim> manu, you wanted to request that we design it anyway and make sure we don't paint ourselves into a corner. and to -1 that approach requested currency and response currency should
Manu: We are doing handwaving on
how this works in the future. One way affects the API deeply,
the other doesn't.
... I don't understand the case that Ian sketched
<Zakim> rouslan, you wanted to clarify v2 totals
IJ: To say a bit more about Rouslan's proposal - was to provide a list of totals rather than a single total
<zkoch> I think the better method is to rely on feature detection
Rouslan: Yes, so totals would be optional (not required) and the two would be mutually exclusive. And totals would be a list of totals.
<adrianba> I think there are multiple ways to support this in future
IJ: So we are not boxing ourselves into a corner in terms of existing implementations
<adrianba> we could allow total to be a sequence
<adrianba> and we can feature detect the difference
Manu: That was not my concern. My concern is that we are creating a hack field. Could avoid it if we were to just make it a sequence not.
<adrianba> we will always have to feature detect new additions
Manu: Easy way is to make it a sequence today
<Zakim> manu, you wanted to note that this is how nasty cruft builds up in APIs. and to provide an alternate
So would the spec say "Sequence but only one used today"?
<zkoch> Well, what Adrian is saying is that we can make it a sequence later and then it’s easy to feature detect for V2
<ShaneM> +1 to making it a sequence now. and yes, Ian
<manu> Ian, yes, it would.
<adrianba> there are already sequences in the API that cause developer confusion - i'd prefer not to add more that we won't even be supporting
Rouslan: I think putting in v1 a list that is required to have one element is more confusing than having 2 fields that are mutually exclusive.
<manu> I agree that it's more complex... but we either eat the complexity up front, or later down the road.
<manu> Ian: It sounds like we could make it a sequence w/o a big issue?
adrianba: We spent some time at
MS thinking about how we might want to add this in the future.
We came up with a number of different options. One is the
proposal that's been discussed - allow the amount to be a
sequence of totals with different currencies.
... developers will need to do feature detection against the
API to see whether they are running in a browser that supports
the newer version
... implementations role out new features more granularly than
specs, so it's a good practice to feature detect.
... there are a few ways we might support detection for
sequence.
... we feel comfortable that we can add sequence later
... there are other issues around support for multiple currency
that are more challenging.
... so I support punting multiple currency to after v1.
... some changes we've made regarding sequences, I think we
have seen some confusion about why we have sequences...so I
would prefer not to add sequences now
<manu> I'm fine w/ punting as long as the group agrees to the rationale to punt and understands what we're paying down the road for punting.
<zkoch> Yes
IJ: I am hearing that having a single name that can be reused would not complicate future development (which was Manu's concern about confusion).
<manu> So, we're agreeing to punt because we think the complexity added down the road isn't going to be a burden for developers.
<manu> I personally disagree with that, but defer to the group (and clearly can't make the implementers implement something they don't want to)
<manu> That sounds close to: "It's too complex and we'd probably never do it?"
IJ: I hear that there are multiple reasons for not doing it now (e.g., can be done via payment apps) and that fortunately we will not prevent future implementations from evolving to handle lists if we want to go there.
MattS: I know there's not much
time left, but I have a question for the group.
... we seem to be punting a lot down the road
... I am uncomfortable with the amount we are punting
... we are trying to create an open API but we only have one
example of a payment method spec.
<marta> +1
<manu> Ian: No particular view on punting - there are a lot of factors that play into decision on where to draw the line.
<manu> Ian: I've been wanting to have more payment method specs to road test the API - been talking w/ Alipay folks about payment apps... there is a proposal to do a Bitcoin one.
<Zakim> Ian, you wanted to support additional payment method specs
<manu> Ian: I know Adrian had already talked about Ripple payment method spec.
<manu> Ian: That may lead us to general conclusions about payment request API.
<manu> Ian: We have to tie up the payment request API and turn our attention to payment methods and payment apps - as part of road testing API.
<manu> Ian: This is more about prioritization than punting.
<dlongley> i also feel concerned that we may be trying to rush a little bit too much so we have "something" vs. making sure all the things we want to support really work well with the API in general
Rouslan: Agree with Ian; need to design in waves; get basic thing in hands of developers and then get data based on experience. I do not think we are punting too much.
Manu: Thanks, Matt for the
question. We are punting on a lot, and I agree we should do so
and iterate rapidly.
... the group has only so much bandwidth.
... but for some things we are punting, I don't know that the
group is clear on the reason we are punting...e.g., "that's a
hard problem and we don't want to think about it now because we
have other pressing issues."
<dlongley> +1 for avoiding designing into corners, don't have to do full designs and implementations but we should spend time thinking about things we want to do in v2 ... making sure we at least think we can do them.
<Zakim> zkoch, you wanted to add if time
<Zakim> manu, you wanted to say yes-ish
zkoch: I agree with most of
what's been said. Product design is tough and hard to draw the
line on occasion.
... I think getting something out there to test is the best
approach right now
<manu> +1 to zkoch
zkoch: if we can get out there
and demonstrate value, it will be easier to solve issues with
momentum
... I do not anticipate all the different payment systems out
there to write formal specs that the WG publishes; I expect
more common will be developer documentation
... I am also excited about the current work on the payment app
spec...we support it at Google...need to cover other regions of
the world (e.g., where cards not widely supported)
... so I feel good with where we are at.
... also, Adrian B has been very conscious about designing such
that we can add features in the future (and not box ourselves
in) and feature detect them
MattS: I feel "a little" more comfortable. But I'd like to make a proposal ... I am concerned that we are not capturing adequately the items we are punting.
<rouslan> +1 backlog
MattS: we need a clear backlog
<manu> +1 to keep track of punted items / backlog
<dlongley> +1
<ShaneM> +1 sure - how about a v2 tag?
<adrianba> I think that's what the "Priority: Postponed" topic on the agenda was supposed to cover
IJ: AHB is using GitHub tags to mark things as postponed.
<manu> Ian: I know AdrianHB is using Github tags as postponed
<manu> Ian: The question is whether that is being done rigorously - Matt, you and I had discussed this issue previously - clearer vocabulary of postponed items - in theory we're trying to do that - good to keep chairs and team contact honest on whether or not we're doing well.
MattS: I have seen some things closed as not being in V1
IJ: Yes, that seems to be a bug
MattS: More formality would make me more comfortable.
PROPOSED: DO not add further
support for multiple totals per payment instrument
... DO not add further support for multiple totals per payment
method
+1
<MattS_> +1, defer to V2
<manu> -0.5 - I'm concerned that we have not considered the negative rammifications of this decision enough.
<zkoch> +1
<adrianba> +1
<BrianS> +1
<dezell> +-0
Manu: I am not standing in the way of a decision
SO RESOLVED: DO not add further support for multiple totals per payment method
23 Jun
nicktr: We will take up PMI grouping/subclassing proposal at next week's call