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 Log
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: 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: 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: concern was to match what customer and vendor support for payment providers.
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.

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