- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Wed, 26 Jun 2013 14:04:31 -0400
- To: Web Payments <public-webpayments@w3.org>
The minutes for this week's Web Payments telecon are now available here: https://payswarm.com/minutes/2013-06-26/ 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-06-26 Agenda: http://lists.w3.org/Archives/Public/public-webpayments/2013Jun/0033.html Topics: 1. Update on GSoC Student Progress 2. ISSUE-12: Registering preferred payment providers 3. Merchant Payment Provider Choice 4. Polyfills for the Payment API Chair: Manu Sporny Scribe: Manu Sporny Present: Manu Sporny, Andrei Oprea, Dave Longley, Kumar McMillan, Travis Choma, David I. Lehn Audio: http://payswarm.com/minutes/2013-06-26/audio.ogg Manu Sporny is scribing. Manu Sporny: Today on the agenda, we're covering Andrei's progress on the open Web Apps marketplace. Discussing getting rid of the whitelist for payments API for mozPay and issues surrounding that. Manu Sporny: Any updates or changes to the agenda? Topic: Update on GSoC Student Progress Andrei Oprea: Since the last time, I was able to complete Web Keys registration process for PaySwarm. The site is up here: Andrei Oprea: http://webpayments.jit.su/ Andrei Oprea: There is still an issue w/ registration process, but that should be fixed today Andrei Oprea: Next goal is to get asset and listings working. I have a question regarding that. Andrei Oprea: Asset and listing may be decentralized, does that mean that after I create an asset/listing for a good/service - should the user receive a digital receipt? Andrei Oprea: Does the asset and listing only remain on the website where they were created? Manu Sporny: In PaySwarm, assets and listings are decentralized. They are digitally signed by the content creator or vendor and they have a validity period associated with them. This means that they can be taken and placed anywhere on the Web and they'll still work. For your demo, you will have the asset and listing on the marketplace website. Andrei Oprea: Does an asset have a public URL just as the PaySwarm identity? Dave Longley: asset and listing should have their own URLs, public is good practice. Manu Sporny: it's also possible to have private assets and listings - basically, assets and listings that transact a unique good where the asset and listing are unique to the transaction. So, for example, buying an asset that has a very particular serial number. Manu Sporny: Website looks good, you're using both Persona and Web Keys, right? Andrei Oprea: Yes, you sign in w/ Persona... you need to register with payswarm authority as well. When the vendor registers, they get public/private keypair. Manu Sporny: where are you storing the private key? Is it only for the marketplace? Andrei Oprea: Yes Manu Sporny: ok, good. We don't want to get into a security situation where you're managing thousands of private keys. That would be disastrous if there was ever a security break-in. Manu Sporny: So, this is a problem for this particular use case. People have to sign in with Persona, and then they have to basically do the same things by signing in via a PaySwarm Authority. It's duplication of effort. It would be much easier to assign who your preferred providers are via Persona. Kumar McMillan: Not sure how to fully address that - not many people have tried to tie data to e-mails. Kumar McMillan: A lot of sites already tie information to Persona - they say "login with Persona", then they say "We need to complete your registration". They may need you to set a username. That might be an easy approach. "Now complete your registration". Manu Sporny: That's not an ideal experience... if that's the future of the Web, I don't think Persona does enough. We want to be able to auto-fill registration information when you sign up to a website. We don't want you to have to go through a 2 or 3 stage registration process. Travis Choma: There is a connected project, PiCL - you can store profile information in there... we are going to be looking at it for storing receipts. Manu Sporny: Are you involved in that project? Travis Choma: Not directly, but here's the link to that: https://github.com/mozilla/picl-server Manu Sporny: Yes, the site looks good that Andrei is working on. Andrei Oprea: How would developers associate their PaySwarm identity with the account. Manu Sporny: So, for the time being you're going to have to log in via Persona and then do a registration where you "log in" via PaySwarm. The resulting object when you "log in" will be an identity and financial account where deposits should be made. That'll be good enough for the first cut of the marketplace. Topic: ISSUE-12: Registering preferred payment providers https://github.com/web-payments/browser-payments/issues/12 Kumar McMillan: Real fast, before we jump into the whitelist - let's circle back for some context. Something that came up on the last payments call and discussions elsewhere. Kumar McMillan: People are asking why the mozPay API is different... why not just have a hosted buyflow? Kumar McMillan: The main difference is that it pings this central server when the merchant includes the shim. The user doesn't have any say in that. They can't say that they don't want to use the merchant use paypal or checkout. Kumar McMillan: We want device-centric selection of payment provider. Kumar McMillan: User can pay w/ bitcoin where merchant doesn't take bitcoin. It's up to the payment provider to do the translation. Kumar McMillan: MozPay is a dumb router to some servers (the mozPay API). It's a dumb pipe, not much more than that. We have a whitelist that restricts what payment providers merchants can use. Kumar McMillan: The first Firefox OS will support Mozilla's payment provider - we'll also whitelist some other providers, maybe not in the first version, we do want competition. Kumar McMillan: Whitelist is in there because it was the easiest way to ship 1.0. Kumar McMillan: We also wanted whitelist to address some security concerns. If any payment provider could show itself to the user, it could spoof mozilla payment provider. There is not a really easy way to trust that a payment provider is going to do good. Not just take money and disappear from the Internet. Kumar McMillan: What it comes down to to solve this problem, I think, is let the user decide who can be on the whitelist. Kumar McMillan: Some UI to accept/reject new users. We can put that trust in the user's hands, not in Mozilla or operator's hands who is running the device. Manu Sporny: Ultimately, this is exactly what we want - put the power to decide in the customer's hands. If we give this decision power to the payment providers, there will be collusion. If we give it to the operators, there will be collusion. Even if we give it to Mozilla, that's centralization and we don't want Mozilla picking winners and losers. At the same time, we need to protect customers from bad actors. There's a balance here that we have to hit - choice + reasonable protection. Dave Longley: Maybe we can use Web Intents to make some navigator call to register the user as a valid payment provider? Dave Longley: Maybe they would show up in the list or as a default or as a choice among many? Kumar McMillan: Yeah, Web Intents is based on Android Intents, You are on a website and click a share button, instead of having Twitter hardcoded onto the site, the device asks you how you want to share this. Kumar McMillan: So, I don't know if there is a way to fit it directly into payment processing part. It could in that a user could say he wants to use bitcoin app? Kumar McMillan: It could use a web intent to ask how you want to pay. Since Bitcoin has registered itself, it could be selected. Kumar McMillan: Registering w/ a new payment provider is interesting, we should explore that. Maybe we can use intents to register a new payment provider and establish trust. Kumar McMillan: There is a delicate balance here - we want to give user choice, but Mozilla is also in a unique position to provide security to users who are not savvy. It was easy to solve w/ a whitelist, not ideal though. Kumar McMillan: We want to retain ability to blacklist or filter out malicious intents. Maybe we can establish trust / revoke trust in some kind of trusted way. Manu Sporny: We've been kicking around an idea for a while that we'd have a whitelist registry for PaySwarm. This registry would require fairly testable criteria: 1) Is the company a business and 2) Are they running software that passes the test suite? That could be a first cut. The second stage would be public trust metrics, like "Has any other payment provider asserted that this payment provider owes them money?". This concept could be extended to vendors and buyers as well. Having a trust system in place would make it easier to determine bad players in a decentralized fashion. Kumar McMillan: Is this a centralized solution, or a decentralized service? Manu Sporny: Ideally decentralized, because if we centralize it and it's not under the control of an independent 3rd party, then there is a risk of collusion. Does that answer the question? Kumar McMillan: yes, thanks Travis Choma: If a verification is verifying the address - maybe we can show the user the address when they associate the payment provider. That would be another thing we could do to help prevent phishing. Dave Longley: If a merchant and a buyer have two different payment providers, both payment providers must trust each other in order to exchange money. If a payment provider isn't on that list, it's going to be a big barrier. Dave Longley: We may want to require that payment providers on the whitelist do business w/ others on the whitelist. Dave Longley: if a payment provider meets a basic reputation level or other parameters [scribe assist by Dave Longley] Kumar McMillan: So, to clarify - you do want to get rid of the whitelist? Manu Sporny: Yes, user prompt first, then centralized whitelist/blacklist, then decentralized trust metrics. Kumar McMillan: We could allow users to add whatever they wanted, but we could switch to a blacklist model. Kumar McMillan: That's the way firefox addons work - there are some pretty vicious addons. It's not an ideal end-game solution, maybe we can begin to build a trust model that would replace the centralized blacklist. Manu Sporny: Concerned about blacklist - there are millions of sites out there that could be blacklisted. The problem is that it's easy to setup a domain and make the payment provider registration call. Kumar McMillan: Yeah, it's a concern. It does provide some protection. Manu Sporny: Ok, so to put out a strawman proposal, we're talking about an API call that looks like this: navigator.payments.register() Dave Longley: Yes, when you go to a payment provider, that provider should be able to register itself with payment provider. Topic: Merchant Payment Provider Choice Travis Choma: I was going to add - question - if there is a register call, the user would be prompted if they would want to use payment provider? Travis Choma: Can the merchant choose which payment provider the user can use? We've talked about customer choice, what about the merchant? Travis Choma: Different payment providers may clear funds at a different rate, can merchants choose? David I. Lehn: Yes, this is important for PaySwarm, certainly. Choice for both the buyer and vendor side. Kumar McMillan: We only did customer choice here - easier problem than merchant choice. In order to use a payment provider, they have to trust that they're going to get paid. otherwise going to get scammed. Kumar McMillan: Whitelist is a very user-centric problem. In the initial stage, we can't tackle solving the merchant whitelist. Kumar McMillan: Merchant would have their own trusted providers. If they're using Wallet, customer can only use wallet. Kumar McMillan: PaySwarm could solve that problem, it's separate from user whitelist issue. Dave Longley: With PaySwarm, merchant and buyer can use different payment providers. Dave Longley: effectively what would happen, though, is that they'd be interoperable and it would just work. Dave Longley: Merchant's choice is still there to pick a payment provider that they trust. Money would always just flow. In a different system, where you have to pick same provider between merchant and user, you may need to have something where merchant states what their preferences are. Dave Longley: Everyone uses the payswarm protocol, everyone gets paid, that's one of the big benefits of PaySwarm. If they're using something like PayPal or Amazon Payments, then both the customer and the merchant are forced to use the same system. If PayPal or Amazon Payments implements PaySwarm, then there is interoperability between those two services. Manu Sporny: We can provide a way for merchants to limit payment processor choice via navigator.payments.getProviders() - which would return a list of payment providers that the customer has. Dave Longley: You could have a restricted list that user can choose from based on who merchant uses for payment provisioning. So, if customer has Meritora, PayPal, and Amazon Payments, and merchant only accepts PayPal, then PayPal is negotiated. Topic: Polyfills for the Payment API Manu Sporny: I think polyfills are going to be very important to getting adoption. We plan to support this, right? Kumar McMillan: There's been a lot of pushback against polyfills at Mozilla... not sure exactly why. Kumar McMillan: We could polyfill API to get Android up and running, they wanted to implement native Android API. Kumar McMillan: So, I don't know if this pushback is for Mozilla's case. Kumar McMillan: I think polyfills are essential for adoption. Kumar McMillan: I don't see a way around it - a lot of the concerns against the polyfill come from security concerns - phishing case. They want to show a native chrome window. Kumar McMillan: Sounds like polyfill is a last resort for Mozilla. Then again, Google Wallet is a polyfill. Travis Choma: Kumar, I agree re your point on polyfilling. Manu Sporny: Yeah, we just need to not prevent polyfills in the API Dave Longley: There are other things we can do - payment providers show custom images to users where sensitive information is displayed. There are solutions for some of the phishing cases. Manu Sporny: Ok, so it sounds like we have consensus on this. Kumar McMillan: Registration idea is straight forward, sounds like a decent approach. Kumar McMillan: How is getProviders() going to work, again? Kumar McMillan: If you have an idea for the spec, maybe you can write it up in the spec... Dave Longley: I think early on, if a merchant doesn't see a provider they trust, they have to tell the user. Manu Sporny: navigator.payment.getProviders() will probably return a list of providers that the customer has. It would be taken from the list populated by the navigator.payments.register() call. The vendor would then create a UI that would allow purchases to be initiated with any one of the ones in the getProviders() list that they support. Kumar McMillan: Maybe we can provide some way for the merchant to figure out trending payment providers as well? It would be good to know how many sales have been lost due to a failure to use a particular payment provider. Dave Longley: They could keep track of who is in that list, it would be a fairly clean way to collect that data. Manu Sporny: There is a security concern with this. You wouldn't want any website to be able to get the list of payment providers you have. It would be like allowing anyone to take a look in your wallet to see what sorts of credit cards you have. We would probably have to change getProviders() to take a list that the vendor supports. This isn't an issue for PaySwarm, but it is an issue for PayPal, Google Wallet, etc. Dave Longley: Merchant could give list of restricted providers they accept. Then browser responds, then site can put up information. That way we are not leaking information and they can tell when they've lost a sale to someone that doesn't have the same payment provider that they do. Kumar McMillan: thanks all for the call, chat with all of you next week. -- 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, 26 June 2013 18:05:16 UTC