Web Payments WG TPAC Face-to-Face
19 Sep 2016

Introductions, prep

<Ian> [Agenda review]

wseltzer: Great to see everyone here. Reminder about our discussions, which are technical in nature
... see my email to the group today; I wanted to bring to your attention the antitrust and competition guidance from IDPF, the group with whom W3C is working closely on digital publishing:

<http://idpf.org/sites/default/files/corporate-documents/IDPF_Antitrust_Policies.htm>

nicktr: Any agenda change proposals?

[None]

Editor report on payment request API

<zkoch> Presentation from Zach on Payment Request API (Slides)

zkoch: In this session we'll set the stage for where we are at and what the editors want to close
... we have an in-depth session before (and continuing after) lunch
... I"m speaking on behalf of AdrianB and also Roy (present)
... Lots of progress since Feb - closed about 133 issues, about 7 left we want to close at TPAC
... first implementation in the wild this week...Chrome on Android
... we've got public statements from merchants...we are getting feedback that we'll discuss later
... MS Edge is also working on its implementation

AdamR: Mozilla is in the planning phase, implementation schedule not yet known

zkoch: We merged a number of changes recently to align more closely with the Apple API (which we will review)
... high level goal is to leave TPAC with all issues resolved that we need to get to CR
... We will quickly walk through the pull requests from the last 72 hours

Manu: Regarding timing of CR, I think given recent changes we would like an opportunity to review the changes
... I don't see anything marked as "at risk". Are there any at risk features in mind?

IJ: Can we wait until we've seen issues before we do timing?

zkoch: I want to be pragmatic but efficient

nickTR: I think over two days we'll better understand issues and thus timing

max: What is the relationship between PAG and CR?

wseltzer: We do have a PAG underway per the W3C patent policy. Our process is that the groups should continue its work. Patent issues are discussed solely within the PAG. All members represented in the group are welcome to participate in the PAG.
... at the time that we move to Proposed Recommendation we will want to have the PAG concluded

nicktr: Contact Wendy if your organization wants to get involved in the PAG

<Zakim> ShaneM, you wanted to ask about reaching agreement on what "features" are tested for CR

ShaneM: I'd like to sync up on CR and what we expect to test

<wseltzer> [and to be clearer, our goal is to enable the spec to move forward royalty-free]

[On Basic Card]

zkoch: 1 issue and 2 pending PRs merit discussion at TPAC

[Payment Method Identifiers]

zkoch: We've looked at different proposals. I think we have moved closer and closer to consensus.
... I believe we have agreed to leverage short strings (for w3c) and URLs for proprietary payment methods (aka closed payment methods)
... however, I don't think we have full consensus on what the URLs designate
... I think we will need more discussion at a breakout (tomorrow)
... I also have two new proposals based on merchant feedback
... there's been a frequent request from India for a COD payment method spec
... there is a desire to leverage the info collection aspect of the API without the CC data.
... invoice is another payment method also with no input/output
... we'll talk about these as well
... a large number of merchants have raised issues that drive both of these new, simple payment method specs
... So I think we are close and if we are efficient this meeting we can resolve all our issues

max: Regarding PMIs, can we use URLs for closed payment methods?

zkoch: Yes

nicktr: Thanks for the intro

Payment Apps

Payment Apps Update (slides)

<manu> scribe: manu

Ian: We're going to talk a bit about changes to Payment Apps, we may want to dive into a few of the topics here.
... We have a growing number of people in the task force.
... The biggest changes since July...
... In response to suggestions/questions in July - created a whole new section wrt. model and design considerations.
... One way this can be useful is to give people a high-level overview of Payment Apps.
... I'd like us to get this spec to FPWD through a CfC after this meeting. A key consideration that I have is to hear from browser vendors that they're okay with the general direction.
... We've tried to be responsive to generation conversation around trust. Which technology approach should be most interesting for payment apps - it would be good to continue to go down a path where we're on the right path wrt. the browser vendors.
... The design considerations section may or may not survive, it may be useful as a communications piece - it has helped the task force speak the same language, see if we're communicating our intentions clearly.
... AdamR, based on discussions, has contributed detailed spec text wrt. ServiceWorkers - that approach helps address a number of issues wrt. browser-based payment apps. Still open questions wrt. native payment apps.
... Based on security review, we've added security and privacy considerations - still thin, trying to raise issues.
... Shopify asked whether or not we need registration - you need registration when you want persistence, if you want to use an app beyond one use, across many sites. Merchant-recommended payment apps could be used immediately. We observe that registration is not required, but it's useful for persistence (reuse across transactions).
... We have had some discussion where browser may have some services that use payment apps - ordering, won't require certain display order questions, what's good practice - removed a few things, weren't getting any airtime - browser recommended payment apps, that has been removed.
... No one has pushed on that concept.
... That's been removed, but we could come back - here are the main topics wrt. that list of changes.
... We want to get through Service workers, PMIs/Payment Apps, UX harmonization, protocol questions, and native payment apps.
... With browser folks in mind, systematic view of UX so we can make them useful and consistent in the future.
... Focus for last few months has been working on browser payment apps - what about native apps? Should we say something, nothing? Any other topics or concerns?

NickTR: You said it would be useful to get feedback from browser vendors - what's the best process to get you guys comfortable with this stuff?
... I think this may be the biggest next step for the group.

Zach: I haven't had the opportunity to deeply understand the proposal, just need a high-level intro and then deep dive.
... Whatever the open questions - manifest is a sticking point, would be good to understand what the sticking points are.

AdamR: I'm okay with the spec so far, working closely working w/ Firefox folks designing feature.

NickS: Like Zach, we haven't had a chance to review the proposal yet.

Ian: I hear a request to go through at a high-level.

AdamR: Can we get an overview of service workers from Jake.

Ian: I'd like to give a higher level overview first. The idea is sketched out in the design considerations.
... The flow that we have in mind starts with the assumption in the architecture that by moving to the notion of a payment method to abstract away software from data.
... First assumption, for closed payment methods, the payment method owner gets to say who gets to implement the payment method. How do you ensure they're the ones that get to say who gets to use it. We may need digital signatures on payment apps to make sure they're the right payment apps. We haven't talked about Payment Apps.
... The expectation is that we'll see more open payment methods than closed ones. This advantages the merchant.
... What's the right balance wrt. what they're willing to hand off and what they want to control.
... One of the ways we want to give the merchant some control - what's a recommended payment app from the perspective of a merchant?
... The merchant might get to say what payment apps they recommend. With respect to user experience, how should that be ordered? This is some way the merchant can get back some control over the experience?

NickTR: This idea of merchants having some control is important to some merchants. It's good that we're considering this as an approach, it's only going to be a hint for the implementers.

Manu: We don't have enough merchants in the room. We need to get data from them.

NickTR: It would be good to have more merchants in the group, it would be great to have their voices in the room.
... On a weekly basis, they want fine grained control over what they do and don't accept.
... Merchants want control over this process, there is a balance to be struck. Merchants are taking the credit risk, they want a degree of control, that they are balancing those risks.

Max: I agree with NickTRs comments, as a merchant we want some control of payment apps that are displayed.

<Ian> Max: Alibaba is a merchant; we'd like to have at least some control over ordering

Max: If the merchant wants to take full control, there is a problem - coldstart
... If people want our W3C standard to be used, we want to provide motivation for the merchant - why are they using the API? We need more opinions from merchant.

