See also: IRC log
<Ian> => https://github.com/w3c/webpayments/wiki/Agenda-20170316 agenda
<Ian> present_ AdrianHB
<Ian> See announcement => https://lists.w3.org/Archives/Public/public-payments-wg/2017Mar/0054.html
<AdrianHB> +1
<Ian> nicktr: Thanks from the Chairs to the PAG!
<Ian> [IJ recaps action leading to incorporation of edits]
<AdrianHB> +1
<Ian> AdamR: I thought in discussion we said we could call out an extension point.
<AdrianHB> ian: mostly an ommission, not familiar with that pattern
<nicktr> scribenick: Ian - I think it's just an omission
<Ian> AdamR: I think for example service workers has an example of this
<AdrianHB> ian: if that is the intent then that's fine. Any comment from editors?
<Ian> IJ: Seems ok to me if that is our intent and there's a good way to do this
<Ian> zkoch: Yes
<AdrianHB> note that this was the content of the resolution from last week
<Ian> nicktr: I am hearing we need an editorial amendment
<Ian> Ian: I can do the amendment but would like one xample
<Ian> ACTION: AdrianHB to add an explicit mention of extension point to text on matching in show() and canMakePayment() [recorded in http://www.w3.org/2017/03/16-wpwg-minutes.html#action01]
<trackbot> Created ACTION-54 - Add an explicit mention of extension point to text on matching in show() and canmakepayment() [on Adrian Hope-Bailie - due 2017-03-23].
<zkoch> brb, 2 min
<nicktr> notes Issue 446 pertains: https://github.com/w3c/browser-payment-api/issues/446
<Ian> " For example, it might include details of products or breakdown of tax and shipping. It is optional to provide this information. "
<lte_> lte
<Ian> IJ: Should it say "Should not include details" instead?
<Ian> AdamR: I felt compelled to repeat that people who use the API will not be reading the spec.
<Ian> ..so if we think this is privacy protection, we are fooling ourselves.
<Ian> Laura: In the scenario you are discussing, sharing line items, when you talk about sharing that data is it the merchant who makes the decision they want to use the capability, or an automatic assumption that it will be passed (to a third-party app)?
<nicktr> ian: this is moot until third-party payment apps are available
<Ian> Laura: This is merchant data and should not be sent to the payment app, or decided by the merchant whether to do so
<Ian> Trent (Walmart): +1
<AdrianHB> Note: There are two sets of data. The line items and the user data. We must discuss them independantly.
<Ian> zkoch: I don't think we need to change the spec. Just leave guidance in PR API.
<Ian> ...if you really want information, can require it in payment method specific data
<AdrianHB> +1 to zkoch
<AdrianHB> Are we talking about just line items or user data too?
<Ian> PROPOSED: Payment app spec does not include displayItems in payment app request data
<AdrianHB> +1
<adamR> +1
<rouslan> +1
<mweksler> +1
<Ian> Nick: Would this close 446?
<Ian> (And close payment apps issue #91)
<zkoch> https://github.com/w3c/browser-payment-api/issues/446
<Ian> https://github.com/w3c/browser-payment-api/issues/446
<nicktr> https://github.com/w3c/webpayments-payment-apps-api/issues/91#issuecomment-283111711
<Ian> AdrianHB: I agree that we can close 446
RESOLUTION: Payment app spec does not include displayItems in payment app request data
<Ian> (Actions to be to close 446 and 91)
<nicktr> https://lists.w3.org/Archives/Public/public-payments-wg/2017Mar/0032.html
<Ian> Laura: Merchant customer data is still what we would consider merchant's choice.
<Ian> ..I understand the value of the use case from a payment app perspective
<Ian> adamR: As I have been thinking about this over the past week...the payment app will necessarily have a longstanding relationship with the purchasing party...when app is set up
<Ian> ..the collection of this information would probably have been provided at that time (especially around payment methods)
<Ian> ...seems like this feature is "slightly nice to have" but probably redundant
<AdrianHB> The custodian of the data for the user is the browser, not the merchant. The data is being cached by browsers (in the same way it is for form auto-complete).
<Ian> ...I think this does not add a lot of value and creates privacy concerns and would not be inclined to do it.
<Ian> nicktr: In Frank's message he talks about display items...
<Ian> Ian: No longer relevant here
<Zakim> rouslan, you wanted to talk about initially collecting info
<Ian> rouslan: AdamR Mentioned that payment apps are likely to collect this information at other times....but one interesting use case to not forget is on the fly registration of payment apps, which will help bootstrap the ecosystem
<Ian> ...if, e.g., Walmart requests payment via payment request API and, say, accepts PayPal, it would be great to bootstrap the user's account setup
<Ian> mweksler: Shipping address would help streamline process
<Ian> ...I think we have some opportunities in sharing data to improve the user experience
<Zakim> AdrianHB, you wanted to talk to up front registration data
<Ian> ...all the data we are talking about is sensitive, so this is not more of a privacy issue than other things we are doing
<Ian> adrianHB: +1 to Michel. If the bar we set for adding things to the API is that there's a use case, then that bar has been met here.
<Ian> ...on a per transaction basis, knowing where goods are shipped is an important part of the Klarna use case, and that business case is becoming more common all over the world (dynamic credit)
<Ian> ...I think we can get user permission to have access to user data straightforwardly.
<Ian> ...regarding privacy, I think that this does not break privacy rules.
<Ian> ...I'm failing to understand what the objection is to this; seems straightforward to me
<Molly> oops!
<Ian> ...Frank has made the case that this should be in version 1
<Molly> accident
<Ian> adamR: For the use case Rouslan is describing (on the fly registration). If I already have a PayPal (example) account, they already have my address. If they don't, then there's a lot of other information they would need for me to set up my account.
<Ian> ...when you talk about the level of involvement in account setup, we are not decreasing the friction very much. So for Rouslan's use case, I see the improvement as only very slight
<Ian> ...in response to AHB's comments, I have some concerns about the specific use case that AHB mentioned. If payment providers are making go/no-go decisions, that can be trivially games unless verifiable
<AdrianHB> The use case is for per transaction information. I will give you credit for this transaction because I know the physical address of where the goods are being shipped.
<Ian> AdamR: For example, I could make tweaks to my browser to present one piece of information to merchant and another to payment app provider to game
<AdrianHB> Verification of the data by the provider is a separate issue to making it more efficient for them to collect it.
<Ian> zkoch: I can certainly see marginal utility to giving this data to payment apps ... e.g., I moved to a new house ... easy updates could be interesting
<Ian> ...the way that browsers structure consent models is somewhat complex
<Ian> ...I see this as a challenging addition, and challenging to ask for in Chrome
<Ian> ...so while I agree with you on utility, I hesitate given the real complexity
<Ian> ...I don't see this as making CR for payment request
<Ian> ...suggest we continue to work this out in payment app task force
<adamR> +1 to zkoch’s point about the complexity of reasonably asking users for permission here.
<AdrianHB> This would not impact the PR API spec at all
<Ian> zkoch: It would be difficult for users to reason about and for us to present.
<Ian> nicktr: I am hearing two use cases (1) dynamic enrollment (2) real-time credit
<Ian> ...I am also hearing issues - complexity, privacy concerns
<AdrianHB> Propose that we agree that there is a use case here so we take that discussion off the table? Then we can focus on the viability of adding this to the spec(s) in terms of implementability.
<zkoch> molly is busy slapping RRSagent
<mweksler> haha
<Ian> Molly: Would like to discuss during FTF meeting
<Ian> AdrianHB: It would be useful if we agree there's a use case here and look at implementability
<nicktr> Use cases from Frank's mail:
<nicktr> https://www.irccloud.com/pastebin/U4aiGpVp/
<Ian> AdrianHB: In developing economies, this is a particularly important use cases
<Ian> ...for doing business
<Ian> ..payments are evaluated in real time ... in some cases a mobile number may be used to assess whether to extend a bit of credit
<Ian> https://www.w3.org/2017/Talks/ij_apps_201703/ij-apps-wpwg-201703.pdf
<lte_> i was in the queue as well a while back
<zkoch> sg
<lte_> i did
<Ian> Ian: Zach, if you can find out more about permissions for next week, that would be helpful
<Ian> Trent: the way that data is classified, it has an implication on processing
<Ian> rouslan: This is data that is stored in the autofill data in the browser
<Ian> ...the data is by default going to the merchant if the merchant requests it
<Ian> ...we are talking here about taking data from browser and giving to payment app
<Ian> ..so from our standpoint this is use data stored in the browser
<zkoch> +1 to it always being “user data"
<AdrianHB> +1
<Ian> NickTR: I am hearing that there is interest in use cases, so that we take that now as accepted and move on to the other issues surrounding it
<Ian> https://github.com/w3c/webpayments/wiki/FTF-March2017
<nicktr> https://lists.w3.org/Archives/Public/public-payments-wg/2017Mar/0053.html
<Ian> IJ: Hold off reading payment app spec; still changing
<Ian> NickTR: Reminder also of 22 March IG meeting
<Ian> NickTR: Let us know if you have any comments on the agenda
<Ian> ..there will be a lot of people there (~50)
<Ian> ..some will be new ...
<Ian> ..we will need to balance speed and thoroughness...I ask for your patience
<Ian> ...will need strong queue discipline
<Ian> Ian: Look at payment apps on Monday
<Ian> AdamR: I will endeavor to add detail this week
<Ian> ...I don't think the structure is likely to change
<nicktr> ian: we have a couple of extra tickets for improv - contact Ian if interested
<nicktr> ... we are also looking at whether anyone would like to listen to some blues on 23rd March at Kingston Mines
<lte_> french? what about lou malnatis
<nicktr> ... but they have to organise themselves
<lte> .
<Ian> nicktr: Looking forward to next week's meeitng