Part 2: PaySwarm vs. OpenTransact Comparison

bcc: OpenTransact Mailing List

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

http://manu.sporny.org/2012/web-payments-shootout-part-2/

------------------------

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

Part 2: PaySwarm vs. OpenTransact Shootout
By ManuSporny On January 1, 2012 In PaySwarm, Standards

The Web Payments Community group is currently evaluating two designs for
an open payment platform for the Web. A thorough analysis of PaySwarm
and OpenTransact was performed a few weeks ago, followed by a partial
response by one of the leads behind the OpenTransact work. This blog
post will analyze the response by the OpenTransact folks, offer
corrections to many of the claims made in the response, and further
elaborate on why PaySwarm actually solves the hard problem of creating a
standard for an interoperable, open payment platform for the Web.

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.

You can jump to each section below:

The Purpose of a Standard
Web Payments – The Hard Problem
The Problem Space
General Misconceptions
Detailed Rebuttal
Continuing the Discussion

The Purpose of a Standard

Ultimately, the purpose of a standard is to propose a solution to a
problem that ensures interoperability among implementations of that
standard. Furthermore, standards that establish a network of systems,
like the Web, must detail how interoperability functions among the
various systems in the network. This is the golden rule of standards –
if you don’t detail how interoperability is accomplished, you don’t have
a standard.

In Pelle’s blog post, he states:

"OpenTransact [is] the payment standard where everything is out of scope"

This is the major issue with OpenTransact. By declaring that just about
everything is out of scope for OpenTransact, it fails to detail how
systems on the payment network communicate with one another and thus
does not support the golden rule of standards – interoperability. This
is the point that I will be hammering home in this blog post, so keep it
in mind while reading the rest of this article.

What OpenTransact does is outline “library interoperability”. The
specification enables developers to write one software library that can
be used to initiate monetary transfers by building OpenTransact URLs,
but then does not specify what happens when you go to the URL. It does
not specify how money gets from one system to the next, nor does it
specify how those messages are created and passed from system to system.
OpenTransact overly simplifies the problem and proposes a solution that
is insufficient for use as a global payment standard.

In short, it does not solve the hard problem of creating an open payment
platform.

Web Payments – The Hard Problem

Overall, the general argument put forward by Pelle on behalf of the
OpenTransact specification is that it focuses on merely initiating a
monetary transfer and nothing else because that is the fundamental
building block for every other economic activity. His argument is that
we should standardize the most basic aspect of transferring value and
leave the other stuff out until the basic OpenTransact specification
gains traction.

The problem with this line of reasoning is this: When you don’t plan
ahead, you run the very high risk of creating a solution that works for
the simple use cases, but is not capable of addressing the real problems
of creating an interoperable, open payment platform. PaySwarm
acknowledges that we need to plan ahead if we are to create a standard
that can be applied to a variety of use cases. This does not mean that
every use case must be addressed. Rather, the assertion is made that
designing solutions that solve more than just the initiation of a simple
monetary transfer is important because the world of commerce consists of
much more than the initiation of simple monetary transfers.

Clearly, we should not implement solutions to every use case, but rather
figure out the maximum number of use cases that can be solved by a
minimal design. “Don’t bloat the specification” is often repeated as
guidance throughout the standardization process. Where to draw the line
on spec bloat is one of the primary topics of conversation in standards
groups. It should be an ongoing discussion within the community, not a
hard-line philosophical stance.

The hard problem has always been interoperability and the OpenTransact
specification postpones addressing that issue to a later point in time.
The point of a standard is to establish interoperability such that
anyone can read the standard, implement it, and is guaranteed
interoperability from others that have implemented the standard. From
Pelle’s response:

"We don’t specify how one payment provider transacts with another
payment provider, but it is generally understood that they do so with
OpenTransact."

and

"An exchange system between multiple financial institutions can be
achieved by many different means as they are today. But all of these
methods are implementation details and the developer or end user does
not need to understand what is going on inside the black box."

A specification elaborates on the implementation details so that you can
guarantee interoperability among those that implement the standard.
Implementation details are important because without those, you do not
have interoperability and without interoperability, you do not have an
open payment platform. Without interoperability, you have the state of
online payment providers today – payment vendor lock-in.