David: I want to second what my colleagues said - I represent NACS - what NickTR said, it's very difficult to get merchants to tell you what they want until you give them something you don't want. Getting them to tell you what they want is a challenge.

DavidE: I don't know what the strategy that the right level of involvement is - they are mostly not interested in this level of the work. That doesn't mean their input isn't important.

Manu: To clarify, I said we don't have "many" merchants in the group. :)

<Ian> zkoch: I think we have to trust orgs that work closely with merchants to feed back info

<Ian> ...I think we have to trust that we will be effective proxies

<nicks> I hear Apple has a small online retail presence as well

<Ian> zkoch:...merchant checkout flows are public...you can see what people do, how they rank methods, etc.

<Ian> ...you can get a pretty comprehensive picture of how merchants think about things

<Ian> ...this informs how we prioritize things...we look at real-world scenarios

zkoch: There is a data driven approach - you can look at the top merchants and their checkout flows and see how they prioritize things.

<Ian> ...+1 to Max's observation that we need to drive adoption by offering value in exchange for handing off some control

<Ian> zkoch: I have not seen the concept of a "recommended payment app" in my merchant conversations.

<Ian> ...+1 to registration not being a requirement for all use cases

<Ian> ...I think your proposal addresses this

zkoch: If we can't drive conversions at the end of the day, this isn't going to catch on. I haven't seen a request for recommended payment apps - registration is no longer necessarily a requirement. There is concern from merchants, what if the user doesn't have PayPal registered? That use case has come front and center.

<Ian> ...one requirement is "If I support it I want you to list it"

Ian: One of the UI questions wrt. experience - what the merchant wants you to see vs. ordering.

<zkoch> nicks: sorry, never heard of “apple”.

Ian: A general statement is - gathering preference information from merchants and users and giving it to browsers so they do the right thing.

<Zakim> adamR, you wanted to ask about use cases

adamR: I think we have 3 uses cases (missed) and tease them apart to see what merchants want.

<marta> I have huge concern about the clarity and usability of such approach - it will be very hard to build something that is not forcing user to use the "merchant recommended" app. It starts opening door to full control over what user can use.

Ian: The flow... merchants may recommend apps - user has said I have these apps.

<zkoch> marta, can you clarify which approach you’re referring to?

Ian: When browser computes intersection - there are apps that are displayed. What happens in push payment world - network failure, how do we deal with that?
... I registered my payment app, I've updated software - browser doesn't support four additional payment methods. There may be one thing that solves these problems - Service Workers.
... We have Jake Archibald here with us today to talk about Service Workers. You can make security guarantees wrt. service workers, who has access, who can update.

<dezell> Wanted to say - yes, it seems obvious from where I am that Merchants Want this Control. They spend $$$$ with lots of companies to customize the payment experience for their customers. This customization drives a tremendous amount of software development today, hence why I think it's obvious.

JakeA: A service worker is just a javascript context - somewhere you can execute javascript when you don't have an open window. It's a worker, so it doesn't have access to the DOM

<marta> instead of a great solution where users can choose his preferred app, which gives him control over his payment methods and so on, now we add the possibility of merchant saying "oh no, you should use these ones that I chose for you". I know that they are only "recommended" for now but potentially it could go sideways

JakeA: It has its own update system, wrt. push messaging - you get origin, javascript runs in background, asks for push-registration details.

JakeA: You send that to your server - send a push message that would send you those details - that would land on phone, OS would spin up browser and service worker, push event is in hands of developer who can decide what to do.
... The way this could work wrt. payment provider, you are on foo.com but you want to use bar.com - if user has service worker for bar.com, on foo.com it could fire bar.com service worker sending it details of payment.
... You may want to open a window where you want extra details from user. Having this in the service worker you get the lifecycle for free, if you are a payment provider and only support visa, and you have 500 users, and you add mastercard, you can send out a push event to update what you support.

<Ian> Jake: Push notification gives you ability to update payment apps that have been distributed

JakeA: We're thinking of launching foreign fetch - fetch is used to get resources for your page, origin gets to control all pages. With foreign fetch, other origin gets to pick and have final say in what happens. Remote installation of a service worker, for example.
... User may never go to that origin - remote installation of service worker - sounds similar to preferred payment app provider thing. If I want you to have paypal installed, it might be the same mechanism for paypal.

<Ian> zkoch: Yes, we need a way to remotely install payment apps

zkoch: I think you answered my question - we may not want to enforce registration - we might need some mechanism like this, a way to install something.

<Ian> JakeA: Can do via header today

JakeA: The bit we are missing - where I can ask for something to happen, don't have an API for that yet.

zkoch: Can you support this today via a hack?

JakeA: You can poll.

AdrianHB: Why do you need this today?

AdamR: There are security guarantees that you need.

<crestxu> I think the browser can recommend the users' last payment apps, but also can give some control to the merchants, In china the merchants always have cooperation with the payment apps, like use WeChat payment 9.5 discount or something else,

<Ian> zkoch: UX challenge here (cf web indents....we should learn from that )

zkoch: This isn't necessarily about service worker - we have a UX challenge here, maybe we can learn something w/ web intents - hasn't been successful for a variety of reasons.

Ian: The browser folks have a lot of experience with external apps, plugins or failed web intents - getting the user experience right are hard.

<Ian> jake: Low-end devices can be a challenge (not much memory)

<Ian> ...for launching windows

JakeA: On low memory devices you can run the risk where the browser is thrown out of memory if you try to update asynchronously.

<Ian> JakeA: Service worker uses less memory so that can help

Max: What is the intended status of this proposal?

JakeA: It's a working draft now, we're hoping to get to CR this year.

<ShaneM> http://caniuse.com/#search=service

Max: How is our work based on Service Worker?

Ian: We're not at FPWD yet, if the group concludes that we want Service Worker, then we may be able to apply pressure so they can get stuff done.

AdamR: Push notifications are a big thing, they're going to push it faster.

Max: wrt. dependency on Service Worker - seems like an implementation detail

AdrianHB: It's the one implementation detail that we can depend on.
... We can't standardize how Android can do this - how do we bring in the idea of origins for native apps
... We don't want to close the gate on browser-based payment apps,

Ian: Earlier, we had talked about a different approach - HTTP POST-based, not service worker based.
... There is a benefit to doing it one way that uses another web standard, so people know when registering, what to provide.
... We may force people to invent this again and again - let's see if AdamR's proposal captures the right level of requirement. If we said nothing, we'd punt on the whole problem. Questions about registration/security - this solves multiple problems for us
... It's one implementation choice, without it though, no one would do it.

<Zakim> ShaneM, you wanted to ask about service worker support

<adamR> ShaneM: https://jakearchibald.github.io/isserviceworkerready/

ShaneM: I agree that it would be great to give guidance to implementers, service workers solve problems, multiple implementations could get through CR. That's great, but if it's not on every popular platform, there is still a problem

Ian: I'm willing to wait six months to find out.
... We may need to hold spec
... until Service Workers goes a bit further.
... You get a number of things addressed for free.
... With that, just want to touch on a couple of other topics...
... We've had a number of requests - identity needs - maybe there isn't agreement on what it takes to identify a payment method. When you dereference them, you get some data back on how payment method lives in the ecosystem. That may be all we have to say.
... Separately we want to refer to payment apps, we need to be able to identify payment - separately, associate data with payment apps - this payment app supports this payment methods.
... We have a need to identify payment methods. Same URL to identify payment method/app - at conceptual level, we want to talk about payment apps, and payment methods - where do I put data associated with each one. Stuff associated with payment apps, stuff associated with payment methods. These are the sorts of questions we're going over.

