W3C home > Mailing lists > Public > public-webpayments@w3.org > October 2011

Web Payments Telecon Minutes for 2011-10-07

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Fri, 07 Oct 2011 15:26:54 -0400
Message-ID: <4E8F527E.5010603@digitalbazaar.com>
To: Web Payments CG <public-webpayments@w3.org>
The minutes for today's call are now available here, thanks to Manny
for scribing:

http://payswarm.com/minutes/2011-10-07/

Full text of the discussion follows, as well as a link to the complete
audio transcript:

Web Payments Community Group Telecon Minutes for 2011-10-07

Agenda:
   http://lists.w3.org/Archives/Public/public-webpayments/2011Oct/0002.html
Chair:
   Manu Sporny
Scribe:
   Jose 'Manny' De Loera
Present:
   Jose 'Manny' De Loera, Manu Sporny, Pelle Braendgaard, David I.
   Lehn

Jose 'Manny' De Loera is scribing.

Topic: Payment Links

Manu Sporny:
   http://lists.w3.org/Archives/Public/public-webpayments/2011Oct/0000.html
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:
   http://lists.w3.org/Archives/Public/www-tag/2009Sep/0055.html
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.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
Standardizing Payment Links
http://manu.sporny.org/2011/payment-links/
Received on Friday, 7 October 2011 19:27:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 7 October 2011 19:27:24 GMT