Web Payments Community Group Telecon

Minutes for 2011-10-07

Agenda
http://lists.w3.org/Archives/Public/public-webpayments/2011Oct/0002.html
Topics
  1. Payment Links
  2. Gradual Rollout of Web Payment Technologies
  3. Use Case Review (continued)
  4. Donor-Centric Donations
  5. Software Distribution
  6. Per-page Payments
  7. High-Quality/Low-Quality Image Sales
  8. Manufacturing Rights to an Invention
  9. Subscription-based Games
  10. Any Other Business?
Chair
Manu Sporny
Scribe
Jose 'Manny' De Loera
Present
Jose 'Manny' De Loera, Manu Sporny, Pelle Braendgaard, David I. Lehn
Audio Log
Jose 'Manny' De Loera is scribing.

Topic: Payment Links

Manu Sporny: Let's limit discussion to payment links to 15 min for brevity purposes and cover it gradually over the next several web conferences
Pelle Braendgaard: payment links is a simple attempt of getting individuals to integrate with a payment standard - it is simple way to request payment.
Pelle Braendgaard: Paypal does have something similar, but there is a need for standardization
Manu Sporny: My main concern is to find a middle ground, but if we stop at payment links, it does not address many of the use cases we have
Manu Sporny: another concern is if payment link spec is created, what is the likelyhood that Amazon and others would utilize such a link
Pelle Braendgaard: not much interest from PayPal, Amazon or Google - they're the leaders and probably don't want anything that would enable competition... European banks have expressed interest.
Manu Sporny: moving forward to create spec for payment links would be expressed in an IRI, it is not an end solution, but it still may be worth pursuing
Manu Sporny: The examples are for http, but it should work for any Internet protocol that has a scheme with parameterized options.
Pelle Braendgaard: Square could use this scheme to do Web Payments via Square's application.
Manu Sporny: I will volunteer to translate Pelle's email into a spec and we'll take it from there.

Topic: Gradual Rollout of Web Payment Technologies

Pelle Braendgaard: We should focus on releasing different tier-ed levels of payment standards, rather than present this all at once. A tiered approach with payment link being first would be good.
Pelle Braendgaard: It's difficult to sell the whole idea at one time. It's not the agile way of doing things, start small with payment links and then auto-payments then build on that.
Manu agrees since payment technologies can be overwhelming technologically.
Manu Sporny: The end goal is the democratization of finance. I agree that a gradual roll-out may help us maximize our ability to be successful. We will make mistakes along the way, we need to be able to learn from failures... not get to the end and find out that we have specified something that nobody is going to use.
Manu Sporny: However, I want to make sure that we don't lose sight of the end goal - the democratization of finance - the work we do here should have a massively positive effect on the world - how people pool resources - not just slightly tweak the way people pay each other.
Manu Sporny: Payment Links do fit in with PaySwarm - we could utilize email address a simple peer-to-peer transaction. What about the other two - Automated Payments and Payment Notifications?
Pelle Braendgaard: on automated payment processing - the way it would work would be to use an OAuth token with certain permissions to charge $20 a month for X many months.
Pelle Braendgaard: Payment Notifications are similar to PayPal IPN
Pelle Braendgaard: Another example of why we can't roll out the whole thing at one time i.e. pre-existing invoicing system, can't roll out PaySwarm until you can integrate it into their invoicing system.
Jose 'Manny' De Loera: I agree - gradual rollout seems reasonable - agile way is good - start small, get acceptance - build on that. [scribe assist by Manu Sporny]
David I. Lehn: I'm sure we'll do a good bit of this work in parallel. [scribe assist by Manu Sporny]
Manu Sporny: Ok, then - we all agree on the basic direction of a gradual roll out.

Topic: Use Case Review (continued)

Manu Sporny: The last use-case we covered was the Publishing with Per-Country Prices use case.
Manu Sporny: The next use case is the whistleblower use case.

Topic: Donor-Centric Donations

A whistleblower leaking documents from inside the government showing evidence of torture practices, in text or pdf. She specifies: anonymity; no content modification; free, but donation requested (user chooses); no commercializing.
Manu Sporny: anonymity is already covered - upload via Tor or proxy organization. The request of donations is where payment links could be utilized.
Manu Sporny: commercialization and no content modification cannot be enforced if you are anonymous - so you'd have to go through another organization.
Pelle Braendgaard: Something like the Free Software foundation may be one way to enforce that - they enforce GPL on behalf of licensors.
Manu Sporny: Dontations may work best with the Payment Links stuff we just discussed and something a bit more dynamic like PaySwarm with multiple listings for each suggested donation target. We also support the ability for people to specify extra their own Payees via a contract.
Jose 'Manny' De Loera: If we think we can support it w/ the current spec, we might as well support it. Payment Links seems like it would work out well in this case - we should support this use case. [scribe assist by Manu Sporny]
Manu Sporny: We also state in the PaySwarm spec that the license should be machine readable, but linked to via a URL - so machine-readability of licenses is important.
Use case is accepted, specifically for the Payment Links portion of the use case.