<ShaneM> I note that you can solve any problem by adding a layer of abstraction. But you still need to map the abstraction to something.

Ian: We're just going to tell you what data you need to know - we need identifier for app, and data associated with the app - maybe you get it from the web, maybe you have it cached, touching on this briefly.

<JakeA> manu: ideally native payment apps would be instead of a service worker, so the spec will still be useful for UAs that don't have service worker yet

Ian: UX harmonization - see table - there are a variety of things we want to do.

Ian goes over a few use cases.

Ian: In each case, you can see what the outcome should be in the last row.

AdamR: In working through implications of what to put up wrt. UX - I found an issue.

Ian: Yes, so if you go down the table, you can see all of the predicted outcomes.

<adamR> To put meat on that issue — service workers (and code in general) are prevented from popping windows without user interaction. We need to make sure that “launch payment app automatically” isn’t an end-run around this requirement.

Ian: We haven't really studied this table yet and hammered everything out, but it's there as a guide.

<JakeA> adamR: we could decide that the payment event is an interaction event

<ShaneM> I would like to do a detailed review

<JakeA> It is from the user's point of view anyway

Ian: We should try to publish a FPWD the document - maybe we should get review before we do a CfC?

<adamR> JakeA: That’s what my text says now.

<JakeA> \o/

<JakeA> adamR: I should probably read it and answer my own questions

zkoch: What's the timeline for the review?

<adamR> JakeA: But since a web page can call the API without user interaction, popping a window without interaction would enable a potential flow for non-interaction-triggered window opening.

<JakeA> adamR: I thought the user would have to select which payment app they want to use from a menu?

Ian: By 6th of October, we can have people weigh in... that's a concrete proposal.

<JakeA> I guess if there's only one choice the flow may be different

<Ian> ACTION: Max, Zach, Shane will review the payment apps spec by 6 Oct with an eye toward giving a thumbs up to go to CFC for FPWD [recorded in http://www.w3.org/2016/09/19-wpwg-minutes.html#action01]

<adamR> JakeA: yep, that’s exactly the situation I’m commenting on.

<Ian> [IJ reiterates - review by all is WELCOME!]

<adamR> JakeA: It’s solvable, we just need to make sure it’s solved before we call it done. :)

Implementation experience

<Ian> [Led by Rouslan]

<Ian> scribe: Ian

Rouslan: We'll lead with a Chrome demo (for mobile)

{rouslan opens Chrome beta}

rouslan: We've written a number of developer examples that we will be using
... We have implemented ability to query payment request for credit cards.

[shows click on buy button]

rouslan: UI shows icon, name, and origin of the merchant site
... the view shows summary, what it's for etc.
... demo shows addition of a credit card

[...took about 4 seconds to add :) ]

scribe: when user picks a card to pay with, there is a prompt to enter a CVV
... chrome prompts user to save credit card information whenever the user has entered it on a site
... but chrome does not (per payment method rule) save the CVV

[Demo shows the JSON blob received by the web site]

rouslan: so this is how we envision card payments...now we look at android pay

[Android pay example]

[Demo shows android pay info passed to web site]

Rouslan: The data you get back is what you would expect from Android Pay
... The data is the same in payment request API (but the format is slightly different)

zkoch: We will send you the URL to you so you can test your implementations
... there are other examples with shipping addresses, contact info, etc.

Zach: See the integration guide; demos are linked from there.

zkoch: We have been exploring third party payment app support from Chrome. We have been working with Alipay to experiment

[Demo on use of Alipay]

Max: Before the Demo, I'd like to share a draft
... In the demo Rouslan just showed, we need to ensure that the payment app is the payment app I expect

Max: Here are some use cases we want to prevent against:

- how to avoid user being fooled into choosing a fake app

- how to ensure that the selected app is the one that the user expects

Max: We also need to take into account native apps - no origins associated with native apps

Restating problem statements from the spec:

Problem 1: The payment app should be the one as it claims to be.

Problem 2: How to prevent fake/malicious payment app to do malicious things, for example, phishing etc.

Max: To address problem 2 we propose using a digital signature

Max: this signature is available on the payment service provider's web site
... that helps to ensure the signature's validity
... we propose to document this mechanism in our specification.

[Back to the demo]

[Demo shows buy button on a merchant site]

scribe: when the user clicks the buy button, there's a selection box rendered by Chrome
... Alipay payment method is available through a native payment app
... [demo has user click confirm button]
... the next page that shows up is the Alipay payment app, which has a "Confirm" button
... then Alipay app takes over authentication
... and then the payment response goes back to the merchant
... [Next demo shows a different authentication method by the payment app]
... [user does not enter password; uses a watch for auth]

Max: We also have some different user experiences we could show: sound wave, QR code, fingerprint, smart bracelet,

[sound wave example....frequency may not be audible to the user...sensor is just a microphone]

Max: User does not need NFC chip to do the sound wave payments
... More than 1M merchants use QR code payments from Alibaba

[Smart watch demo shows generation of bar code on watch face to do payment]

Q. Is the bar code unique to each transaction?

Max: Yes

<Zakim> adamR, you wanted to ask about how payment-app-provided signature file solves phishing attack described in first use case

adamR: Regarding the phishing use case...how does the proposed mechanism with signature mitigate the phishing concern?

Max: the logic behind that is that the payment service provider controls the URL of the payment server web site
... We could use certificates as well ... to avoid phishing

AdamR: I'm not sure that certs help that much...I think the proposal works for native cases, but for Web-based apps we may need other mechanisms than what is proposed

Max: I think that origins of payment method identifiers can help for web-based cases

AdamR: Yes, we have been talking about payment method manifests including origins for authorizing other origins to provide payment apps
... I think that for open payment methods and web-based apps we need something beyond origins and signatures

AdrianHB: This is a useful way (Max's proposal) for solving the native case
... I think native payment apps could also use origins...

<zkoch> Propose to punt on this discussion for breakout or later, to get through other demos before 12:30

<adamR> +1 to zkoch

AdrianHB: There is also the question of whose origin we are talking about

<Zakim> AdrianHB, you wanted to clarify the requirement

AdrianHB: There are three categories (1) Open without a manifest (2) Proprietary open (with manifest) (3) Proprietary closed

Mountie: Is Alipay a payment app or method or both/

<zkoch> Btw, any one can demo PaymentRequest in Chrome at: https://googlechrome.github.io/samples/paymentrequest/

Max: In the demo, Alipay is a payment app

<zkoch> It’s in Chrome 53, which should be in stable soon (this week). Otherwise, you can download Chrome Beta from the Play Store

Mountie: Did you try QR code with payment request API?

Max: That's independent of payment request API

AdrianHB: Right, web auth and other specs are relevant here (but not about payment request API)

Max: We'll have more demos on Friday from other Chinese vendors

[Samsung demo]

Dongwoo: We'll demo "Samsung Internet"
... Samsung Internet is based on Chromium engine with a Samsung UI
... pre-installed browser on most Galaxy devices
... user base is growing
... version that I'll show is based on Chromium M51
... we are syncing with Chromium and also contributing (with Rouslan)
... we also want to figure out how to leverage Samsung hardware (e.g., for biometric auth)

[Demo shows selection of grassfed biltong]

[Demo shows check out button]

scribe: our UI shows details, etc.
... select an address from the address book
... you see total price changes based on shipping address
... then you choose a payment method (here a credit card)
... and click pay
... you enter a cvv code

Dongwoo: We worked with Shopify on the demo; got some changes made
... here is what we found:

1) It is better to make some items optional in payment request (e.g., billing address, CVC)

