PaySwarm - Use Cases

Unofficial Draft 25 October 2011

Editor:
Manu Sporny, Digital Bazaar, Inc.

Abstract

The primary goal of the Web Payments work at the World Wide Web Consortium (W3C) is to create a safe, decentralized system and a set of open, patent and royalty-free specifications that allow people on the Web to send each other money as easily as they exchange instant messages and e-mail today. The following use cases focus on transforming the way we reward each other on the Web as well as how we organize financial resources to enhance our personal lives and pursue endeavors that improve upon the human condition.

Status of This Document

This document is merely a public working draft of a potential specification. It has no official standing of any kind and does not represent the support or consensus of any standards organisation.

Table of Contents

1. Introduction

The Web continues to transform the way humankind communicates and builds our world. At the heart of most of these endeavors is the exchange of value. Gifts, attention, and payments each play a role in the ecosystem that we call the economy. Until now, there has been no open and universal way of sending and receiving payments on the Web through your browser. This is why people are still compelled to reach for their credit card or log into a payment site when purchasing something over the Web.

There are a number non-interoperable payment solutions today. This document outlines use cases that are supported by existing payment solutions today, and also outlines innovative use cases that could be supported in the future by a universal payment mechanism to enable next generation mobile payments, alternative currencies, crowd-sourced investing, next-generation banking, and electronic commerce.

This specification outlines use cases that are enabled by universal payment for the Web. The goal of addressing the use cases as a whole is to create a safe, decentralized system and a set of open, patent and royalty-free specifications that allow people on the Web to send each other money as easily as they exchange instant messages and e-mail today. Addressing these scenarios will transform the way we reward each other on the Web as well as how we organize financial resources to enhance our personal lives and pursue endeavors that improve upon the human condition.

2. PaySwarm 1.0 Use Cases

The following use cases outline scenarios that are targeted to be supported in the set of PaySwarm 1.0 specifications.

2.2 Independent Distribution and Pricing

Jude blogs about music and movies and has achieved a respectable following of people that read his blog. He would like to sell content that he writes about to his many readers, but doesn't have the music and movie industry connections to acquire content for distribution. Typically, content deals require an multi-million dollar, advance payment in return for the right to sell content. This high up-front cost removes many potential sellers, harming the overall incentive to distribute for people that run smaller music websites and blogs.

There are many existing clearing houses for content on the web today. If those clearing houses were able to manage artist content, content creators could use the clearing house to setup the distribution rights for their content. Smaller content distributors, like Jude, could then offer content to their site visitors without worrying about the high-cost or management overhead associated with managing content catalogs.

2.2.1 Requirements

  • The asset provider (blogger) may be a separate entity from asset owner (musician/label/production company).
  • The asset provider must be able to distribute content without the asset owner direct permission as long as the asset license and royalty payments set by the asset creator is respected.
  • The asset provider must be able to set distribution prices independently of the asset owner.
  • The asset owner must be able to set base royalties independently of the asset provider and those base royalties must be enforced by the transaction authority.

2.3 Decentralized, Machine-readable Metadata

Lars would like to ensure that the purchase process for a digital good is streamlined as much as possible into the web browser that he has created. When somebody uses the web browser, he would like to display a "Buy" button in the address bar. The media details such as the title of the work, the price and the details required to perform a swarming purchase would be lifted from the web page.

The purchase process would be as simple as the buyer clicking the Buy button and watching a download progress dialog appear on the screen. Account and payment details could be stored in the web browser to ease the purchase process. Not bothering the person browsing for payment details would be especially useful in scenarios where very small payments were needed to access content.

2.3.1 Requirements

  • Asset details should be expressed in a Web page such that a Web User-Agent can extract the details of a piece of digital content.
  • All relevant payment details should be expressed in a Web page such that a Web User-Agent may purchase content after detecting the payment processing details on a page.
  • All assets and listings for sale must be able to be listed in an ad-hoc manner. There must not be a centralized asset or listing service of any kind.

2.4 Separation of Content from Licenses

