12:55:41 RRSAgent has joined #apps 12:55:41 logging to http://www.w3.org/2016/08/24-apps-irc 12:55:43 Zakim has joined #apps 12:55:59 Meeting: Payment Apps Task force 12:56:01 Chair: Ian 12:57:19 agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2016Aug/0110.html 12:57:20 agenda? 12:57:33 agenda+ invocation 12:57:35 agenda+ origin information 12:57:39 agenda+ display and selection 13:00:49 TommyT has joined #apps 13:01:10 jnormore has joined #apps 13:01:30 conorh-worldpay has joined #apps 13:01:54 Hi all, just waiting to connect to call. 13:02:57 present+ adamR 13:03:31 present+ Ian 13:03:36 present+ AdrianHB 13:03:39 present+ Tommy 13:03:42 present+ Max 13:04:05 agenda => https://lists.w3.org/Archives/Public/public-payments-wg/2016Aug/0110.html 13:05:13 present+ jnormore 13:06:16 zakim, take up item 1 13:06:16 agendum 1. "invocation" taken up [from Ian] 13:06:32 present+ Mahesh 13:06:41 AdamR's proposal 13:06:41 https://github.com/w3c/webpayments-payment-apps-api/blob/gh-pages/proposals/jsapi.md 13:06:57 IJ: Status of Max and AdrianHB reads? 13:07:17 maheshkk has joined #apps 13:07:22 AdrianHB: I have read through the proposal. Good approach in general. I have a few questions I've not yet written up. 13:07:34 ...one thing that I'm not sure about is how security boundaries will work. 13:08:15 ...also, with relation to our conversations around storing data about payment methods (and data pointing to payment apps)...do we need to have information whether registration should be more manifest-like? 13:08:36 ...should there be a rel link to a manifest of a payment app? 13:08:54 ...I've seen various things (Mike West, Marcos) around origin-level security and it seems like people are doing things different. 13:09:08 ...maybe TPAC is an opportunity to get people together on this. 13:09:17 ...but overall +1 to this approach for app invocation 13:09:52 IJ: Breakout on origin approaches to security? 13:10:13 https://www.w3.org/wiki/TPAC2016/SessionIdeas 13:10:27 AdrianHB: I think next step is concrete text. Thanks AdamR! 13:10:34 IJ: Max? 13:11:02 Max: I read the proposal lightly. 13:11:27 ...I can read it in more detail for next week. 13:11:35 IJ: Jason did you have a chance to read it? 13:11:57 Jason: I skimmed it. I will send some comments by next week? 13:12:14 Mahesh: I also skimmed; I like the approach 13:13:21 Max has joined #apps 13:13:45 IJ: Mike mentioned that it could use service worker. 13:14:00 AdamR: I think service workers are invoked via URL. 13:14:11 ...this approach (from WebRTC) works and has received security review 13:14:29 ...I don't have enough knowledge to say "we can't use service workers" or "if we did this is how we would look" 13:14:45 ...the WebRTC architects may have more rationale. 13:15:23 ...if it were based on service works, I don't know how they would be invoked...I don't understand the startup sequence, though it's possible it could work. 13:16:32 ...ask Mike to send me a few sentences about how a service worker would start up to fulfill this task. 13:16:49 ACTION: Ian to write to Mike5 with the service worker question 13:18:21 AdrianHB: It might be that some messages are missed (if app is invoked and listeners are registered)...the synchronization of things is important but I don't know how it works. 13:19:13 IJ: Time to move to spec text or want more reviews? 13:19:18 AdamR: Let's wait for reviews. 13:19:37 q? 13:19:58 Mike West's origin-wide policies via manifest: 13:19:58 https://discourse.wicg.io/t/proposal-set-origin-wide-policies-via-a-manifest/1617/1 13:20:07 zakim, take up item 2 13:20:07 agendum 2. "origin information" taken up [from Ian] 13:20:13 Mark Nottingham 13:20:13 https://mnot.github.io/I-D/site-wide-headers/ 13:20:17 App Manifest 13:20:17 https://www.w3.org/TR/appmanifest/ 13:20:51 AdrianHB: Mike is proposing a manifest with a set of security policy statements. The second one is a proposal using headers. 13:21:21 ...so we are talking about a variety of a "manifests"...should payment apps use the manifest model? 13:21:42 ...there was pushback in the group previously (due to app manifest status for example) 13:22:23 IJ: I'd like to have a group-wide discussion about payment method (URL) data 13:25:10 [Question about objections to an api call for registration in the case of app manifest] 13:25:19 AdrianHB: I can't recall the nature of the objections 13:26:05 ACTION: Ian to find out the status of app manifest (and objections) 13:26:47 zakim, take up item 2 13:26:47 agendum 2. "origin information" taken up [from Ian] 13:28:26 conorh-worldpay has joined #apps 13:28:31 IJ: Today I would propose sharing payee origin information with the payment app. 13:28:47 +1 to sharing origin 13:28:48 AdamR: I have given this more thought and now I'm ok with passing it along in all cases. 13:28:50 AdrianHB: +1 13:29:09 ...I think the argument is compelling for the payment app to tell the payer whom they are paying 13:29:39 PROPOSE: Close issue 27 with the answer "Yes, the origin information should be sent to the payment app" 13:29:47 +1 13:29:49 +1 13:29:50 +1 13:29:53 +1 13:29:55 SO RESOLVED 13:29:56 +1 13:30:06 ACTION: Ian to update the issue 27 with the resolution 13:30:09 q+ 13:30:19 ack AdrianHB 13:30:32 AdrianHB: Will we have any way of asserting that the payment app will trust that that is the correct origin. 13:30:47 ..should the payment app trust the payment request assertion of origin 13:31:25 ...what is verifiable (e.g., due to ssl connection and certs) 13:31:52 adamR: I think you will have a hard time getting people to sign off on decisions based on DV v. EV 13:32:13 AdrianHB: Is it safe for an app to be sure that request has come from a given origin. 13:32:21 ...is there a way for the browser to have gotten it wrong? 13:33:47 ...what security considerations are in order here? 13:34:25 ...user sees origin information in the prompt..is that a good idea? I would say it's not a good idea unless we have guarantees that the origin the user sees initiated the payment request...or its delegate 13:34:50 Mahesh: I think the only way a site could fake origin is by taking over DNS 13:35:00 AdrianHB: I am not so much worried about the sites being taken over. 13:36:19 AdamR: The only thing I can see being an issue is script injection. We have web security models that attempt to prevent this and I don't think we'll do better here. 13:37:00 IJ: Does requiring "secure context" help? 13:37:09 AdamR: No. Site owner has willingly loaded third party javascript 13:37:30 ...that script could maliciously call the payment request API under the origin of the site 13:37:42 ...so I think we should note this as a potential problem and point to other mitigation techniques 13:39:16 IJ: I will add a note on the security concern to the github issue thread and we can put something in the spec. 13:39:35 zakim, take up next item 13:39:35 agendum 1. "invocation" taken up [from Ian] 13:39:43 zakim, close item 2 13:39:43 agendum 2, origin information, closed 13:39:44 zakim, close item 2 13:39:44 I see 2 items remaining on the agenda; the next one is 13:39:44 1. invocation [from Ian] 13:39:44 agendum 2, origin information, closed 13:39:45 I see 2 items remaining on the agenda; the next one is 13:39:45 1. invocation [from Ian] 13:39:47 zakim, take up next item 13:39:47 agendum 1 was just opened, Ian 13:39:50 zakim, close item 1 13:39:50 agendum 1, invocation, closed 13:39:52 zakim, take up next item 13:39:52 I see 1 item remaining on the agenda: 13:39:52 3. display and selection [from Ian] 13:39:52 agendum 3. "display and selection" taken up [from Ian] 13:40:15 https://github.com/w3c/webpayments/blob/gh-pages/proposals/payment_app_id_identification.markdown 13:40:15 From last week: "Max to write up a new proposal about 13:40:15 managing the authenticity of payment apps (for proprietary 13:40:15 payment methods). 13:40:15 " 13:41:06 Max: We want to ensure that an app is in fact the app it claims to be, and 13:41:25 ..also prevent apps from faking who they are (e.g,. phishing issue) 13:41:46 ...last week we discussed Zach's proposal (which uses origin in URLs) 13:41:55 ...the origin is used to ensure the identity of the payment app 13:42:14 ...but we think that origin information only solves problem one (claim) and not problem two (fake apps) 13:43:02 ...e.g., if someone hacks a merchant web site, they can insert "fakeapp.com" in the page in place of "realapp.com" 13:43:59 ...so the idea is to include a digital signature for the payment app.... 13:44:23 ...the proposal is to have the signature data for the app available at a predictable URL on the app owner site 13:44:34 q+ 13:46:12 ack me 13:46:26 IJ: This digital signature could go into the manifest that Zach is thinking about 13:46:33 Max: yes, I think it could go there. 13:46:48 q+ to clarify the attack we are protecting against 13:46:56 ...I think that the signature should be available on the payment app site. 13:47:21 ..when the merchant invokes the payment app, the browser should THEN do the signature verification before launching the app, by getting the signature 13:48:26 ack AdrianHB 13:48:26 AdrianHB, you wanted to clarify the attack we are protecting against 13:49:08 AdrianHB: I thought I understood the attack but now I'm not sure. Are we trying to mitigate against malicious payment apps getting installed in the user's system, or are we protecting against a hacker attacking the merchant and inserting their own payment method? 13:49:17 Max: The latter should definitely be in scope. 13:49:43 AdrianHB: Who is doing the verifying? 13:49:49 Max: I think it's the browser 13:50:08 AdrianHB: Can't the browser verify that the payment app comes from the origin because that's the origin from whence the javascript was downloaded? 13:50:21 ...I would see value here in having a key or cert of the payment app to SIGN the payment response. 13:50:36 ..that allows the merchant to verify that a response came from a given app; that might be payment method specific. 13:50:45 ...I'm trying to understand what the proposal does beyond origin binding 13:51:11 ...why would somebody hack the merchant site 13:51:13 ? 13:51:39 Max: the use case is that if a hacker hacks the merchant web site and inserts a fake payment method URL 13:52:15 AdrianHB: In the payment request that comes from the merchant, the only thing it has is payment method identifiers or recommended payment apps...so you are saying that it might be a malicious recommended payment app? 13:52:48 ..it's a phishing attack via merchant attack. 13:53:07 ...I note that when I register an app via app provider, I have origin information. 13:53:38 ...but I see the point that if I am using a recommended payment app, I don't have the same origin protection...so this is an "argument against recommended payment apps" 13:54:25 IJ: Max, do you agree this problem is limited to "recommended payment apps" use case? 13:54:45 AdrianHB: Where this might be useful is for native apps 13:55:07 ...where I install a payment app through some other mechanism that does not involve origin (e.g., native app) 13:55:14 ...then it makes sense. 13:55:35 ...browser can verify signature against a cert that has an origin. 13:55:53 q? 13:56:08 can anyone here me? 13:56:13 hear 13:56:21 some problem of my computer 13:56:24 sorry 13:56:29 can you hear us? 13:56:37 I can hear you. 13:56:39 ok 13:57:13 no, maybe my earphone's problem. 13:57:30 IJ: Two things occur to me: 13:57:44 - in the text about registration, talk about the origin challenge of recommended payment apps 13:58:09 - bring the proposal to Zach 13:58:39 - add to the proposal the use cases we discussed here: 13:58:43 - recommend apps by the merchant 13:58:44 ok, will do that. 13:58:56 - native app installation that doesn't automatically do origin 13:59:06 another topic: https://github.com/w3c/webpayments/blob/gh-pages/proposals/payment_app_user_experience.markdown 13:59:07 -- put differently, recommended payment apps may be used as a channel for phishing attacks where users are duped into registering malicious apps (possibly following hack of merchant website) 13:59:22 sorry we do not have time for that. let discuss next week. thanks 13:59:30 +1 - thanks Max 13:59:33 ACTION: Ian to update the payment app spec to mention this issue in section on registration 13:59:42 ACTION: Max to update his proposal and point Zach at it 13:59:49 Topic: Next meeting 13:59:52 31 August 13:59:59 OK, Thanks, bye! 13:59:59 rrsagent, make minutes 13:59:59 I have made the request to generate http://www.w3.org/2016/08/24-apps-minutes.html Ian 14:00:02 rrsagent, set logs public