scribe: so the user is not required to enter billing address or CVC)

2) There should be ability to indicate reason for failure modes(e.g., address validation has failed, param validation has failed)

Dongwoo: Our desire is to release this browser in Q4 2016

<nick> i thought we’d already agreed CVC was optional…

Dongwoo: we are still exploring UX improvements

Mahesh: We don't yet have a Samsung Pay demo
... we will take more about Samsung pay payment method spec in upcoming session

Mahesh: We have some concerns about adoption and it would be good to have more open payment method specs

<Zakim> nicktr, you wanted to ask about payment app

NickTR: In the demo we just saw ... was there a Samsung payment app?

Mahesh: No, that was all in-browser

roy: You have Samsung as a proprietary payment method that supports tokenization...see our draft tokenization payment method spec.

MaheshK: We'd like to implement the generalized token spec (when there is one)

Mahesh: The concern about fragmentation is about payment methods...would like to see more "open" specs that, like basic card, abstract someone to make life easier for developers

<Zakim> manu, you wanted to ask about fragmentation specifically, what's the proposed change? Or is it just a concern?

<Zakim> AdrianHB, you wanted to talk about gateway token standard

AdrianHB: It's valuable to align specs to make development easier, but ultimately you can't get around merchant agreements with specific issuers
... I think the best value we can get is standardizing on a format.

IJ: How is it going on the Apple front?

Tess: AdrianB recently made some edits that align a few feature with the Apple API; they look good
... I think the remaining difference with the W3C API is merchant validation
... merchant validation is an Apple Pay requirement (that is not part of payment request API)
... it may not make sense in the context of payment request API and can be done out of band
... I don't think it should be a requirement for V1 of payment request API

zkoch: AdrianB and I compared payment request and Apple Pay...we added some bits to get alignment
... I think there are still some other additional
... eg. "required shipping address"
... +1 that merchant validation can happen out of band (Android pay does similar thing out of band)
... It would be great for Apple folks to look at changes and make sure we did them right

[Results of early testing]

Shane: I have done no testing yet. Mike5 has.

Mike5: When we start writing test cases we generally find that implementations do something ... I have filed some bugs in Chrome that Rouslan has been responsive to.
... there are other scenarios where I am filing bugs on the spec (e.g., spec does not say enough)
... but there have been limited testing capabilities due to the nature of this API
... we are testing the payment request API constructor
... what we really want to have soon is a way to have a mock payment service that is available cross platform
... the grand goal for the test suite would involve a cross platform payment service
... but so far there have been no big surprises..I think the spec is in good shape in that regard

Rouslan: Do you mean payment app or payment service?

Shane: It has been pointed out that payment request API does not require payment apps
... so I think that we need some known payment methods

AdrianHB: So, practically, you want to call the API with a made-up payment method identifier? Or with basic-card?

IJ: I suggest that testers + Rouslan put heads together and discuss "common server" idea at session tomorrow.

Shane: Higher-order comment on specifications wrt testability...requirements on users/usage not testable ... ok to say those things but what is the user agent behavior in different cases?

[General question to implementers]

AdrianHB: Any other comments people want to make?

Rouslan: The API is changing fast from an engineering perspective. Thanks for taking our feedback into account and changing the API
... thanks to Samsung with whom we are working; they are helping us with updates
... I agree with the testing folks that we could use more clarity on error throwing.
... so +1 to being explicit on error handling

AdrianHB: How are you tracking feedback?

Rouslan: Testers are finding issues and logging bugs on chrome or against the specs

<Zakim> Mike, you wanted to ask about flexiblity for Chrome/Blink to make any changes if spec needs to change after shipping

Mike5: I think that you are shipping Chrome 53 now enabled
... How much flexibility do you have if there are significant API changes?

Rouslan: We are providing a shim to merchants that pledge to not break in the face of API changes for 2 releases

zkoch: there are a variety of forces at play to give enough confidence that we'll support, at same time as we need to make changes
... So far our changes have been additive except for the basic card spec filters
... but if there were some glaring issue that were to emerge we would be open to the conversation about changes

manu: We've had some implementers at Digital Bazaar read the spec...we have around 30 bits and pieces ... e.g., if an error were thrown would they know what was going on?
... most issues have been small. I think the biggest implementation feedback topic is that the spec is complex...there are many types of errors that could be thrown
... the other bit is "the amount of stuff than can go wrong"
... we can convert these observations into specific spec feedback

IJ: My preference would be to resolve Zach's known issues then add new ones

Key issues for payment request API

zkoch: I'm going to run quickly through main changes
... Some changes were based on WG consensus (reached over last few weeks), others based on experience, others based on Apple convergence
... Treat the situation of duplicate shipping options as equivalent of no supported options
... there are really two options here (1) throw and fail; but that's abrupt (2) what we have - ignore

Shane: Is there a way for the merchant to know that there were zero shipping options?

zkoch: No.

Manu: Another approach is "last one wins"

zkoch: I will file a new issue with some proposals
... Another webidl spec to make our interfaces serializable
... this is a small webidl change
... We added timeout support. We have a problem in payment request API ... we don't want to be stuck in an endless spinner state
... so we allow implementations (optionally) to include a timeout. E.g., chrome does 60-second timeout
... so this is not requirement on browsers but allows them to implement timeout

nickTR: Note that "time away from browser" may increase significantly for third party payment apps

zkoch: The ones we are thinking of are about "updateWith" ....
... timeouts are to prevent blocking when waiting
... there would not be a timeout involved with handing control to a third party payment app
... Regarding careOf we did what the group asked (removed field; added note on multiline)
... We added a custom error field. This was #1 merchant request - clarity on errors that are occurring
... e.g,. can't ship to PO boxes, or "we can ship but there's a surcharge"
... First we thought about enumerating failures, but after conversation with merchants we concluded very broad, so now we support error message input from merchant
... our intent is that it's associated with ERRORS not meant to be a general purpose information field

AdrianHB: What about user experience of highlighting where the error occurs?

zkoch: We decided not to do per-field errors since (1) it's complicated ....
... (2) errors we expect to cover here are not field specific
... implementers can do the right thing to validate address input

Manu: So error message will be displayed?

zkoch: We'll make more explicit that it will be displayed

Manu: Are thrown errors shown in UI...spec is not clear on that

zkoch: We'll look to clarify in the text
... Another change - allow same PMI for same type (this for filtering)

<adrianba> For the error message, the spec says "the user agent should update the user interface to display the error message contained in error."

IJ: Restating - allows you to say "or" between different card options (filtering)

zkoch: Another change has to do with filtering criteria...in the instance where there's a duplicate filter, we take the first one that matches

<adrianba> for the places where an error is thrown and a user agent may display an error, the spec says "User agents might show an error message to the user when this occurs. "

zkoch: so this implies that the developer needs to put the most specific matches first..the burden is on them

Manu: Feedback we have on this - this forces developer to know how the algorithm executes.
... we think that it is complex.

zkoch: This is an advanced use case. I don't think for many use cases this level of understanding will be important
... we think that this filtering scenario exists but is an edge case
... if you want to be in this complex state, there is a mechanism to do so.

IJ: The spec is designed so that the easy case is easy
... I don't object to marking it a CR based on adoption, but I don't think CR it targeted at usage..it's more about implementability (by browsers)