Topic: Software Distribution

A software engineer with a program for a particular OS, in zip or other compressed format. He specifies: authorship; no content modification; payment per download with constraints/permissions of: demo use is free on one machine for a month; payment thereafter is due for each machine in use with the program; downstream commercializing is possible with constraint of: payment to original author of 25% of net profits from resale or from any other commercializing, specifically including advertising.
Manu Sporny: This is an incredibly complex use case, with most of the important bits falling outside of the purview of a payments specification of any kind.
Manu Sporny: The major issue is that there is no easily spec-able way to enforce these constraints via software... most of this falls into enforcement via the legal system. Let's go through each item...
Manu Sporny: authorship and no content modification - covered by standard copyright. Downstream commercialization is covered by another use case as is 25% profit margin. Payment per download is covered by another use case.
Manu Sporny: Enforcing a cut of advertising revenue is far outside of the scope of any of the specs we intend to work on and it's very difficult to enforce in software without a completely unified software architecture for sales and advertising.
Manu Sporny: I think we should reject use case outright and not add it to our future timeline - we already cover the stuff we can cover and the rest of the stuff is not implementable in software.
General agreement, no objections to rejecting the use case. This use case is rejected.

Topic: Per-page Payments

A carpenter publishes plans with photos and text describing how to build a solar outhouse, in html or pdf. He specifies: authorship; no content modification; payment per download (pdf); payment per page view (HTML); no downstream commercializing.
Manu Sporny: I don't understand what he means by "payment per page view" - does that mean for every time the person loads the page?
Jose 'Manny' De Loera: Maybe he means that that page one is free, but the rest are for-profit pages. Page 2 is measurements, page 3 is the material you'll need, page 4 is how to build it, etc. [scribe assist by Manu Sporny]
Manu Sporny: other way to read that is that every single browser refresh causes another payment to happen - although, that's a pretty lame business model, so it must be what you said, Manny.
Manu Sporny: Payment per download and payment for pages identified by URLs is already covered by another use case
This use case is rejected since all items are covered in other use cases.

Topic: High-Quality/Low-Quality Image Sales

A visual artist (oils and acrylics) with high- and low-resolution JPEGs of the paintings. She specifies: authorship; no content modification; free access online to low-res images of paintings; payment per download for hi-res images of paintings, calculated by total surface area of the image; downstream commercializing permitted with explicit author agreement.
Pelle Braendgaard: I think this use case is covered by the other use cases. Calculating by total surface area of the image is something the sales software would do - doesn't have to be in the spec. [scribe assist by Manu Sporny]
Jose 'Manny' De Loera: This is covered - also if you use SVG - there is no "total surface area" [scribe assist by Manu Sporny]
Agreement that this use case is covered by other previously approved use cases.

Topic: Manufacturing Rights to an Invention

An inventor of a patented simplified mechanical tool with a description in pdf and html text accompanied by embedded jpegs. He specifies: authorship; no content modification; free HTML access to a summary of the tool specification; payment per pdf download of the complete specification including patent document; downstream commercializing allowed with constraints of: no resale of the patent or description itself; manufacturing of the tool for sale in any given country is permitted after explicit agreement with the inventor for that country.
Manu Sporny: All of the items above are covered by previously approved use cases, standard copyright law and standard patent law.
Manu Sporny: This is good, we seem to be hitting a saturation point with the use cases. The more we start rejecting, the more certain that we can be that we have a good sampling of what people will want to do with these standards.

Topic: Subscription-based Games

A digital game programmer with a new multi-player game for online and/or offline use. He specifies: authorship; content modification allowed with constraint of: no commercialization once modified; payment for online use by subscription (monthly, yearly); or single payment for downloaded version; downstream commercializing permitted for unmodified download version only, with constraints of: 30% of gross sales receipts paid to original author, as well as 10% of site advertising revenue (if any) from the downstream page selling the game.
Manu Sporny: Strange... we don't have a use case for subscriptions yet - such a useful use case - payment for online use by subscription (monthly, yearly)
Manu Sporny: These are already covered by other use cases or standard copyright: authorship; or single payment for downloaded version; downstream commercializing permitted for unmodified download version only, with constraints of: 30% of gross sales receipts paid to original author
Manu Sporny: These are not implementable in software, but could be a part of the license: content modification allowed with constraint of: no commercialization once modified; as well as 10% of site advertising revenue (if any) from the downstream page selling the game.
Pelle Braendgaard: Yes, this is a very important use case - we must support subscriptions.
General agreement that we support the subscription-based use case.

Topic: Any Other Business?

Pelle Braendgaard: I may have some other possible use cases - I will send them out on the mailing list.
Manu Sporny: Ok, so how about we take a one week break from meetings and then come back and discuss requirements?
Pelle Braendgaard: I'll send my use case in for physical product sales - application of device in physical space such as NFC device or payment card via OAuth
Manu Sporny: Our next meeting will be October 20th, 2011.

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