W3C home > Mailing lists > Public > public-webpayments@w3.org > January 2012

Part 3: PaySwarm vs. OpenTransact Comparison

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Mon, 09 Jan 2012 16:33:01 -0500
Message-ID: <4F0B5D0D.4050804@digitalbazaar.com>
To: Web Payments <public-webpayments@w3.org>
bcc: OpenTransact Mailing List

The third blog post of the comparison between PaySwarm and OpenTransact
has just been published. In this post, I respond to Pelle's most recent
blog post about design decisions made for OpenTransact and the
implications of those design decisions:



Full-text below for the purposes of archival external to my personal blog.

Web Payments: PaySwarm vs. OpenTransact Shootout (Part 3)
By ManuSporny On January 8, 2012 In PaySwarm, Standards

This is a continuing series of blog posts analyzing the differences
between PaySwarm and OpenTransact. The originating blog post and
subsequent discussion is shown below:

Web Payments: PaySwarm vs. OpenTransact Shootout by Manu Sporny

OpenTransact the payment standard where everything is out of scope by
Pelle Braendgaard

Web Payments: PaySwarm vs. OpenTransact Shootout (Part 2) by Manu Sporny

OpenTransact vs PaySwarm part 2 – yes it’s still mostly out of scope by
Pelle Braendgaard

It is the last post of Pelle’s that this blog post will address. All of
the general points made in the previous analysis still hold and so
familiarizing yourself with them before continuing will give you some
context. In summary,

TL;DR – The OpenTransact standard does not specify the minimum necessary
algorithms and processes required to implement an interoperable, open
payment network. It, accidentally, does the opposite – further enforcing
silo-ed payment networks, which is exactly what PaySwarm is attempting
to prevent.

1. Why OpenTransact Fails To Standardize Web Payments
2. General Misconceptions (continued)
3. Detailed Rebuttal (continued)
4. Conclusion

Why OpenTransact Fails to Standardize Web Payments

After analyzing OpenTransact over the past few weeks, the major issue of
the technology is becoming very clear. The Web Payments work is about
writing a world standard. The purpose of a standard is to formalize the
data formats and protocols, in explicit detail, that teaches the
developer how two pieces of software should interoperate. If any two
pieces of software implement the standard, it is known that they will be
able to communicate and carry out any of the actions defined in the
standard. The OpenTransact specification does not achieve this most
fundamental goal of a standard. It does not specify how any two payment
processors may interoperate, instead, it is a document that suggests one
possible way for a single payment processor to implement its Web API.

Here is why this is a problem: When a vendor lists an OpenTransact link
on their website, and a customer clicks on that link, the customer is
taken to the vendor’s OpenTransact payment processor. If the customer
does not have an account on that payment processor, they must get an
account, verify their information, put money in the account, and go
through all of the hoops required to get an account on that payment
provider. In other words, OpenTransact changes absolutely nothing about
how payment is performed online today.

For example, if you go to a vendor and they have a PayPal button on
their site, you have to go to PayPal and get an account there in order
to pay the vendor. If they have an Amazon Payments button instead, you
have to go to Amazon and get an account there in order to pay the
vendor. Even worse, OpenTransact doesn’t specify how individuals are
identified on the network. One OpenTransact provider could use e-mail
addresses for identification, while another one might use Facebook
accounts or Twitter handles. There is no interoperability because these
problems are considered out of scope for the OpenTransact standard.

PaySwarm, on the other hand, defines exactly how payment processors
interoperate and identities are used. A customer may choose their
payment processor independently of the vendor, and the vendor may choose
their payment processor independently of the customer. The PaySwarm
specification also details how a vendor can list items for sale in an
interoperable way such that any transaction processor may process a sale
of the item. PaySwarm enables choice in a payment processor,
OpenTransact does not.