zkoch: Another issue we added an attribute iframe to enable an embedder to authorize payment request to iframe

adamR: I hate to do exactly what someone else is doing ("feature policy") with another syntax

zkoch: I am sympathetic to that, but this is such a blocker

AdamR: Is there something we can define here that is forward compatible?

zkoch: I think that's the general idea

shane: I think "sandbox" would work

zkoch: Sandbox attribute is the opposite
... by default it says "remove all capabilities from this iframe and you can add them back"
... but that would be complex for developers....
... we want the opposite of sandbox

ShaneM: Ok

AdamR: I'd like us to be clear that this is a bandage and see to what extent we can future-proof it.

zkoch: I will ask Mike West how to solve our immediate needs and align with feature policy
... We also made 3 changes to align with Apple Pay

1) parameter to change UI so that you can say "deliver to" (for a pizza) instead of "Ship to"

Sam: You have a different set of values...why?

zkoch: "Store pickup" ...do you allow an address for the store?

NickS: In English "pick up" means both "in store" or "at the curb"
... "Service pickup" is for something like "pick me up in the taxi"
... where as "in-store" was "pick a thing up in a store"

zkoch, : Another new field for alignment is PayerName

scribe: we also added "pending"..I think the use case is to indicate to user that some piece of information is forthcoming (e.g., "I will be back to ask you, the user, for shipping address")

zkoch: Any objections to these? These are small UI tweaks.
... another use case is travel - I'm booking an hotel...I need to know your name but not your shipping address

Resume after lunch.

zkoch: We're going to walk through key issues around payment request API

224 Push payments -> https://github.com/w3c/browser-payment-api/issues/224

[IJ notes we have a breakout imagined tomorrow]

zkoch: We'll skip 224 since in breakout tomorrow

Issue 228 -> https://github.com/w3c/browser-payment-api/issues/228

and 229

zkoch: General point I understand from Adam is whether to add guidance around user consent
... Question is the degree to which we discuss consent good practice

AdamR: The suggestion is "get consent" not "how to get consent"

zkoch: It's a complex issue; we have examples in the past of not doing this well

IJ: How far can we go given variety of consent scenarios?
... in some cases consent is contractual (e.g., car pickup service)
... on other cases consent may be per transaction...

AdamR: I don't think we should punt completely...and I agree this may be a w3c-wide information

<adrianba> we say "The user agent should never share information about the user to the web page (such as the shipping address) without user consent. "

zkoch: I think it's a product and company level decision about consent (temporal v. persistent, for example)

<adrianba> and we explicitly don't define user consent - which I think is best

<Zakim> manu, you wanted to say we should write /something/ in the spec about this, and I'm confident we can be vague where necessary - this is non-normative text.

zkoch: so from an editor perspective we think that the existing language is strong enough, while also allowing others flexibility.

<nicktr> +1 to Manu - we should explain the exposure

IJ: I volunteer to share the group's thinking to augment the current statement; I like Manu's characterization of "saying what the WG was thinking"

AdamR: That is likely suffice but I'd like to see the text.

Mountie: There are different types of consent needs (strong auth, for example)
... What is different here is that payment information belongs to users...without strong authorization from users it can violate user thinking.

<adamR> Ian: https://w3c.github.io/mediacapture-main/getusermedia.html#privacy-and-security-considerations

<adamR> Ian: To be clear, I think *that* is a reasonable treatment of this kind of issue.

ack AdrianHB: One of the points raised in the issue - we should make even clearer that some information can be used to track users across origins

zkoch: I don't think we need to be explicit about this...this is already true when people submit forms today
... we don't want to leak information without user consent. ... we don't need to say what potential misuse there could be ...it's common enough that we don't need to add that.

<scribe> ACTION: Ian to clarify the language around consent (to say more about WG thinking) for security and privacy considerations [recorded in http://www.w3.org/2016/09/19-wpwg-minutes.html#action02]

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

AdamR: Please see the get user media spec for an example

<nicktr> +1 to adamr's pointer to mediacapture spec

https://github.com/w3c/browser-payment-api/issues/237

zkoch: Right now there are no "retry" capabilities of the API
... this issue raised the question about whether a "reshow" option should be available
... we propose here to not make changes at this time,
... and let merchants address flow for the many reasons that can go wrong (e.g., wrong cvv, etc.)
... through progressive enhancement, merchants can handle this today
... once we get feedback, we can consider augmenting the UI.
... and for example "retry" could just be a button that recalls the API

adrianhb: As a merchant, I don't know whether the user has more cards...I think that there would be a lot more we would have to do to support this; I am +1 to not adding this feature now....
... though we may find in the future we want to support this

<adrianba> also, 237 calls for excluding an instrument on failure, which I don't think we can ever do

<Zakim> AdrianHB, you wanted to say there is granularity here that we can't support easily

<AdrianHB> PROPOSAL: Push issue #237 to future version

nicktr: Strong +1 to not include this in v1
... don't want to prevent someone from using a instrument from the same issuer

<manu> +1

+1 to the proposal to postpone

<nicktr> +1

<adrianba> my proposal is to close 237 and then to push retry to a future version - happy to open a new postponed issue for that

<MattS> +1

<adamR> +1 to postpone

<rouslan> +1

<JakeA> +1

<ShaneM> +1

<MattPi> +1

<dezell> +1 to postpone

<jyrossi> +1

<bensmith> _+1

<Roy> +1

<pascal_bazin> +1

<MaheshK> +1

RESOLUTION: close 237 with no change to the spec..postpone issue to later

<nicktr> https://github.com/w3c/browser-payment-api/issues/247

zkoch: Two use cases:

1) If you call payment request, is a given payment method available?

zkoch: We think this use case is fundamentally supported by the API

2) A merchant wants to know whether a particular payment method is available (e.g., to be able to show a specific button)

scribe: or a merchant has an agreement with bobpay and the merchant only wants to show bobpay if the user has support for it.
... the challenge that we've had is what mechanism will not leak information to arbitrary merchants
... we'd like in some sense to support it but we don't know how to do so without leaking information.
... so we recommend that for V1 we do not have a mechanism to determine whether a SPECIFIC method is supported.
... for "SOME" payment method, show() returning false suffices

JakeA: Does show() leak information?

zkoch: What stops that risk is that show() creates a user experience
... so there is a blocking UI

nickS: Also, show needs a user action to trigger, doesn't it?

zkoch: Show does not require user action right now in the spec

rouslan: That could be added

<manu> Ian: Two comments

<JakeA> apologies I'll use the queue rather than butting in

<manu> Ian: Some of this feels like it bumps up into the land of payment apps

<adrianba> I'm generally against adding user action as a requirement if we can avoid it but happy to add an informative suggestion

<adrianba> we could also add a suggestion about rate limiting

<AdrianHB> adrianba - Logged an issue: https://github.com/w3c/browser-payment-api/issues/283

<manu> Ian: Does the user have payment app X? That's one way to do that. One way to feel more relaxed about this is the payment app approach gives merchants a bit more say. We haven't gotten into that in detail.

<AdrianHB> +1 about rate limiting

<manu> Ian: The merchant is telling the browser something - even though we haven't figured out how it's supposed to work, it takes pressure off of payment request api to give merchants information.

IJ: I think that payment apps get you part way (through recommended payment apps)...that has not yet been entirely figured out in the payment app task force, but it would take some pressure off of payment request API

zkoch: Yes, recommended payment apps could get you part way, but it doesn't get you the device bound payment method detection

