- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Wed, 15 May 2013 15:05:52 -0400
- To: Web Payments <public-webpayments@w3.org>
The minutes for today's telecon are now available here: http://payswarm.com/minutes/2013-05-15/ Full text of the discussion follows for archival purposes at the W3C. Audio of the meeting is available as well (link provided below). -------------- Web Payments Community Group Telecon Minutes for 2013-05-15 Agenda: http://lists.w3.org/Archives/Public/public-webpayments/2013May/0041.html Topics: 1. Introductions 2. Browser Payments Overview 3. Browser Payments API 4. Browser Payments Questions, Answers, and Issues 5. Browser Payments Timeline Chair: Manu Sporny Scribe: Manu Sporny, David I. Lehn Present: Manu Sporny, Iulian Dumitraşcu, Pindar Wong, Kumar McMillan, Fernando Jiménez Moreno, Elliott Sprehn, Brent Shambaugh, Charles (McCathieNevile) Nevile, David I. Lehn Audio: http://payswarm.com/minutes/2013-05-15/audio.ogg Manu Sporny is scribing. Manu Sporny: Today's telecon is going to focus mostly on the mozPay API by Mozilla and Telefonica. We'll do introductions first, then get a brief overview of the API from Kumar and Fernando, then move on to Q/A. Any questions about or additions to the Agenda? Topic: Introductions Iulian Dumitraşcu: I'm interested in helping the Web Payments work - specifically helping with PaySwarm. I've wanted to try something like this for several years now. I'm inclined to support the work you're doing here. Iulian Dumitraşcu: I think you're involved with a number of things that are aligned with my goals. Pindar Wong: This is Pindar from Hong Kong - Creative Commons - interested in payments and intellectual property (digital content sales). Kumar McMillan: Hi, Kumar from Mozilla - worked on mozPay API that is going to ship in FirefoxOS phones this summer - doing mostly the server-side compontent, some client stuff. Fernando Jiménez Moreno: Fernando from Telefonica - working on mozPay API - client side. Iulian Dumitraşcu: Service provider - experienced w/ payments - interested in startups that bring global services to bear on problems like payments. Elliott Sprehn: Hi Elliott from Google - working on Request Autocomplete spec - different approach for payments on the Web. Brent Shambaugh: Thinking about the MNDS project - decentralized payments for projects, funding people in a automatic/decentralized way. Charles (McCathieNevile) Nevile: Charles Nevile from Yandex, been involved in standards for a long time, just listening in. David I. Lehn: Dave Lehn - work at Digital Bazaar on PaySwarm. Manu Sporny: Manu - I'm the current chair of Web Payments at W3C. I also chair the RDFa and JSON-LD groups at W3C. HTTP Auth Working Group member. Heavily involved in standards. I work at Digital Bazaar on the PaySwarm standards. [scribe assist by David I. Lehn] Topic: Browser Payments Overview Kumar McMillan: I can give a brief intro - probably better to keep it short and then go into questions. Kumar McMillan: The short view of mozPay is that Mozilla wants to have this sort of native apps ecosystem - we want it to shift to the Web for developers - mainly because it's easier to develop using web technologies. Kumar McMillan: We hope that mozPay will bring commerce to the FirefoxOS ecosystem. It's built into the phone, it's easy for developers to use, we want the user side to be really easy. Making a payment is going to be super-simple... once you do it once, if you use mozPay, it'll be really simple to do repeat payments. Kumar McMillan: So, that's the short FirefoxOS view - it could apply to desktop in the future. Fernando Jiménez Moreno: The idea for Telefonica was to build this w/ carrier billing capabilities - credit card and other payment methods. We also wanted the API to be as open as possible, we wanted to introduce a different marketplace as well - we wanted to use the same API for all marketplaces... not just the Telefonica one. Manu Sporny: what's the timeline on the rollout of mozPay API? [scribe assist by David I. Lehn] Kumar McMillan: right now, developers can do simulated payments - pass a flag through JSON web token that will bypass any real payment to help them integrate w/ the client-side via callbacks and server-side via posts. Kumar McMillan: It's not live yet, it's only possible to do simulations. The timeline is a bit hard to pin down - it's in the hands of our partners - like Telefonica... they're going to be shipping some phones soon. Kumar McMillan: As far as our other partners - possibly any day now. Fernando Jiménez Moreno: We are thinking perhaps this summer - most of the pieces of the mozPay API are completed. A simulation for developers is working as well. Manu Sporny: at a high level does anyone have questions? we wanted to spend call on questions about mozPay api [scribe assist by David I. Lehn] Elliott Sprehn: What are the perceived advantages of building this into the browser? We were discussing this at Google - very similar to Wallet API - you can do this w/ standard JavaScript libs, so why the browser? What's the advantages of building this into the Web platform? Kumar McMillan: One thing that I do want to stress is that Mozilla is shipping FirefoxOS and is very focused on building an open mobile alternative - so, in the very simplest case - we want the API to ship on the phone so that developers have an easy integrated payment solution. You don't have to think about what shim to use, what library to use, optimize it for mobile networks (to load fast, etc.), you just use the mozPay API because it's on the phone. Kumar McMillan: So, if we can get a standard way of doing payments, it'll be easier for everyone to participate in payments. It's not totally clear that building this into the client makes it easier/better/more open, so that's future work that needs to be done. In the shortterm it's important that developers can build apps and build a business around it. Elliott Sprehn: Currently, the API is focused on digital goods - is there a plan to extend it to physical goods? Kumar McMillan: physical goods is a bit of an issue for legal reason. The API doesn't prevent it from being used for physical goods - we might want to move that "restriction" out of the spec. Kumar McMillan: If anyone were to implement shippable goods on that API, it would work just the same. Manu Sporny: From a PaySwarm perspective, we have a set of specs for doing decentralized payments on the Web... credit card phishing is a big issue on the Web currently. [scribe assist by David I. Lehn] Manu Sporny: one reason for building it into browser is to mitigate many of these phishing attacks [scribe assist by David I. Lehn] Manu Sporny: typical attack: you get links in email and see popups with dialogs for phishing site that says PayPal (or similar) and can get your card numbers stolen. [scribe assist by David I. Lehn] Manu Sporny: Benefit of payments built into browser helps with financial attacks that are current today, like fake 'credit card input' forms from phishers. [scribe assist by David I. Lehn] Manu Sporny: developers can just do navigator.pay and money will transfer, no need to ask for credit card numbers. That's the future, payments built into the browser. [scribe assist by David I. Lehn] Manu Sporny: if it's in browser, the browser chrome can show a standard payment dialog that will never ask for CC numbers. [scribe assist by David I. Lehn] Manu Sporny: important part of that buy flow is customers never have to enter credit card numbers .. [scribe assist by David I. Lehn] Manu Sporny: advantages in browser: ease of use, less attacks, more interesting payment ui .. [scribe assist by David I. Lehn] Manu Sporny: currently payswarm implemented with a popup, but that's phishable - we'd rather use a standard chrome checkout UI. [scribe assist by David I. Lehn] Kumar McMillan: Before we move on from the phishing discussion. You don't have to enter your credit card into every site - that is also a motivation for the mozPay API - it's a bit more tricky on mobile devices. I think we don't solve phishing on mobile devices yet - there will be malicious apps that may be used to phish - hard problem to solve, even on android - so that's on our minds, but is an unsolved problem. Fernando Jiménez Moreno: For this specific FirefoxOS case - we have a problem with payment frames - we don't have the idea of chrome/window that is owned only by the browser. In FirefoxOS, everything that the user sees on the screen is web content - we couldn't give any impression of security to the user. Implementing this payment flow that opened a single window via window.open() is what we did? We didn't do a chrome frame because everything in FirefoxOS is web content - even the status bar is a web page. Any application w/ fullscreen capabilities oculd emulate a window w/ a URL bar. So, phishing is possible. Fernando Jiménez Moreno: Embedding the payment flow in a window is something that any application could simulate. We have a dialog on top that lets the user see part of his own screen. That is something that any other application cannot do. Kumar McMillan: The design is that the window is floated on the home screen - hard for an attacker to simulate that window. There is some debate on that point, that was the intention of the design of FirefoxOS window - it looks different from any other app. Kumar McMillan: the mozPay() api uses a Trusted UI on Firefox OS to mitigate phishing risks Topic: Browser Payments API http://web-payments.github.io/browser-payments/ Manu Sporny: a couple days ago had a chat with Kumar on how to move spec into W3C. [scribe assist by David I. Lehn] Manu Sporny: as web payments chair I want to get this to move forward this year. People want to see this happen. Wanted to get the spec out for people to see, it helps when you have a spec to point to and talk about. [scribe assist by David I. Lehn] Manu Sporny: The W3C Browser Payments spec is almost a direct port of mozPay spec [scribe assist by David I. Lehn] Manu Sporny: temporary title and it may change [scribe assist by David I. Lehn] Manu Sporny: spec is fairly straightforward. intro, signin, various details, basic browser api [scribe assist by David I. Lehn] Manu Sporny: this is one of the specs the web payments group is working on. browser payments, http signatures spec with the IETF which will be used with PaySwarm, maybe be used with other specs. [scribe assist by David I. Lehn] Manu Sporny: something still up for discussion is identity and if it belongs in the specs and how to not force one identity solution [scribe assist by David I. Lehn] Manu Sporny: hoping to work on spec over next few months so when w3c working group starts work on payments they will have a spec to start with. good to start with a spec that has had work on it versus just a bunch of ideas. [scribe assist by David I. Lehn] Manu Sporny: firefox os, mozpay api, and payswarm are good signal to start a working group [scribe assist by David I. Lehn] Manu Sporny: any questions on spec or what we want to do with it? [scribe assist by David I. Lehn] Kumar McMillan: To follow-up on the spec - what Mozilla wants to do is propose the smallest amount of navigator.pay() API that works. So, that's where we are right now. There are lots of parts of it that are missing - identity being one of them. We wanted to get some of the easy problems spec'd. We feel that some of them are simple, having an API that they can initiate a payment with is pretty straight forward. Kumar McMillan: Developer registration/sign up - some of that stuff is in the spec just for reference, but I think ultimately we'll need to remove that stuff from the spec - it's not clear, it's an implementation detail. The payment processor can figure that stuff out. Topic: Browser Payments Questions, Answers, and Issues https://github.com/web-payments/browser-payments/issues Manu Sporny: number of issues logged. Kumar raised one, I added more. [scribe assist by David I. Lehn] Brent Shambaugh: Was talking to a network security guy - he was concerned about web payments from the standpoint that if his computer got stolen, he was worried that folks would use it to spend money. Kumar McMillan: Yeah, so that has been a security concern from the very beginning - it's especially important w/ mobile phones. Some south american countries have a high rate of phones being stolen. Kumar McMillan: We are trying to strike a balance between payments being easy to use, and also secure. Hard balance to strike. Kumar McMillan: There are things that are not specified yet in the mozPay API - when the window pops open to make a payment, you are logged in w/ a Persona e-mail account (email based identity solution) Kumar McMillan: Once you're logged into your phone, you're logged in forever. Your identity is on your phone, it's "sticky". Kumar McMillan: When you make repeat payments, you don't have to re-login - but you have to enter a basic PIN. Kumar McMillan: If the phone gets stolen, you can't just guess a pin - it's server-based, if you stole a phone, you'd also need to know the PIN. Kumar McMillan: There is no way to turn the PIN off - some partners want more security than a PIN, so we might introduce something greater. Kumar McMillan: There is also the general "child problem" - kids buy things all the time when you don't have a PIN. Manu Sporny: There's a minimum whitelist now, payment providers approved now, how do other companies get on that list, how can this be decentralized [scribe assist by David I. Lehn] Kumar McMillan: So, to sumarize - when a developer sets up payments for an app - they register w/ a provider to process payments. When a user goes to pay, they don't really have a choice - they choose what the developer has prescribed, it makes sense because the developer needs a payout. So the people that can process the payments are hardcoded on the FirefoxOS phone, so in order to get on that list, the vendor who ships the phone will have to honor that in their build. Kumar McMillan: So, that process is still not totally clear - but Mozilla isn't really happy w/ that approach. For v1, I think it's going to be good enough. What Mozilla will want to do is add enough payment providers to that list to make it competitive for developers and users - no one is being gouged, healthy amount of competition. There are people that are not going to be on that list, and they're not going to be happy about not being on that list. Kumar McMillan: That's not going to be solved for version 1, everyone wants to solve that, but the first approach is to not solve that hard problem. Manu Sporny: Question if chargebacks and refunds are out of scope for the API. They are specific to a credit card buy flow. [scribe assist by David I. Lehn] Manu Sporny: Is the API going to be just payments or include other features like chargebacks, refunds, and crowdfunding. [scribe assist by David I. Lehn] Kumar McMillan: The thing that's a bit weird about this API is that it has both a client-side and server-side component. There aren't a lot of APIs that have both client and server-side. We might just want to standardize the client-side and push that through since it's easier. However, in order for a payment to be secure, there is a signed JSON web token. So the developer needs to verify the signature. It must happen on the server-side, it can't happen on the client-side. Kumar McMillan: We'll need to keep the postback for the charge-back - that's how you are guaranteed that you got paid. Future work - we do want to add refunds through the API. Fernando has done a lot of thinking on that. Refunds are sort of happening in a separate process, someone wants to get a refund for an app. Someone wants to go through Mozilla's marketplace, they get refunds through the mozilla marketplace. Fernando Jiménez Moreno: You can create a JSON Web Token for a refund, for v1, there is no server-side that supports that sort of token. In terms of the API, there is more work to do to verify that a request is a refund. In terms of API, it'll only need to modify the JSON web token. Manu Sporny: How do you see PaySwarm, Bitcoin, or other standards integrating with this API? [scribe assist by David I. Lehn] Kumar McMillan: I don't think a lot of people at Mozilla know about the PaySwarm work. As far as I know, PaySwarm is the only attempt at an open, decentralized payment problem. So, that's interesting to me personally, I don't think mozPay has any solution for that. FOr example, the whitelist on the phone isn't great. We could have a registration built into the API - maybe a user-flow on the API so they can opt-in to payment providers. So, that's open and it sounds like PaySwarm and Mozilla have similar goals - we both believe that anyone should be able to participate in the payment flow. Kumar McMillan: You want people to be able to participate on either side, as a customer as a merchant provider, etc. Manu Sporny: Elliott, interested in what you're doing, and how this overlaps with PaySwarm and other web payments group work. [scribe assist by David I. Lehn] Elliott Sprehn: So, the request auto-complete spec has a slightly different goal - it's not specific to payments, it is mostly about filling out form information. Elliott Sprehn: We can have payment profiles, and give a person a good way to select a payment solution. Our goal was on how to take existing payment flows and make them completely hassle-free but without requiring a payment processor on the background. Elliott Sprehn: There is an auto-complete attribute on all form attributes - shipping/billing addresses, credit cards, etc. The Request Autocomplete spec is generalizable - you could use it on the form and the browser could provide an UI to do selection. Kumar McMillan: I was curious - looked into this a little bit. It's a convenience for the user, is it still correct that they post an actual credit card number to the site? Elliott Sprehn: Yes, they still post it to the site. David I. Lehn: Who is controlling how that information gets populated into the form. Elliott Sprehn: The spec is vague about this - it's a browser-provided user UI flow. So, the sheet would come out of the address bar... or on mobile, they can provide a dialog on the user's home screen. On that dialog, they could select what the information they want to select is. Topic: Browser Payments Timeline Manu Sporny: What do you want to see out of this group? Kumar McMillan: What Mozilla's interested in is getting more Web device vendors interested in helping us on the spec. We want to do something that's good for the ecosystem. Kumar McMillan: So, I don't know how best to use these meetings, but I want to help w/ that discussion. Still working on the spec, we'll be shipping that - focus on shipping the product. Kumar McMillan: Elliott, do you know if the Wallet folks know about the mozPay API since it's based a lot on what Google Wallet did? Elliott Sprehn: So, wallet is based on Request Autocomplete - it's our protection implementation, so processing is done on the backend - we generate a one-time creditcard number, that is tied to a wallet account. Elliott Sprehn: Not sure if they've looked at mozPay. There are concerns about how to evolve the client-side experience, because this is baked into the browser, that whitelist is concerning. Elliott Sprehn: Committing to be a payment provider requires you to commit to be a long-term payment provider. If it's baked into the platform, then that's a different thing. Kumar McMillan: Yes, that came up for us as well. One of our first implementations was a polyfill similar to Google Wallet. Elliott Sprehn: Don't know what the Wallet team things, they're focused on request auto-complete. Manu Sporny: Sounds like we need Wallet group on the call. Tried to get Safari on call, haven't reached out to Microsoft yet. [scribe assist by David I. Lehn] Manu Sporny: Some browser vendors might not want to converge on a soltuion yet until they know what buy flow is. [scribe assist by David I. Lehn] Manu Sporny: Try to get Wallet, Safari, Opera, Microsoft on call. [scribe assist by David I. Lehn] Elliott Sprehn: Yeah, I'll reach out to the Wallet team - I'll see what they can do. They've been very busy w/ I/O this week. Manu Sporny: Calls only twice a month. Should be plenty of warning. [scribe assist by David I. Lehn] Manu Sporny: Thanks to everyone. Minutes should be up soon. [scribe assist by David I. Lehn] -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/
Received on Wednesday, 15 May 2013 19:06:16 UTC