Re: Web Payments Telecon Minutes for 2013-05-15

amazing minutes... more like a transcript!

p.



On Thu, May 16, 2013 at 3:05 AM, Manu Sporny <msporny@digitalbazaar.com>wrote:

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