AdrianHB: Do you anticipate a mechanism to limit information hunting by merchants (e.g., rate limitation)?

nickTR: I think there's no way to stop the merchant from seeking support one by one

<Zakim> AdrianHB, you wanted to ask implementers how they will protect against repeat requests

AdrianHB: Unless you rate limit, for example after multiple tries
... There are two goals (1) control over payment methods (2) farming information

AdamR: First one does not seem like a privacy violation.

zkoch: Yes, I think 1-by-1 calls can be legitimate
... e.g., valid use case to test a proprietary support first then fall back to web-based api

<Zakim> MaheshK, you wanted to comment on merchant feedback

MaheshK: Merchants would like in some cases to take user through their traditional flow if a payment app is not supported.

zkoch: You can use the API with fallback mechanisms...suppose you want to use payment request API for proprietary mechanisms and fall back to forms if you want
... It's a merchant decision whether or not to show specific payment method buttons
... or a single buy button
... We have to make a decision here - current Api does not allow you to test payment method support in order to NOT show a button
... so v1 proposal is to err on site of user privacy
... and we can circle back after some additional merchant feedback

PROPOSED: Close #247 with no changes to the spec

AdamR: I think that's right
... You can't put the genie back in the bottle.

<Zakim> nicktr, you wanted to ask about multiple i-frames

nick: I agree merchants want this. Problem is that nobody has a proposal on the table that stops a site from knowing what payment instruments you have....this is tricky for privacy, user profiling, etc.
... the way it works on apple pay...is that we have a database that we maintain; but that's not an option here.

Mahesh: What if Samsung pay knows about a web site, and if Samsung pay says "I trust the site" then some information could be sent back to the site?

zkoch: I suggest that we stick with "show or throw" for v1...I acknowledge that we probably want this and it requires more thought (e.g., dual authentication)
... so let's keep up the conversation and think about ways we might address this (but not for v1)

AdamR: I especially like the native app approach...(from Mahesh)

AdrianHB: There are other approaches people are trying out in some CGs to find out whether people have something installed...so this problem is not unique to payments

nicktr: Now that we are supporting iframes...with different payment requests in them...what would behavior be if I have 6 iframes in my page
... suppose each one is used with a single payment method

<bensmith> ben agrees with proposal to show/throw for V1. also happy to work with Mahesh on proposal

AdrianHB: You can create the same scenario without iframes today

zkoch: My hunch wrt Nick's question is "first one is shown"

<Zakim> AdrianHB, you wanted to ask if we allow app publishers to detect their own app

AdrianHB: Do you think it's fair for an app publisher to detect if their app is shown

IJ: I want to punt that to app task force

<manu> Ian: There is a proposal on the table - no change for the v1 spec. Mahesh will work on the problem, but not for version 1.

<manu> MaheshK: I still think we should take a look at this for v1.

<manu> NickS: If there is not a way to solve the privacy question, there will be a rejection from ad networks..

<manu> Zach: Can we close this issue, but assign an action to Mahesh?

<manu> Ian: /me thx ShaneM

<manu> NickTR: I'm hearing Mahesh say he wants v1, I'm hearing other people say they don't want it for v1.

<ShaneM> thank you

IJ: I am hearing (1) soft expectation that we not change the spec for v1 but (2) Mahesh will work on this and if there's a proposal with very strong support then it can be considered

zkoch: Another thing we could do is time-box the proposal

<bensmith> +1 to Ian proposal

zkoch: It sounds like it's important and I think it's reasonable to time box a proposal (e.g., 2 weeks from now to see a proposal and a decision within 2 weeks of that)

<Zakim> Ian, you wanted to ask for clarification

RESOLUTION: We will time box a proposal to handle merchant query for specific payment methods to 2 weeks from now (+2 weeks for decision) otherwise spec will not have this feature in V1