The Association of Science Journalists Conference would like to present a series of live keynotes by luminaries in their respective fields. The presentations would be open to conference attendees or those that pay for a virtual day pass for the conference. The license could be purchased separately and then could be used to access a number of download sources. Remote access to journalists would be granted at a different payment rate than non-members.

It is important that a separation is made between the content license and the download contract. The content license specifies usage and access rights. The download contract specifies the download negotiables, such as payment rate, speed and other details associated with the data stream. By separating the two concerns, we can allow network specialization to occur between those that would grant licenses for digital content and those that would deliver digital content. Ensuring that both could operate semi-autonomously would allow semi-independent optimization of market variables.

2.4.1 Requirements

  • The system must be able to distinguish between licenses and contracts for data delivery.
  • One should be able to purchase the license and then have the option of choosing their download source separately. Content licenses and data delivery contracts should be able to be negotiated separately.
  • Licenses may be used to get access to data streams on 3rd party provider sites. Payment for licenses and payment for data should be separate concerns.

2.5 Micropayments to Thousands of Individuals

Penelope has completed her fourth book of photography. She would like to charge a very small amount for her travel expenses and supplies but doesn't want to make a living from the sale of her book. Penelope does, however, want to make a number of contributions to charities that she would like to support as well as give her fans the ability to contribute to their favorite charities.

Giving individuals on the network the ability to add optional payees to licenses and contracts would enable payment models such as online tipping for artists, donations to charity, and batched payments to a particular initiative or cause to be made along-side the purchase.

2.5.1 Requirements

  • Network participants must be allowed to add arbitrary accounts as payees for transactions if allowed by the original content owner.
  • A large number of payee accounts must be allowed to be batched with content transactions. Lists of payees should be allowable up in the thousands of payees.

2.6 Re-Sale Permissions

Quincy, a medical researcher in the USA, produces a PDF report about the side-effects of a new prescription drug. He wants to sell access to the full article from his website, but with a "no resale" limitation.

2.6.1 Requirements

  • Assets must be allowed to be only re-sold by the original creator of that asset through some set of "resale permissions" that are expressed in the asset listing.

2.7 Recurring Payments

A game programmer creates a new multi-player game for online and/or offline use. He would like to list the game for sale online noting him as the game creator. He also believes in player generated content, so would like to allow content modification. However, if the game is modified, it can no longer be commercialized. He would like to collect payment for online use by subscription (monthly, yearly); or collect a single payment for the downloaded version of the game. He also wants to allow downstream commercializing for the unmodified, downloaded version only. The downloaded version profit should be limited to 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.

2.7.1 Requirements

  • Subscription-based payments must be supported.
  • Ad-hoc, recurring payments must be supported.
  • Complex rules must be allowed in the license. The rules may be machine-readable.

2.8 Mobile Computing-based Purchase

Boris picks out a few items at a street vendor stand and wants to check out using his mobile device. The vendor tallys up all of the items that Boris wants and points Boris at a nearby NFC reader. Boris waves his phone in front of the NFC reader, views the amount and clicks the Pay button. The vendor is notified and gives Boris his items.

2.8.1 Requirements

  • A mobile device must be able to read a purchase suggestion from a non-Web based location containing all of the details of the purchase.
  • A purchase must be performed on an asset that does not exist on the Web, but for which all of the information describing the asset is communicated during the purchase suggestion.
  • A purchase response must be allowed to be sent back to the vendor via a non-Web communication channel.

2.9 Point-of-Sale Device

Yavin owns a mobile food truck and allows his patrons to pay via any card with a magnetic stripe on it. Yavin uses the alternate payment network because it charges lower per-transaction fees than the major payment network that most of the surrounding businesses use. He accepts payments via a magnetic stripe card reader that is attached to his cellphone. Each card swiped is tied to a payment account, which is charged directly and he sees the result of the transaction on his mobile phone. This allows people to continue using their existing magnetic stripe cards, but allows Yavin to process transactions over alternate payment networks.

