Web Payments Working Group Teleconference

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

Face to Face - 7 & 8 July - London

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!

Issue Management

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.

PaymentRequest API issues

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

Issue 3

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

Next meeting

23 Jun

nicktr: We will take up PMI grouping/subclassing proposal at next week's call