OpenTransact continues to lock in customers and merchants into a
particular payment processor. It requires that they both choose the same
one if they are to exchange payment. While Pelle has asserted that this
is antithetical to OpenTransact, the specification fails to detail how a
customer and a merchant could use two different payment processors to
perform a purchase. Leaving something as crucial as sending payment from
one payment processor to the next as unspecified will only mean that
many payment processors will implement mechanisms that are
non-interoperable across all payment processors. Given this scenario, it
doesn’t really matter what the API is for the payment processor as
everyone has to be using the same system anyway.

Therefore, the argument that OpenTransact can be used as a basic
building block for online commerce is fatally flawed. The only thing
that you can build on top of OpenTransact is a proprietary walled garden
of payments, an ivory tower of finance. This is exactly what payment
processors do today, and will do with OpenTransact. It is in their best
interest to create closed financial networks as it strips market power
away from the vendor and the customer and places it into their ivory tower.

Keep this non-interoperability point in mind when you see an “out of
scope” argument on behalf of OpenTransact – there are some things that
can be out of scope, but not at the expense of choice and interoperability.

General Misconceptions (continued)

There are a number of misconceptions that Pelle’s latest post continues
to hold regarding PaySwarm that demonstrate a misunderstanding of the
purpose of the specification. These general misconceptions are addressed
below, followed by a detailed analysis of the rest of Pelle’s points.

"PaySwarm is a fully featured idealistic multi layered approach where
you must buy into a whole different way running your business."

The statement is hyperbolic – no payment technology requires you to “buy
into a whole different way of running your business”. Vendors on the Web
list items for sale and accept payment for those items in a number of
different ways. This is usually accomplished by using shopping cart
software that supports a variety of different payment mechanisms –
eCheck, credit card, PayPal, Google Checkout, etc. PaySwarm would be one
more option that a vendor could employ to receive payment.

PaySwarm standardizes an open, interoperable way that items are listed
for sale on the Web, the protocol that is used to perform a transaction
on the Web, and how transaction processors may interoperate with one

PaySwarm is a pragmatic approach that provides individuals and
businesses with a set of tools to make Web-based commerce easier for
their customers and thus provides a competitive advantage for those
businesses that choose to adopt it. Businesses don’t need to turn off
their banking and credit card processing services to use PaySwarm – it
would be foolish for any standard to take that route.

PaySwarm doesn’t force any sort of out-right replacement of what
businesses and vendors do today, it is something that can be phased in
gradually. Additionally, it provides built-in functionality that you
cannot accomplish via traditional banking and credit card services.
Functionality like micro-payments, crowd-funding, a simple path to
browser-integration, digital receipts, and a variety of innovative new
business models for those willing to adopt them. That is, individuals
and businesses will adopt PaySwarm because; 1) it provides a competitive
advantage, 2) it allows new forms of economic value exchange to happen
on the Web, 3) it is designed to fight vendor-lock in, and 4) it
thoroughly details how to achieve interoperability as an open standard.

It is useless to call a technology idealistic, as every important
technology starts from idealism and then gets whittled down into a
practical form – PaySwarm is no different. The proposal for the Web was
idealistic at the time, it was a multi-layered approach, and it does
require a whole different way of running a Web-based business (only
because Web-based businesses did not exist before the Web). It’s clear
today that all of those adjectives (“idealistic”, “multi-layered”, and
“different”) were some of the reasons that the Web succeeded, even if
none of those words apply to PaySwarm in the negative way that is
asserted in Pelle’s blog post.

"However the basic PaySwarm philosophy of wanting to design a whole
world view is very similar to central planning or large standards bodies
like ANSI, IEEE etc. OpenTransact follows the market based approach that
the internet was based on of small standards that do one thing well."

As stated previously, PaySwarm is limited in scope by the use cases that
have been identified as being important to solve. It is important to
understand the scope of the problem before attempting a solution.
OpenTransact fails to grasp the scope of the problem and thus falls
short of providing a specification that defines how interoperability is

Furthermore, it is erroneous to assert that the Internet was built using
a market-based approach and small standards. The IEEE, ANSI, and even
government had a very big part to play in the development of the
Internet and the Web as we know it today.