2.9.1 Requirements

  • Point-of-Sale devices must be able to initiate automatic transfers given an access PIN that is tied to a particular payment site and customer account.

2.10 Automated Vending

It is a hot day and Larson is thirsty. He spots a nearby refrigerated vending machine that is selling cold lemonade. He notices that the vending machine, while having no Internet connection to the outside world, allows him to use his mobile device to make a purchase using PaySwarm. He clicks the button, his phone activates and asks him if he wants to make the purchase, he clicks yes and the lemonade drops into the receiving bucket.

2.10.1 Requirements

  • A device must be able to route purchases through customer devices and receive a purchase receipt from the customer device.
  • A device must be able to verify a purchase receipt counter-signed by a trusted source other than the payment authority.

2.11 Currency Exchange

Olaf would like to exchange 50 Euro into US Dollars through a simple online money exchange service. He would like his payment authority to be the initiator of the exchange and the final destination of the exchange to be a newly created account for US Dollars.

2.11.1 Requirements

  • There must be a mechanism to translate one currency into another currency.
  • There may be a mechanism where one specifies a mint to create new units of currency and transfer those units into a payment authority.

2.12 Alternative Currencies

Rigo would like to create a local currency for his town, which is fairly poor but contains a moderate population that volunteers their time at a number of community-supported farms in the area. He would like to reward the area citizens with time-banked credits that can be redeemed for food or other services at local businesses and restaurants.

2.12.1 Requirements

  • Alternative currencies must be supported.
  • Alternative currencies must be allowed to be created dynamically in the system.

2.13 Streaming Payments

Tellulah is a DJ and would like to setup a non-profit Internet radio station to stream Weekly Top 40 songs along with a mix of independent music. She would like to cover her expenses as well as the standard per-song ephemeral broadcasting fee set by the US Copyright Arbitration Panel to ensure she is legally compliant at all times. Registering and tracking royalties can be a very daunting and time consuming process. A mechanism that reduces the burden of legal compliance could drive more stations to come online.

Online radio broadcasters are also presently limited in their ability to grow their stations due to the ephemeral broadcasting royalties that must be paid on a per person/per song basis. Running these stations make it difficult to collect, track and distribute royalties in a way that makes it easy to integrate into the web browser. Often, donating or signing up to a single download provider can be more trouble than it is worth. If there was a universal mechanism to pay very small amounts for data streams on the Web, new legal avenues for distributing content legally would be enabled.

2.13.1 Requirements

  • Payment must be able to be associated with a section of a stream of data. Payment should be allowed to be associated with a particular number of bytes or temporal time frame.
  • Small fractions of whole currency amounts should be allowed in order to ensure accurate metering and payment recouping for content streams.

2.14 Crowd-funding

Dione would like to raise $10,000 to design and build a solar powered, personal ground water pump and purifier for developing nations. He intends to publish all of the plans on the Web as open hardware and start taking orders from NGOs to install these pump-purifiers in villages around the world. Rather than go through the process of writing a grant and waiting up to a year to start on the work, he believes that he can raise the money faster through the Web and start the project within 3 months.

2.14.1 Requirements

  • Intent-based deposit contracts must be supported, which can be redeemed by the payee in one bulk transfer. The entity raising the funds should be able to hold on to deposit contracts for a number months and "cash them in" when a certain threshold has been reached.

2.15 Proof-of-Purchase and Verifiable Digital Receipts

Luciano has purchased a song from an online music store. The band that created the song would like to give people that purchased any song from their last album the chance to view their latest music videos and behind-the-scenes footage.

Since Luciano's browser was used to make the purchase, it has stored a digitally signed receipt of the sale. When he visits the band's website, it asks his browser for a receipt that proves that he has purchased a song from their latest album. The digital receipt is sent to the website, is verified, and Luciano is allowed into the special VIP section of the band's website.

2.15.1 Requirements

  • The system must be able to express a digital receipt of sale or license that can be verified by a 3rd party.
  • The system must define a straight-forward mechanism for websites to request digital receipts of sale.
  • The system may define a mechanism for web browsers to transmit a proper receipt or license based upon information on a page, but after transmission of the receipt has been authorized by the person or entity in posession of the receipt.

