PaySwarm - Frequently Asked Questions

Unofficial Draft 23 March 2010

Editor:
Manu Sporny, Digital Bazaar, Inc.

Abstract

The PaySwarm web platform is an open standard that enables web browsers and web devices to perform micropayments and copyright-aware, peer-to-peer digital media distribution. This document is designed to answer a number of frequently asked questions surrounding the PaySwarm standardization process.

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

This document answers a number of frequently asked questions about the PaySwarm standardization work.

1.1 What is PaySwarm?

PaySwarm is an open web platform standard that enables web browsers and web devices to perform micropayments and copyright-aware, peer-to-peer digital media distribution.

1.2 What does PaySwarm do?

PaySwarm enables people that create digital content to distribute it through the Web and receive payment directly from their fans and customers. It is also designed to help fans and customers distribute digital content on behalf of the content creators in a way that is both legal and financially beneficial to the creators, fans and customers. The technology is designed to be integrated directly into web devices, finally making legal digital content distribution a first-class citizen on the web.

1.3 What is an open web platform?

An open web platform is a combination of technology that is patent-free, royalty-free, published in a free specification, using well-defined protocols and other open technologies. The combination of open technology to accomplish a particular set of related tasks on the web defines an "open web platform".

1.4 What is a Micropayment?

The term micropayment is used loosely, as we don't want to bother the customer to reach for their wallet every time they need to spend a couple of cents, or even a couple of dollars. Micropayment in this case, specifically refers to the ability to divvy royalties and payments in increments of up to 1/10,000th of a cent to various royalty and payment accounts as listed in the digital contracts.

1.5 Who can implement and use the technology?

Anybody. The entire PaySwarm standard is implementable on a patent and royalty-free basis, just like HTTP [HTTP11], HTML 4.01 [HTML40] and Javascript. This means that anybody may implement any part of the system without worrying about technology licensing fees or patent suits from any of the participating W3C member companies.

2. Scope, Goals and Objectives

This section discusses the scope of the PaySwarm work while outlining short-term and long-term goals and objectives.

2.1 What is the scope of the PaySwarm work?

We are sensitive to the needs of the entire content creation, distribution, payment, and customer ecosystem. This includes content identification and search (RDFa, Microformats, etc.), account crediting (credit card, PayPal, bank transfer, network-to-network cash transfer), identity management (OpenID, X509 certificate generation, validation and revocation), content registration, content distribution (physical point-of-sale, web-based, peer-to-peer based), contracts and licensing, royalty payments, coupons/discounts, dynamic pricing, and many other aspects that are vital when considering the operation of such a system.

That said, it is important to have a sharp focus when performing good standardization; the work must produce a tangible technology product. For version 1.0, PaySwarm will focus on enabling web browsers to buy and resell digital content among one another.

2.2 What is the objective of PaySwarm?

The objective is to create a standards-based, patent and royalty-free micropayment and content distribution platform that is capable of meeting the needs of the digital content industries, web browser manufacturers, content distributors and content customers. We are focusing initially on digital music, film and print media.

The long-term goal is to ensure that commercial content is directly available for purchase via web browsers with a single button click.

The technology to do this is open sourced because we want to ensure that it is available for browser manufacturers to implement (patent and royalty-free).

2.3 What will the end product look like?

The PaySwarm web platform will be a collection of REST APIs that can be implemented by web servers and web clients to enable the legal transfer of digital content. The collection of REST APIs will mimic the tremendously simple and successful API model used by Twitter, Flickr, Google, Digg and a variety of other online services.

2.4 How does PaySwarm deal with online identity?

Online identity exchange and management is something that has multiple solutions online at the moment. Granted - they are not integrated into the browser, but we have to pick the technology that will be the catalyst for getting online identity management started. We think the PaySwarm API will kickstart more online identity standardization work at the W3C and thus online identity may be better suited for the PaySwarm 2.0 work.

2.5 How does PaySwarm deal with credit card processing?

Checking account, bank card, online payment services and credit card processing are monetary transfer mechanisms that have multiple solutions online at the moment. Granted - they are not integrated into the browser, but we have to pick the technology that will be the catalyst for getting card processing and financial transfer standardization work started at the W3C. We think the PaySwarm 1.0 API will act as a catalyst to get the broader standards work related to inter-network financial transfer started at the W3C.

3. Core Technology

This section discusses core technology that is used by the PaySwarm web platform.

3.1 What types of technology are used for PaySwarm?

Where it is possible, PaySwarm re-uses a number of standard technologies for digital content distribution. Here are all of the technologies that PaySwarm is built on top of:

Messaging
HTTP - all peer-to-peer messaging is performed using the Hyper Text Transfer Protocol [HTTP11] [HTTP-TLS].
Serialization
JSON - all peer-to-peer message encoding is formatted in Javascript Object Notation.
Security
AES, TLS, X.509 Certificates, DSA,and PKI - all peer-to-peer communication is secured via [AES] and [HTTP-TLS]. Identities are verified using X.509 certificates. Digital contracts are signed using DSA.
Steganography
Binary file processor module plugins to provide custom steganography mechanisms by file type. For example, processing MP3 files may have N steganography algorithms for encoding the contract information into the file without degrading audio quality in any way.

