Web Payments Telecon Minutes for 2013-08-08

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

https://payswarm.com/minutes/2013-08-08/

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

Agenda:
   http://lists.w3.org/Archives/Public/public-webpayments/2013Aug/0005.html
Topics:
   1. Inside Bitcoins Review
   2. Update on GSoC Student Progress
   3. Continuing Analysis of MozPay API - Price Points
   4. Icons
   5. Product Data
   6. Postback URL
   7. Chargeback URL
   8. Analysis of JOSE specifications wrt. Web Commerce API
Chair:
   Manu Sporny
Scribe:
   David I. Lehn
Present:
   David I. Lehn, Manu Sporny, Andrei Oprea, Dave Longley,
   Kumar McMillan, Travis Choma
Audio:
   http://payswarm.com/minutes/2013-08-08/audio.ogg

David I. Lehn is scribing.
Manu Sporny:  Any updates or changes to the agenda?
Manu Sporny:  adding update to Inside Bitcoins conference

Topic: Inside Bitcoins Review

Manu Sporny:  Inside Bitcoins conference was really neat. I
   wasn't sure what to expect, thought there might be lots of
   hobbyists, not many professionals, but it was quite the opposite.
   There were solid technology companies there. They had their head
   screwed on straight about regulations and technical concerns. Not
   what you might expect if you just get your news from the Web.
Manu Sporny:
   http://lists.w3.org/Archives/Public/public-webpayments/2013Aug/0000.html
Manu Sporny:  The talk went really well, standing room only with
   300+ people. Lots of excitment about web payments. Still catching
   up with email. A number of people might be joining the group.
Manu Sporny:  Got some good press coverage for the work we're
   doing. Some more coming up in the next few weeks - IEEE Spectrum,
   etc.

Topic: Update on GSoC Student Progress

Andrei Oprea:  Have enabled payments in the marketplace. For
   instance in the recipies example. Checking user preferences about
   budgets. Direct purchase should work.
Andrei Oprea:  Adding parts of a regular marketplace. Can upload
   files, can select previews. Still working on how to do previews
   for audio or video.
Andrei Oprea:
   https://github.com/digitalbazaar/payswarm.js/issues/5
Manu Sporny:  Ok, so what you're implementing right now is in-app
   payments. Any other support needed?
Andrei Oprea:  url should take you to payment page. method not
   there for nonces.
Dave Longley:  Need to implement that hook yourself to handle
   nonces. It will get called for you.
Manu Sporny:  The reason we use nonces is to deal with sites
   without SSL certificates. You can handle low value transactions
   using this method.
Manu Sporny:  You can still sniff the traffic but it does let you
   use the system.
Dave Longley:  Manu talking about protecting credentials like
   cookies.
Andrei Oprea:  Still a few bugs to fix but it is a functional
   prototype.
Manu Sporny:  Got a link?
Andrei Oprea:  Dealing with a hosting issue for live site, but
   it's on github. There's an issue needing public access to
   listings and assets.
Manu Sporny:  We'll set up a VM to run the demo for you.

Topic: Continuing Analysis of MozPay API - Price Points

Manu Sporny: http://manu.sporny.org/2013/mozpay-analysis/
Manu Sporny:  Almost done with discussion on MozPay API. Only a
   few more items to go.
Manu Sporny:  Kumar, Mozilla in position of needing to adjust
   price points.
Kumar McMillan:  Currency might need to change per region and per
   carrier for direct payment.
Travis Choma:  Price points might take days or weeks to change.
Dave Longley:  What's the problem with two operators using price
   point X?
Travis Choma:  Like app store, there are various reasons to pick
   different price points.
Dave Longley:  With payswarm you could setup multiple listings
   with restrictions for each region. When you select listing to buy
   just need to match up with your region.
Kumar McMillan:  The reason we have price points is to make it
   easier to decouple how the carriers change prices for items being
   purchased. From what I'm reading about PaySwarm, you digitally
   sign the asset, but what happens if you need to change the price?
