Web Payments Community Group Telecon

Minutes for 2011-09-30

  1. Web Payments Base Technology Platform
  2. Quick update on PaySwarm spec
  3. Standardizing Payment Links
  4. Steven Rowat Use Case Review (continued)
  5. Anonymous, Free Content
  6. Conditional Re-Distribution
  7. Publishing with Per-Country Prices
  8. Picking a Chair
Manu Sporny
Mike Johnson
Pelle Braendgaard, Manu Sporny, David I. Lehn, Jeff Sayre, Mike Johnson, Jose 'Manny' De Loera
Audio Log
Pelle Braendgaard is scribing.
Manu Sporny: We have Payment Links and use cases on the Agenda today, any additions to the Agenda?
Pelle Braendgaard: I'd like to discuss the base technology platform for this work - because it sounds like it is PaySwarm?

Topic: Web Payments Base Technology Platform

Manu Sporny: We need a base standard to work from, we don't want this work to devolve into philosophical discussion.
Manu Sporny: We are proposing PaySwarm as the base technology because it seems to fit the use cases discussed thus far the best. However, it is not a fully baked specification, it is undergoing heavy change - specifically, the change from OAuth 1.0a to digitally signed messages.
Manu Sporny: We need to bring ideas and technical concepts in from Bitcoin and Open Transact and Open Transactions. We need to support as much as possible without overly complicating the specification.
Manu Sporny: We need to create something simple... and do it quickly.
Pelle Braendgaard: I think that we need to have discussions about the basics... use cases are important. [scribe assist by Manu Sporny]
Pelle Braendgaard: However, I do think PaySwarm, as it is is too complex - it's too wide - it wants to do too many things. It would be easier if we split it into smaller pieces. [scribe assist by Manu Sporny]
Pelle Braendgaard: I find it difficult to see how it could take off in its current level of complexity. [scribe assist by Manu Sporny]
Manu Sporny: Typically the way standards associations works is that we need to work out the use cases, then settle on requirements, then dive into the technical discussion. That's what we're attempting to do here.
David I. Lehn: Also, please feel free to send messages to mailing list with concerns about the direction of Payswarm.
Manu Sporny: Yes, let's please have this discussion sooner than later. On the mailing list would be great because we want to have a record of this conversation and the reasons that we are making the decisions that we're making.

Topic: Quick update on PaySwarm spec

Manu Sporny: PaySwarm spec is being simplified. The latest release uses digital signatures instead of OAuth 1.0a.
Manu Sporny: We needed to implement nonces as we moved away from OAuth 1.0a, which also uses nonces. The nonce's didn't scale for Twitter, Facebook etc, but is needed for small publishers if we are not going to use OAuth 1.0a. We found a more elegant solution than nonces, but we're still working on it.
Manu Sporny: We use a form of asymmetric message encryption. PaySwarm Authorities that are required to use SSL, which means that asynchronous messages coming back can be encrypted in a different way and delivered over regular HTTP. This means that publishers can use plain HTTP - they don't need to buy an expensive security certificate every year to be able to sell content via their website. So, we have removed the need for nonces, which makes the technology scale, while protecting against replay attacks and ensuring that Web Publishers don't need an SSL certificate in order to sell things via the Web.

Topic: Standardizing Payment Links

