Web Payments Telecon Minutes for 2013-07-10

Thanks to Dave Lehn for scribing. The minutes for this week's Web 
Payments telecon are now available here:

https://payswarm.com/minutes/2013-07-10/

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-07-10

Agenda:
    http://lists.w3.org/Archives/Public/public-webpayments/2013Jul/0006.html
Topics:
    1. Update on GSoC Student Progress
    2. ISSUE-12: Registering preferred payment providers
    3. ISSUE-3: Using multiple payment providers
    4. ISSUE-2: Pure chrome-based buyflow
Chair:
    Manu Sporny
Scribe:
    David I. Lehn
Present:
    David I. Lehn, Manu Sporny, Andrei Oprea, Dave Longley, Mark
    Cavage, Kumar McMillan
Audio:
    http://payswarm.com/minutes/2013-07-10/audio.ogg

David I. Lehn is scribing.
Manu gives overview of agenda - mostly browser Payments work
    today.
Manu Sporny:  Let's get an update from Andrei

Topic: Update on GSoC Student Progress

Andrei Oprea:  code able to produce listings and assets
Andrei Oprea:  now working on making a purchase and a marketplace
Andrei Oprea:  filed an issue with current payswarm.js module
Andrei Oprea:  when you try to install it there's a issue between
    payswarm.js and jsonld.js versions
Dave Longley:  should work.  we'll look into it.
Andrei Oprea:  issue is on github
Andrei Oprea:  create asset and digitally sign it.  also create
    listing and associate asset with listing.  do you have to sign
    the whole listing?
Dave Longley:  yes, you have to sign asset and listing
Dave Longley:  reason you have to sign listing is so the terms
    you add in listing can't be changed
Andrei Oprea:  any restrictions to licensing?  what license
    should you use?
Dave Longley:  look at demo we have.  you can use any license.
    you can look at license we use.  there's a certain format but you
    can use any text you want.
Andrei Oprea:  what currency can you use?
David I. Lehn:  We have a w3id.org currency thing that is setup
    for USD, USD maps to some IRI. Other currencies would be added to
    it when needed. [scribe assist by Manu Sporny]
David I. Lehn:  At present, we only support USD, but we will add
    more support in the future. [scribe assist by Manu Sporny]
Andrei Oprea:  You have support for many currencies, even
    Bitcoin. [scribe assist by Manu Sporny]
David I. Lehn:  If you have other currencies you want to support,
    let us know. [scribe assist by Manu Sporny]
Dave Longley:  We will support others in the future, for now,
    just keep it simple w/ USD. [scribe assist by Manu Sporny]
Andrei Oprea:  besides publishing assets and making purchases,
    how would you resell an asset?
Andrei Oprea:  this is after you buy something and want to resell
    it
Dave Longley:  you can handle this with asset listing
    restrictions.  don't put any restrictions on who can sell the
    asset.
Dave Longley:  can also use payee rules.  anyone can resell the
    asset as long as they comply with all the listing restrictions
Manu Sporny:  use cases that are things like company that wants
    to let you resell music.  don't put restrictions on who can
    resell as long as certain amount goes to artist or label.
Manu Sporny:  also a app marketplace where you allow any other
    marketplace to also sell app as long as certain amount goes back
    to author
Dave Longley:  allows a decentralized way to control assets
Andrei Oprea:  asset contains link to content you get in the end.
     not sure how this works.  if you go to that url, do you have to
    provide a receipt to get product?
Dave Longley:  yes, that's typically how it works.  that url has
    to have mechanism to handle receipt.  this may be via a POSTed
    receipt that the server checks.
Manu Sporny:  Mark, any HTTP Signature stuff we need to discuss
    today?
Mark Cavage:  Just lurking today, no need to discuss HTTP
    Signatures.

Topic: ISSUE-12: Registering preferred payment providers

Manu Sporny:
    https://github.com/web-payments/browser-payments/issues/12
Manu Sporny:
    http://lists.w3.org/Archives/Public/public-webpayments/2013Jul/0000.html
Manu Sporny:  have updated the spec to have a rough cut of this
    api
Manu Sporny:  has been discussion on that issue
Manu Sporny:  new api registerProvider.   takes object with
    identity of provider, uri to find out more about payment
    provider.  all up for discussion.
Manu Sporny:
 
https://github.com/web-payments/browser-payments/commit/a0885d71abbc90efad5743752f67b014f7143b26
Manu Sporny:  some discission on the commit
Kumar McMillan:  want to get rid of getproviders.  no reason to
    expose to client.
Manu Sporny:  agree we don't want api call to be spamy.  ...
Manu Sporny:  need to see how other specs do this to show it's a
    user initiated thing
Manu Sporny:  spec isn't what mozPay uses right now
Manu Sporny:  There are two main options. The first is specifying
    a 'start the buyflow' URL value and passing it directly to the
    call. The second is using /.well-known/something and listing
    service URLs in that file. PaySwarm uses the latter approach.
Kumar McMillan:  I like the .well-known approach.  mozPay just
    has single url at start of buy flow.
Kumar McMillan:  good to move into a .well-known.  mozPay
    provider could move to this.  client can cache this.
Dave Longley:  client will have one request that can be cached
Manu Sporny:  don't need to fetch that document that often.
    probably not at the start of every transaction.  might be a
    session based thing.  fall back to HTTP caching semantics and let
    browser deal with it.