General Misconceptions

There are a number of general misconceptions that are expressed in
Pelle’s response that need to be corrected before addressing the rest of
his feedback:

"PaySwarm attempts to solve every single problem up front and thus
creates a standard that is very smart in many ways but also very complex."

What PaySwarm attempts to do is identify real-world use cases that exist
today with payment online and proposes a way to address those use cases.
There are a number of use cases that the community postponed because we
didn’t feel that addressing them now was reasonable. There were also use
cases that we dropped entirely because we didn’t see a need to support
those use cases now or in the future. To say that “PaySwarm attempts to
solve every single problem up front” is hyperbolic. It is true that
PaySwarm is more complex than OpenTransact today, but that’s because it
attempts to address a much larger set of real-world use cases.

"It’s background is I understand in a P2P media market place called
Bitmunk where licenses, distribution contacts and other media DRM issues
are considered important."

PaySwarm did start out as a platform to enable peer-to-peer media
marketplace transactions. That was in 2004. The technology and
specification have evolved considerably since that time. For example,
mandatory DRM was never implemented, but watermarking was – both
technologies have been dropped from the specification due to the
needless complexity introduced by supporting those features. There was
never the concept of a “distribution contract”, but digital contracts –
outlining exactly what was purchased, the licenses associated with that
purchase, and the costs associated with the transaction seem like
reasonable things to support in an open payment platform.

"Manu Sporny of Digital Bazaar has also been a chair of the RDFa working
group so PaySwarm comes with a lot of linked data luggage as well."

I’m also the Chair of the RDF Web Applications Working Group and the
JSON-LD Community Group, am a member of the HTML Working Group, founded
the Data-Driven Standards Community Group, and am a member of the
Semantic Web Coordination Group. Based on those qualifications, I would
like to think that I know my way around Web standards and Linked Data –
others may disagree  . While I don’t know if Pelle meant “luggage” in a
negative sense, if he did, one must ask what the alternative is? If we
are going to create an open payment platform that is interoperable and
decentralized like the Web, then what alternative is there to Linked Data?

Many people do not know that we started working with RDFa and JSON-LD
because we needed a viable solution to the machine-readable
decentralized listing of things for sale problem in PaySwarm. That is,
we didn’t get involved with Linked Data first and then carried that work
into PaySwarm. We started out with PaySwarm and needed Linked Data to
solve the machine-readable decentralized listing of things for sale problem.

"OpenTransact comes from the philosophy that we don’t solve a problem
until the problem exists and several people have real experiences
solving it."

This is a perfectly reasonable philosophy to employ. In fact, PaySwarm
adheres to the same philosophy. PaySwarm’s implementation of the
philosophy diverges from OpenTransact because it takes more real-world
problems into account. Online e-commerce has existed for over a decade
now, with a fairly rich history of lessons-learned with regard to how
the Web has been used for commerce. This history includes many more
types of transactions than just a simple monetary transfer and
therefore, PaySwarm attempts to take these other types of transactions
into account during the design process.

The Problem Space

In his response, Pelle outlines a number of lessons learned from OpenID
and OAuth development. These are all good lessons and we should make
sure that we do not fall into the same trap that OpenID did in the
beginning – attempting to solve too many problems, too soon in the process.

Pelle implies that PaySwarm falls into this trap and that OpenTransact
avoids the trap by being very focused on just initiating payment
transfers. The reasoning is spurious as the world is composed of many
more types of value exchange than just a simple payment initiation. The
main design failure of OpenTransact is to not attempt to detail how the
standard applies to the real-world online payment use cases established
over the past decade.

It is not that PaySwarm attempts to address too many use cases too soon,
but rather that OpenTransact attempts to do too little and by being
hyper-focused, does not solve the problem of creating an open payment
platform that is applicable to the state of online commerce today.

Detailed Rebuttal

The following section provides detailed responses to a number of points
that are made in Pelle’s blog post:

IRIs for Identifiers

"I’m sorry calling URI’s IRI just smells of political correctness.
Everyone calls them URI’s and knows what it means. No one knows what a
IRI is. Even though W3C pushes it I’m going to use the term URI to avoid
confusion."