Manu Sporny: I wrote this article last week http://manu.sporny.org/2011/payment-links/ in response to the bitcoin community's desire for a payment link.
Jeff Sayre: The article questions whether or not we need a standard way of expressing payment links on the web? [scribe assist by Manu Sporny]
Jeff Sayre: In the post, Manu suggests how Payment Links could be implemented, but questions whether or not they should be implemented - what use cases they solve. [scribe assist by Manu Sporny]
Manu Sporny: Just having a payment link without describing what is being payed is insufficient - people like paying for refined goods, they have more of a problem buying unrefined goods and Payment Links seem to be associated with unrefined goods (tipjars, donations, etc.). Gregory Rader has a good series of posts on this topic
Manu Sporny: You don't know what you are paying for and who you are paying - it's not tied in with the purchase process - that's problematic for pure Payment Links.
Pelle Braendgaard: So, I think very differently on this - I think a simple payment link is a great idea. [scribe assist by Manu Sporny]
Pelle Braendgaard: We can't model everything out - whatever you are buying - it's out of the scope of a Web standard. I think the bitcoin standard link is a good idea - but for web-based systems - it should be a URL with some parameters on the end of it. It really doesn't have to be more complex than that. I think it'll be an error if we get more complex than that. [scribe assist by Manu Sporny]
Jeff Sayre: I agree. We don't want to be in a situation where there needs to be a new IRI for every new payment scheme that comes up. We need to be sufficiently generalized. There are issues with payment links - bitcoin example in Manu's article is good. We want something more generalized - that gets around the uniqueness of each currency. [scribe assist by Manu Sporny]
Mike Johnson is scribing.
Pelle Braendgaard: 99.9% payments are done without digital sigs, fully legal. Legal system does not care about digital signatures and RDF. Courts care about email, HTML, and logs. Engineers over-complicate, payment links will fail if they turn it into something complex.
Pelle Braendgaard: No need for standard, PayPal just uses https links. It can be good to add some details, but there is no need for a payer field or bitcoin accounts to draw from.
Pelle Braendgaard: Link, specify amount, who it is to and some other information. Can just be straight HTML.
Manu Sporny: That argues away the entire need for standardization. That link allows people to implement whatever they want, but the whole point is to standardize the architecture people use to pay each other.
Manu Sporny: If you take the oversimplification approach, that does nothing to standardize the payment process.
Pelle Braendgaard: Take only one thing to standardize, payment link would be a lowest common denominator.
Pelle Braendgaard: Payment links now have an asset as well. Payment provider builds something based off the link information.
Pelle Braendgaard: I'm worried about over-complicating.
Manu Sporny: I'm lost as to the direction Pelle wants the group to head in... what is actionable from what Pelle is saying?
Pelle Braendgaard: Payment link is just one of the really basic things, a starting point.
Pelle Braendgaard: Have a link on your homepage with your banking details exposed for payment, don't destroy implicitness of link. Links should have some parameters that are standardized, rest is just the web.
Pelle Braendgaard: Bitcoins don't need to understand assets. Bitcoin just handles the payment part.
Manu Sporny: Pelle wants just a generic payment link, parameters are just standardized.
Pelle Braendgaard: Just a link, not even attributes. Something you could put in an email and someone could follow to do payment.
Manu Sporny: Why would that need to be standardized at all, parameters are part of HTTP - people can do this today.
Pelle Braendgaard: Parameters should be known to work with any payment mechanism - it would be a way of expressing how much you want to get paid and where to deposit the money.
Manu Sporny: Amount and person to pay should be in the link.
Pelle Braendgaard: Even the amount should be optional.
Manu Sporny: Too hard to solve with just a link without browser (user-agent) knowing what accounts are.
Manu Sporny: To do that you have to assume that the person has to have a specialized account for whatever service you want to use.
Pelle Braendgaard: The person has to have that account, PayPal, Bitcoin, etc.
Manu Sporny: Yes, but then you have the NASCAR problem - sites plastered with all sorts of payment buttons.
Pelle Braendgaard: Yes, but that is a different issue.
Manu Sporny: Let's discuss this on the mailing list - it would be good to understand the exact proposal.
Pelle will write up a proposal and send to mailing list.

Topic: Steven Rowat Use Case Review (continued)

Manu Sporny: Most of these use cases are addressed by discussing the licenses associated with the asset. That conveys most of the information necessary.
Manu Sporny: We addressed case 1 last week, we will start with 2.

Topic: Anonymous, Free Content

A journalist in Africa with an ogg or mp4 video of atrocities in an ongoing war. She specifies: anonymity; no content modification; free; no downstream commercializing.
Manu Sporny: Probably associate CC no-derivs license with the work. Distribute for free, no downstream commercializing.
Manu Sporny: 2 seems not to be a use case we have to cover, Creative Commons handles this use case completely.
Mike Johnson: Mike: +1
Group chooses to pass on use case 2 - it is handled by Creative Commons

Topic: Conditional Re-Distribution

A writer with a complete novel in pdf, doc, html, and other text formats. He specifies: authorship as pseudonym; no content modification; payment per download; downstream commercializing allowed with constraints of: no advertising (direct sale only); payment of 20% of gross per copy re-sold; any additional commercial rights for other media must obtain agreement of the original author.
Manu Sporny: Downstream commercialization, direct sale only and no advertising.
Manu Sporny: PaySwarm listings allow a variety of terms to limit resale rules.
Manu Sporny: No other rights are conveyed unless they are specified.
Manu Sporny: Standard copyright practice for no content modification and requirement for additional commercial rights to be cleared by the author.
Jeff Sayre: I agree that this falls under payment - it's a use case we care about.
Jeff Sayre: My company, PubPie, would benefit from this.
Jeff Sayre: Resale would help, gets around copyright and DRM issues, has social incentive.
Jose 'Manny' De Loera: Very benefitial, expands distribution ability for authors while maintaining control.
Pelle Braendgaard: +1
Mike Johnson: +1
Group accepts conditional redistribution use case.

