16:02:15 <RRSAgent> RRSAgent has joined #wpwg
16:02:15 <RRSAgent> logging to http://www.w3.org/2016/05/12-wpwg-irc
16:02:17 <trackbot> RRSAgent, make logs public
16:02:18 <Zakim> Zakim has joined #wpwg
16:02:19 <trackbot> Zakim, this will be
16:02:19 <Zakim> I don't understand 'this will be', trackbot
16:02:20 <trackbot> Meeting: Web Payments Working Group Teleconference
16:02:21 <trackbot> Date: 12 May 2016
16:02:22 <briansullivan> briansullivan has joined #wpwg
16:02:28 <jnormore> present+ jnormore
16:02:34 <Ian> agenda: https://github.com/w3c/webpayments/wiki/Agenda-20160512
16:02:54 <zkoch> present+ zkoch
16:05:31 <Ian> scribe: Ian
16:05:34 <Ian> topic: FTF meeting
16:05:39 <Ian> https://github.com/w3c/webpayments/wiki/Web-Payments-Working-Group-FTF-Meeting-%28July-2016%29
16:05:47 <Ian> AHB: Please register -> https://www.w3.org/2002/09/wbs/83744/wpwgftf-201607/
16:05:52 <Ian> ..thanks to Brian and Visa Europe for hosting us
16:05:56 <Ian> ..London, 7-8 July
16:06:04 <Ian> ..near Paddington Station
16:06:22 <nicktr> nicktr has joined #wpwg
16:06:26 <Ian> ...chairs will start building agenda once we've addressed pressing issues on the issues list
16:06:30 <nicktr> q?
16:06:32 <adamR> present+ AdamR
16:06:45 <Ian> Marta: If I have to choose between IG and WG, which should I do?
16:07:00 <nicktr> present+ nicktr
16:07:02 <nicktr> Q?
16:07:39 <nicktr> zakim, who is here
16:07:39 <Zakim> nicktr, you need to end that query with '?'
16:07:40 <Ian> IJ: seem like if you want to go to the workshop, pick the IG meeting
16:07:42 <nicktr> zakim, who is here?
16:07:42 <Zakim> Present: jnormore, zkoch, AdamR, nicktr
16:07:44 <Zakim> On IRC I see nicktr, briansullivan, Zakim, RRSAgent, jnormore, zkoch, dezell, alyver, maheshk, collier-matthew, ShaneM, adamR, mountie, shepazu, hober, slightlyoff, mkwst, schuki_,
16:07:44 <Zakim> ... dlongley, manu, wseltzer, trackbot, dlehn, Mike5, AdrianHB, adrianba, davidillsley, dwim_, Ian
16:07:50 <Ian> ..and if you want to focus on payment apps and payment request API, pick the WG
16:08:06 <Ian> adrianHB: The IG will focus on "up and coming" whereas the WG will focus on specific deliverables
16:08:23 <nicktr> q?
16:09:03 <Ian> [Regarding hotels, see the meeting page and also Visa special rates]
16:09:10 <Roy> Roy has joined #wpwg
16:09:24 <Ian> to tpac?
16:09:27 <Ian> Topic: TPAC 2016
16:09:33 <Ian> https://www.w3.org/2016/09/TPAC/
16:09:37 <Ian> Lisbon, Portugal19-23 September 2016
16:09:46 <dezell> q+
16:09:55 <Ian> WG meets 19-20 Sept
16:10:01 <lgombos> lgombos has joined #wpwg
16:10:02 <Ian> https://www.w3.org/2002/09/wbs/35125/TPAC2016/?login
16:10:14 <kriske> kriske has joined #wpwg
16:10:33 <kriske> kriske has left #wpwg
16:10:40 <Ian> [Please register for TPAC!]
16:10:43 <Ian> ack dezell
16:10:46 <nicktr> ack dezell
16:11:08 <Ian> dezell: adrianHB, however you want to schedule ILP at TPAC is fine by me
16:11:18 <Ian> adrianhb: We'll pick up offline
16:11:21 <Ian> Topic: Payment Method Identifiers
16:11:22 <nicktr> q?
16:11:28 <kriske> kriske has joined #wpwg
16:12:06 <Ian> adrianhb: There's a pull request from Ade that is significant in terms of text change (narrowing doc to URLs)..but doesn't fundamentally change functionality
16:12:11 <Ian> https://github.com/w3c/browser-payment-api/pull/183
16:12:25 <Ian> ..the PR requests the group consensus from last week to use Absolute URLs for PMIs
16:12:31 <Ian> ..any questions?
16:12:32 <dlongley> q+
16:12:37 <Ian> ack dlongley
16:12:49 <Ian> dlongley: My only comment was that there was more specific text for options to resolve PMIs
16:12:57 <Ian> ...there is still an issue marker in the text
16:13:06 <Ian> q+
16:14:15 <Ian> dlongley: I'd like to see the section that was in there still in there.
16:14:20 <nicktr> ack Ian
16:15:10 <Ian> https://github.com/w3c/webpayments/wiki/PMI_Notes
16:15:30 <zkoch> +1 to deletion and keeping issue marker
16:15:35 <dlongley> q+
16:15:44 <nicktr> ack dlongley
16:15:45 <Ian> IJ: I think the issue marker does the job
16:16:02 <zkoch> That seems fine to me
16:16:02 <Ian> dlongley: Let's put the text in the issue marker...then I'm ok with moving it
16:16:16 <Ian> if zach and dave happy, I'm happy
16:16:32 <AdrianHB> PROPOSAL: Accept PR 183 and move requirements bullets into issue marker
16:16:37 <Ian> +1
16:16:44 <AdrianHB> +1
16:16:46 <zkoch> +1
16:16:54 <dlongley> +1
16:17:03 <jnormore> +1
16:17:18 <Ian> SO RESOLVED
16:17:24 <nick_tr> nick_tr has joined #wpwg
16:17:32 <Ian> RESOLVED: Accept PR 183 and move requirements bullets into issue marker
16:18:08 <Ian> AdrianHB: We did not get consensus on 10 and 11 last week.
16:18:15 <Ian> ..there are elements of PMIs that we need to address.
16:18:22 <Ian> ..right now there are no concrete proposals to address them.
16:18:40 <Ian> ...there has been discussion (e.g., MattS+Ian, then MattS+Ian+AHB)
16:18:46 <adrianba> I believe using URLs addresses issue #11
16:18:47 <Ian> ...there are some ideas floating around, but not on the list yet
16:19:04 <Ian> +1 that using URLs addresses 11
16:19:19 <nick_tr> q?
16:19:30 <Ian> PROPOSED: Close 11 since we are using URLs
16:19:56 <Ian> adrianba: Now that we are using URLs we get distributed extensibility
16:20:12 <Ian> ...we can deal with optimizations (short strings) as a separate issue
16:20:28 <zkoch> +1 to closing #11
16:20:30 <rouslan> rouslan has joined #wpwg
16:20:31 <adrianba> q+
16:20:35 <Ian> adrianHB: I agree we can close 11 but there are still issues around dereferencing URLs
16:20:39 <rouslan> present+ rouslan
16:20:43 <Ian> ...I don't want to make an assertion around priorities
16:20:46 <Ian> +1 to closing 11
16:20:48 <nick_tr> ack adrianba
16:21:32 <AdrianHB> +1 to closing #11
16:21:34 <Ian> adrianba: I think dereference topic is something we should talk about (but separately)
16:21:43 <nick_tr> Q?
16:21:46 <dlongley> +1 to close #11, we have #46 to talk about resolving URLs
16:21:50 <Ian> AdrianHB: Any objections?
16:21:52 <Ian> [None]
16:22:10 <Ian> (Done)
16:22:36 <zkoch> q+
16:22:38 <Ian> adrianHB: So this is an appeal to the group to look at the PMI spec after 183 merger and outstanding issues and fashion some proposals.
16:23:00 <Ian> zkoch: I do think we have a number of proposals on the table....I think we don't have consensus yet.
16:23:05 <Ian> ...e.g., short strings, etc.
16:23:13 <Ian> ...all of these proposals have pros and cons
16:23:22 <Ian> ...I'm skeptical that there's a magical solution that will address all concerns
16:23:32 <Ian> ...so at some point I think we will just need a decision on a  starting point.
16:23:40 <Ian> AdrianHB: I am referring to pull requests.
16:24:43 <Ian> zkoch: My point is not that we are missing concrete text, but rather we just don't have consensus yet.
16:24:48 <Ian> q+
16:24:51 <Ian> ack zkoch
16:25:29 <Ian> q-
16:25:35 <Ian> AdrianHB: So the priority questions are:
16:25:41 <Ian>  * Short identifiers (and how would they work)?
16:25:47 <Ian>  * Grouping and subclassing?
16:25:58 <Ian> * Dereferencing?
16:25:59 <zkoch> Clarification: They don’t necessarily have to be “short”. They just have to be standardized.
16:26:04 <AdrianHB> Grouping: https://github.com/w3c/browser-payment-api/issues/30
16:26:26 <dlongley> q+ to note that we had spec text in the options for how to do short identifiers
16:27:05 <Ian> IJ: I believe that there is consensus that we do not require dereferencing. Therefore, that topic should be lower priority for now.
16:27:09 <Ian> ack dlongley
16:27:09 <Zakim> dlongley, you wanted to note that we had spec text in the options for how to do short identifiers
16:27:15 <Ian> dlongley: We have seen spec text (in issues)
16:27:18 <Ian> ...just not as PR requests
16:27:44 <Ian> Topic: What data should be sent to the payment app?
16:28:14 <Ian> adrianhb: When a browser gets data, should it do anything before handing to the payment app?
16:28:17 <Ian> ...or just pass it on?
16:28:37 <Ian> q+
16:28:50 <Ian> adrianhb: Relates to some other issues
16:28:52 <zkoch> q+
16:28:58 <dlongley> q+
16:29:11 <nick_tr> ack Ian
16:29:23 <Ian> IJ: Topics:
16:29:25 <Ian> * Shape of APIs
16:29:28 <Ian> * What data is passed?
16:29:35 <Ian> * What mechanisms used to pass it?
16:30:12 <zkoch> q-
16:30:15 <zkoch> +1 to Ian
16:30:16 <dlongley> q-
16:30:22 <Ian> IJ: I think the priority issue is "what data does a payment app need"?
16:30:25 <Ian> ..then we figure out how.
16:30:26 <dlongley> q+
16:30:32 <Ian> ack dlongley
16:30:45 <Ian> dlongley: I agree with Ian's approach, but also important to try to make sure that we don't over specify any particular role
16:30:55 <Ian> ..it's really easy to overspeicfy the payment mediator role.
16:30:59 <Ian> q+ with concrete proposal!
16:31:04 <Ian> q+ to make a concrete proposal!
16:31:20 <Ian> Proposal for what goes to the payment app:
16:31:43 <Ian>  * The PMIs supported by the payment app
16:31:47 <Ian> * The transaction data
16:31:52 <Ian> * Any payment method specific data
16:32:15 <dlongley> q+ to talk about core messages relation to this
16:32:15 <adamR> +1
16:32:23 <nick_tr> ack Ian
16:32:23 <Zakim> Ian, you wanted to make a concrete proposal!
16:32:42 <Ian> IJ: I suggest we move that topic to the payment app spec.
16:33:33 <Ian> adrianHB: The crux of issue 157 is, when you make a payment request from the merchant site, you provide PMIs and PM-specific data...when the browser passes it on, Ian is proposing handing off only the relevant PMI info
16:33:56 <adamR> q+
16:34:29 <Ian> adrianHB: Question is sharing too much info from payment app, v. verbosity, and related is signing payment info
16:34:35 <Ian> dlongley: Some of this relates to the core messages spec.
16:34:44 <Ian> ...which specifies what does to the payment app
16:34:57 <Ian> ...the idea is to have some core message base independent of payment method
16:35:09 <nicktr> nicktr has joined #wpwg
16:35:13 <Ian> ...regarding digital signature from the merchant....that's very important for push-type payments
16:35:18 <nicktr> q?
16:35:21 <Ian> ...app needs to know that nothing was interfered with
16:35:25 <Ian> ack dl
16:35:25 <Zakim> dlongley, you wanted to talk about core messages relation to this
16:35:34 <Ian> ..my opinion is that we should not have the payment mediator filter the data
16:35:44 <Ian> ..I think there's a relationship between merchant and payment app
16:35:53 <Ian> (IJ does not think, in general, there is relationship between merchant and payment app)
16:35:59 <nicktr> ack adamR
16:36:02 <Ian> ack ad
16:36:36 <dlongley> q+
16:36:43 <Ian> adamR: If all we do is throw data back and forth, we create potential of super cookie. I think that the mediator will need to play a role of policing that. So I think there will be some modification.
16:36:45 <zkoch> +1 to adamR
16:36:49 <Ian> +1 to adamR
16:36:52 <nicktr> ack dlongley
16:36:54 <Ian> ack dlongley
16:37:08 <Ian> dlongley: As soon as we police data, we put constraints on extensibility.
16:37:27 <Ian> ..if the payment mediator decides what the app gets, we will have limitations to innovation.
16:37:52 <Ian> nicktr: Feel free to spec out that proposal.
16:38:23 <Ian> https://github.com/w3c/webpayments/wiki/PaymentApp_Notes
16:38:32 <Ian> IJ: My point is that this issue is not about paymentRequest API
16:38:37 <Ian> ...it's about payment app spec.
16:39:28 <Ian> q?
16:39:46 <Ian> adrianHB: I think people now understand the discussion points, and I think we should move discussion to the wiki or mailign list
16:39:54 <Ian> Topic: User data
16:40:19 <Ian> adrianHB: PR 174 was merged after discussion between MattS and editors
16:40:27 <Ian> ...I think MattS may log some issues separately
16:41:17 <Ian> ...looking for PRs
16:42:17 <Ian> adrianhb: Crux of concern is this: browser gets some user data that merchant (at different domain potentially than payment app) can view before completion
16:43:49 <nicktr> q?
16:45:01 <Ian> IJ: Seems like a same-origin issue.
16:45:49 <AdrianHB> q+
16:45:51 <zkoch> q+
16:46:21 <Ian> IJ: is the characterization that you are providing information to B and it gets to A?
16:46:57 <Ian> AdamR: I don't think that's the issue, it's that data is available to the Web site even though it was sent without my knowledge.
16:47:11 <Ian> ack adrianhb
16:47:18 <dlongley> the two scenarios: you enter information into merchant.com vs. you enter information into a special browser UI (and not merchant.com branded) and that information is sent to merchant.com whenever you make a selection even if you don't accept the payment, etc.
16:47:58 <Ian> adrianHB: I think Adam has characterized it correctly ... I want to reemphasize what I said - when you call show() what is not the payment app but rather privileged browser UX. In that privileged browser UX that data is being captured...any time data is captured there, the site can tell
16:48:09 <Ian> ..this does not have to do with payment app yet
16:48:34 <Ian> zkoch: I agree with Adam we need to be careful. This is browser UI at the end of the day.
16:49:00 <Ian> ...chrome tries to do things to show what is browser UI but it's not obvious that users know that
16:49:16 <Ian> ...I agree we need to figure out the consent issue...and need to leave the mediator the role of addressing it.
16:49:39 <nicktr> q?
16:49:43 <nicktr> ack zkoch
16:49:47 <adamR> q+
16:49:49 <Ian> ..there are subtle things going on...good that ew are having the conversation...but at the end of the day, I think it's the responsibility of the mediator to say what consent is.
16:49:53 <dlongley> seems like we could do the same thing with shipping address and provide a <shipping-address> component (or similar) as an alternative mechanism for collecting that info on the merchant site
16:50:19 <Ian> IJ: Would "mediator needs to get user consent" be a requirement?
16:50:44 <Ian> adamr: Perhaps not a requirement, but for example, some privacy preserving proof of concept as an example.
16:50:53 <Ian> ..but allow mediators to do things differently as well
16:50:57 <zkoch> adamR, is one of the PRs you mentioned taking a stab at this? I would be supportive of that language
16:51:04 <nicktr> q?
16:51:17 <adamR> zkoch: It wasn’t, but I can give it a go. :)
16:51:19 <Ian> Topic: API design issues
16:51:24 <Ian>  Issue 16 - Use navigator.payments singleton, factory method, or PaymentRequest constructor.
16:51:40 <Ian> AdrianHB: This seems mostly like a question of taste.
16:51:45 <Ian> Here's a concrete proposal from Manu:
16:51:46 <Ian> https://github.com/w3c/browser-payment-api/issues/16#issuecomment-217269345
16:52:02 <Ian> ...goal is to leave room for new API calls
16:52:20 <adamR> zkoch: I think the big issue is that there are basically two ways to solve this; one is with the current API and carefully crafted UX. The other is by doing data collection in one phase, and payment submission in another. I think the second is safer, but likely more controversial.
16:52:28 <dlongley> +1 to the proposal.
16:52:33 <nicktr> q?
16:52:37 <Ian> ack adam
16:52:40 <adamR> q-
16:52:44 <zkoch> q+
16:53:16 <Ian> adrianhB: This issue is like bikeshedding
16:53:26 <Ian> ...anyone opposed to using something akin to a factory method?
16:53:43 <Ian> zkoch: I don't necessarily have a strong objection. It might be unnecessary (+0)
16:53:56 <Ian> ..before we decide this, I'd rather get some sense from Ade who had to leave the call
16:54:15 <Ian> adrianHB: Let's postpone that one to when Ade is here
16:54:26 <Ian> Topic:  Issue 122 - Format of complete()
16:54:38 <Ian> https://github.com/w3c/browser-payment-api/pull/191
16:55:14 <zkoch> +1
16:55:22 <Ian> IJ: +1 to approach of treating unrecognized as "empty string"
16:55:26 <adamR> +0
16:55:40 <dlongley> +1 to the PR, but I think using the "empty string" is weird.
16:55:40 <Ian> [No objections]
16:56:01 <Ian> RESOLVED: accept  PR 191
16:56:37 <Ian> Topic: Issue 2
16:56:41 <Ian> Payment Request API only available in a top-level browsing context?
16:56:46 <zkoch> q+
16:56:59 <Ian> adrianHB: So, if an iframe attempts to call the API it won't work.
16:57:13 <Ian> ...but we know that merchants use an iframe that pulls content from a PSP
16:57:24 <Ian> ...we can imagine a PSP having the code to call the API
16:57:32 <Ian> ...we'd like to hear from PSPs on this topic
16:57:46 <Ian> ...how would you want this to be handled?
16:57:47 <nicktr> q+
16:57:56 <Ian> ack zk
16:58:18 <dlongley> +1 to giving permission from the parent.
16:58:27 <Ian> zkoch: I am now coming down on the side of allowing non-top-level (aka iframe) as long as we can find a way to give permission (parent to iframe) via the sandbox attribute
16:58:32 <alyver> alyver has left #wpwg
16:58:50 <adamR> q+
16:58:55 <Ian> ...I there may be some UX challenges, but can write up a proposal.
16:59:25 <Ian> nicktr: I recognize the use case that adrianHB described. I recognize that iframes have issues as well.
16:59:48 <Ian> ...I would like to talk to my Worldpay colleagues to understand consequences of such an approach
16:59:51 <Ian> ack n
16:59:53 <Ian> ack ad
17:00:09 <Ian> adamR: I need, also, to consult with my security colleagues (e.g., about sandbox)
17:00:10 <Ian> +1 to researching that!
17:00:13 <adamR> q-
17:00:29 <Ian> adrianHB: I am hearing "top level unless parent has given consent"
17:00:36 <dlongley> q+ it may also depend on the payment request itself in some way
17:00:37 <Ian> (e.g., through sandbox approach)
17:00:41 <dlongley> q+ to say it may also depend on the payment request itself in some way
17:00:41 <zkoch> sandbox=“allow-payment”. We would need an extension spec, too, probably
17:00:52 <nicktr> ack dlongley
17:00:52 <Zakim> dlongley, you wanted to say it may also depend on the payment request itself in some way
17:01:31 <Ian> dlongley: Another use case (future) is calling API outside of parent site (e.g., IOT)
17:01:44 <Ian> rrsagent, make minutes
17:01:44 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/12-wpwg-minutes.html Ian
17:01:53 <Ian> nicktr: Thanks everyone, there was a lot on the agenda!
17:01:56 <zkoch> I’ll see you guys in June!
17:02:03 <zkoch> Thanks!
17:02:08 <Ian> RRSAgent, make minutes
17:02:08 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/12-wpwg-minutes.html Ian
17:02:12 <Ian> rrsagent, set logs public
17:02:29 <Ian> Topic: Next meeting
17:02:35 <Ian> 19 May
17:02:38 <Ian> RRSAgent, make minutes
17:02:38 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/12-wpwg-minutes.html Ian
17:02:41 <Ian> rrsagent, set logs public