See also: IRC log
<scribe> scribe: manu
nicktr: Happy to take any
suggestions to that agenda
... Day 1 is security review and payment apps spec
... We'll try to pickup new payment methods spec during later
part of day 1
... A number of our european colleagues are excited about the
SEPA payment method spec.
matts: At the moment, we have a draft proposal - Ian has put it into ReSpec. I'm going to commit that to the new repos. The intent is we'll do a few revs of it during the meeting. Will present that at the face-to-face.
The spec is in the new repo: https://github.com/w3c/webpayments-methods-credit-transfer-direct-debit/blob/master/index.html
nicktr: Some feedback from members - they're not enthusiastic because we're not talking about stuff they're interested in... stuff like SEPA. For me, wearing my "engagement of wider group hat", I'm interested in doing that.
Some admin required on that repo to setup branches properly)
icktr: Second day - payment request API and basic cards spec - go into that a bit later today - look at HTTP API in the afternoon. Give ourselves a bit of a buffer at the end of the day.
nicktr: Feedback from anyone?
No comments on agenda - the group is either happy with the layout, or everyone is asleep. Those are the only possible states.
https://github.com/w3c/webpayments/wiki/Support-for-multi-price-and-currency
AdrianHB: AdrianB has also put in a pull request for that proposal.
Rouslan: Our proposal is what
Shopify, Ian, and I have been talking about - not to be
confused w/ AdrianB and Zach's proposal.
... We want to support different line items for payment
methods. Optionally, would provide total for particular payment
method. Debit cards have a different total from credit cards -
then we also were thinking about notifying the website when the
user has expressed their preference to select a certain payment
method.
... At that time, we'd notify the website and the website could
update the line item total - line items at this time would
change - we've also decided in our group discussions to punt on
multi-currency - our reasoning is that from the point of the
website, if you are requesting GBP or Euro, you should be
getting what you're requesting. If an app is not able to
fulfill the request in GBP/Euro, it should reject the
request.
... Internally, ifi the app is dealing w/ bitcoin, the app can
convert to the proper currency. Let's hear AdrianB's proposal
as well.
AdrianHB: What Rouslan is saying is right, if we look at DCC today, it's specific to card payments. I think we shouldn't try to complicate the API with DCC - it's a feature of a payment method, so it's a payment method by implication. If you have a payment method that supports DCC, the payment method will define how that works.
dlongley: +1 to AdrianHB
Manu is in agreement w/ pushing DC off +1 to AdrianHB
adrianba: We had a few goals with this proposal - the first one was that while it is an important use case, we also think the majority case will not have that happen, in particular we want to avoid complicating the APIs in that common case while allowing the more complex case. If you don't care about different amounts for the payment method, you don't need to do anything differently.
https://github.com/w3c/browser-payment-api/pull/211
adrianba: Then we let people
declare up front what the different totals would be for
different payment methods. We've added that to payment details
object. The first parameter lists the supported payment method
and any specific payment method should be something that's
constant through payment request, but you'd want to change
total amount based on shipping amount, so this is an additive
thing onto payment details. Payment methods use different
total.
... It allows you to add on additional MISSED those additional
things would allow you to have things appended - line item that
says "this is a discount" or "this is a surcharge for
debit/credit" and that would be added to display items. We
wanted to avoid having event based on MISSED for the payment
method, it's possible for UI to show ?? payment instead of
having UI to present it. we propose that you display different
totals in details.
ouslan: After reading through adrianba on his pull request - we should forego the event and use declarative methods.
Manu: +1 for using declarative methods.
dlongley: +1 for a declarative approach
AdrianHB: Question for
clarity.
... There is a way for a merchant to add extra display items -
where do those get inserted in the list? Is there a way to
manage ordering of where those fit in?
zkoch: No, total is always specified
AdrianHB: The reason I ask - do
we force user agent to calculate total or is the total always
specified?
... Do we need to specify that amount and response was
specified by merchant?
adrianba: You should expect that total amounts to appropriate one - this seems like a low-cost position for the avoidance of doubt. This is the payment method, this is the corresponding total that was selected, so we can be sure of what the user agreed to.
AdrianHB: I wonder if this is an unnecessary restriction, it assumes that payment methods can't calculate a total on the fly. I've already said DCC is a payment method specific thing, as a merchant I can get a response back that says I want to pay $60 CAD as a result back to the merchant if I say I accept CAD.
nicktr: As a merchant, if I specify an amount then I would be expecting to get that amount back in the response.
dlongley: payment method may even allow negotiation of some sort ... agree that we don't want to lock things down too much
AdrianHB: I don't think there is a need for us to put that in the API spec, I like the idea of having a field in the response - I don't think we need to say that something is going to correspond with the amounts in the request.
dlongley: +1 to AdrianHB
AdrianHB: I don't think we need the browser to enforce business rules.
dlongley: If you can do
declarative, it's better. Rule of Least Power: https://www.w3.org/2001/tag/doc/leastPower.html
... If you can do declarative, it's better. Rule of Least
Power: https://www.w3.org/2001/tag/doc/leastPower.html
AdrianHB: +1 to the PR with a change to remove a normative requirement for response total to be one of the request totals
zkoch: I think I’m fine removing total from the response
dlongley: We should be matching data to data, nothing more (hopefully)
manu: One of the things that has been bothering me lately is that we keep proposing these complex imperative solutions when a simple declarative one would provide more flexibility, would be easier to implement, and will thus hopefully create a better ecosystem for this stuff. +1 to declarative solutions, -1 to imperative solutions (in general).
nicktr: Yes, sounds good.
adrianhb: I think having the total there is fine just don't force it to be one of the request totals
rouslan: Do we have consensus on this? It appears that we do - Ian had a few minor nitpicks. I don't think we have objections, we want to hear from Shopify - one of the groups that were part of the imperative proposal. I think declarative proposal has traction.
adrianHB: In fact, I think having the total in the response is great
nicktr: I think what I'm hearing is let's not ask for consensus, but this PR is moving in the right direction.
adrianba: Ian... matching payment
identifier... plan is to have pricing per payment method
... logic for payment method identifiers change, this will need
to change too - orthogonal issue. I propose that we take the
PR, whether to include total at all - provided total - my
preference would be to take PR and open issue to discuss what
we do about proposal - then it'll be locked down - PMI will be
followed up by Ian.
nicktr: That's a concrete proposal from adrianba - accept the PR and then deal w/ that particular problem.
AdrianHB: +1 to merge and deal with response total via an issue
adrianba: Sounds like PR is in the right direction, minor details to iron out.
zkoch: +1
manu: +0 - haven't reviewed the PR in detail.
rouslan: +1
dlongley: +1
ShaneM: +1
<inserted> nicktr: adrianBA's proposal is accepted - accept PR 211
https://github.com/w3c/browser-payment-api/pull/209
AdrianHB: AdamR, do you want to say something about proposed change?
AdamR: Point I've raised in past coupel of calls - shutting down flow is something we have - but having something that says: We failed and here's the reason is important, but don't have counter proposal to current proposal.
dlongley: +1 to AdamR - same feelings.
AdrianHB: Unless there are any objections, we merge this - adam and dave's nuances - we raise them as new issues.
nicktr: Ok, we're pulling in PR209.
AdrianHB: Everyone seems to be happy w/ this - don't know if people have reviewed this - any objections?
adrianba: If the merchant was
really using shipping option and using shipping address - we
added special case support if you provide a single shipping
option, then that one would be selected by default. Having no
shipping options blocks the request, for example if you have an
address that ... having a single option wouldn't require the
user to select the single option, it allows you to create a
payment request that flows simply through the experience.
... In order to make it possible to preserve a users option, if
they have a different address, shipping, if you want to
preserve that, we added selected field - this is one that's
currently selected.
ShaneM: +1 to remove special magic
adrianba: select the defualt,
included in the pricing for example - simply having that field,
they can be explicit about what's being selected. We're
proposing to remove the special magic from the spec. This way
developers won't be surprised if single option was selected if
they had a seelcted field that and users won't be surprised if
developer makes a mistake, perhaps shipping option is expensive
and you want user to be aware that they're selecting an
expensive
... option, that's the proposal - remove it.
rouslan: +1 remove the magic
dlongley: +1
zkoch: +1
AdrianHB: +1
... What this means is that we've implemented a fair amount of
stuff into the API, there have been quite a few changes to the
FPWD - browser vendors/group - how comfortable are we with
publishing another WD of this spec soon?
... We know that Chrome already has some implementation of this
API in its developer version w/o needing to polyfill - will
that be updated soon? Implementations to follow?
adrianba: I was planning a new WD
by next F2F meeting. I think I was proposing that we do that a
week or so from now.
... show some progress, publish a new version.
nicktr: Makes sense to me, have a wd for next face-toface
Rouslan: There was a question -
what's the status of Chrome - we're constantly updating API on
trunk - in git - it has a new version - hasn't been pushed to
dev channel yet - summer slack w/ people on vacation, probably
- usually dev is once a week - delta once a week - every
version you'll see that we're trying to keep up with latest
changes to API.
... That being said, API is moving fairly quickly - opera and
samsung is helping w/ API version - trying to keep it up to
date, we're slightly behind now, so having another public
working draft would be a good milestone/snapshot. Our goal is
to b e on the bleeding edge.
AdrianHB: i.e. is there an impact on implementers if we are slow to publish WDs
zkoch: We don't need a WD to make progress, we follow as spec evolves, if there is consensus we implement.
adamR: We don't pay a lot of attention to WD/ED - we'll implement whatever the latest thing is. On Web Payments, while I have interest, we haven't allocated resources to implement this yet.
nicktr: Is there a nightly of Edge with Payment Request?
adrianba: We have an experimental implementation - but it's not really externally accessible - relies on a service to do part of the processing. We have internally experimented, API can be turned on w/ a flag - not quite useful yet to public.
AdrianHB: For non-implementers in
the group, there are new folks - as we hit milestones, it's
important to understand where implementations are.
... This is becoming very real, thanks for all the work from
implementers on that.
nicktr: There is another dev that's joining from WorldPay - AdrianHB - keen to join Payment App breakout group.
AdrianHB: Only a few minutes left, let's not dive into anything too detailed. Go and look at F2F agenda - topics missing, flesh out, specific stuff you want to point out in that session. There is a Task Force that is working on a proposal for how payment apps might work in the browser - focused on what happens when payment request is received by a browser - call it a sibling spec to payment request API.
zkoch: Do you guys have a deadline for draft of payment app spec?
AdrianHB: It's being developed in
proposals folder in core WG repo. Call is next week after this
call. Our goal is to have something ready by face-to-face that
we can adopt as ED at face-to-face.
... We want to adopt at end of day Payment Apps spec at
face-to-face
nicktr: We want to have testing strategy on face-to-face agenda, I will do that.
zkoch: The final issue that we want to talk about is iframes and support for those - formal email to WebAppSec to ask what they recommend wrt. iframes. All of them have limitations, point to them see if they have a response. Issue #2 - we can get feedback from there.
https://github.com/w3c/browser-payment-api/issues/2
AdrianHB: +1 to resolve
nicktr: Yes, divisive issue in security community - we'll have to take position and see where we go.
AdrianHB: We want to have a proposal and give it to WebAppSec. We'll see what they have to say.
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/If you can do declarative/dlongley: If you can do declarative/ Succeeded: i/Topic: PR 209/nicktr: adrianBA's proposal is accepted - accept PR 211 Succeeded: s/Topic: Multiple Pricing Options and Currencies in Payment Request/Topic: PR 211 - Multiple Pricing Options and Currencies in Payment Request/ Found Scribe: manu Inferring ScribeNick: manu Present: AdrianHB Dongwoo dlongley dlehn manu shaneM AdamR NickTR Rouslan MattS dezell zkoch adrianBa Kepeng Roy Agenda: https://github.com/w3c/webpayments/wiki/Agenda-20160609 Got date from IRC log name: 09 Jun 2016 Guessing minutes URL: http://www.w3.org/2016/06/09-wpwg-minutes.html People with action items:[End of scribe.perl diagnostic output]