Topic: Publishing with Per-Country Prices

A folk-musician in Siberia who records local throat-singing into mp3 or ogg vorbis files. He specifies: authorship; no content modification; free streaming of first 10% of content online; payment per download at sliding scale proportional to user-country's average yearly income per person; no downstream commercializing.
Manu Sporny: This use case basically allows a 10% sample and per-capita income price adjustment. No downstream commercializing.
Manu Sporny: Free streaming might make sense if other people just stream 10% from their websites.
Manu Sporny: First and last requirements fall out due to being address by standard copyright.
Manu Sporny: License would have to allow first 10% to be streamed without compensation.
Manu Sporny: Sliding payment scale can be accomplished in two ways: Geoloc IP database to serve up different payment licenses with the PaySwarm Authority enforcing regions.
Manu Sporny: technically it can be accomplished, but it is very complicated to do on the client-side.
Manu Sporny: From a PaySwarm perspective the Authority would just have to enforce regional licenses.
Jeff Sayre: Applies to publishing as well. Sliding scale of royalties. Net or retail books sold above this many units, additional royalty earned.
Jeff Sayre: What scale and what unit? Books sold, country sold in, etc.
Jeff Sayre: What you are talking about - how are payments split.
Mike Johnson: This is how the movie industry does things too - they have a bunch of different regions - Region 2, Region 1 - publishers may still be interested in locking down content to different regions. [scribe assist by Manu Sporny]
Jose 'Manny' De Loera: This happened to me the other day too, downloading a Kindle book and was denied because not in US.
Mike Johnson: We still need to understand whether or not the PaySwarm Authority needs to enforce these criteria - maybe this should be PA specific - maybe it doesn't need to apply to all PAs? [scribe assist by Manu Sporny]
Jose 'Manny' De Loera: Odd to happen with books.
Jeff Sayre: Can get around using anonymizer sites, but those are often prevented.
Jose 'Manny' De Loera: In this particular case, how would someone using an IP masker be able to prove they are not in a specific region.
Manu Sporny: Do we even want to support this to start, because it often works against publishers (and customers!) when people cannot access content in their region.
Jeff Sayre: With a publisher, an author might have US rights only contract, or Aussie, etc.
Jeff Sayre: Most get world rights now, but there might be specific cases.
Mike Johnson: There is a huge legacy to music licensing here as well - you can't distribute outside of country it was created in... lots of cases where this is applicable. Hard to say if we need to address it in PaySwarm 1.0 - do we create a mechanism, but don't directly address this use case right now? [scribe assist by Manu Sporny]
Jeff Sayre: Maybe this is something we can push to 2.0?
Jose 'Manny' De Loera: Yes, this does seem to be very complex.
Manu Sporny: We do have legacy issues, and some publishers without the ability to limit might be in big trouble unless we are able to support this.
Manu Sporny: The standard definitely needs to address this, and though we may push it off to 2.0 we need to not limit this from happening in the future in the 1.0 spec.
Manu Sporny: We should add to 1.0, but I do not feel strongly about this.
Jeff Sayre: Larger institutions would probably like this support earlier than later.
Manu Sporny: Allowing the transaction based on the sellers country and buyers country.
Mike Johnson: Is this only applicable to countries? Or is it broader? [scribe assist by Manu Sporny]
Manu Sporny: This use case is complex, not just on country of origin, was on GDP and such.
Manu Sporny: Making listings for every country might be wasteful, complex.
Manu Sporny: Another way to address the issue would be a payment formula.
Mike Johnson: Since each authority may be run by a different company, maybe some would allow certain types of transactions and others wouldn't. [scribe assist by Manu Sporny]
Pelle Braendgaard: This is a competitive implementation detail - all the standard might need is plain english explaining how to apply the general process, but the more specific stuff in an external specification. [scribe assist by Manu Sporny]
Manu Sporny: We may want to address in PaySwarm 1.0, but not address all business rules.
Manu Sporny: Let's push to 2.0, but be willing to address in 1.0 if we feel we need to have it sooner.
Mike Johnson: +1
Manu Sporny: We're out of time for this call. Thanks for everyone's contributions.
Manu Sporny: Let's do another call next week, use cases take time but we are making good progress.
Jeff Sayre: I maybe absent next two weeks - traveling.

Topic: Picking a Chair

Manu Sporny: We might not pick a chair for right now, operating fine without one. Need more people in group so it's not just the few of us picking from a select few.
Manu Sporny: We will need the chair more once have more members and more paperwork, until then, I can do all the paperwork as I have been doing these past several months.
The group agrees to operate without chair for now.

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