<scribe> ACTION: MaheshK to work with Ben Smith on a proposal to handle merchant query for specific payment methods [recorded in http://www.w3.org/2016/09/19-wpwg-minutes.html#action03]

https://github.com/w3c/browser-payment-api/pull/177

zkoch: I don't think these are useful diagrams; hard to digest. I think we should revisit explaining flows in simpler diagrams.
... I don't think these things add a lot of value ...my preference is to not have in this spec....and instead have a high-level explainer

<Zakim> manu, you wanted to note that we shouldn't use a complex diagram, but a simple one.

Manu: I agree that this specific diagram may not be helpful, but having SOME issues could be helpful.
... I hesitate to put it in a separate document....some feedback we've gotten on the spec is that "it jumps right into it"
... I've heard two schools of thought at W3C (1) separate explainer docs (2) in same spec, some friendly front matter
... so I think the payment request API spec starts out "too strong" and would be helpful to have simple diagram and nice intro

<Zakim> AdrianHB, you wanted to ask about audience

AdrianHB: IMO the audience for this spec is people implementing the API not people using it
... I don't think the diagram adds value to browser implementers
... I think an explainer spec is sufficient
... I don't think we need to mix material for implementers with material for developers

dezell: I have actually used the diagram

AdrianHB: But if you had an explainer would you use it?

dezell: Yes

AdrianHB: Note also that this diagram has features that are not addressed in payment request API (e.g., payment apps)

<Zakim> Ian, you wanted to talk about audience and good practice doc

<manu> Ian: We have new resources coming up - payment method spec guidance

<manu> Ian: There is a growing sense that also helping payment app specs is helpful

<manu> Ian: The next one is payment app guidance

<manu> Ian: Other items like the the chrome developer docs are helpful, can we use some material from there? One proposal for handling this is to pull away from payment request into a document we need anyway. If you have starter material, that may not be as hard to do. Drop the diagram and start a payment request API good practice

<manu> Zach: Move it to more developer focused thing to implementer focused.

<nicktr> I think diagrams are always useful but I think it depends on the particular learning style of the reader . Here's an example from worldpay tech doc: -> http://support.worldpay.com/support/kb/bg/htmlredirect/htmlredirect.htm#rhtml/Overview.htm%3FTocPath%3D_____3

<manu> Ian: I don't know what the full set of topics are, but it feels like we're getting a more full set of these documents.

PROPOSED: We start a new doc on "web app developer good practice" (an explainer), and remove image and explanation from the payment request API

<Zakim> manu, you wanted to note that web devs read these specs, not just implementers.

manu: I have not seen these types of documents be useful at W3C.
... devs sometimes start with external materials then they turn to the spec to answer questions on gaps
... our devs typically do not start with primers, they start with the specs.

zkoch: I think that browser vendors do a pretty good job of developing these things...I think the community as a whole will step in and provide clarity
... I don't think these specs are (or should) also be for developers...hard to have both brevity for user agent developers and clarity for devs

Manu: We did this for JSON-LD spec...developers have said they love it.
... I think 60% of the spec or so is high-level explanation....
... we got really good feedback on it

<Zakim> ShaneM, you wanted to ask why this document ISN'T for developers

ShaneM: Zach you asserted that "this document is not for developers". I'm curious why you think it's not.

zkoch: I think you cannot serve 2 masters. Clear documents for developers with examples, and targeting a lot of different proficiency levels is one problem...and if you want to do it well you should do it well...and I think it requires a lot of text
... to Ian: as an organization...are we targeting implementers

<manu> Ian: I've worked on specs that take both approaches. Ones that provide a gentle introduction to the reader, others that don't do that.

IJ: We could look at previous architecture specs (that did not get uptake)

PROPOSED: Drop the image; others who want to propose image or alternative text within a 2 week time frame can do so

AdrianHB: Clarification - the image is only for "what's in there" not new ideas

<manu> -1 for 2 week timeframe, since this is editorial

<MattS> +1

<manu> just remove the 2 week limit

<rouslan> +1

<manu> +1

<ShaneM> +1 to not using this particular diagram

<nicktr> agreed - remove the time frame

RESOLUTION: Close issue 177 removing image

https://github.com/w3c/browser-payment-api/pull/238

zkoch: Two parts to this (1) incognito mode is a proprietary term (2) private browsing mode in general is not a defined concept

JeffB: The problem with not saying anything about private browsing mode is that you write a spec that is completely incompatible. I think it's fine to not say "what a browser should do" in private browsing mode

zkoch: Proposal is not to say anything about private browsing mode as this is implementation dependent at this time

AdamR: I Think that this is a larger question than just payments...the TAG checklist does mention private browsing mode

<adrianba> browsers should be allowed to compete on what features their private browsing modes provide and how "good" they are - there does not need to be standardization here

AdamR: I hesitate to close this issue WITHOUT asking the TAG to remove the corresponding text from the checklist

PROPOSED: Close issue 238 with no change. Write to the TAG to provide them feedback that we don't know what to say given ambiguity.

AdamR: I am ok with that but don't want to lose the issue

Jake: Neither push nor (scribe missed second reference to a specification) mentions private browsing

zkoch: Private browsing is a browser feature (not a standard) ...

<nicktr> +1 to not losing the issue

<scribe> ACTION: Ian to work with AdamR on feedback (and question) to the TAG about ambiguity around what to do re: private browsing mode [recorded in http://www.w3.org/2016/09/19-wpwg-minutes.html#action04]

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

https://github.com/w3c/browser-payment-api/issues/275

zkoch: I think there are different use cases...

- when you return a set of shipping options but 2 or more have the same ID...that should probably throw an error

- second scenario is multiple selected options marked as true...current proposal is to take the last one...I am less convinced here that there should be an error since the user can still fix it...in other words, second use case is reconcilable

PROPOSED: [Zach] Make explicit to throw in scenario 1 and not throw in scenario 2 (multiple selections)

Shane: If I am a merchant I think it would be useful to have something broken because merchant will fix it

AdamR: We have copious experience that that is not the case in practice on the Web

zkoch: Today the user agent already handles radio button groups a particular way

Jake: It's easier to go from throwing to accepting

dezell: I am sympathetic to making things easy, but uncomfortable with quirks mode for payments

<Zakim> manu, you wanted to speak in favor of being more conservative up front.

actions?

<adrianba> can we be concrete about the changes? one I see is to say we will reject the acceptPromise if the data from the updateWith promise has errors

<adrianba> another is to change the behavior in the constructor for shipping options

zkoch: I am hearing the more people in the group are leaning towards being conservative up front

<AdrianHB> Reopened https://github.com/w3c/browser-payment-api/issues/230 to track "private browsing" issue

zkoch: someone should volunteer concrete proposals of what needs to change.

<manu> Dinner plans are at 7pm

<scribe> ACTION: Shane to write a pull request on what might change around error handling re: addresses [recorded in http://www.w3.org/2016/09/19-wpwg-minutes.html#action05]

<trackbot> Created ACTION-32 - Write a pull request on what might change around error handling re: addresses [on Shane McCarron - due 2016-09-26].

<nicktr> https://goo.gl/maps/5KWLhe9oHVM2

Payment methods

zkoch: First quickly on changes to basic card spec
... three changes made to basic card

1) Minor clarification - we updated the label to match what's in payment request API

scribe: called a "payment address" now

2) Second clarification is to get rid of the long list of payment method identifiers in favor of generic "basic-card"

3) We have added filters: supported networks and supported types

MattS: Are we tracking an issue somewhere ... I see here it's called "Supported Networks" and in Android pay it's called something else

zkoch: Apple Pay calls is "supported networks" and Android Pay calls it something different
... it's hard for us to go to android pay to tell them to update labels

<betehess> also, http://schema.org/PaymentMethod

<AdrianHB> matts: shouldn't we be standardizing these since they are appearing in a number of payment methods

MattS: At the moment, we are limiting extensibility
... My suspicion is that other open methods are going to need something similar; it seems to me that this should be part of the payment method specs not the payment request API
... I want to track this issue.
... I want to ensure the issue we've punted on is captured somewhere.
... issue 30 was punted to issue 1 in PMI
... this is a solution to basic card but we have not solved

zkoch: We also added a new type called "prepay"...

<MattS> it is https://github.com/w3c/browser-payment-api/issues/30

IJ: see also https://github.com/w3c/webpayments-methods-card/pull/9

Roy: What is the goal for basic card? Will it go to CR and beyond?

<bensmith> q does commercial card need to be added, or small business card?

<manu> Ian: One of the things that I think could be stated very clearly in basic card -

<manu> Ian: This is supposed to replace basic card input via web forms - that's why it doesn't have features like tokenization. As long as people want to replace web forms with payment request API, they should use this. If they want extra security features, they should use those other specs.

IJ: My proposal is that the basic card spec be "to replace forms"

issue related to basic card:

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

<bensmith> if an issuer wanted to use tokenisation for payment app, do any of the specs not allow that ?

zkoch: We are going to collect data irrespective of what the merchant "doesn't want"

<manu> Ian: Can you talk about the user experience you have in mind?

zkoch: When we gather card information, we are going to gather all of it
... so there is pain, but only one time
... (so less friction across merchants subsequently)
... it is also the case that almost all this information is required all the time
... You can ignore data that we return

adamR: Browsers may behave differently, like gather data collectively and only on demand.

MattS: We have two different implementation opinions.
... The pull request says it's a HINT to browsers

zkoch: I think we can clarify that (1) by default you get all the data (2) .......

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

<manu> Ian: It's useful to clarify... the card spec uses WebIDL - there are interesting words "required" and "optional" - that means not all card networks require every field. The specific information in this document is that you may not need information.

<manu> Ian: I don't want us to focus on "required" or "optional"

<manu> Ian: If I'm a merchant and I don't want the user to be asked for something because it'll cause friction, and I don't want it. It's about not bugging the user for the information.

<manu> Ian: A solution that says "we have the data and we're going to return that"

zkoch: We use CVV to unlock

Nick: As do we

MattS: These are my use cases:

- reduce user friction (by not asking for CVV, for example)...that's a HINT to browser

scribe: e.g., amazon checkout does not want to collect CVV

- second use case is not wanting "billing address"

scribe: user friction use case

IJ; I hear the flow being:

- browsers return all the data that the payment method supports for that network

- MattS wants a hint (that can be ignored by browsers) to not ask the user for a particular field.

zkoch: Seems like we should close this pull request
... It would need to be clear that this can be ignored by the browsers.

MattS: I want to avoid writing a pull request if there are no browser implementers interested.

AdamR: I would support the pull request ... being able to "not ask" in some cases

zkoch: In all the flows, CVV is the biggest source of friction
... you typically know your address but not your CVV
... CVV is the biggest point of friction

AdrianHB: Note also that third party apps could return card data...so browsers aren't the only implementations

zkoch: One counter-proposal has to do with CVV

<mountie> CVV is not working at some country's card network.

zkoch: we could be more specific on whether you want to collect CVV

nicktr: There's an implementation IOT implication here as well (using basic card)..and machines may not be able to return CVV

