<Ian> http://www.w3.org/2017/Talks/ij_ping_201702/payments.pdf

<tara> Giving people a few minutes to join...

<tara> Do we have any volunteers for scribe?

Payment Request API

<Ian> http://www.w3.org/2017/Talks/ij_ping_201702/payments.pdf

<tara> https://w3c.github.io/browser-payment-api/

<tara> Ian Jacobs, Web Payments WG (presenting)

chartered to make check out more secure and reliable

getting enough implementation so thinking of going to CR - asked for wide review - now meeting here - hope to get some comments from PING

<keiji> scribe: christine

spoke to US Treasury about this work - he said why not show how pay.gov would change, see slide 3

walk through slides 4, 5, 6

<tara> Slide 7 represents the beauty of the future

looked at the data they collect - much is reused

pay button, show all the information that we already know see slide 8, 9

user experience improvement - get away from web forms - turn some functionality to the user side

<tara> (slide 10)

model - merhcants build web sites (slide 10) using the api - declare which payment method they support

users register (not install) payment apps - inform browser that I have this software

used to compute the intersection that is acceptable for the transaction

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

easier for merchants to build websites

slide 11 - payment methods are data

tried to decouple data from software

identifier for each payment method

core example - basic-card payment spec

looked a common fields across the web

no data required by the merchant for the payment api

payment app returns card number, expirt, name on card etc.

<weiler> Q: how extensible is this? what happens if card # format changes? (e.g. to 18 alphanumerics) or we add an add'l field?

if decouple lots of people could respond to merchant's request about payment method

<tara> Payment method mechanism is extensible by design

<tara> Two methods to identify payment

<tara> 1. By URL - URL will be part of matching algorithm, e.g. "SamPay"

<weiler> [we're using URLs as unique identifiers? how.... interesting.]

answer to q: payment method mechanism is extensible by design - 2 approaches for payment method (a) by URL (b) w3c payment specs (abstraction specs)

re (b) cover a buch of different systems that do the same thing, e.g. no specific to Mastercard system or Visa system

plus a little filtering - basic-card but only under the following conditions ...

and emerging model

for (b) we use short strongs

strings

<npdoty> how does one register new payment methods with a browser instance?

what if new data requirements? expect that to happen - expect to be versioning of the identifiers - new spec (e.g. basic-card)

<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?

<tara> Response to npdoty

you don't really have to

merchant delcares I accept nick pay (URL) and payment apps in the world accept nick pay - when there is a match, browser pops up

once user hits okay, data goes back to the merchant on the channel

no registration expectation

<tara> Could a bad actor set up a payment method as a tracking method?

<tara> But there could be a small number of (valid) payment methods

we wondered if there should be a registry of payment methods - we thought not for w3c - web is the registry

issue of how to handle malicious payment apps

working on that question as well for payment methods by URL

including digital signatures

<npdoty> okay, great, thanks

not so much the method, but the apps that might claim to support it that is the problem

q from simon

payment data storage is not in the scope of our spec

roughly speaking the ecosystem - merchant sends request, browser mediates, payment apps

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)

we are working on the web-based and how to integrate

what they do internally is up to them and out of scope

browsers might use OS primiatves

and apps might use cloud

how do I know that the call to the payment request app is acceptable?

<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?

two cases there - site has been hacked (no protection - general problem out of scope)

<Ian> https://www.w3.org/TR/payment-request/#paymentrequest-and-iframe-elements

how sites get hacked is not the web payments working group purview - more web sec

see link

how using origins to see if call is legit

e.g. if in top level or iframe authorised - treated as legit

q from barry

<Ian> Ian's request to the PING: please suggest pointers to privacy recommendations!

<Ian> We even have a placeholder for you!

<Ian> https://www.w3.org/TR/payment-request/#privacy-considerations

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

answer - hope that is ping

have a placeholder for privacy considerations, happy to help get into spec

if guidance to implementers for browsers sound appropriate and welcome

but if for building apps and checkout sites, not sure how excited the WG would be about that guidance

