W3C home > Mailing lists > Public > public-webpayments@w3.org > May 2013

Web Payments Telecon Minutes for 2013-05-15

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Wed, 15 May 2013 15:05:52 -0400
Message-ID: <5193DC90.3050807@digitalbazaar.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:23 UTC