3.2 How are the digital contracts signed and verified?

The digital contracts are expressed in JSON. Identities on the network must be verified and tied to a bank account. Contract Sections are digitally signed using the verified identity's private key using the DSA standard.

4. Existing Technologies

This section provides arguments for standardizing PaySwarm over other pre-existing technologies.

4.1 Affiliate systems already exist, why do we need PaySwarm?

While affiliate programs are one avenue for a blogger or website owner to sell content, what they really want is the ability to sell content directly from their website without having to send their customers to an external website - they want to create a solid online presence for their community and affiliate links detract from that presence.

The PaySwarm system also allows website operators to set their markup fees independently. With the system, content producers and distributors set their fees and royalties independently and dynamically. The combined total results in the final price of the product. This allows independent control over the final prices on the network - which leads to market efficiencies, while ensuring that royalties set by the content companies are always respected.

Some bloggers may choose higher fees because of the strength of their followers, others might choose lower fees because they are attempting to attract more purchases from their site. The end result is that content creators are always guaranteed the royalty amounts that they have set for themselves, but you allow the bloggers to compete using different payment models.

This approach is far more powerful than affiliate links because it allows bloggers to have complete ownership over their site while ensuring a steady royalty stream to the content owners.

4.2 There are thousands of online content stores, why isn't that good enough?

While there are certainly many sites that already sell digital content online, there is a larger issue that is of concern.

The goal of many W3C standards is to ensure that the technology is ubiquitous and implemented in every web browser. Closed systems will never be implemented in every web browser due to the nature of proprietary systems. In other words, relying primarily on a few retailers artificially constrains the avenues available to distribute and monetize digital content. That is something that concerns both independent content creators and large content creators alike.

There are roughly 1.7 billion individuals that use the Internet via a web browser today. Those numbers will continue to increase as the mobile device market expands. These markets are magnitudes larger than the iTunes install base (50-70 million), or those who use Napster (0.8-1.0 million), or other online retailers.

The PaySwarming work endeavors to make every web browser and Internet device into a point-of-sale and redistribution for digital content.

4.3 It's easy to stream digital content now, what added value does PaySwarm provide?

While it is true that anyone can stream music or video on the Internet, those organizations are struggling to create a business model that is effective at getting their listeners to pay for a stream on a regular basis without resorting to advertising or funding it themselves.

One of the driving reasons for this is due to most Internet radio business models requiring monthly subscriptions or advertising. So, it requires somebody to either pull out their credit card and put their information into a site, or the station owner to have a fair amount of knowledge about the advertising industry to make the station work.

If payment and streaming were integrated into the browser, the customer would not have to pull out their credit card whenever they wanted to listen to a for-pay stream - instead, they would set a spending limit (perhaps on a per-site basis), and micropayments would flow out of their account depending on what they were listening to on a song-by-song basis. If they didn't want to spend money, their web browser could request to stream several advertisements (if available), which would then credit the listener's account. That credit could then be used to listen to the stream.

We're focusing on developing technology to make this scenario easier for browser manufacturers and software developers - to make it easier to implement in a way that respects copyright while ensuring that the endeavor is financially viable for everyone involved.

4.4 There are already digital download widgets, how is PaySwarm different?

There are certainly mechanisms out there that allow one to pair up with one or two proprietary services in order to provide downloads directly from one's website. The downside with that approach is:

The underlying point to all of this is that while it may be possible to solve the problem using a proprietary solution with a proprietary vendor - the ideal solution is to follow what has made the web successful. That is, define an open standard for doing these sorts of transactions. There are a great number of halo effects that occur from standardization - to come back to this example, three of those effects would be:

  1. You wouldn't need a widget of any kind to enable the scenario because the web browser has the ability to purchase content from anybody that provides the PaySwarm API.
  2. Bloggers could use the same API interface to interact with music, movie and book publishers.
  3. Customers could choose their Micropayment provider independently of where they are purchasing their content - providing a sort of single sign-on service for digital content purchasing.

A. Acknowledgements

The editors graciously acknowledge reviews and contributions from (in alphabetical order): Mike Johnson, David I. Lehn, Dave Longley, Dave Raggett, Doug Schepers

B. References

B.1 Normative references

No normative references.

B.2 Informative references

[AES]
NIST FIPS 197: Advanced Encryption Standard (AES). November 2001. URI: http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
[HTML40]
Ian Jacobs; David Raggett; Arnaud Le Hors. HTML 4.0 Specification. 24 April 1998. W3C Recommendation. URL: http://www.w3.org/TR/1998/REC-html40-19980424
[HTTP-TLS]
E. Rescorla. HTTP Over TLS. May 2000. Internet RFC 2818. URL: http://www.ietf.org/rfc/rfc2818.txt
[HTTP11]
R. Fielding; et al. Hypertext Transfer Protocol - HTTP/1.1. June 1999. Internet RFC 2616. URL: http://www.ietf.org/rfc/rfc2616.txt