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.
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.
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.
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 firstname.lastname@example.org and you want to send $1 to email@example.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.
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 Treasury (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 relies on digital signatures instead of OAuth 2 for the same reason that it relies on JSON instead of XML. XML is a perfectly good technology, but JSON is simpler and solves the problem in a more elegant way. That is, adding XML to the specification would needlessly over-complicate the solution, which is why it was rejected.
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.
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 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 to re-invent TLS. PaySwarm utilizes TLS to provide security against man-in-the-middle attacks. It also utilizes TLS to create a secure channel from the customer to their PaySwarm Authority and from the merchant to their PaySwarm Authority. 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!).
Follow-up to this blog post
[Update 2012-01-02: Second part of response by Pelle to this blog post: OpenTransact vs PaySwarm part 2 - yes it's still mostly out of scope]
[Update 2012-01-08: Rebuttal to second part of response by Pelle to this blog post: Web Payments: PaySwarm vs. OpenTransact Shootout (Part 3)]
* Many thanks to Dave Longley, who reviewed this post and suggested a number of very useful changes.