Wikipedia defines the Internationalized Resource Identifier (IRI) as: a
generalization of the Uniform Resource Identifier (URI). While URIs are
limited to a subset of the ASCII character set, IRIs may contain
characters from the Universal Character Set (Unicode/ISO 10646),
including Chinese or Japanese kanji, Korean, Cyrillic characters, and so
forth. It is defined by RFC 3987.

PaySwarm is on a world-standards track and thus takes the position that
being able to express identifiers in one’s native language is important.
When writing standards, it is important to be technically specific and
use terminology that has been previously defined by standards groups.
Usage of the term IRI is not only technically correct, it acknowledges
the notion that we must support non-English identifiers in a payment
standard meant for the world to use.

IRIs for Identifiers (cont.)

"We don’t want to specify what lives at the end of an account URI. There
are many other proposals for standardizing it, we don’t need to deal
with that. Until the day that a universal machine readable account URI
standard exist, implementers of OpenTransact can either do some sensing
of the URI as they already do today (Twitter, Facebook, Github) or use
proposals like WebFinger or even enter the world of linked data and use
that."

The problem with the argument is expressed in this phrase – Until the
day that a universal machine readable account URI standard exist[s].
PaySwarm defines a universal, machine-readable account URI standard.
This mechanism is important for interoperability – without it, it
becomes difficult to publish information in a decentralized,
machine-readable fashion. Without describing what lives at the end of an
account IRI, you can’t figure out who owns a financial account, you
can’t understand what the currency of the account is, nor can you extend
the information associated with the account in an interoperable way.
PaySwarm asserts that we cannot just gloss over this part of the problem
space as it is important for interoperability.

Basic Financial Transfer

"OpenTransact does not specify how a transfer physically happens as that
is an implementation detail. It could be creating a record in a ledger,
uploading a text file to a mainframe via ftp, calling multiple back end
systems, generating a bitcoin, shipping a gold coin by fedex, etc."

At no point does the PaySwarm specification state what must happen
physically. What happens physically is outside of the scope of the
specification. What matters is how the digital exchange happens. This is
primarily because any open payment platform for the Web is digitally
native. That is, when you pay someone, the transfer is executed and
recorded digitally, at times, between two payment processors. This is
the same sort of procedure that happens at banks today. Rarely does
physical cash move when you use your credit or debit card.

The point of supporting a Basic Financial Transfer between systems boils
down to interoperability. OpenTransact doesn’t mention how you transfer
$1 from PaymentServiceA to PaymentServiceB. That is, if you are
bob@mypay.com and you want to send $1 to jane@superfund.com, how do you
initiate the transfer from mypay.com to superfund.com? That is, what is
the protocol? OpenTransact is silent on how this cross-payment processor
transfer happens. PaySwarm asserts that specifying this payment
processor monetary exchange protocol in great detail is vital to ensure
that the standard enables a fair and efficient transaction processor
marketplace. That is, specifying how this works is vital for ensuring
that new payment processor competitors can enter the marketplace with as
little friction as possible. If a payment standard does not specify how
this works, it enables vendor lock-in and payment network silos.

When it comes to standards, implementation details like this matter
because without explicitly stating how two systems may exchange money
with one another, interoperability suffers.

Transacted Item Identifer

"It would be great to have a standard way of specifying every single
item in this world and that is pretty much what RDF is about. However
until such day that every single object in the world is specified by
RDF, we believe it is best to just identify the purchased item with a url."

This argument seems to be saying two contradictory things; 1) It would
be great to have a standard way of describing machine-readable items on
the Web and 2) until that happens, we should just use URLs.

PaySwarm defines exactly how to express machine-readable items on the
Web. Since the first part of the statement is true today, the last part
of the statement becomes unnecessary. Furthermore, both OpenTransact and
PaySwarm use IRIs for transacted item identifiers – that was never in
question. OpenTransact uses an IRI to identify the transacted item.
PaySwarm uses an IRI to identify the transacted item, but also ensures
that the item is machine-readable and digitally signed by the seller for
security purposes.

There are at least two reasons that you cannot just depend on URLs for
describing items on the Web without also specifying how those items can
be machine-readable and verifiable.