Manu Sporny:  other questions in spec, what the .well-known name
    should be.
Manu Sporny:  should it be .well-known/payments or transactions?
    it's where you start the buy flow.
Manu Sporny:  it could be .well-known/payswarm, and we condense a
    whole bunch of this stuff there.
Manu Sporny:  could work like how PaySwarm works with Web Keys,
    we put service URLs in both locations.
Kumar McMillan:  names are hard.  in a couple versions of firefox
    os could include a register url.
Kumar McMillan:  Let's start with .well-known/payments and go
    from there.
Dave Longley:  what do you send to urls? What's the protocol?
    it's different between what payswarm and mozilla are doing
Manu Sporny:  will start with .well-known/payments with an entry
    to start the buy flow
Dave Longley:  browser needs to know what protocol to speak to
    the endpoints it finds
Manu Sporny:  Doesn't the client know the protocol based on the
    JSON-LD key that is used?
Dave Longley:  need to know what to do if everything looks the
    same, like start of buyflow.
Manu Sporny:  if these are JSON-LD documents we can specify what
    to do as extra properties on the URL.
Kumar McMillan:  we have type specified.  that let's you know
    what protocol to use.  might need to be more strict and put
    version of spec.
Manu Sporny:  This is good enough for a first pass. Will go
    through several iterations of this.  can add markers and fix up
    through later passes of the spec.

Topic: ISSUE-3: Using multiple payment providers

Manu Sporny:
    https://github.com/web-payments/browser-payments/issues/3
Manu Sporny:
 
https://github.com/web-payments/browser-payments/commit/a0885d71abbc90efad5743752f67b014f7143b26#L0R662
Manu Sporny:  concern was to match what customer and vendor
    support for payment providers.
Dave Longley: more discussion here:
 
https://github.com/web-payments/browser-payments/commit/a0885d71abbc90efad5743752f67b014f7143b26#L0R735
Manu Sporny:  didn't want to leak info to merchant
Manu Sporny:  kumar raised issue we probably don't need to expose
    providers to merchant
Manu Sporny:  customer would go off register many providers.  at
    merchant they click buy button, merchant says what providers it
    supports, client would select which provider they want to use
    based on that list, if there's a match buy flow starts, else
    register flow starts
Kumar McMillan:  there's nascar problem with this but for our
    sanity should ignore that for now since it's hard to solve.
Manu Sporny:  don't have nascar problem now.  you get list of
    providers merchant accepts, user has list of preferred providers,
    client would select automatically.  chrome could show option to
    add new provider.
Kumar McMillan:  correct.  in best case, user won't have to do
    anything since system will select provider automatically.
Kumar McMillan:  case where you may have big list of providers
    still will have nascar issue with lots of icons
Dave Longley:  all vendor has to do is send ordered list of
    payment providers, browsers can handle it or show all the options
    if they like.
Dave Longley:  in the future payswarm case it may all work
    automatically and you don't have to choose anything
Manu Sporny:  I like Dave Longley's approach.  client handles
    provider selection.
Dave Longley:  want to handle automatic purchases in the future
Manu Sporny:  sounds like we can remove getProviders from the
    spec
Kumar McMillan:  issue with user registering provider that the
    merchant doesn't support.  don't want to allow user to do that.
Dave Longley:  you could perhaps have a middleman 3rd party
    payment agency that would transfer bitcoins to google wallet.
Dave Longley:  merchant could only allow google wallet, but
    another provider could expose itself as google wallet proxy that
    does the exchage for the user
Kumar McMillan:  in the future would be a good differentiating
    feature
Manu Sporny:  I don't know how important the differentiating
    feature is - then again, having a merchant that only accepts
    PayPal be able to accept Bitcoin via a 3rd party w/o knowing
    about it would be pretty powerful. Those that wanted to only pay
    in Bitcoin could do so via 3rd party escrow.

Topic: ISSUE-2: Pure chrome-based buyflow

Manu Sporny:  This issue is mostly about how to do in-app
    purchases where the app does one of two things. The first is a
    purchase where the receipt is shown. The second is a purchase
    where the receipt is not shown. Kumar, what's Mozillas thinking
    about this as related to single click purchases? Is single-click
    purchasing a use case Mozilla wants to support?
Kumar McMillan:  Yes, interesting use cases. Use case with no
    window shown is trickier.  need some UI feedback.
Dave Longley:  in the case of an automatic purchase payswarm has
    the concept of a budget to authorize a certain amount of funds.
    the buyer previously authorized that.  can trust site to provide
    a UI for it.
Kumar McMillan:  need to address spoofability of this.  window
    floats over your home screen icons.
Kumar McMillan:  in practice you could put up home screen icons.
Kumar McMillan:  not sure how other platforms solve this.  issues
    on android and ios too.  maybe better on ios.
Dave Longley:  could you show users picture of themselves?
    harder to spoof.
Kumar McMillan:  early proposal to do this.  by the time you do
    that you've lost the user.
Kumar McMillan:  savy users may want to do this to lock it down
    themselves.
Manu Sporny:  We're thinking about this because we want to do one
    click purchases
Manu Sporny:  It's an important use case
Kumar McMillan:  good time for an iteration of the spec and start
    a new discussion
Manu Sporny:  thanks everyone.  will try to rev spec over the
    next week and put up new agenda with new issues.

-- 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, 10 July 2013 17:21:17 UTC