Dave Longley:  You can put an expiration on an asset.
Kumar McMillan:  An expiration might be a nice way to solve this.
Kumar McMillan:  When developer says price point 10, and price
   can vary, that sucks for developer.
Kumar McMillan:  Might be a grace period for a price to be valid.
Dave Longley:  The recipes data is resigned each day and valid
   for a day. So if you have old asset you can still buy it for a
   day, even though new price is available.
Manu Sporny:  Wanted to make sure asset and listing are valid
   even though you might not have network activity. You could still
   sign it and give it to someone who does have network access.
Dave Longley:  The validity time period is up to the owner.
Travis Choma:  The UX is also important. Might be nice to set per
   region pricing but daunting to do it. This is why you just set a
   point and all the prices and currencies are setup for you on
   current app stores.
Dave Longley:  Yeah, but you can decouple UX from prices in an
   asset. You can still ask them to set the price using a price
   point, but the asset itself would have the actual prices across
   all regions/carriers.
Kumar McMillan:  Want to understand how prices vary between
   listings. If you own an asset who would sign the listing?
Dave Longley:  Whoever is selling can sign it, it this case the
   marketplace.
Kumar McMillan:  Yeah, that might be a better solution. Allow the
   marketplace to generate pricing information for the asset based
   on price point, set it to expire within a day.
Manu Sporny:  Important to note this is a UX issue as Travis
   said.
Manu Sporny:  The developer can still pick a price tier and then
   the marketplace could pick the prices across every region the
   asset is sold in.
Manu Sporny:  Conclusion is we could support price point
   mechanism, but it sounds like setting prices on a per region
   basis would be better.
Dave Longley:  Marketplace can calculate prices for you to
   simplify things.
Kumar McMillan:  Like this, it's more explicit to the developer.
   They don't have look up prices.

Topic: Icons

Manu Sporny:  How to model this data, just a 64x64 icon. JSON-LD
   could model this. We could also model it using an array that
   contains objects describing each icon. Might be better using the
   latter approach.
Kumar McMillan:  Using array of objects makes sense. Using hash
   since that's how app manifest works. Has been discussed on dev
   list and others were unhappy about that.

Topic: Product Data

Kumar McMillan:  This format lets a merchant look up information
   about the purchase internally.
Manu Sporny:  This is an internal product identifier?
Kumar McMillan:  Yes.
Manu Sporny:  When this was discussed in the past with respect to
   PaySwarm, we wanted a richer way for users to markup store or
   vendor specific information.
Manu Sporny:  Example is home improvement store is using digital
   receipt format, they want to list out detail meta data about
   item. Like an asset description. Have weight, time, item count,
   etc that would help in the future.
Manu Sporny:  With receipt store could use that internally for
   analytics.
Dave Longley:  Users could have 3rd party analysis on your own
   data.
Dave Longley:  Don't have to come up with exact use cases but let
   people innovate with this data.
Kumar McMillan:  Product data is specific use case, not to deal
   with product data, but reconcilliation.
Kumar McMillan:  Nothing to do with sharing data with customers.
Manu Sporny:  Is product data a string or deeply nestable object?
   No harm in using object since you can still put a string as a
   key/value in the object.
Dave Longley:  The point with JSON-LD is you can put in any data
   you want. Marketplace can put anything in they want without
   stomping on other data.

Topic: Postback URL

Manu Sporny:  PaySwarm uses it. MozPay uses it. It's needed.
Kumar McMillan:  We'd like to allow developers to do in-app
   payments without their own server. Haven't figured out how to do
   it without a server at all.
Kumar McMillan:  Only solution we've found is hosting a
   verification service for developers.
Kumar McMillan:  Want to make it easy for developers. If we could
   get rid of postback URL would be easier to use.
Manu Sporny:  PaySwarm has budget concept that supports
   associating vendors.
Manu Sporny:  When you go to buy something a payment is
   pre-authorized. You can run a request and get back a
   pre-authorization.
Manu Sporny:  That's how we do subscriptions and in-app payments.
Dave Longley:  To clarify, first payment would be posted back to
   your server.