2.16 Conditional Redistribution

Rosa wants to publish a complete novel in multiple text formats. When selling the novel, she wants to specify authorship as pseudonym; no content modification; and payment per download. She would like downstream commercializing to be allowed, but with the following constraints; 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.

2.16.1 Requirements

  • Redistribution rules must allow the following conditions; limiting the down-stream profit and limiting advertising.

3. Future Use Cases

The following use cases were identified as important use cases, but have been postponed until implementation lessons have been learned from the base PaySwarm specification.

3.1 Crowd-Sourcing Digital Distribution

Jane, who is an independent film maker, has just finished her documentary and wishes to distribute it to a very large audience. She does not have the resources to provide High-Definition streaming of her content to her fans. She would also like to charge enough for the current documentary in order to cover the production costs of the next documentary. She could use BitTorrent to distribute her work, but it lacks the ability to collect payment on her behalf. She would like to give some of the proceeds of each sale to those that will help her distribute her documentary.

Ideally, Jane would register her work with a content clearinghouse. That clearinghouse would provide the reference file which would be used to seed the network. Once enough downloads have been performed, others on the network could distribute the file in exchange for monetary compensation for providing a download source.

3.1.1 Requirements

  • The system must be able to swarm file downloads from multiple sources.
  • Payment must be able to be divvied out among thousands of download sources.
  • Payment must be allowed to be made to arbitrary accounts on the network.

3.2 Ad-Based Content Payment

Joss directs and produces a number of excellent television shows. Over the years, he has garnered a strong online following but doesn't have the required numbers for a long television production run. He would like to distribute his shows via the Web. Joss would like to partner with an advertising network to provide audio and video advertisements to cover the costs related to the production and distribution of his shows. In order to do this, the system that he uses must be able to credit and debit payment accounts accordingly whenever advertising is inserted into the content stream.

When a fan watches each episode, they can opt to pay for the episode in full, pay for reduced advertisements, or request that advertisers cover the entire cost of the show. Advertisers can choose to provide small payments for anonymous advertisements, or larger payments if customers provide advertising details and preferences to the advertisers.

3.2.1 Requirements

  • Network participants should be allowed to credit other accounts on the network. For example, asset acquirers should be allowed to ask other network participants (advertisers) to partially cover their costs in exchange for the insertion of ads into the data stream.
  • Buyers should have the option of purchasing goods without advertising.

3.3 Negotiation

Gregor runs a fairly active high-definition movie download site. His data transmission prices are high during peak hours and low during off-peak hours. He would like to give his customers the option to negotiate for lower download prices if they download their movies during the off-peak times. He would also like to reserve the right to refuse a contract re-negotiation attempt if he has not made a pre-set sales quota and even raise his prices if it would make sense for his business.

The ability to change prices based on market demand would enable a more dynamic marketplace, leading to more competition between download providers. Giving buyers the ability to re-negotiate terms of sale would not only give them a sense of empowerment, but could eliminate bad pricing behavior on the network, leading to overall market efficiencies.

3.3.1 Requirements

  • The system should allow asset acquirers and asset providers to negotiate the data download prices associated with a particular download.
  • The system should allow buyers to negotiate the license details as well as the license price with a particular asset owner.

3.4 Live Pricing Algorithms

Aiyana, a folk-musician in Siberia, records local throat-singing music. She would like to distribute the work via her website. She specifies authorship but does not want anyone to modify the content. She allows anybody re-selling the song on her behalf to allow free streaming for the first 10% of the song. She also wants to charge on a per download, on a sliding scale proportional to user-country's average yearly income per person; no downstream commercializing.

3.4.1 Requirements

  • Dynamic price calculation formulas should be allowed to be specified instead of a fixed price.

4. Acknowledgements

The editor is thankful for reviews and contributions from (in alphabetical order):

A. References

A.1 Normative references

No normative references.

A.2 Informative references

No informative references.