July 2016 Web Payments Working Group Face-to-Face Meeting
08 Jul 2016

<manu> Agenda: https://github.com/w3c/webpayments/wiki/Web-Payments-Working-Group-FTF-Meeting-%28July-2016%29

<Ian> Nick: Welcome!

<manu> scribe: manu

Introductions and Meeting Administrivia

nicktr: Welcome to all, we have some administrative stuff to go over first.
... IRC channel is #wpwg, WiFi is on the board at the front of the room.

<Ian> agenda: https://github.com/w3c/webpayments/wiki/Web-Payments-Working-Group-FTF-Meeting-(July-2016)

nicktr goes over other administrative items - talking, queue, github

Ian: Thanks to all for coming to the meeting, thanks to Brian Sullivan and Visa for providing the meeting space.
... We take minutes in real time, they are public. Let's do roll call and we want to figure out dinner items.

BrianS: Since some of our competitors are here - competition lawyers have asked me to read a statement. We need to make sure we don't share competitive information today. I'll type this out into IRC. Please don't share things that are commercially sensitive to your organization.
... Please object if you hear anything that sounds like sharing of competitive or commercially sensitive information.

<brian_s> Here is the statement:“Some of the attendees today are competitors of each other so we all need to ensure that we do not share competitively sensitive information today as exchange of competitively sensitive information between competitors is a major competition law concern. I would therefore be grateful if you could bear this in mind and ensure that you do not disclose at this meeting anything of a commercially sensitive nature regarding your company. [CUT]

Ian: If you wish to keep something off of the public record, please say "don't minute this"

<Ian> Huw_bailey

<brian_s> the rest of the statement...This includes, for example pricing, investment strategy, product strategy, marketing plans and forecasts. If you have any concerns that we may be discussing competitively sensitive information, please object to the discussion so that your objection can be recorded in the minutes of the meeting.”

nicktr: On screen is the agenda, we're starting by talking about payment apps spec.
... We set priorities today/tomorrow to discuss payment request api and payment method identifiers, payment apps, payment method specs, some about strategy, http api
... To set expectations, there will be a lot of discussion - it's inevitable that many questions won't be answered. I will be looking for volunteers to take questions forward.
... This can't just rest on the shoulders of 2-3 people or just the editors.

Ian: We are planning a meal tonight - by noon we'd like preliminary menu - at break, we'll have you look at Smiths Bar and Grill menu - dinner at 7pm
... There have been some requests for significant others, we may have some space.

brian_s: We have security outside to guide you to restrooms, etc.

Payment Apps

<Ian> Payment Request API

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

AdrianHB: A quick overview of the Payment Apps spec - it's a proposal, not an adopted spec, we want to come to consensus on what's in this spec. Pick some editors w/ a view to publish it as an editors draft and send it to CR.
... This proposal is a partner spec to payment request API - scoped very specifically for browsers - broader scope of the group is beyond that - payment request is user agent API - proposed to be a partner API for that. What Payment Request does, it accepts a payment request from a website and sends a payment response.
... We are doing message brokering here, not payment processing. How do you pass a message from a website to a payment processor - anyone that's new to the work, we're trying to specify a way to move payment request from website to payment processor and get payment response back.
... PaymentRequest takes a payment request - who handles the payment request - just an idea that the request is formed, algorithms in the browser to implement. What the PaymentApp does is it provides a way to get payment apps that are not the browser into the ecosystem.
... Payment Apps are what, from a card industry perspective, call a digital wallet. We threw that out early on as there were too many options.
... We don't make any other determinations about what it can do - remote services, biometric security, we don't specify that - it's just an interface.
... How do browsers become aware of payment apps, how do they update their capabilities... and so on. we need to figure these things out over the next few days.
... How does a payment app make browser aware that it's been uninstalled?
... The browser says it accepts certain ways of paying, app becomes an option - provides user with some kind of selection - we provide tools for payment app publishers to do that.

AdrianHB explains how payment flow works for what this WG is proposing.

<Ian> Payment App spec -> https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html

nicktr: There is a diagram in an architecture summary proposal that's helpful, we may be taking up that work tomorrow.

AdrianHB: This is a simple Javascript API that we're defining.
... HTTP interface provides how information is passed from browser to payment app - payment options is a new concept, exposing payment instrument selection up front.
... Early on, we thought of payment apps as just an app with multiple cards loaded into it. It's difficult then to give user option up front. How does payment app expose which cards are there. PaymentApp has a registration feature, is option usable for a payment request.

<CyrilV> * the link to the diagram ?

Depeng: With respect to registration, 3rd party service provider - user doesn't need to register payment service/apps - customer can just click purchase and merchant redirects to merchant. From user experience perspective, I suggest the WG should focus on what the gain/benefit is for this sort of user experience.

<conorh> https://w3c.github.io/webpayments/proposals/wparch/ (Section 4)

AdrianHB: There is a benefit - when website requests payments, there is no UI there yet - what a website can do is say "I'd like you to pay, but using payment apps that I recommend."
... That's roughly the same user experience

Ian: I'd like to step back a bit - just a reminder, the high level goal of the payment app work is to create an open ecosystem for payment apps.
... Browser can store credentials and make it easier for user to save typing - a lot more is possible in the 3rd party payment app case - strong authentication, integrate payment with mobile banking, etc. Payment App spec overlays the underlying payment request API to add payment apps to the ecosystem.
... yesterday, in discussion with Alibaba, they asked why this new approach is going to benefit the customer.
... The benefits will differ based on payment method or payment app. For example, with credit cards it reduces typing and that's good. But for Alipay, you don't have to type information in anyway. Our messaging around payment apps may need to be more nuanced.
... Second observation, I think we agreed that a world in which user can configure how payment apps can be used is a better experience than hunting around on merchant sites for how to pay.
... Third, users can specify via the underlying API where they can use certain payment apps - user choice.
... For many payment methods, there may only be one payment app - like PayPal or Alipay - when there is only one app, there may not be an intermediate payment selection page.
... For these cases, we may want to have a quick/automatic selection mechanism.
... This is independent from other topics wrt. how payment apps are quickly selected.

Depeng: I suggest the Working Group focuses on how to improve that (the Alipay) case.

<Ian> Max: We can help add "how this improves the user experience" info to the spec

<Ian> https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html#paymentapp.register

Depeng: Payment registration requires a URL, but that isn't useful for native apps.

AdrianHB: I don't think we are g oing to specify anything that is too explicit to how native apps work - that's going to be platform specific - android vs iOS vs desktop - there is an open question on how much should we say. Platform vendors should say something.

<Ian> +1 to best practices documentation on how to create apps on different platforms

Depeng: For native apps, maybe the Working Group can produce a provisional document for platform specific implementations.

AdrianHB: Adam produced a document that he shared several days ago - not quite normative, but this is how we think this should work. We shouldn't use the WG time on this - we're not going to produce something normative on that.

<Ian> Max: We'd like to contribute to such good practice

Depeng: Alipay would like to collaborate on this.

nicktr: We can have this discussion via spec text and provide informative text like you describe via specs.

<Ian> NickTR: +1 to create resources around good practices

AdrianHB: How do you describe ordering of apps?
... How do you bootstrap the ecosystem?
... Do we need to say anything about defaults?

Mahesh: We (Samsung Pay) could collaborate on those practice as well.

Ian: Let's walk through the spec and discuss specific issues after that.
... A quick overview around the structure of the specification - much of the structure has been explained, written wrt. lifecycle of payment apps. How they get registered, how browser knows about them, how they are unregistered, etc.
... In section 4, we set out the model on how this works.

<Max> Mahesh， OK, thanks

