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 message format
  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 Log
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: 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.
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 message format

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: 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]
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

Created by the Web Payments Community Group. Shared with love under a CC-BY license.