See also: IRC log
<conorh-worldpay> Hi all, just waiting to connect to call.
AdamR's proposal
https://github.com/w3c/webpayments-payment-apps-api/blob/gh-pages/proposals/jsapi.md
IJ: Status of Max and AdrianHB reads?
AdrianHB: I have read through the
proposal. Good approach in general. I have a few questions I've
not yet written up.
... one thing that I'm not sure about is how security
boundaries will work.
... 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?
... should there be a rel link to a manifest of a payment
app?
... I've seen various things (Mike West, Marcos) around
origin-level security and it seems like people are doing things
different.
... maybe TPAC is an opportunity to get people together on
this.
... but overall +1 to this approach for app invocation
IJ: Breakout on origin approaches to security?
https://www.w3.org/wiki/TPAC2016/SessionIdeas
AdrianHB: I think next step is concrete text. Thanks AdamR!
IJ: Max?
Max: I read the proposal
lightly.
... I can read it in more detail for next week.
IJ: Jason did you have a chance to read it?
Jason: I skimmed it. I will send some comments by next week?
Mahesh: I also skimmed; I like the approach
IJ: Mike mentioned that it could use service worker.
AdamR: I think service workers
are invoked via URL.
... this approach (from WebRTC) works and has received security
review
... I don't have enough knowledge to say "we can't use service
workers" or "if we did this is how we would look"
... the WebRTC architects may have more rationale.
... 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.
... ask Mike to send me a few sentences about how a service
worker would start up to fulfill this task.
<scribe> ACTION: Ian to write to Mike5 with the service worker question [recorded in http://www.w3.org/2016/08/24-apps-minutes.html#action01]
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.
IJ: Time to move to spec text or want more reviews?
AdamR: Let's wait for reviews.
<AdrianHB> Mike West's origin-wide policies via manifest:
<AdrianHB> https://discourse.wicg.io/t/proposal-set-origin-wide-policies-via-a-manifest/1617/1
<AdrianHB> Mark Nottingham
<AdrianHB> https://mnot.github.io/I-D/site-wide-headers/
<AdrianHB> App Manifest
<AdrianHB> https://www.w3.org/TR/appmanifest/
AdrianHB: Mike is proposing a
manifest with a set of security policy statements. The second
one is a proposal using headers.
... so we are talking about a variety of a "manifests"...should
payment apps use the manifest model?
... there was pushback in the group previously (due to app
manifest status for example)
IJ: I'd like to have a group-wide discussion about payment method (URL) data
[Question about objections to an api call for registration in the case of app manifest]
AdrianHB: I can't recall the nature of the objections
<scribe> ACTION: Ian to find out the status of app manifest (and objections) [recorded in http://www.w3.org/2016/08/24-apps-minutes.html#action02]
IJ: Today I would propose sharing payee origin information with the payment app.
<AdrianHB> +1 to sharing origin
AdamR: I have given this more thought and now I'm ok with passing it along in all cases.
AdrianHB: +1
... I think the argument is compelling for the payment app to
tell the payer whom they are paying
PROPOSE: Close issue 27 with the answer "Yes, the origin information should be sent to the payment app"
<TommyT> +1
<adamR> +1
<AdrianHB> +1
<Max> +1
SO RESOLVED
<maheshkk> +1
<scribe> ACTION: Ian to update the issue 27 with the resolution [recorded in http://www.w3.org/2016/08/24-apps-minutes.html#action03]
AdrianHB: Will we have any way of
asserting that the payment app will trust that that is the
correct origin.
... should the payment app trust the payment request assertion
of origin
... what is verifiable (e.g., due to ssl connection and
certs)
adamR: I think you will have a hard time getting people to sign off on decisions based on DV v. EV
AdrianHB: Is it safe for an app
to be sure that request has come from a given origin.
... is there a way for the browser to have gotten it
wrong?
... what security considerations are in order here?
... 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
Mahesh: I think the only way a site could fake origin is by taking over DNS
AdrianHB: I am not so much worried about the sites being taken over.
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.
IJ: Does requiring "secure context" help?
AdamR: No. Site owner has
willingly loaded third party javascript
... that script could maliciously call the payment request API
under the origin of the site
... so I think we should note this as a potential problem and
point to other mitigation techniques
IJ: I will add a note on the security concern to the github issue thread and we can put something in the spec.
<Max> https://github.com/w3c/webpayments/blob/gh-pages/proposals/payment_app_id_identification.markdown
From last week: "Max to write up a new proposal about
managing the authenticity of payment apps (for proprietary
payment methods).
"
Max: We want to ensure that an
app is in fact the app it claims to be, and
... also prevent apps from faking who they are (e.g,. phishing
issue)
... last week we discussed Zach's proposal (which uses origin
in URLs)
... the origin is used to ensure the identity of the payment
app
... but we think that origin information only solves problem
one (claim) and not problem two (fake apps)
... e.g., if someone hacks a merchant web site, they can insert
"fakeapp.com" in the page in place of "realapp.com"
... so the idea is to include a digital signature for the
payment app....
... the proposal is to have the signature data for the app
available at a predictable URL on the app owner site
IJ: This digital signature could go into the manifest that Zach is thinking about
Max: yes, I think it could go
there.
... I think that the signature should be available on the
payment app site.
... when the merchant invokes the payment app, the browser
should THEN do the signature verification before launching the
app, by getting the signature
<Zakim> AdrianHB, you wanted to clarify the attack we are protecting against
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?
Max: The latter should definitely be in scope.
AdrianHB: Who is doing the verifying?
Max: I think it's the browser
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?
... I would see value here in having a key or cert of the
payment app to SIGN the payment response.
... that allows the merchant to verify that a response came
from a given app; that might be payment method specific.
... I'm trying to understand what the proposal does beyond
origin binding
... why would somebody hack the merchant site
?
Max: the use case is that if a hacker hacks the merchant web site and inserts a fake payment method URL
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?
... it's a phishing attack via merchant attack.
... I note that when I register an app via app provider, I have
origin information.
... 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"
IJ: Max, do you agree this problem is limited to "recommended payment apps" use case?
AdrianHB: Where this might be
useful is for native apps
... where I install a payment app through some other mechanism
that does not involve origin (e.g., native app)
... then it makes sense.
... browser can verify signature against a cert that has an
origin.
<Max> can anyone here me?
<Max> hear
<Max> some problem of my computer
<Max> sorry
can you hear us?
<Max> I can hear you.
ok
<Max> no, maybe my earphone's problem.
IJ: Two things occur to me:
- in the text about registration, talk about the origin challenge of recommended payment apps
- bring the proposal to Zach
- add to the proposal the use cases we discussed here:
- recommend apps by the merchant
<Max> ok, will do that.
- native app installation that doesn't automatically do origin
<Max> another topic: https://github.com/w3c/webpayments/blob/gh-pages/proposals/payment_app_user_experience.markdown
<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)
<Max> sorry we do not have time for that. let discuss next week. thanks
<AdrianHB> +1 - thanks Max
<scribe> ACTION: Ian to update the payment app spec to mention this issue in section on registration [recorded in http://www.w3.org/2016/08/24-apps-minutes.html#action04]
<scribe> ACTION: Max to update his proposal and point Zach at it [recorded in http://www.w3.org/2016/08/24-apps-minutes.html#action05]
31 August
<Max> OK, Thanks, bye!