Ian: The specification attempts to state declaratively on given state of interaction with user - we may prune out definitions in time that we don't need. This was inspired by observation that when I get a payment app, but haven't provided credentials to it, should that app match - when I go to pay, I have not yet given it my credit card information. Should it prompt me to enter my information?
... A matching application should have /these/ properties.
... I think definitions section, we can refine those, don't want to spend much time on those - first section that's meaty of the specification is section 6 - registration of payment apps - what is the mechanism by which we can tell a browser that I am a payment app - world of web-based payment apps, world of native payment apps - can we do that interoperably between platforms. What information do you provide before user goes away. How do you, in the web platform,

register something w/ the browser?

adrianba: General question about approach here - the way that we've structured the payment request API enables this idea of extensibility via payment apps but doesn't say anything specific about payment apps. As we start to consider enabling payment apps, there are a bunch of decisions we have to make around model for payment apps. Some of those might be more specifics around payment app matching, bunch of different ways around what an app can do, what can an app

support, etc.

<Ian> AB: Saying (but not proposing) "maybe can only use payment apps that support payment methods that come from the same origin of the payment app"

adrianba: One way we could do this (not suggesting it's what we should do), only support payment apps from same origin - that would allow Alipay to have Alipay app on their origin, but wouldn't allow anyone else to provide an Alipay app - there are a bunch of decisions that we have to make on this stuff.

<ShaneM> adamR I agree that it was a proposal

adrianba: This document has some description of this space in the model section and then goes into specifics, it's hard for me to connect general idea on abstract model, and specific decisions. I'm not sure how we review this in detail, we are jumping into some of the deeper parts. I'd like to understand the implicit decisions taken in how the web-based model is presented. What are some of those decisions?

<zkoch> Yeah, I don’t think Adrian is proposing that we limit apps to a singular origin

Ian: You are correct in your observation - there were some concrete decisions made on emerging model, not sure if you're asking if we're all in agreement on current model.

<Zakim> manu, you wanted to note on layering issues.

adrianba: I'm not sure what the best way is to address.

<zkoch> I think he’s just saying it’s unclear what assumptions were made to reach the current app spec

<Ian> manu: I looked at the spec from the viewpoint of the HTTP API

<Ian> ...it felt like the HTTP API could use pieces of this...except that this spec layered is on top of the browser API spec

<Ian> ...so it feels like the layering is off

<Ian> ...E.g., would be easier to create a separate registration spec

<Ian> ...I think that HTTP spec should reuse the registration section but today it can't easily do so

<Ian> ..is the plan that it be reusable ?

<Zakim> AdrianHB, you wanted to respond to adrianba

AdrianHB: The proposal as it stands, it started out very specific. This started out as web-based interface - explicitly not payment apps - inspired by first architecture proposal - request API, dependent on payment method api spec - different payment app specs - web-based payment app specs. This is a very narrowly scoped proposal, potentially one of many. This is the way the WG thinks about payment apps. Payment apps to be written that are accessible via URLs - th

at was the design decision behind it. Reuse via HTTP API was not a goal.

AdrianHB: I think it would be a failure if HTTP API has a normative requirement on this spec - this is very much a browser API spec.

<Zakim> ShaneM, you wanted to say that we should not restrict methods to app origin

nicktr: So we're going to get two families of specifications - one in browser-mediated specifications, one in non-browser-mediated specifications.

AdrianHB: I think it would be nice if we have common specs, but today we're doing specific specs - this is a browser API specification.

ShaneM: You mentioned as a potential concept, we could scope app to a single domain - I think that's overly restrictive and it disenfranchises people not in this room.

adrianba: I wasn't proposing that, I suggested that to be deliberately provocative.

<Ian> Manu: Having read through a lot of the spec text, a large part would be duplicated in the HTTP API

<Zakim> manu, you wanted to note that a good chunk of the text in the HTTP API payment app would copy the text in this spec.

<Ian> manu: My concern is that that we are getting a set of browser specs, and a different set for non-interactive payments

<Ian> ...I am starting to see that we are duplicating

AdrianHB: Yes, aware that that is happening - in programming terms, write what works now, then abstract later. We are building HTTP and Browser to specific requirements, they may overlap - in future - we may want to pull out duplicate bits into something like Core Messages, but I think it'll be difficult if we try to push a unified stack.

zkoch: Looking at payment app spec, I'm confused about fundamental assumption - it would be nice to have a rationale document to explain the frame of reference for spec.
... There are assumptions around payment apps and payment methods - any payment app can register with any payment method - a payment method could be as general as a visa card, but another payment method are these closed loop payment methods - like paypal.
... No one except for paypal can return back a paypal token - a random payment app can associate itself w/ a different payment method
... We want players like LastPass to be able to play in the ecosystem.
... We should standardize the open ecosystems and have specs for those. Don't think we should do that for closed ecosystems.
... I think we should consider that - notion of recommended payment apps - who provides that list.

Ian: When you say - we say "nngh" (x mark with arms) - browser would complain, is that what the browser should do? origins don't align - registrations might be the right place to do that.

<Laurent> +1 to Adrian

zkoch: If person says they support PayPal payment method, don't want to set a user up for failure - when merchant only supports paypal - but people go through experience and find out that PayPal is not a viable payment option. We may have a world where proprietary apps are allowed that have partners.

<Ian> zkoch: I can see partnerships as use cases (e.g., some company licenses another company to implement the proprietary system)

zkoch: For right now, we could say closed loop systems have to match origin.

<nick> I can certainly imagine a developer *accidentally* claiming to support a payment app they don’t

AdrianHB: I think it would be useful for payment app to say why it would expose payment methods that it doesn't. We don't want to overstep here, if we start differentiating between closed loop and open loop payment systems - we'd have to have a registry, there are dragons there.

zkoch: We have people here from the payments industry - here is a standard payment system, standard enough that people use them - SEPA, ACH, is that feasible/not feasible.

nicktr: We are heading into deep/uncomfortable water - what is open loop vs. closed loop - even that's not clear - regulator in Europe, Visa is treated differently than Amex - equally, there are aggregators that fit into payment application architecture - especially if you extend the architecture to include payment apps. Who can / can't do that is problematic.
... I also note that this is very browser specific - I think it would be useful to get a sense from the group to grow it to include all iteraction modes or if we want to have two specific work streams.

<ben> amex has a poin

<ben> point

<Faraz> I agree. Restrictions that potentially restricts players from the ecosystem are a bad idea.

Laurent: Since it's easier to implement this between payer/payee directly rather than imposing at tech layer. For example, PayPal can restrict at their side, no need to do it at the browser side.

<Faraz> I also think recommended methods also suffers from similar issues. Anything that restricts or props any player is usually a bad idea

zkoch: That doesn't solve the core problem - if Alipay provided a payment app, but Tencent says they support it where they don't.

AdrianHB: How do you stop payment apps from saying they'll support payment of something when they don't.

Ian: Let's take the approach for the moment that the standard doesn't support anything.
... Recommended payment apps - Zach and I have discussed this - there are moments when I might find myself in a bad user experience - I don't have an app, retailer wants me to use their app, browser is aware of payment app for particular payment method - configure it, install it - based on previous face-to-face - recommended payment app - you might want to install /this/. That could figure into user experience.
... When I have something installed, it's not our point to say how that is displayed.
... User experience to deal with them - Zach, do you have suggestions on how this should be done?

nickS: I have a few questions - same origin being dangerous? Seems odd to me that iframes in HTML have same origin but we're saying payments might not. I agree with Zach, naieve to say payment extensions will all be good, some will suck.
... When there wasn't a curated way to install plugins, people did horrible things. Some of this might be accidental - help people make the right decisions.

AdrianHB: Yes, we need to figure out a way to not send users down ratholes. With respect to same origin - we are not suggesting to throw that out the window. Payment Apps are not origin bound.
... Amex payment method is not at Amex.

nickS: Yes, but Walmart is.

Ian: I'm hearing that people want a proper user experience - what does the standard need to support so that the experience can be optimized for the user.

nickS: Yes, but same origin is also a security issue.

Ian: Yes, but the 'same origin' that was mentioned was not the 'same origin security' issue.

nicks: It's a security issue as well - if an airline says they have miles, another airline could say they support it to find out if a user has another airline's miles.

Charlie: We can't talk about anything wrt. restricting competition.

<Zakim> nicktr, you wanted to ask Amex for their input

<Ian> [IJ thinks that that's precisely why the standard needs to not pick a particular regulatory regime]

nicks: There are some places where these restrictions are mandated - things that prefer companies over users - we need to make sure we have something that helps us meet regulatory obligations around the world.

Charlie: Yes, but we should be very careful here - we can't have discussions that restrict competition.

AdrianHB: I'm hearing that we need to protect against malicious payment apps.
... At a technical level, do we want there to be a way that let's payment method providers restrict apps? Not known supporters of a particular payment method. That's what I'm hearing as a requirement.

Depeng: With respect to fake payment methods, we don't want users to be misled.

AdrianHB: There are certainly concerns wrt. phishing, etc.

<Zakim> Ian, you wanted to recharaterize

AdrianHB: We may have another session on this.

Ian: There are two framings - one from payment method provider perspective, another from user perspective.

AdrianHB: I think this will be dealt with in payment method specs.

Ian: Yes, but let's not make that decision now.

<Ian> IJ: I think that we may need to augment the payment API re: registration data

nicktr: In framing discussion around restriction - it makes it difficult for schemes to participate in the discussion - regulators in europe in various geographies - discussion around restriction itself is problematic. Anything that talks about ability to restrict based on commercial respects is problematic.

adamR: Something that puts restrictions on a per-payment method spec is not going to scale.

<Zakim> adamR, you wanted to point out that per-spec prose doesn’t scale

<Zakim> manu, you wanted to note "display" language in spec.

<Ian> manu: There's a lot of language in the algorithms about display requirements

<Ian> ...I don't have a strong opinion on that other than it feels strange

Ian: One of the things I agree with, we don't and can't give display guidance - there are parameters that we can speak to - we do have precendent in Web Accessibility Guidelines - however you do this, you need to make sure that you do X. Some of the requirements that are in here are intended to be non-exclusionary - if it's matching, a browser can't discriminate - it's not a visual/oral display - it's a non-discriminatory requirement.

<ShaneM> friendly comment - we should say "present", not "display"

ian: These things may be obvious/unnecessary to say - we are trying to provide intent on what should be displayed.

manu: +1 on "present"

Ian: We try to frame things in ways that show intent.

adrianba: The spec currently has a statement where it says "The user agent must display all matching payment options" - Manu mentioned the poor track record of W3C specs having this in the past, often because they didn't include the why.
... There are other ways to ensure how we do that - we lose the why, and because of that, they lose the reasoning and don't do it.

Ian: When we've only provided "why" only, we haven't gotten interoperability either.
... The closer we can get to what people should do w/o going over that line of being overly prescriptive - that's what we're trying to do.

AdrianHB: We need to decide if we're going to be specific about this and what level of detail that will have. This is about constituency requirements.

nicks: I agree with both Adrians - I can see recommended apps being of great value to both parties, in less ideal world, I think we could disadvantage. We need to find the right balance.

AdrianHB: We're adding a fairly green feature set to the Web - the more features that we add, the more likely we are to add things that have side effects that we didn't think about. Would like to focus on simple over complex solutions. Let's not try to introduce too many new features to counteract features that may happen...

<Ian> Nick: Present entire ecosystem, e.g., may lose placement but also will get more conversions

nicks: We need to look at the entire ecosystem in order to convince merchants.

Faraz: The word "ordering" is also problematic - objection to talk about that.

Ian: I have written some of these items down - would be nice to think about whether spec lends itself to that world easily or less easily.
... Recommended apps - flesh it out w/ "the why" - how can it be used and misused.
... We talked about open vs. closed systems - more rationale for why we are doing certain things - ordering is something that we may or may not want.
... Refactorization may be the right thing to do in time.
... Connor sent a few things to the list as well.

nicktr: Break for coffee, we'll be back in a bit.

<Ian> scribe: Ian

Implementation Experience

adrianhb: We'd like in this session to hear back from implementers about their experiences and implications for the spec
... I think we are getting close to pushing payment request API to CR; I would like to get feedback from browser vendors in particular, but Worldpay also have a demo
... Also want to know priority of issues to make progress

adrianba: API is in development at MS
... the number one thing that is important to us to stabilize the API
... our current implementation is experimental both in terms of UX experience and integration,
... but also the way that we have prototyped it means that it's not production ready
... for us to transition to shipping version, we want greater confidence that changes are diminishing

<Roy> If anyone is interested or it is useful, we built a crude PaymentApp implementation at FB for a hackathon, I have some demo videos and am open to questions about our experience.

adrianba: to the point where changes come from implementation experience rather than feature desires
... one issue: there is currently no good way to indicate to the user that a merchant can't deliver to a particular address
... so one option is sending back an empty list to the user to say "I can't ship" for some reason (e.g., not to a given country, or can't ship to a PO box, or address is invalid
... what a user should do next based on the reason the merchant cannot ship
... for example, if the address is invalid, the user can fix it. But if the rationale is "can't ship to a country" then no tweaking the address will suffice
... so we need to figure how (the API can) do this interaction with the user
... e.g., should there be an enumeration of popular reasons
... but we may not want to support a generic message from the Web site

AdrianB: When I think about the time we've spent discussing the API, we've spent more time about merchant integration (in our team at MS) than anything else
... the thing we fear the most is that we have not here spent enough time figuring out how to bootstrap the ecosystem
... at the beginning when few browsers have the API and when few users will have populated with data, the process for merchants will be different than it will be in the future.
... initially, adopting the API might risk merchant conversion rates
... if you drive users through the API, but there isn't support for the payment methods, then there might be lower conversion

adrianba: We need feedback from merchants about how integration might work.
... e.g., we may need to figure out how merchants can learn what is supported
... we want to avoid adding yet another button to busy sites
... so we may need some other API feature in order to bootstrap the ecosystem
... so I'd like to hear from merchants (or those with relationships) to hear how integration will work

adrianhb: I suggest that we have a session specifically on bootstrapping

NickTR: I agree that bootstrapping is an issue; the Worldpay demo is helping us talking to our own customers

<Zakim> manu, you wanted to ask about privacy thoughts/implications of sharing shipping address, email, and any other information shared via selection events.

Manu: I'd like to hear what the discussion has been around privacy implications of the API. When somebody selects a shipping address, there's a notification sent back to the merchant...customer can cancel out of the payment but merchant still has information.
... Have implementers had feedback on privacy?

NickS: Today the way that Apple does this in Safari is that we don't release the email/phone until after you've paid...we take that as consent.
... in terms of address, I"m not sure the problem has been solved...we redact our addresses
... we return 5-digit zip in the US, we redact other information in Europe
... some merchants have very unique use cases (e.g., 1 hour delivery)
... sometimes the same zip code in the us can be subject to different taxes
... if we ever were to release a full address, it would be with user consent
... I work on Apple Pay (not Webkit)...so I can discuss some implementation but I would like my webkit colleagues to give the bulk of the feedback on the API
... Apple offers customization in some fields...that's not supported in payment request API
... e.g., changing some of the terminology used...for example, if you are a ride share service you don't "ship"
... so one topic is whether the payment request API should support customization this way
... second topic...we also have an option in our spec for things like "customer name"...useful for something like a ride share service where you want to know the person's name
... Another topic - billing address...we heard from merchants that a lot of their systems require it.
... we also have a "Discovery API"....this comes back to merchants and how they want to implement the API
... we hope that payment request API will improve conversion...some merchants may want push users to use it
... in some cases merchants may want to know "Can the user make a payment right now with the payment methods I support?"
... so that's a more generic question than "specific payment methods"
... we have the discovery API...that API is validated (merchant identity)...not sure that validation is necessary here.
... the biggest difference for us is Merchant Validation..that's something we'd like to consider for this API and we think payment methods (beyond Apple Pay) will want
... we make assumptions today that payment service providers will be able to accept a payment, but perhaps a merchant account has been closed.
... I think we should consider merchant validation
... we have a step after you start the payment request....the merchant has to provide some additional information as a security feature
... helpful, eg., if a merchant's domain has been compromised.
... I can see various ways that could work in the API...my webkit colleagues can provide details
... generically, the question is whether we can go to the payment method provider and get acknowledgment before a bad user experience
... I think we should consider the case where a payment method provider does not want to accept a payment request
... there may be other reasons to not support a payment (e.g., security infrastructure issues)
... I hope to have concrete issues in github over the next couple of weeks
... Apple implementation of our API is available in developer release

zkoch: First a status update: Blink implementation is in line with the current spec
... you can call the API with support for per-payment-method totals, the UI does not yet support it
... check out android developer channel (chrome dev)
... we continue to iterate ... we made public our intent to ship
... In terms of issues, I have a few topics
... like AdrianB I support goal of getting to CR rapidly
... I think merchant feedback is really important
... so spec does not have to be perfect
... we've heard back that "knowing whether a payment method is available" is something merchants have asked for
... trying to balance merchant and privacy requirements is tricky; we don't have a good proposal yet
... another issue is that we need a way to bootstrap the ecosystem for card payment methods and sub-brands
... we'd like to resolve that dependency ASAP
... autofill has a security/privacy model
... regarding sharing shipping address, we do share it in the DOM
... we are happy with this from a user consent perspective
... but there are some issues...we can't use information as seamlessly as we might, due to consent requirement around privacy
... we use "pay" as a user consent model
... as we get more merchant feedback I will share
... e.g., iframe has come up
... one question is whether to support payment request in a secure iframe even when not in a secure context
... also, we might benefit in providing some higher-level information for merchants
... we hope to ship the API before the end of 2016...we probably will be publishing a shim during a transition period.
... we plan to have the implementation keep up with the spec, the shim would protect the merchant for a couple of versions of the browser
... we want this to be in place by Q4 (before holiday freeze)

<nicktr> holiday season varies by geography but see November and December typically as no-go areas for change for merchants

adamr: Is blink implementation basic card?

zkoch: Yes.
... potentially also support for android pay
... we have thoughts about third party payment apps on Android...we'd like to support this as soon as possible (notably for global payments)

<conorh> +q

<nicktr> reminder that the agenda is here -> https://github.com/w3c/webpayments/wiki/Web-Payments-Working-Group-FTF-Meeting-%28July-2016%29

conor: Worldpay happy to participate in the task force

https://github.com/w3c/webpayments/wiki/PaymentApp_Notes

DanAppelquist: We are working on this at Samsung.
... a lot of the current focus and thinking is how to connect samsung pay to the web through the samsung browser...we are at the prototype stage
... so please include is in the list of implementers

Roy: At Facebook we did a hackathon and I implemented (draft) payment app proposal and interface with payment request API
... we did this on the web and on mobile..the web was the most straightforward since the payment app proposal covers that well
... on native we had to wing it and see how the payment app proposal would translate...we used intents on Android
... but it did make us wonder how the web proposal would translate to native and if that's something we would want to specify
... I think that is most useful to be able to make it easy to pay from any device...would be interesting to try to get consistent cross-device experience for user

adrianhb: Clarification - do you mean that when I register an app that registration information is shared across devices?

Roy: That, too.
... from Facebook's perspective, the most interesting for us would be that if you registered facebook.com as your payment app .. what would it look like if you also had a native app on your device?
... we ended up implementing this through our FB SDK
... that seemed to be the most natural UX

adrianhb: Seems like a good question for platform implementers who are thinking about the native app story - is there reusability in what we are doing? Will our model translate to native? Can I expose a platform API to native apps that looks similar

<manu> Ian: Following up on what Dan said - I've been reaching out to more payment method providers to roadtest the API

<manu> Ian: We have more card folks at the table now too - reached out to Samsung Pay - they're thinking of doing a payment method spec. I'd like to reach out to others here to reach out to other people working on Payment Method specs.

<manu> Ian: Please keep this in mind as we continue the discussion.

nicktr: Do you anticipate (NickS) that there would be an Apple Pay payment method spec?

nickS: I don't know. Apple Pay is a payment method and the output can depend on a number of factors including region
... so "potentially"...might depend on things I mentioned earlier such as merchant validation

zkoch: I expect we will have "documentation" (though probably not a w3c spec)

[IJ agrees that all these things should not necessarily be w3c specs...but whatever form they take, they are useful. Our goal is to allow scalability so we expect these to exist all over the place]

Max: On issue 2 - should payment request API only be available in top-level context (or iframe)
... we support the idea of providing a security mechanism

adrianhb: Current proposal is top level PLUS other contexts authorized by the top-level context
... e.g., top level can provide an attribute to the iframe provided by a payment service provider

NickS: Here's what we do today for Apple Pay - you have to have actual javascript in the top level, but you can trigger it from an iframe through post messages
... we do that to support Stripe, for example, which drop in a checkout form in an iframe
... also the proposal on github regarding delegation seems like it would do the job

Max: In the definition of Show() method (section 4.2)...when the user selects a payment method, what happens if there's no response message.

adrianhb: The intention here is that we are not being specific about what the browser does....
... in the case where ther is no content in the response....
... there is a response even if there is no data in the response
... the promise resolution returns control to the browser

AdrianBA: The API takes into account the use case where the response data is empty

Max: What happens when there is a delay before the response?

AdrianBA: I am hearing we need to do a better job in the spec of saying when the algorithm executes; we will do that.
... Regarding support in native apps,
... UX considerations are important (e.g., to avoid spoofing UI)

[Worldpay demo]

Conor: I have created a web service that accepts payment information from the web site. Worldpay determines which payment methods are supported and returns that list to the merchant so the merchant can build a payment request

[Conor shows polyfill usage from Ade on top of the service]

conor: When I click "authorize" credentials are sent to the site where they are tokenized; the token is then sent to the merchant's back end
... tokenization happens on world pay's server
... Browser gets data, sends to worldpay which tokenizes and sends back to the merchant

[More discussion of tokenization]

[One-time v. reuse]

MattS: This implementation is a one-time token
... to avoid passing the PAN

Roy: When we built the Facebook version of this we did things similarly.
... we encrypted the token in a cryptogram with a Facebook App API key, and expect the merchant to know how to decrypt the block
... so we encrypted in our back end and forwarded the token to the merchant's JS where they could maintain PCI compliance

IJ: I mentioned three ways to do things (which may be useful in a transition period)

1) Split context in the browser where there's a merchant app and also PSP code that is separate

2) Third party payment app does work

3) Payment method spec itself means token circulates