<Ian> https://github.com/w3c/payment-request-info

we just started a place for developer guidance (see link above)

resuming with the slides - 12

api does make the nascar thing not necessary

merchant adoption taskforce

stay tuned

(ian going through slide 12)

<weiler> Q: so no way for user to see other supported payment methods, unless user also supports them?

our api does not change the status quo

for merchants

answering sam

I want to know all the payment methods the merchant accepts even if I do not have all the apps that support

<barryleiba> Also: merchants and payment providers want to advertise their faves.

<npdoty> presumably your browser could show you the full list if you really want to see it

we are discussing recommended apps

not sure if should be done in web page or in browser

some security questions

"concerns"

what if untrusted info displayed in browser chrome - ongoing discussion

having a discussion about a proposal for "other"

let's suppose set of registered payment apps and then unregistered that the merchant would like to recommend and are acceptable to merchant

if user has not installed, merchant needs to label them

security cocnern that if the merchant provides the logo, could be phishing risk

even though could do today in web, worse if appears in otherwise trustworthy chrome

have an ecosystem bootstrapping problem, and in a secure way - ongoing discussion

back to slide 13

(see slide)

encourage reviiew of going to RC and Note

also working on user experience and web architecture in taskforce

also looking at how to make more secure payments on the web - exchange of tokens

working with amex and facebook on that

credit transfer is espeically popular in europe

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

slide 14

payment request api is hot

(talking about implementation)

also some with payment apps

slide 15 - privact design goals

data minimisation

slide 16 - user consent

statements about what users must consent to

a bit of a balance between making payments easy and not returning data to merchant

we are trying to make the user epxerince as good as possible

merchant filtering

even before rendering payment - canMakePayment - borrowed from ApplePay and I think AndroidPay

something a little less powerful because Apple has contractual arrangements with merchants (way to enforce behaviour) - so able to give them more info

some rate-limiting to counter fishing by merchants - but would appreciate ping gudiance

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)

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

paymentrequestid

unique identifer per transaction for reconcilitation

if push payment, network failure so way of knowlng

a way for servers to talk

we introduced a new identifier

scope a little by domain

heads-up, in case this raised any concerns

welcome your rveiew

face-to-face meeting in 5 weeks - comments before then would be appreciated

at meeting will try to get consenus to go to CR

need wide review, relationship between paymentreuqestapi and payment app api - timing and dependency

nick speaking - very useful overview

will have lots of comments for you

are the privacy goals for the whole project documented somewhere

<Ian> https://www.w3.org/Payments/WG/charter-201510.html

helpful if this was written down somewhere, e.g. if someone writing a new spec

<Ian> 2.4 Security and Privacy Considerations

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

for now, charter key place

nick - would be great to write that down

sounds like you have a lot of that already in thinking

<Ian> IJ: Seems helpful!

ian - ahppy to work with you on a one-pager to capture this subject to time

<tara> Christine: will someone in PING take lead to work with WebPayment WG? Sounds like Nick has comments...also Simon?

<tara> Christine: Device API WG, years ago, made a standalone doc as "privacy design" guidance

<tara> Christine: or we could also include this in questionnaire (priv questionnaire), could have place for such guidance

<tara> Christine: some learnings from this group could be applicable to other groups

<Ian> https://github.com/w3c/webpayments/wiki

ian - starting point of internal working page - right side - issues list

interest group compiled some notes

can possibly help translate

if that helps streamline

the issue raising

thanks ian

<Ian> thanks for having me

tara - we received a request, will raise on mailing list

date for next call?

23?

<Ian> (IETF is 27-31 March)

pencil in 23/3

This is scribe.perl Revision: 1.148  of Date: 2016/10/11 12:55:14  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found Scribe: christine
Inferring ScribeNick: christine
Present: Ian tara user barryleiba npdoty keiji weiler
Got date from IRC log name: 16 Feb 2017
Guessing minutes URL: http://www.w3.org/2017/02/16-privacy-minutes.html
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.