Dave Longley:  You get back note that customer has a budget.
Dave Longley:  You could get user to go setup budget.
David I. Lehn:  This is assuming that you don't need to have
   authorization for every request. [scribe assist by Manu Sporny]
David I. Lehn:  There is still a case where if you needed to have
   confirmation on every purchase, you need to have a server.
   [scribe assist by Manu Sporny]
Dave Longley:  Yes, you may need to ask user to go and update
   their budget.

Topic: Chargeback URL

Manu Sporny:  The chargeback URL is interesting, PaySwarm doesn't
   have it yet. Could you give us some background, Kumar?
Kumar McMillan:  Chargeback URL is catchall system for money
   being taken away. This may cover strange fraud, refunds, and
   other issues.
Kumar McMillan:  Lots of functionality in here. This is mostly a
   notice for developers to handle their state.
Manu Sporny:  For PaySwarm we talked about putting all messages
   to same postback URL.
Dave Longley:  For long term issues like 30 days later might have
   other authority specific mechanisms.
Manu Sporny:  We don't have a chargeback message right now.
   Probably should.
Manu Sporny:  Refunds and chargebacks are different. Notification
   of fraud might be important. May be chargeback due to fraud.
Manu Sporny:  Challenge is what messages to do in postbacks.
Manu Sporny:  Purchase successful, chargeback, or refund
   occurred.
Dave Longley:  May not be able to rely on URL. Might change over
   long period of time. As vendor need to be aware of this.
Kumar McMillan:  Having long delayed reversal message is
   theoretical. We haven't seen anything where we had to do that.
Kumar McMillan:  Not even sure our system sends chargebacks.
   Haven't implemented automatic refunds. Done manually now.
Manu Sporny:  Authority required to back all transactions on the
   network. Refunds on PaySwarm are exceptionally rare.
Manu Sporny:  Delays in their now due to current financial
   systems and consumer protections.
Manu Sporny:  Some transactions might be so high value that
   authority can't absord chargebacks and needs to pass on to
   vendor.
Kumar McMillan:  Does payswarm support refunds?
Manu Sporny:  All the data is available to do refunds, to reverse
   a transaction. We just haven't implemented it in the live system
   yet.
Kumar McMillan:  We don't want to turn on refunds for in-app
   purchases. Apps might not want to support refunds. For instance a
   game where you unlocked a level, how do you handle that?
Kumar McMillan:  Refunds would have to be opt-in. Need to be able
   to test it's handled properly or users will be angry.
Manu Sporny:  Need to think more of chargebacks. Need to figure
   out problem due to consumer protections.
Kumar McMillan:  One URL makes sense to handle this. We didn't
   have strong typing system.
Manu Sporny:  JSON-LD types will let you do this differentiation.

Topic: Analysis of JOSE specifications wrt. Web Commerce API

Manu Sporny: http://manu.sporny.org/2013/sm-vs-jose/
Manu Sporny:  Analyzed HTTP Keys vs JOSE stack.
Manu Sporny:  A number of JOSE specs used to do crypto. Post
   tries to analyze those vs the secure messaging spec.
Manu Sporny:  Post is rough, some points are weak, may go back
   and update.
Kumar McMillan:  Good discussion on the mailing list about post.
Kumar McMillan:  More library support for JWT since it's been
   around longer.
Kumar McMillan:  Can build missing libraries.
Travis Choma: I need to drop off for another meeting, see you
   next week guys. cheers!
Manu Sporny:  Libraries missing now are Ruby and Java. [work
   being done to address that]
Dave Longley: https://github.com/jsonld-java/jsonld-java
Manu Sporny:  Should be quick job for someone who knows what they
   are doing.
Manu Sporny:  Next week we'll take a deeper look at this. Figure
   out what mix of JSON, JSON-LD, etc we want to use.
Kumar McMillan:  Right now Mozilla is the only implementation.
   Can sunset features right now. Firefox OS features can change.
Manu Sporny:  Anything else? Thanks, will chat again next
   Wednesday

-- 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 Thursday, 8 August 2013 17:49:35 UTC