Here are just a few of the technologies that we enjoy today because of
the IEEE: Ethernet, WiFi, Mobile phones, Mobile Broadband, POSIX, and
VHDL. Here are the technologies that we enjoy today because of ANSI: The
standard for encoding most of the letters on your screen right now
(ASCII and UTF-8), the C programming language standard, and countless
safety specifications covering everything from making sure that
commercial airliners are inspected properly, to hazardous waste disposal
guidelines that take human health into account, to a uniform set of
colors for warning and danger signs in the workplace.

The Internet wouldn’t exist in the form that we enjoy today without
these IEEE and ANSI standards: Ethernet, ASCII, the C programming
language, and many of the Link Layer technologies developed by the IEEE
on which the foundation of the Internet was built. It is incorrect to
assume that the Internet followed purely market-based forces and small
standards. Let’s not forget that the Internet was a centrally planned,
government funded (DARPA) project.

The point is that technologies are developed and come into existence
through a variety of channels. There is not one overriding philosophy
that is correct in every instance. The development of some technologies
require one to move fast in the market, some require thoughtful planning
and oversight, and some require a mixture of both. What is important in
the end is that the technology works, is well thought out, and achieves
the use cases it set out to achieve.

There are many paths to a standard. What is truly important in the end
is that the technology works in an interoperable fashion, and in that
vein, the assertion that OpenTransact does not meet the basic
interoperability requirements of an open Web standard has still not been

Detailed Rebuttal (continued)

In the responses below, Pelle’s comment on his latest blog post is
quoted and the rebuttal follows below each section of quoted text. Pay
particular attention to how most of the responses are effectively that
the “feature is out of scope”, but no solution is forthcoming to the
problem that the feature is designed to address. That is, the problem is
just kicked down the road for OpenTransact, where the PaySwarm
specification makes a concerted effort to address each problem via the
feature under discussion.

Extensible Machine Readable Metadata

"Again this falls completely out of the scope. An extension could easily
be done using JSON-LD as JSON-LD is simply an extension to JSON. I don’t
think it would help the standard by specifying how extensions should be
done at this point. I think JSON-LD is a great initiative and it may
well be that which becomes an extension format. But there are also other
simpler extensions that might better be called conventions that probably
do not need the complication of JSON-LD. Such as Lat/Lng which has
become a standard geo location convention in many different applications."

The need for extensible machine-readable metadata was explained
previously. Addressing this problem is a requirement for PaySwarm
because without it you have a largely inflexible messaging format. Pelle
mentions that the extensibility issue could be addressed using JSON-LD,
which is what PaySwarm does, but does not provide any concrete plans to
do this for OpenTransact. That is, the question is left unaddressed in
OpenTransact and thus the extensibility and interoperability issue remains.

When writing standards, one cannot assert that a solution “could easily
be done”. Payment standards are never easy and hand waving technical
issues away is not the same thing as addressing those technical issues.
If the solution is easy, then surely something could be written on the
topic on the OpenTransact website.

Transactions (part 1)

"I don’t like the term transaction as Manu is using it here. I believe
it is being used here using computer science terminology. But leaving
that aside. OpenTransact does not support multi step transactions in
itself right now. I think most of these can be easily implemented in the
Application Layer and thus is out of scope of OpenTransact."

The term transaction is being used in the traditional English sense, the
Merriam-Webster Dictionary defines a transaction as: something
transacted; especially: an exchange or transfer of goods, services, or
funds (electronic transactions). Wikipedia defines a transaction as: an
agreement, communication, or movement carried out between separate
entities or objects, often involving the exchange of items of value,
such as information, goods, services, and money. Further, a financial
transaction is defined as: an event or condition under the contract
between a buyer and a seller to exchange an asset for payment. It
involves a change in the status of the finances of two or more
businesses or individuals. This demonstrates that the use of
“transaction” in PaySwarm is in-line with its accepted English meaning.