The first reason is because the seller can change what is at the end of
a URL over time and that is a tremendous liability to those purchasing
that item if the item’s description is not stored at the time of sale.
For example, assume someone sells you an item described by the URL
http://example.com/products/82737. When you look at that URL just before
you buy the item, it states that you are purchasing tickets to a
concert. However, after you make the purchase, the person that sold you
the item changes the item at the end of the URL to make it seem as if
you purchased an article about their experience at the concert and not
the ticket to go to the concert. PaySwarm protects against this attack
by ensuring that the machine-readable description of what is being
transacted is machine-readable and that machine-readable description is
shown to the buyer before the sale and then embedded in the receipt of sale.

The second reason is that the URL, if served over HTTP, can be
intercepted and changed, such that the buyer ends up purchasing
something that the seller did not approve for sale. PaySwarm addresses
this security issue by ensuring that all offers for sale must be
digitally signed by the seller.

Alternative Currencies

"In most cases the currency mint is equal to the transaction processor."

The currency mint is not equivalent to the transaction processor. Making
that assertion conflates two important concepts; 1) the issuer of a
currency, and 2) the transaction processors that are capable of
transacting in that currency. To put it in different terms, that’s as if
one were to say that the US Federal Reserve (the issuer of the USD
currency) is the same thing as a local bank in San Francisco (an entity
transacting in USD).

Access Control Delegation

"But Digital Signatures only solve the actual access process so you have
to create your home built authorization and revocation scheme to match
what OAuth 2 gives us for free."

In software development, nothing is free. There are always design
trade-offs and the design trade-off that OpenTransact has made is to
adopt OAuth 2 and punt on the problem of machine-readable and verifiable
assets, licenses, listings, and digital contracts. While Pelle makes the
argument that OpenTransact may add digital signature support in the
future, the final solution would require that both OAuth 2 and digital
signatures be implemented.

PaySwarm does not reject OAuth 2 as a useful specification, it rejects
it because it overly-complicates the implementation details of the open
payment platform. PaySwarm does not use OAuth 2 for the same reason that
it does not use XML. XML is a perfectly good technology, but it does not
apply to the problem space PaySwarm is addressing.

Furthermore, PaySwarm had previously been implemented using OAuth and we
found it to be overly complicated because of this very reason. OAuth and
digital signatures largely duplicate functionality and since PaySwarm
requires digital signatures to offer a secure, distributed, open payment
platform, the most logical thing was to remove OAuth. By removing OAuth,
no functionality was sacrificed and the overall system was simplified as
a result.

Machine Readable Metadata

"Every aspect of PaySwarm falls apart if everything isn’t created using
machine readable metadata. This would be great in a perfect greenfield
world. However while meta data is improving as people are adding open
graph and other stuff to their pages for better SEO and Facebook
integration, there are many ways of doing it and a payment standard
should not be specifying how every product is listed, sold or otherwise."

This argument is a bit strange – on one hand, it is asserted that it
would be great if a product could be listed in a way that is
machine-readable while simultaneously stating that a payment standard
shouldn’t do it. More simply, the argument is – it would be great if we
did X, but we shouldn’t do X.

Why shouldn’t a payment platform standard specify how items should be
listed for sale? If there are many ways of specifying how a product
should be listed for sale, isn’t that a good candidate for
standardization? After all, when product listings are machine-readable,
we can automate a great deal of what previously required human intervention.

The reason that Open Graph and Facebook integration happened so quickly
across a variety of websites is because it provided good value for the
website owners as well as Facebook. It allowed websites to be more
accurately listed in feeds. It also allowed Facebook to leverage the
people in its enormous social network to categorize and label content,
something that had been impossible on a large scale before. The same is
true for Google Rich Snippets and the recent schema.org work launched by
Google, Microsoft, Yahoo! and Yandex. Website owners can now mark up
people, events, products, reviews, and recipes in a way that is
machine-readable and that shows up directly, in an enhanced form from
regular search listings, in the search engine results pages.

