IRC log of apps on 2016-08-24

Timestamps are in UTC.

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