The argument that multi-step transactions can be easily implemented is
put forward again. This is technical hand-waving. If the solution is so
simple, then it shouldn’t take but a single blog post to outline how a
multi-step transaction happens between a decentralized set of
transaction processors. The truth of the matter is that multi-step
transactions are a technically challenging problem to solve in a
decentralized manner. Pushing the problem up to the application layer
just pushes the problem off to someone else rather than solving it in
the standard so that the application developers don’t have to create
their own home-brew multi-part transaction mechanism.

Transactions (part 2)

"I could see a bulk payment extension supporting something similar in
the future. If the need comes up lets deal with [it]."

Here are a few reasons why PaySwarm supports multiple financial
transfers to multiple financial accounts as a part of a single
transaction; 1) it makes the application layer simpler, and thus the
developer’s life easier, 2) ensuring that all financial transfers made
it to their destination prevents race conditions where some people get
paid and some people do not (read: you could be sued for non-payment),
3) assuming a transfer where money is disbursed to 100 people, doing it
in one HTTP request is faster and more efficient than doing it in 100
separate requests. The need for multiple financial transfers in a single
transaction is already there. For example, paying taxes on items sold is
a common practice; in this case, the transaction is split between at
least two entities: the vendor and the taxing authority.

OpenTransact does not address the problem of performing multiple
financial transfers in a single transaction and thus pushes the problem
on to the application developer, who must then know quite a bit about
financial systems in order to create a valid solution. If the
application developer makes a design mistake, which is fairly easy to do
when dealing with decentralized financial systems, they could place
their entire company at great financial risk.

Currency Exchange

"…most of us have come to the conclusion that we may be able to get away
with just using plain open transact for this."

While the people working on OpenTransact may have come to this
conclusion, there is absolutely no specification text outlining how to
accomplish the task of performing a currency exchange. The analysis was
on features that are supported by each specification and the
OpenTransact specification still does not intend to provide any
specification text on how a currency exchange could be implemented.
Saying that a solution exists, but then not elaborating upon the
solution in the specification in an interoperable way is not good
standards-making. It does not address the problem.

Decentralized Publishing of X (part 1)

"These features listed are necessary if you subscribe to the world view
that the entire worlds commerce needs to be squeezed into a web startup."

I don’t quite understand what Pelle is saying here, so I’m assuming this
interpretation: “The features listed are necessary if you subscribe to
the world view that all of the worlds commerce needs have to be squeezed
into a payment standard.”

This is not the world-view that PaySwarm assumes. As stated previously,
PaySwarm assumes a limited set of use cases that were identified by the
Web Payments community as being important. Decentralization is important
to PaySwarm because is ensures; 1) that the system is resistant to
failure, 2) that the customer is treated fairly due to very low
transaction processor switching costs, and 3) that market forces act
quickly on the businesses providing PaySwarm services.

OpenTransact avoids the question of how to address these issues and
instead, accidentally, further enforces silo-ed payment networks and
walled gardens of finance.

Decentralized Publishing of X (part 2)

"I think [decentralized publishing] would make a great standard in it’s
own right that could be published separately from the payment standard.
Maybe call it CommerceSwarm or something like that."

There is nothing preventing PaySwarm from splitting out the listing of
assets, and listings from the main specification once we have addressed
the limited set of use cases put forth by the Web Payments community. As
stated previously, the PaySwarm specification can always be broken down
into simpler, modularized specifications. This is an editorial issue,
not a design issue.

The concern about the OpenTransact specification is not an editorial
issue, it is a design issue. OpenTransact does not specify how multiple
transaction processors interoperate nor does it describe how one
publishes assets, listings and other information associated with the
payment network on the Web. Thus, OpenTransact, accidentally, supports
silo-ed payment networks and walled gardens of finance.

Decentralized Publishing of X (part 3)