Making things in a web page machine-readable, like products for sale,
automates a very large portion of what used to require human oversight.
When we automate processes like these, we are able to gain efficiencies
and innovate on top of that automation. Specifying how a product should
be marked up on the Web in order to be transacted via an open Web
payment platform is exactly what should be standardized in a
specification, and this is exactly what PaySwarm does.

Recurring payments

"With OpenTransact we are still discussing how to specify recurring
payments. Before we add it to the standard we would like a couple of
real world implementations experiment with it."

This is a chicken and egg problem – at some point, someone has to
propose a way to perform recurring payments for an open payment
platform. When the OpenTransact specification states that it won’t
implement recurring payments until somebody else implements recurring
payments, then the problem is just shifted to another community that
must do the hard work of figuring out how to implement recurring payments.

PaySwarm has gone to the trouble of specifying exactly how recurring
payments are performed. There are many other implementations of
recurring payments implemented by the many credit card transaction
processors, PayPal, Google Checkout, and Amazon Payments, to name a few.
There are many real-world implementations of recurring payments today,
so it is difficult to understand exactly what the designers of
OpenTransact are waiting on.

Financial Institution Interoperability

"OpenTransact is most certainly capable of interoperability between
financial institutions. We don’t specify how one payment provider
transacts with another payment provider, but it is generally understood
that they do so with OpenTransact."

The statement above seems to contradict itself. On one hand, it states
that OpenTransact is capable of interoperability between financial
institutions. On the other hand, it states that OpenTransact does not
specify how one payment provider transacts with another payment provider.

By definition, you do not have interoperability if you do not specify
how one system interoperates with another. Furthermore, claiming that
two systems interoperate but then not specifying how they interoperate
is an invitation for collusion between financial institutions and is a
step backwards when looking at how financial institutions operate today.
That is, at least there is an inter-bank monetary transfer protocol that
you can utilize if you are a bank. This functionality, of detailing how
two payment processors interact, is out of scope for OpenTransact.

Digital Signatures

"Digital signatures are beautiful engineering constructs that most
engineers who have worked with them tend to hold up in near religious
reverence. You often hear that a digital signature makes a contract
valid and it supports non-repudiation."

PaySwarm does not hold up digital signatures in religious reverence, nor
does it assert that by using a digital signature, a digital contract is
automatically a legally enforceable agreement. What PaySwarm does do is
utilize digital signatures as a tool to provide system security. It also
utilizes digital signatures so that simple forgeries on digital
contracts cannot be performed.

By not supporting digital signatures in its core protocol, OpenTransact
greatly limits itself regarding the use cases that can be addressed with
the standard. These use cases that are not addressed by OpenTransact are
regarded as very important to the PaySwarm work and thus, cannot be ignored.

Secure Communication over HTTP

"We are not trying to reinvent TLS because certs are expensive, which is
what PaySwarm proposes."

PaySwarm does not try and re-invent TLS. PaySwarm utilizes TLS to
provide security against man-in-the-middle attacks. What PaySwarm also
does is allow sellers on the system to run an online storefront from
their website over regular HTTP, thus greatly reducing the cost of
setting up and operating an online store-front. The goal is to make the
barrier to entry for a vendor on PaySwarm cost absolutely nothing, thus
enabling a large group of people that were previously unable to
participate in electronic commerce via their website to do so in a way
that does not require an up-front monetary investment.

Continuing the Discussion

The fundamental point made in this blog post is that by being
hyper-focused on initiating payment transfers, OpenTransact misses the
bigger picture of ensuring interoperability in an open payment platform.
Until this issue is addressed and it is demonstrated that OpenTransact
is capable of addressing more than just a few of the simplest use cases
supported by PaySwarm, I fear that it will not pass the rigors of the
standardization process.

In his blog post, Pelle only responded to around half of the analysis on
OpenTransact and thus further analysis will be performed on his
responses when he is able to find time to post them.

If you are interested in listening in on or participating in the
discussion, please consider joining the Web Payments Community Group
mailing list at the World Wide Web Consortium (W3C) (it’s free, and
anyone can join!).

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

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: PaySwarm vs. OpenTransact Shootout
http://manu.sporny.org/2011/web-payments-comparison/

Received on Sunday, 1 January 2012 17:49:49 UTC