Expanded card payment spec

Nick: I have recruited a volunteer to help me write a tokenized spec

AdrianHB: Yes, let's call for volunteers
... I'd like to close two issues on our issue list in next 15 mins

- non-standard currencies

- which data goes to payment apps

<manu> My point is that this sounds like it's out of charter

People who want to work on advanced card spec: NickTR, Faraz, Laurent, Kevin(?) from Facebook?

Proposal related to non-standard currencies

https://github.com/w3c/browser-payment-api/issues/185#issuecomment-228117620

[AHB summarizes the proposal]

- you specify registry and entry in registry

- default registry is ISO 4217 registry

<Zakim> AdrianHB, you wanted to suggest we define an enhancement to card for encrypted pan

Kris: ISO is looking at a way to extend their current mechanism to meet this sort of requirement
... ISO also looking at using URLs

PROPOSED: Adopt AdamR's proposal for handling currency codes and addressing 185

<manu> +1

<nicktr> +1

<AdrianHB> +1

<rouslan> +1

+1

<alyver> +1

<ShaneM> +1

<CyrilV> +1

<adamR> +1

<conorh> +1

[No objections]

<MaheshK> +1

SO RESOLVED

<Dongwoo> +1

<Laurent> +1

<scribe> ACTION: AdamR to work on concrete spec language around currency codes [recorded in http://www.w3.org/2016/07/07-wpwg-minutes.html#action01]

<trackbot> Created ACTION-20 - Work on concrete spec language around currency codes [on Adam Roach - due 2016-07-14].

[Issue 157]

AHB: Question is how much data to pass to the payment app of the original payment request

[Pros and cons of sending all the original data v. sending only a subset]

Subset: Don't send unnecessary data; preserve merchant privacy

Full data: Signing

<Zakim> manu, you wanted to note security implications of this decision.

Manu: I think it's too early to decide what to do because we don't know how to prevent man in the middle attacks
... general concern is inability to sign messages...since some data is at the top level
... I think until we have a good strategy for how to sign pieces of message, then I have concerns about subsetting parts of the original message
... potential security issue where you can recompose messages to do things that the merchant never wanted to do

<Laurent> +1 to Manu on impact on signatures

rouslan: Speaking as a Google engineer, I think that Android pay would not want to have any kind of information about unsupported payment methods. So I support subsetting the data.
... to address Manu's concerns, I think we should address the signature question (and rapidly). One way to avoid remixing of the payment request data is to specify exactly what we can sign...e.g., sign the details and each individual piece of API data.
... the only remixing that would be allowed in this case would be for the mediator to be able to filter the requested payment methods, which I think is it's job

adrianba: My point on this was a scoping point. I think there are a variety of questions that have come up about what data gets passed to apps. I think it's an important question but is not blocking of the payment request API. I think it's tied to the broader question about communication between browser and apps

AdrianHB: I am ok to close this in the payment request API repo and opening in the payment app issues list

<dka> Possibly of relevance to this discussion: https://www.w3.org/2001/tag/doc/APIMinimization.html

PROPOSAL: Close issue 185 on payment request api and move to the general issue list.

+1

<adrianba> +1

[No objections]

SO RESOLVED

LUNCH

Payment Methods

[SEPA / Direct Credit ]

[Basic Card]

https://w3c.github.io/webpayments-methods-card/

<zkoch> Nick, can you zoom in on screen?

MattS: First topic there to resolve is payment method identifiers
... there's a long list of identifiers in the spec
... one thing that I think is an issue is "how we match"
... the list in the basic card spec is in complete....some may be unhappy to not be listed here; those who are in there may feel we have not modeled their space correctly

adrianhb: We have a lot of time dedicated to payment method identifiers

MattS: The basic card spec currently has no data for payment request input
... one pull request from me involves the ability for a merchant to specify information as required

https://w3c.github.io/webpayments-methods-card/

https://github.com/w3c/webpayments-methods-card/pull/4

MattS: the pull request enables the merchant to indicate which ones it wants the app to try really hard to get
... some merchants do not collect CVV, for example, and that's a business decision

adrianba: I think this spec is not a good example of payment method specs; since cards work differently than many other payment methods
... for this spec you mentioned the point about differentiating debit and credit
... and why it's a useful feature for some scenarios
... and complexities around other matching
... given "cards" are special, I am leaning toward the approach where there is just one identifier for card payments
... and within the payment method specific data we can provide other data such as which networks are supported
... keep the URL matching simple and move extensibility elsewhere
... if we did that it would change some of the conversations we're having more broadly and maybe make the card spec a better model

MattS: SEPA also has some "required" fields requirements

Cyril: Please note that EMV has some identifier schemes
... for card payments
... we might want to refer to that work

brian_s: I think there are AIDs and extensions in EMV...it's in the same space but not quite the solution

Nick: You can't necessarily rely on AIDs belonging to the networks that manage them

<manu> Ian: Matt's pull request is about the merchant saying "I need this data" - seems to me that you may want to say the opposite - "The following is 'optional' to me."

<manu> Ian: I can't tell whether you feel like it should be "I don't need this, don't bother."

<manu> Ian: I hear you saying - "this may be a requirement, maybe we should pull it out into the Payment Request API"?

<manu> Ian: Maybe, but not yet - that's my personal sense.

<manu> MattS: We called it out in SEPA spec.

MattS: The basic card spec does not support PCI compliance well yet
... I think we also need to address that

NickTR: We have agreed we will do a tokenized spec

MattS: Who has an implementation of basic card?

Zach: We have

Andre: We are considering it

AdrianHB: This is our "bootstrap" spec
... It should be possible for a merchant to support basic card as an interim step before their existing payment page
... I think this is an important transition step...but I think it won't take long before there are implementations of other payment methods

<manu> Ian: I heard a proposal from Matt to accept pull request - can we try to close that loop?

PROPOSED: The basic card spec should support "required fields" specification from the merchant

<manu> +1 to AdrianHB

pull request -> https://github.com/w3c/webpayments-methods-card/pull/4/commits/ba6c5c5d679596246db446ef3137f8adbffb5ecd

<AdrianHB> +1

<manu> +1

Zkoch: May want editorial work to make clear that this is input data.

AdrianBa: I don't think we should do this. We should return the data we have and if the merchant doesn't want the data, they don't have to use it.
... this seems like an unnecessary refinement

+1 to the proposal

AdrianBa: One of the reasons we changed the fields so that card number was the only required field, was that there are some cards where all fields don't make sense
... depending on the card type, there are some fields and you have them you should return them.
... one thing that MattS is suggesting is that the security code that merchants may not request
... if a merchant chooses not to use data in its processing it can do so...it doesn't seem onerous to return data if present, and if you don't have it you don't have to give it back
... each new requirement increases implementation and testing cost
... my position is that we can still be successful without this feature...we can add later

zkoch: In the case you return back more data than the merchant has requested you don't lose anything

MattS: You can't store CVC..you always have to capture it...but some merchants don't want it due to checkout friction

zkoch: The case of "not getting data you need" is worse than "getting too much data beyond what you want"

adrianba: the only case we would return without a cardholder name is where there is a card that does not have a name, so I wouldn't return it

zkoch: The downside of having too much data is "thrown away" with potential of lost sale...but you don't have insight into reasons for lost field.
... this is therefore a "nice to have" feature.

AdrianBA: You could add to the spec and we ignore it.

nick: One question I have - what happens if you accept union pay (for example) and visa and the required fields are different
... the current proposal doesn't address some use cases

MattS: That's why we are focused on the use case today - whether "required fields" use case is worth being a feature in v1
... I think this is "do-able" if this is advisory and the payment app does its best to fulfill the merchant's expectations

Nick: I think it's unlikely that user agents will know what to do for each payment method

<AdrianHB> laurent: getting too much data may have compliance implications

Laurent: There's also a question about receiving sensitive data (e.g., PCI compliance) that you don't want

<AdrianHB> ... eg for PCI DSS

Laurent: So if you get more data than you want, it may harm your compliance

Faraz: One alternative is to not query the customer if you recently gathered data from the user
... so there may be other ways to minimize friction

NickTR: I am not hearing consensus yet.
... therefore we will not resolve the issue in this session

{IJ wonders whether we should think about "optional" approach and see if that's easier to manage)

[Direct Credit]

http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/

MattS: As it is written, it is the SEPA Credit Transfer spec
... we stripped out non-SEPA stuff and also direct debit stuff
... we have narrowed the scope
... the others are important...we just felt it was good to do a smaller set of things well and then do the others once we have the experience
... in the SEPA CT case, the payment app initiates the payment

(the push version)

scribe: there is a variation with SEPA that is a pull version, but there are some security issues that are being dealt with separately
... this is a case where the payment method absolutely needs input fields

MattS: Do people feel that collaboration diagrams are a better way of diagramming than a sequence diagram?

<Laurent> +1 to collaboration diagram

<zkoch> +0 I have no idea what those mean

<zkoch> :)

<nicktr> 0 because I like both

<pirouz> +1

<jyrossi> +1

<AdrianHB> +0 (-1 maybe because I like sequence diagrams)

<manu> I don't think the diagrams help all that much (the ones in the spec right now)

<ShaneM> +0 I also like both

<VincentK> +1 Collaboration diagram

I don't know what collaboration diagram v. sequence

<conorhackett_wp> 0

<conorhackett_wp> +0

<adamR> -1 — sequence diagrams make information flow much clearer, IMHO (although I appear to be in the minority here)

NickTR: SEPA Pull anticipates something we've not seen in the wild yet....

MattS: I think this points at PSD2

DavidBirch: In the UK payments version of this this is called "request to pay"
... maybe avoid the phrase "pull" since that might create some confusion

MattS: I am ok to refactor to common vocabulary; our focus was more on SEPA and using that terminology

DavidBirch: In the general case, the transfer will be instructed through the bank API...the payment will still be user initiated (either triggered by merchant or by user account directly
... I think credit transfer may become a bigger part of the landscape
... so I think it's worth investing the effort

zkoch: My mental model for the payment app is that anyone can write a payment app that can return credit card info. Is the same true with SEPA?

Cyril: for cards, all merchants are connected to acquirers, so it works
... for credit transfer .... if someone wants to develop a SEPA app, it may be a bank for its own customers
... the API needs to be secure (with auth, etc.)
... the idea of PSD2 is to generalize the mechanism so that any type of regulated entity can have access

zkoch: So it's more regulated

MattS: Part of PSD2 is the open banking API....

DavidBirch: there is strong support for the open api framework

nickTR: You can build third party apps to log into an online banking Api that lets you do credit transfers

zkoch: I am hearing that banks do this today, but in the future more will be able to do this (NickTR: PISPs)

DavidBirch: This is being mandated in Europe

zkoch: The input and responses to these are well-defined by regulatory bodies
... What is added value of our own specs if these are specified elsewhere?

MattS: The spec (5.1) does reference the SEPA rule book.
... not every thing from the SEPA rule book is required
... we've also turned terms into what we think will be more developer-friendly

DavidBirch: IN the UK and in EU environment, the likely implementation of this....
... will be done through directories
... I want to illustrate that in the final version will be more user-friendly
... you won't type things in
... just to illustrate why we should be thinking about this use cases

MattS: What we are envisaging is that the user clicks on "pay", logs into the bank payment app, and information is known by the bank

jyrossi: The ecosystem has been created through regulation...it's a work in progress

<Zakim> manu, you wanted to make a few comments on spec - flows are too detailed, align vocabulary.

Manu: Regarding diagram in the SEPA spec...I appreciate that amount of detail, but I think it's "too much"
... for the spec...I think it would be ok to link to it...or a simpler diagram
... also, the vocabulary that's used in the messages
... it would be good to get consistency across specs (e.g., how we express input and output across the specs)
... we reuse fields like "address' and "postal code" except that the field name in sepa doesn't align with payment request API

<nick> +1, I would also like to discuss the AliPay spec

DavidBirch: The EBA is not creating technical specs

IJ: When are EBA requirements coming out?

NickTR/DavidBirch: This month

<Zakim> AdrianHB, you wanted to discuss code conventions and commonality across payment method specs

AdrianHB: I think to answer your question slightly - any payment method that we want to support through the API we need a "spec" for

[IJ notes that some of these things may be "specs" and some may be "documentation"; let's not focus on the word "spec"]

AdrianHB: Our payment method specs say what data is necessary to initiate or send back a payment request/response
... we need these specs because even if the payment methods are defined elsewhere, they do not specify concretely what is needed for a payment request
... Another general point - I think we must be wary of prematurely trying to find common data and pushing it to the payment request level

<nicktr> +1 to AHB - we need to write some of things to find the generalisations

adrianhb: even if three different payment methods require addresses, there may be specifics per payment method

+! to not trying to harmonize up front (but keeping it in mind for later)

kriske: On SEPA, the credit transfer is defined...the thing is "how to get it from this environment into a proper credit transfer"..that's the purpose of these specs
... I don't think that we will arrive at a stage where ISO20022 terminology will be shown on the user screen .... it is key that we use the same types that are defined in ISO20022....
... if they are not the same types, some magic will have to happen somewhere (mapping)

<nicktr> akc nicktr

kriske: we need to have these types interoperable

nicktr: I am a very strong +1 that we define these payment methods
... the reason that they are instructive are they let us examine other specifications closely
... and ensure the underlying specs are not card-specific
... we want the Web spec to be usable all over the world

jyrossi: +1 to making sure we look at these flows
... I think we should continue to study SEPA Direct Debit (which was pulled out of the SEPA CT spec yesterday)

DavidBirch: I think we should not pay attention to direct debit
... to susceptible to fraud

Nicolas_A_: Credit transfers are not just the future; e.g., in NL 90% use credit transfer today

<CyrilV> SDD is still in use in EUROPE. Thanks for us.

[Alipay]

Alipay spec (without diagram) -> https://w3c.github.io/webpayments/proposals/Alipay-payment-method.html

<Max> http://www.plantuml.com/plantuml/proxy?fmt=svg&src=https://raw.githubusercontent.com/w3c/webpayments-flows/gh-pages/PaymentFlows/AliPay/AliPay-Current.pml

Max: I think Alipay is similar to other third party payment methods

[Max reviews the flow]

scribe: user can select Alipay as a payment method
... alipay server sends synchronized message to the browser
... and async message to the merchant server
... merchant can confirm payment using either one
... another comment that I think is valid for other similar payment methods
... when the user agent displays matching payment apps, maybe we can add a parameter to allow the user to redirect to the third party payment website
... sometimes the third party payment provider may have customized UI

<manu> Ian: I think that's part of the payment app specification today - one way to launch a Web-based payment app is to give payment request data to a URL

nickS: Why are there fields that overlap with payment request API

<adrianba> https://w3c.github.io/webpayments/proposals/Alipay-payment-method.html

Max: This was our first try, so if there are params in payment request API, then we should not duplicate them

rouslan: Thanks for producing the draft! You put "charset" in there
... javascript is almost always Unicode 16
... do you use input charset for other purposes than communicating with the browser?

Max: We support multiple encodings...UTF8 is popular for some customers

Rouslan: Some of these fields might need some examples
... do you have links to original documentation? ...suggest links to official documentation

Ian: +1

<Zakim> Ian, you wanted to talk about other user experience topics

<manu> Ian: The starting point for the conversation was "How does this improve the user experience beyond what we have today?" - Alipay showed me two ways to initiate a payment. For some payment methods, there may not be user experience benefit wrt. typing.

<manu> Ian: There are also further benefits - one of them had to do with the edge case where the user has one payment app when they go to pay. My brute force thought on how this works - I click on Alipay button, I have to click again even though I only have one choice - browser may decide to shortcut choice.

<manu> zkoch: We've been talking about this - direct passthrough, there are circumstances under which it might make sense.

<manu> Ian: I mention that to bring up - we would probably not specify, but we could call that out.

<manu> nicks: Another use case - today, many merchants have paid placement agreements.

<manu> nicks: Maybe one could have "checkout w/ PayPal", which still uses this mechanism, but you could have another button for everything else.

<manu> Ian: You might say "I accept payment app registrations", facilitating registration so that the user has to do even less.

<manu> Ian: Payment Apps storing authentication information - interesting question, don't know regulatory implications - the goal is as fast as possible to pay for stuff.

<manu> Ian: I've authenticated to Alipay, do I have to authenticate again or is it cached? What can we tell payment app developers about caching authentication information - yet another faster checkout idea.

<manu> zkoch: It's worth mentioning that there are other web platform APIs that are interesting - like Credential Management API. A trusted model - something to look at. How APIs interplay, work here from WebAppSec that we should look into.

<manu> dbirch: If I'm logging in from home, Visa doesn't require 3D Secure - but if I'm logging in from somewhere else, they require login.

<manu> Ian: If you're browsing, click on the Buy button - do merchants still need users to know which payment apps you have - question is whether payment request API should have an option to say "You may also like... <these other payment methods>"

<manu> Ian: So, what merchants what might like.

<manu> dbirch: If I'm a merchant and I want customers to play with American Express, I may want to steer customers and make AmEx displayed first.

<manu> Ian: If saving typing is not a benefit, there are other reasons - consistent user experience across payment methods. The long term vision is the same in app, in store, and on the Web. It's the same across payment methods.

<manu> Ian: Slightly longer-term benefit, once we have payment apps easily integrated into checkout experience, payment apps doing loyalty is helpful for retailers.

<manu> Ian: Third one - matching and user preferences make the checkout experience easier, checking for relevant app - it shows up again and again for you. Bottom line, we still think this is better.

<Zakim> manu, you wanted to ask about how signatures are used.

Manu: Alipay spec uses signatures
... both merchant-initiated and Alipay response signatures
... can you say why?

Max: We want to ensure that message is actually coming from Alipay (or from merchant)

Manu: the assumption is that you don't care if HTTPS is wrapping the exchange...you want to make sure that the message itself is secure

Max: HTTPS can only secure the channel, not the content of the message, so we sign the data as well

zkoch: Is it similar to the way that Apple Pay does merchant validation?

Max: Yes

danielA: Ian, I wanted to respond to something you said earlier about making it easier for payment apps to be registered

<manu> Ian: I meant to imply that there are settings that make some things easier to accept globally - can we make it easier to accept payment apps?

<manu> dka: I'm very concerned about that.

<manu> dka: A payment app by itself is powerful, it can reach into your device - it's active, not inert.

<manu> Ian: All that's being given to the browser is just information about the app.

<manu> ian: When you see your user interface, you see it as an option to allow it. We're not enabling a powerful feature, just checking to see if it exists.

daniel: I am concerned about registration security...e.g., a fingerprinting issue

<manu> dka: it could still be a fingerprinting issue.

CyrilV: Ian, I want to comment about what you said about authentication....this is a key security component for payment
... so far authentication for card schemes is accepted by the card schemes (including ways like Apple Pay)
... that's because responsibilities are clear
... and there are regulatory obligations as well (e.g., 2factor with exceptions)

<dka> cf TAG finding on unsanctioned tracking https://www.w3.org/2001/tag/doc/unsanctioned-tracking/

CyrilV: we should leave authentication issues to the payment mechanism

Max: Regarding HTTPS, we don't use it to authenticate the merchant...rather the merchant authenticates directly to our server
... Another point ... from our experience we think that for payment request API, it should allow when the user selects Alipay, browser should allow redirect to Alipay site

{IJ thinks this will be supported]

<Zakim> nicktr, you wanted to propose that we take up the alipay specification as a working group work item and to note merchant feedback on coupons and loyalty

NickTR: When I talk to merchants, they are really enthusiastic about coupons in payment apps
... Second point I want to make is that we take up Alipay spec as a payment method spec

PROPOSED: The WG should take up the Alipay payment method spec to published as a W3C Note

AdrianBA: I object to that.
... I think that, especially at this stage, it's valuable for us to investigate different payment methods that work in different ways to ensure that the API supports them.
... as a way of taking forward the original flows work in a more concrete way
... but I don't think that it's valuable to the ecosystem to have vendor-specific payment methods published as W3C documents
... that in fact we should be encouraging a practice where vendors publish them

<nick> +1, I think it could rapidly become unmanageable

AdrianBa: if we are successful, there will be dozens of these things and I don't think we should set a precedent that these should become W3C documents, and we should not favor some vendors with W3C document status and not others

Roy: I have the same concern expressed by AdrianBA
... I question whether this is the best medium for exploring payment methods
... should we use a lighter weight approach to producing the spec than a WG?

Max: As a response to AdrianBA's concern...the WG has a basic card spec that has payment method identifiers in it
... what's the difference between that and other payment methods?

AdrianBA: I plan to propose that we remove PMIs from the basic card spec
... but I haven't had time
... we'll also have discussion about changing this specification so that it is not as proprietary, and network information is a parameter
... I agree it's problematic to have only some brands in the basic card spec or not

Max: Maybe we should attempt a generic approach

AdrianHB: It could be valuable to see whether there is commonality among different types of payment methods
... we may find that there are commonalities and it's worth creating a standard
... I appreciate the concern about publishing vendor-specific specs
... I think we could even call it a "push payment" spec
... e.g., where there's a merchant id and a call back URL and a transaction id
... this might help us avoid massive fragmentation

<Zakim> manu, you wanted to say there is value to get people into the group and guide them through the process. We can always prioritize or spin off a Task Force. and to say or send them

Manu: If there is objection to doing this in the WG as a WG Note, perhaps we should create a CG to work on these, with guidance to companies on how to do this
... I still think that there is value to keeping discussion going in the WG while there still may be impact on the API

<MattS> +1 to Manu

<nicktr> +1 for working on the illustrative specs in this group

<rouslan> +1 to manu

<Laurent> +1 to manu

<Nicolas_A_> +1 to manu

adrianba: I want to be clear that my objection is to a TR document...but I want to emphasize that it's super valuable that we are discussing it in this WG and we should continue to discuss it

IJ: we can just work on it in our github repo

AdrianBa: I am fine with that. At this stage of the process, it's valuable that the WG is discussing these. At some point these docs should be done by their owners

<manu> Ian: In the past, we've talked about two best practices - how to do payment apps, and another that says how to do payment method specs.

<manu> Ian: Should we do payment method spec guidance? Anyone want to volunteer for that?

<scribe> ACTION: Max to work with Ian on starting some payment method good practice documentation. [recorded in http://www.w3.org/2016/07/07-wpwg-minutes.html#action02]

<trackbot> Error finding 'Max'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.

<ShaneM> I would be happy to assist with the guidance document Ian and Max

<alyver> Ian - happy to help with the Payment Method specs

Roy: One thing that stands out with this payment method is the push part
... It would be interesting to look for commonalities among push payments

Security Review

https://lists.w3.org/Archives/Public/public-payments-wg/2016Jul/att-0013/WebpaymentsAPISecurityandPrivacyChecklist.pdf

<nicktr> security review -> https://docs.google.com/document/d/1w7ginyzNg-xZUmITK4vzcGUKB4gbMOAvlkWWaRtX14k/edit?pli=1#

AdamR: We used the TAG checklist (still in development) to do a security review

<nicktr> or pdf -> https://lists.w3.org/Archives/Public/public-payments-wg/2016Jul/att-0013/WebpaymentsAPISecurityandPrivacyChecklist.pdf

AdamR: Evgeny, Ian, and I developed answers to the questions
... we wanted today to go over the recommendations that resulted from the analysis

<nicktr> Call in numbers are here, Wendy

3.1 Does this specification deal with personally-identifiable information?

<nicktr> https://www-emea.intercallonline.com/listNumbersByCode.action?confCode=875114&area=viewNumber

<nicktr> and conference code is 875114

AdamR: We recommend for this one enhancing privacy considerations of Payment Request API spec

3.2 Does this specification deal with high-value data?

zkoch: I am not sure that it's our place to tell businesses where to store or not store credentials.

<nicktr> akc zkoch

zkoch: I want to push back on PCI specifically
... this is governed outside of us
... I don't think we need to say anything...merchants need to be independently aware of this or use services that make them not aware intentionally

AdamR: The card spec strongly encourages storing credit card information...a casual read might suggest that is best practice
... I think that we need to highlight that that is NO LONGER a best practice given the payment request API
... and we should not have flows or language that Encourage storage

zkoch: +1 to opening an issue with this. I think we could make the language more neutral in the spec regarding storage

adamr: I think it's at least useful to have some discussion about the advantages of not storing, and that the historic advantages to storing are largely removed through these specs

zkoch: I am ok with that...expressing goals and implying that storage is no longer

adamr: That sounds good
... I think we don't want to remain silent on PCI since anyone who reads the spec will say "What about this?" We should therefore say explicitly something if only to redirect people .

<wseltzer> +1 to saying something

<wseltzer> to alert people to the security consideration

zkoch: I think it's also reasonable to say "PCI is out of scope for this spec" with a link....I want to minimize our touching on this too much

adrianhb: I support the approach were we are explicit that we are not making PCI go away

3.4 Does this specification expose persistent, cross-origin state to the web?

AdamR: We recommended adopting the "required fields" PR for privacy reasons
... We also think that there should be some consideration to exposing some sort of tracking potential to the user
... from a UX perspective

IJ: Any other examples of alerting the user that "by doing this there may be privacy implications"?

Wseltzer: Check out TAG guidance on unsanctioned tracking

<wseltzer> https://www.w3.org/2001/tag/doc/unsanctioned-tracking/

adrianhb: For me, I am trying to reconcile how using the payment api to send card merchant than how it works today
... is the difference that there is less friction?

AdamR: Furthermore it's potentially automated.

IJ: question is whether to give users a slights head-up given ease of transaction

AdamR: Also notice that other payment methods will reduce traceability

<manu> For those that haven't seen this - it's really interesting/scary: https://panopticlick.eff.org/

Nick: Note that in EMV tokens are persistent
... the token PAN is the same (e.g., from Apple Pay) every time

NickS: The token is the same; what changes is the bit that embeds the amount
... [with apple pay] the token is different across devices, however

<wseltzer> PING note on Fingerprinting Guidance

adrianhb: So is this different enough to mention the tracking risk? If it is, then where we say this we need to say where it's different

nickS: I think this is a reasonable concern. I think the answer is to let the user know they can disable

adamr: I don't think payment request API is the right place

IJ: Should this be in payment app spec?

adrianhb: May not suffice...also makes sense for card payments in payment request

RESOLUTION: Add an issue on the privacy considerations

<scribe> ACTION: Ian to work with AdamR and Jonny on raising an issue about privacy notifications about sharing identifiable information [recorded in http://www.w3.org/2016/07/07-wpwg-minutes.html#action03]

<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., ijacobs, ijmad).

<Zakim> manu, you wanted to focus on more important security issues (that review didn't catch, imho)

<AdrianHB> manu: we need to talk about man in the middle attacks

<AdrianHB> nick: isn't that a payment method specific concern

<AdrianHB> manu: not only. There are aspects of the request which can still be subject to attack

<AdrianHB> nick: how would you secure a basic card payment?

<AdrianHB> manu: a signature on the whole message?

<AdrianHB> ian: talking to webappsec and doing the review is what we are chartered to do. Are there suggestions for other stuff we need to do?

<AdrianHB> manu: we need to talk to experts?

<AdrianHB> ian: this is happening inside member companies. no opposition to soliciting other reviews

danielappelquist: Speaking as a member of the TAG, I think it is valuable to go through this checklist (even if it's not "sufficient" it's "useful")
... I like the report that I'm seeing; it's a good validation of the process

NickTR: Building on what Ian said...we have a roomful of people here..I imagine we all have security counterparts...I would ask the whole group...can you each take away as a challenge some engagement from your security organizations
... I'm happy to sponsor a task force within this WG

<scribe> ACTION: NickTR to try to get a security review organized within Worldpay [recorded in http://www.w3.org/2016/07/07-wpwg-minutes.html#action04]

<trackbot> Created ACTION-21 - Try to get a security review organized within worldpay [on Nick Telford-Reed - due 2016-07-14].

<scribe> ACTION: Huw to try to get a security review within Amex [recorded in http://www.w3.org/2016/07/07-wpwg-minutes.html#action05]

<trackbot> Error finding 'Huw'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.

<scribe> ACTION: Cyril to try to get a security review within BPCE [recorded in http://www.w3.org/2016/07/07-wpwg-minutes.html#action06]

<trackbot> Created ACTION-22 - Try to get a security review within bpce [on Cyril VIGNET - due 2016-07-14].

NickS: I think that security reviews are largely going to be payment method specific.
... it will be beneficial for those with payment methods to consider how they might mitigate security concerns

AdrianHB: I think our priority will be generic payment methods

<Zakim> manu, you wanted to start tracking attacks in "Security" document.

Manu: I would feel much better if the group were to track potential attacks against the API and document those
... for a man-in-the-middle attack in a card payment, here's what we do or don't do
... We need to record the knowledge

<Zakim> AdrianHB, you wanted to propose a wiki page

adrianhb: I am prepared to create a page to track this stuff, and to organize the information by payment method

<ShaneM> assemble the knowledge in a wiki! Maybe at some point publish a Note

<scribe> ACTION: AdrianHB to create a resource that speaks to security topics [recorded in http://www.w3.org/2016/07/07-wpwg-minutes.html#action07]

<trackbot> Error finding 'AdrianHB'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.

UNKNOWN_SPEAKER: the idea is that people will be able to suggest information like "here's the attack surface, here's what we've discussed, here's what we recommend, etc."

wseltzer: I like the thought that I'm hearing going ... thanks to the group for taking on that work

<manu> We did a threat review on http signatures (audit) a while ago - we should at least list these sorts of attacks: https://web-payments.org/specs/source/http-signatures-audit/

wseltzer: as a spec that's dealing with a lot of high-value and privacy sensitive information, it will be important to be able to show that we've taken these issues into account

<wseltzer> https://tools.ietf.org/html/rfc3552

wseltzer: With respect to protocol design, see IETF guidance on security considerations

<manu> IETF Guidelines for Security Considerations: https://www.ietf.org/rfc/rfc3552.txt

3.14 How should this specification work in the context of a user agent’s "incognito" mode?

AdamR: We think the api should work in incognito mode
... but since we've talked about the ability to grant permission to get a 1-click experience
... obviously that has some privacy implications especially in incognito mode
... the recommendation is that the stored information be available but to suggest user confirmation (e.g., that you will be unmasked from incognito mode)

[Review of existing incognito mode]

NickS: Apple Pay - We don't disclose information to the site that payment methods are available when in incognito mode

zkoch: I think the best model we have here is autofill...you still have the information you had, but we don't save NEW information
... I think what NickS says is about third party apps...and I agree we need to think hard about incognito mode

adamR: Sites should not be able to easily know that a user is operating in incognito mode
... there may also be ways to figure out what's going on (e.g., time required for a promise to return)
... we also recommend that the web payment app operates in incognito mode as well
... we recommend that text be brought into the payment request API spec
... in some form

<ShaneM> is there a generic term for "incognito mode" that is used in the W3C specs

(I don't know)

danielappelquist: There is no standard definition of a private browsing mode
... we wonder whether there should be such a definition

<ShaneM> hey wendy - have your groupps define that for us, would you?

3.16 Does this specification have a "Security Considerations" and "Privacy Considerations" section?

AdamR: We think all the docs should have privacy/security considerations sections
... we do call out that the PMI spec should point to the security section of the URI spec
... so we need to augment privacy/security sections of the docs larger

<dka> TAG open issue on private modes: https://github.com/w3ctag/spec-reviews/issues/101 (just FYI)

3.17 Does this specification allow downgrading default security characteristics?

AdamR: We recommend that there be a bit more prose for web app developers that speak to doing things on an HTTPS URL

NickTR: Can I ask that the task force will work on concrete proposals (issues or PRs)

IJ: I would like to set the expectation we'll have suggestions by 4 August

<Zakim> AdrianHB, you wanted to ask about probing in general

adrianhb: I want to raise the point about probing.
... it comes up now and again as a kind of sideline topic
... we often thing of the API as something the site might call once
... but a site might use the API to farm user information
... we might want to note in the page we are starting privacy attacks that might be made through the API
... e.g., submitting payment requests 1 by 1, and the merchant trying things after silent failures to enforce ordering

<nicktr> q

NickTR: We will return to the meeting 8:30am tomorrow

trackbot, start meeting

<trackbot> Meeting: Web Payments Working Group Teleconference