"If supporting these are a requirement for an open payment standard, I
think it will be very hard for any existing payment providers or
e-commerce suppliers to support it as it requires a complete change in
their business, where OpenTransact provides a fairly simple easy
implementable payment as it’s only requirement."

This argument is spurious for at least two reasons.

The first is that OpenTransact only has one requirement and thus all a
business would have to implement was that one requirement.
Alternatively, if businesses only want to implement simple financial
transfers in PaySwarm (roughly equivalent to transactions in
OpenTransact), they need only do that. Therefore, PaySwarm can be as
simple as OpenTransact to the vast majority of businesses that only
require simple financial transfers. However, if more advanced features
are required, PaySwarm can support those as well.

The second reason is that it is effectively the buggy whip argument – if
you were to ask businesses that depended on horses to transport their
goods before the invention of the cargo truck, most would recoil at the
thought of having to replace their investment in horses with a new
investment in trucks. However, new businesses would choose the truck
because of its many advantages. Some would use a mixture of horses and
trucks until the migration to the better technology was complete. The
same applies to both PaySwarm and OpenTransact – the only thing that is
going to cause individuals and businesses to switch is that the
technology provides a competitive advantage to them. The switching costs
for new businesses are going to be less than the switching costs for old
businesses with a pre-existing payment infrastructure.

Verifiable Receipts (part 1)

"However I don’t want us to stall the development and implementation of
OpenTransact by inventing a new form of PKI or battling out which of the
existing PKI methods we should use. See my section on Digital Signatures
in the last post."

A new form of PKI has not been invented for PaySwarm. It uses the
industry standard for both encryption and digital signatures – AES and
RSA. The PKI methods are clearly laid out in the specification and have
been settled for quite a while, not a single person has mentioned that
they want to use a different set of PKI methods or implementations, nor
have they raised any technical issues related to the PKI portion of the

Pelle might be referring to how PaySwarm specifies how to register
public keys on the Web, but if he is, there is very little difference
between that and having to manage OAuth 2 tokens, which is a requirement
imposed on developers by the OpenTransact specification.

Verifiable Receipts (part 2)

"Thus we have taken the pragmatic approach of letting businesses do what
they are already doing now. Sending an email and providing a transaction
record via their web site."

PaySwarm does not prevent businesses from doing what they do now.
Sending an e-mail and providing a transaction record via their website
are still possible using PaySwarm. However, these features become
increasingly unnecessary since PaySwarm has a digital receipt mechanism
built into the standard. That is, businesses no longer need to send an
e-mail or have a transaction record via their website because PaySwarm
transaction processors are responsible for holding on to this
information on behalf of the customer. This means far less development
and financial management headaches for website operators.

Additionally, neither e-mail nor proprietary receipts support Data
Portability or system interoperability. That is, these are not standard,
machine-readable mechanisms for information exchange. More to the point,
OpenTransact is kicking the problem down the road instead of attempting
to address the problem of machine-verifiable receipts.

Secure X-routed Purchases

"These are neat applications that could be performed in some way through
an application. You know I’m going to say it’s out of scope of
OpenTransact. OpenTransact was designed as a simple way of performing
payments over the web. Off line standards are thus out of scope."

The phrase “performed in some way through an application” is technical
hand-waving. OpenTransact does not propose any sort of technical
solution to a use case that has been identified by the Web Payments
community as being important. Purchasing an item using an NFC-enabled
mobile phone at a Web-enabled kiosk is not a far fetched use case – many
of these kiosks exist today and more will become Web-enabled over time.
That is, if one device has Web connectivity – is the standard extensible
enough to allow a transaction to occur?

With PaySwarm, the answer is “yes” and we will detail exactly how to
accomplish this in a PaySwarm specification. Note that it will probably
not be in the main PaySwarm specification, but an application developer
specification that thoroughly documents how to perform a purchase
through a PaySwarm proxy.

Currency Mints

"Besides BitCoin all modern alternative currencies have the mint and the
transaction processor as the same entity."