<MaheshK> +1 to MattS support making billing address, cvc optional

PROPOSED: Close pull request 4 with no change to the spec. Matt has option to issue a new pull request that talks about reducing user friction through hints to the browser

<AdrianHB> +2

<nicktr> +1 to the proposal

zkoch: Ian has a pull request with some editorial changes.

<Dongwoo> +1

zkoch: I don't like the text about storage.
... At most I think we should say that there are burdens; I am not comfortable with recommendations.

nicktr: I think it's fair to flag that having card information raises consequences.

IJ: An alternative is to delete the paragraph and leave the note

AdamR: I am ok pulling the SHOULD NOT out...but mentioning that it becomes less necessary with this API

IJ: Feel free to take the editorial bits of the PR and delete the paragraph around storing card information.

<scribe> ACTION: AdamR to propose text about why the API can reduce need for card data storage; without any recommendations [recorded in http://www.w3.org/2016/09/19-wpwg-minutes.html#action06]

<trackbot> Created ACTION-33 - Propose text about why the api can reduce need for card data storage; without any recommendations [on Adam Roach - due 2016-09-26].

zkoch: I think the rest of Ian's small editorial things are ok

ian: Handle the PR request as you wish; do the right thing

PROPOSED: Remove the diagram from basic card

MattS: +1

zkoch: +1

<manu> manu: +1

<ShaneM> +1

[No objections]

<scribe> ACTION: zkoch to remove the diagram from basic card [recorded in http://www.w3.org/2016/09/19-wpwg-minutes.html#action07]

<trackbot> Created ACTION-34 - Remove the diagram from basic card [on Zach Koch - due 2016-09-26].

mountie: It would be useful to have a diagram somewhere

RESOLUTION: Close pull request #4; MattS may write a new pull request about user friction hints

<nicktr> https://w3c.github.io/webpayments/proposals/method-practice/

<scribe> [New payment method good practice draft]

[Max walks through the document structure]

AdrianHB: Has anyone reviewed in detail or want to add comments?

<AdrianHB> ian: publishing policy we started to discuss. There was push back on publishing proprietary methods as W3C docs

<nicktr> notes that the definition probably excludes tokenised card payments if the tokens are issuer or network tokens

<Zakim> manu, you wanted to ask if we can publish a list of known payment method specs

IJ: I want to draw attention to the publishing policy in light of new specs hitting the group; and may move in direction of general purpose specs

manu: Can we publish a list of known payment methods?
... also can we consolidate with the PMI spec?

AdrianHB: Maybe premature to merge; I'm ok to look at later

NickTR: +1 to suggestion to merge with PMI spec

AdrianHB: I would not put dynamic list of payment methods in a static W3C spec

<manu> Ian: I object to keeping a registry in a W3C specification... in the short term, as we communicate this stuff, we may find it useful to point people to these payment specs.

<manu> Ian: I wouldn't put it in a static report, in the short term we can do that, but in the long term, let's use the Web.

IJ: In the long term let's use the Web as the registry

<mountie> maybe we can reference custom URI scheme case.

<manu> Ian: I think it's premature to ask that this becomes a FPWD, we need more experience with this. We should develop it a bit more with some of the new specs coming in.

NickTR: For me, one of the most important things in this doc is the definition of open/proprietary

zkoch: Those terms are part of PMI discussion tomorrow

Agenda bashing

nicktr: Move HTTP API to tomorrow
... move WG process to tomorrow
... look at payment method specs today

MaheshK: I'm ok for samsung pay payment method spec to be part of tokenization spec discussion.

[Roy walks through the draft]

AdrianHB: Do we see value in the gateway token thing being standardized?
... I definitely think we can standardize on issuer tokens
... not so sure about gateway tokens
... Should we review "how these things work"?

NickS: Gateway token is generated by the gateway...it's about "WHO HOLDS THE MAPPING"
... is it the network? gateway? or issuer?
... often you need to provide information....with android pay you can use gateways..."I'm using stripe; here's my token" and then on the backend android pay gets info from stripe

NickTR: Network tokens have the same format

AdrianHB: What's the difference between an issuer token and a network token?

nicktr: E.g., Barclay card ... token put on cards is an _Issuer_ token

nickS: You should not make any assumptions about the format of tokens in this spec.

AdrianHB: Should we have an EMV tokenization spec?

Ben: The spec could usefully distinguish EMV from other tokenization uses

AdrianHB: How far do networks diverge from EMV?

Ben: Not much

zkoch: Is the idea that tokenization will be more common and that we avoid fragmentation through a general "tokenization" spec?

roy: In my mind, a goal is in the future payment apps could spawn organically and merchants would not need to be aware of their existence.
... and so you'd not want to have to see flourishing of identifiers

<manu> Ian: In the case of basic card, you know what kind of data you're going to get back. Are you achieving the same thing with the tokenization spec?

roy: I am hearing network and issuer tokens could be used here

nickS: Network and issuer tokens are well-formed but region-specific. Gateway tokens can be cross-jurisdiction
... if you are building an app globally, that could be very useful
... in some payment methods the tokens you get back can be different formats...e.g., apple pay typically returns EMV token unless you have an Suica card
... one way to get around this is to abstract into gateway tokens

zkoch: I am very supportive of moving this work forward; but there may be some logistical issues with getting it adopted.

AdrianHB: I spoke with a company last week that provisions tokens. My understanding is that they will provision a device with a token that looks like a network token.
... the acquirer doesn't know it's a token; it looks like a PAN...the fact that it's unique to that merchant or transaction is only known to the issuer.
... the enhancement on top of basic card is "Here is my merchant idea; give me back a merchant-specific token"

Laurent_: On the implementation of this idea - I don't see the diff really between implementing a specific token v. a full-fledged payment method (especially gateway tokens)
... what's the benefit?

AdrianHB: I don't see the value for __gateway__ tokens
... unless we have deeper filtering, you are just pushing it down the road

Laurent: For issuer and network tokens, if they are format preserving tokens, they are supposed to be handled as PANs, so why not basic card payment?

AdrianHB: The different is _input_ data which is not part of basic card

nicktr: You could send tokenized card transactions over basic card...but the value of the tokenization spec is to carry along additional standardized fields like cryptograms

[Discussion of PAR]

Roy: I hear feedback that gateway tokens should be full-fledged payment method specs (and not part of this spec)
... Regarding using tokens over basic card, I think that encryption will be important and that's not part of basic card.
... I will revise the spec based on today's feedback.

Ben: We'll review the spec from an EMV perspective.

<scribe> ACTION: Ben to organize review of tokenization spec from EMV perspective [recorded in http://www.w3.org/2016/09/19-wpwg-minutes.html#action08]

<trackbot> Created ACTION-35 - Organize review of tokenization spec from emv perspective [on Ben Smith - due 2016-09-26].

<scribe> ACTION: Roy to revise the tokenization specification based on today's feedback [recorded in http://www.w3.org/2016/09/19-wpwg-minutes.html#action09]

<trackbot> Created ACTION-36 - Revise the tokenization specification based on today's feedback [on Roy McElmurry - due 2016-09-26].

MaheshK: We also support the direction of this specification.
... regarding gateway tokens

NickTR: Gateway tokens are proprietary ; so vary from gateway to gateway

AdrianHB: From a merchant perspective, unless you can specify WHICH TYPE of gateway tokens your support, the user experience won't be good
... unless the user agent supports that filter.

Roy: Stripe could be viewed as a payment method implemented by a variety of payment apps