16:58:18 <RRSAgent> RRSAgent has joined #privacy
16:58:18 <RRSAgent> logging to http://www.w3.org/2017/02/16-privacy-irc
16:59:12 <christine> christine has joined #privacy
16:59:41 <Zakim> Zakim has joined #privacy
16:59:46 <Ian> present+
17:00:09 <Ian> http://www.w3.org/2017/Talks/ij_ping_201702/payments.pdf
17:00:12 <tara> present+
17:00:44 <npdoty> npdoty has joined #privacy
17:01:22 <tara> Giving people a few minutes to join...
17:01:41 <user> present+
17:02:00 <barryleiba> present+
17:02:22 <npdoty> present+
17:02:23 <user> user has left #privacy
17:02:42 <tara> Do we have any volunteers for scribe?
17:03:04 <keiji> keiji has joined #privacy
17:03:12 <keiji> present+
17:03:34 <weiler> weiler has joined #privacy
17:04:19 <Simon_R> Simon_R has joined #privacy
17:04:57 <Ian> Topic: Payment Request API
17:05:03 <Ian> http://www.w3.org/2017/Talks/ij_ping_201702/payments.pdf
17:05:13 <tara> https://w3c.github.io/browser-payment-api/
17:05:43 <tara> Ian Jacobs, Web Payments WG (presenting)
17:05:55 <christine> chartered to make check out more secure and reliable
17:06:31 <christine> getting enough implementation so thinking of going to CR - asked for wide review - now meeting here - hope to get some comments from PING
17:06:52 <keiji> Chair: tara
17:06:56 <weiler> present+
17:07:07 <keiji> scribe: christine
17:07:08 <christine> spoke to US Treasury about this work - he said why not show how pay.gov would change, see slide 3
17:07:55 <christine> walk through slides 4, 5, 6
17:08:04 <keiji> RRSagent, make minutes
17:08:04 <RRSAgent> I have made the request to generate http://www.w3.org/2017/02/16-privacy-minutes.html keiji
17:08:18 <tara> Slide 7 represents the beauty of the future
17:08:26 <christine> looked at the data they collect - much is reused
17:08:26 <keiji> RRSAgent, make logs team
17:09:15 <christine> pay button, show all the information that we already know see slide 8, 9
17:09:55 <christine> user experience improvement - get away from web forms - turn some functionality to the user side
17:10:16 <tara> (slide 10)
17:10:28 <christine> model - merhcants build web sites (slide 10) using the api - declare which payment method they support
17:10:58 <christine> users register (not install) payment apps - inform browser that I have this software
17:11:23 <christine> used to compute the intersection that is acceptable for the transaction
17:11:55 <christine> one of the benefits is - user only sees those things that they can actually use to pay, appear again and again in a predictable way
17:12:06 <christine> easier for merchants to build websites
17:12:16 <christine> slide 11 - payment methods are data
17:12:23 <christine> tried to decouple data from software
17:12:53 <christine> identifier for each payment method
17:13:10 <christine> core example - basic-card payment spec
17:13:30 <christine> looked a common fields across the web
17:13:42 <christine> no data required by the merchant for the payment api
17:13:58 <christine> payment app returns card number, expirt, name on card etc.
17:14:04 <weiler> Q: how extensible is this?  what happens if card # format changes?  (e.g. to 18 alphanumerics)  or we add an add'l field?
17:15:00 <christine> if decouple lots of people could respond to merchant's request about payment method
17:15:12 <tara> Payment method mechanism is extensible by design
17:15:20 <tara> Two methods to identify payment
17:15:37 <tara> 1. By URL - URL will be part of matching algorithm, e.g. "SamPay"
17:15:58 <weiler> [we're using URLs as unique identifiers?  how.... interesting.]
17:16:01 <christine> answer to q: payment method mechanism is extensible by design - 2 approaches for payment method (a) by URL (b) w3c payment specs (abstraction specs)
17:16:31 <christine>  re (b) cover a buch of different systems that do the same thing, e.g. no specific to Mastercard system or Visa system
17:16:46 <christine> plus a little filtering - basic-card but only under the following conditions ...
17:16:56 <christine> and emerging model
17:17:08 <christine> for (b) we use short strongs
17:17:15 <christine> strings
17:17:24 <npdoty> how does one register new payment methods with a browser instance?
17:18:02 <christine> what if new data requirements? expect that to happen - expect to be versioning of the identifiers - new spec (e.g. basic-card)
17:18:05 <Simon_R> Q1) Can you clarify where the payment data is stored? In the browser, from a payment provider API, from an on-device app? Q2) What prevents an attacker spoofing a browser request to the transaction API?
17:18:37 <tara> Response to npdoty
17:18:47 <christine> you don't really have to
17:19:20 <christine> merchant delcares I accept nick pay (URL) and payment apps in the world accept nick pay - when there is a match, browser pops up
17:19:53 <christine> once user hits okay, data goes back to the merchant on the channel
17:20:07 <christine> no registration expectation
17:20:34 <tara> Could a bad actor set up a payment method as a tracking method?
17:20:57 <tara> But there could be a small number of (valid) payment methods
17:21:01 <christine> we wondered if there should be a registry of payment methods - we thought not for w3c - web is the registry
17:21:11 <christine> issue of how to handle malicious payment apps
17:21:31 <christine> working on that question as well for payment methods by URL
17:22:01 <christine> including digital signatures
17:22:11 <npdoty> okay, great, thanks
17:22:19 <christine> not so much the method, but the apps that might claim to support it that is the problem
17:22:24 <christine> q from simon
17:22:38 <christine> payment data storage is not in the scope of our spec
17:23:05 <christine> roughly speaking the ecosystem - merchant sends request, browser mediates, payment apps
17:23:43 <christine> two types of payment apps - browser itself (extension of what they do - store credit card info) and third party payment apps (native and web tech)
17:23:53 <christine> we are working on the web-based and how to integrate
17:24:06 <christine> what they do internally is up to them and out of scope
17:24:25 <christine> browsers might use OS primiatves
17:24:31 <christine> and apps might use cloud
17:24:54 <christine> how do I know that the call to the payment request app is acceptable?
17:24:55 <barryleiba> Q; When you say "outside of our scope", do you mean to say that there will be no attempt to make recommendations about good and bad practices?
17:25:35 <christine> two cases there - site has been hacked (no protection - general problem out of scope)
17:25:52 <Ian> https://www.w3.org/TR/payment-request/#paymentrequest-and-iframe-elements
17:25:53 <christine> how sites get hacked is not the web payments working group purview - more web sec
17:26:00 <christine> see link
17:26:12 <christine> how using origins to see if call is legit
17:26:37 <christine> e.g. if in top level or iframe authorised - treated as legit
17:26:41 <christine> q from barry
17:27:20 <Ian> Ian's request to the PING: please suggest pointers to privacy recommendations!
17:27:27 <Ian> We even have a placeholder for you!
17:27:31 <Ian> https://www.w3.org/TR/payment-request/#privacy-considerations
17:27:39 <christine> we know there are things to avoid that expose you to releasing private info, known good practices - someone should include pointers that if you implement this api and store account numbers here are good practices and bad practices
17:27:46 <christine> answer - hope that is ping
17:28:01 <christine> have a placeholder for privacy considerations, happy to help get into spec
17:28:33 <christine> if guidance to implementers for browsers sound appropriate and welcome
17:28:53 <christine> but if for building apps and checkout sites, not sure how excited the WG would be about that guidance
17:28:55 <Ian> https://github.com/w3c/payment-request-info
17:29:20 <christine> we just started a place for developer guidance (see link above)
17:29:51 <christine> resuming with the slides - 12
17:30:39 <christine> api does make the nascar thing not necessary
17:30:49 <christine> merchant adoption taskforce
17:30:53 <christine> stay tuned
17:31:22 <christine> (ian going through slide 12)
17:31:37 <weiler> Q: so no way for user to see other supported payment methods, unless user also supports them?
17:31:44 <christine> our api does not change the status quo
17:31:50 <christine> for merchants
17:31:59 <christine> answering sam
17:32:27 <christine> I want to know all the payment methods the merchant accepts even if I do not have all the apps that support
17:32:36 <barryleiba> Also: merchants and payment providers want to advertise their faves.
17:32:38 <npdoty> presumably your browser could show you the full list if you really want to see it
17:32:48 <christine> we are discussing recommended apps
17:33:03 <christine> not sure if should be done in web page or in browser
17:33:07 <christine> some security questions
17:33:14 <christine> "concerns"
17:33:41 <christine> what if untrusted info displayed in browser chrome - ongoing discussion
17:33:57 <christine> having a discussion about a proposal for "other"
17:34:54 <christine> let's suppose set of registered payment apps and then unregistered that the merchant would like to recommend and are acceptable to merchant
17:35:05 <christine> if user has not installed, merchant needs to label them
17:35:26 <christine> security cocnern that if the merchant provides the logo, could be phishing risk
17:35:47 <christine> even though could do today in web, worse if appears in otherwise trustworthy chrome
17:36:23 <christine> have an ecosystem bootstrapping problem, and in a secure way - ongoing discussion
17:36:33 <christine> back to slide 13
17:36:45 <christine> (see slide)
17:37:05 <christine> encourage reviiew of going to RC and Note
17:38:46 <christine> also working on user experience and web architecture in taskforce
17:39:08 <christine> also looking at how to make more secure payments on the web - exchange of tokens
17:39:18 <christine> working with amex and facebook on that
17:39:30 <christine> credit transfer is espeically popular in europe
17:40:20 <christine> a set of common fields and would like to do the same for this use case, but unlike basic card, the merchant provides data and info is used for transfer, response data will also look different, more like confirmation of payment
17:40:38 <christine> slide 14
17:40:43 <christine> payment request api is hot
17:40:52 <christine> (talking about implementation)
17:41:02 <christine> also some with payment apps
17:41:23 <christine> slide 15 - privact design goals
17:41:33 <christine> data minimisation
17:42:11 <christine> slide 16 - user consent
17:42:34 <christine> statements about what users must consent to
17:43:34 <christine> a bit of a balance between making payments easy and not returning data to merchant
17:43:49 <christine> we are trying to make the user epxerince as good as possible
17:44:13 <weiler_> weiler_ has joined #privacy
17:44:27 <christine> merchant filtering
17:45:02 <christine> even before rendering payment - canMakePayment - borrowed from ApplePay and I think AndroidPay
17:45:49 <christine> something a little less powerful because Apple has contractual arrangements with merchants (way to enforce behaviour) - so able to give them more info
17:46:47 <christine> some rate-limiting to counter  fishing by merchants - but would appreciate ping gudiance
17:47:34 <christine> suppose, I as a payment app already know about bad sites, don't want to be used for bad sites, how I can reject (e.g. not show up in list)
17:48:26 <christine> wg is currently saying - only do after the user selected, and can then fail - didn't want to send data about transactions to all payment apps
17:48:35 <christine> paymentrequestid
17:48:50 <christine> unique identifer per transaction for reconcilitation
17:49:25 <christine> if push payment, network failure so way of knowlng
17:49:33 <christine> a way for servers to talk
17:49:41 <christine> we introduced a new identifier
17:50:11 <christine> scope a little by domain
17:50:22 <christine> heads-up, in case this raised any concerns
17:50:26 <christine> welcome your rveiew
17:50:41 <christine> face-to-face meeting in 5 weeks - comments before then would be appreciated
17:50:54 <christine> at meeting will try to get consenus to go to CR
17:51:33 <christine> need wide review, relationship between paymentreuqestapi and payment app api - timing and dependency
17:51:49 <tara> q?
17:51:59 <npdoty> q+
17:52:00 <christine> q+
17:52:23 <tara> ack np
17:52:26 <christine> nick speaking - very useful overview
17:52:38 <christine> will have lots of comments for you
17:52:52 <christine> are the privacy goals for the whole project documented somewhere
17:53:09 <Ian> https://www.w3.org/Payments/WG/charter-201510.html
17:53:16 <christine> helpful if this was written down somewhere, e.g. if someone writing a new spec
17:53:30 <Ian> 2.4 Security and Privacy Considerations
17:54:44 <christine> answer: some are listed in the charter - a starting point for us - and we have begun to put in privacy and security considerations in our specs - we don't have more formal statement and I can feel internally that there is some instiutional knowledge, but if you have a starting point of considerations that we could point spec editors at that would good
17:54:59 <christine> for now, charter key place
17:55:11 <christine> nick - would be great to write that down
17:55:30 <christine> sounds like you have a lot of that already in thinking
17:55:57 <Ian> IJ: Seems helpful!
17:56:04 <christine> ian - ahppy to work with you on a one-pager to capture this  subject to time
17:56:10 <tara> ack chr
17:56:20 <keiji> RRSagent, make minutes
17:56:20 <RRSAgent> I have made the request to generate http://www.w3.org/2017/02/16-privacy-minutes.html keiji
17:56:40 <tara> Christine: will someone in PING take lead to work with  WebPayment WG? Sounds like Nick has comments...also Simon?
17:57:10 <tara> Christine: Device API WG, years ago, made a standalone doc as "privacy design" guidance
17:57:30 <tara> Christine: or we could also include this in questionnaire (priv questionnaire), could have place for such guidance
17:57:47 <tara> Christine: some learnings from this group could be applicable to other groups
17:57:52 <tara> q?
17:58:22 <Ian> https://github.com/w3c/webpayments/wiki
17:58:43 <christine> ian - starting point of internal working page - right side - issues list
17:58:54 <christine> interest group compiled some notes
17:59:02 <christine> can possibly help translate
17:59:13 <christine> if that helps streamline
17:59:17 <christine> the issue raising
17:59:25 <christine> thanks ian
17:59:50 <Ian> thanks for having me
18:00:11 <christine> tara - we received a request, will raise on mailing list
18:00:17 <christine> date for next call?
18:00:36 <christine> 23?
18:00:38 <Ian> (IETF is 27-31 March)
18:00:47 <christine> pencil in 23/3
18:02:05 <keiji> RRSagent, make minutes
18:02:05 <RRSAgent> I have made the request to generate http://www.w3.org/2017/02/16-privacy-minutes.html keiji
18:02:21 <Ian> Ian has left #privacy
18:02:46 <keiji> RRSAgent, make logs public
18:03:14 <barryleiba> barryleiba has left #privacy
18:05:50 <keiji> meeting: Privacy Interest Group Monthly Feb.
18:05:58 <keiji> RRSagent, make minutes
18:05:58 <RRSAgent> I have made the request to generate http://www.w3.org/2017/02/16-privacy-minutes.html keiji
18:08:38 <weiler__> weiler__ has joined #privacy
18:26:00 <keiji> RRSagent, bye
18:26:00 <RRSAgent> I see no action items