These are but a few of the modern alternative currencies where the mint
and the transaction processor are not the same entity (the year that the
currency was launched is listed beside the currency): BerkShares (2006),
Calgary Dollar (1996), Ithica Hours (1998), Liberty Dollar (1998-2009),
and a variety of LETS and InterLETS systems (as recently as 2011).

OpenTransact assumes that the mint and the transaction processor are the
same entity, but as demonstrated above, this is not the case in already
successful alternative currencies. The alternative currencies above,
where the mint and the transaction processor are different, should be
supported by a payment system that purports to support alternative
currencies. Making the assumption that the mint and the transaction
processor are one and the same ignores a large part of the existing
alternative currency market. It also does not protect against
monopolistic behavior on behalf of the mint. That is, if a mint handles
all minting and transaction processing, processing fees are at the whim
of the mint, not the market. Conflating a currency mint with a
transaction processor results in negative market effects – a separation
of concerns is a necessity in this case.


"Saying that you can not do crowd funding with OpenTransact is like
saying you can’t do Crowd Funding with http. Obviously KickStarter and
many others are doing so and yes you can do so with OpenTransact as a
lower level building block."

The coverage of the Crowd Funding feature was never about whether
OpenTransact could be used to perform Crowd Funding, but rather how one
could perform Crowd Funding with OpenTransact and whether that would be
standardized. The answer to each question is still “Out of Scope” and “No”.

Quite obviously there are thousands of ways technology can be combined
with value exchange mechanisms to support crowd funding. The assertion
was that OpenTransact does not provide any insight into how it would be
accomplished and furthermore, contains a number of design issues that
would make it very inefficient and difficult to implement Crowd Funding,
as described in the initial analysis, on top of the OpenTransact platform.

Data Portability

"We are very aware of concerns of vendor lock in, but as OpenTransact is
a much simpler lower level standard only concerned with payments, data
portability is again outside the scope. We do want to encourage work in
this area."

PaySwarm adopts the philosophy that data portability and vendor lock-in
are important concerns and must be addressed by a payment standard.
Personal financial data belongs to those transacting, not to the payment
processors. Ultimately, solutions that empower people become widely adopted.

OpenTransact, while encouraging work in the area, adopts no such
philosophy for Data Portability as evidenced in the specification.


In doing this analysis between PaySwarm and OpenTransact, a few things
have come to light that we did not know before:

There are some basic philosophies that are shared between PaySwarm and
OpenTransact, but there are many others that are not. Most
fundamentally, PaySwarm attempts to think about the problem broadly
where OpenTransact only attempts to think about one aspect of the Web
payments problem.

1. There are a number of security concerns that were raised when
    performing the review of the OpenTransact specification, more of
    which will be detailed in a follow-up blog post.
2. There were a number of design concerns that we found in
    OpenTransact. One of the most glaring issues is something that was
    an issue with PaySwarm in its early days, until the design error was
    fixed. In the case that OpenTransact adopts digital receipts,
    excessive HTTP traffic and the duplication of functionality between
    digital signatures and OAuth 2 will become a problem.
3. While we assumed that Data Portability was important to the
    OpenTransact specification, it was a surprise that there were no
    plans to address the issue at all.
4. There was an assumption that the OpenTransact specification would
    eventually detail how transaction processors may interoperate with
    one another, but Pelle has made it clear that there are no current
    plans to detail interoperability requirements.

In order for the OpenTransact specification to continue along the
standards track, it should be demonstrated that the design concerns,
security concerns, and interoperability concerns have been addressed.
Additionally, the case should be made for why the Web Payments community
should accept that the list of features not supported by OpenTransact is
acceptable from the standpoint of a world standards setting
organization. These are all open questions and concerns that
OpenTransact will eventually have to answer as a part of the
standardization process.

* Many thanks to Dave Longley, who reviewed this post and suggested a
number of very helpful changes.

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: PaySwarm vs. OpenTransact Shootout
Received on Monday, 9 January 2012 21:36:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:29 UTC