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.
You may jump to each section of this blog post:
- Why OpenTransact Fails To Standardize Web Payments
- General Misconceptions (continued)
- Detailed Rebuttal (continued)
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 another.
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 achieved.
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 addressed.
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.
…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 specification.
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.
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.
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.
- 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.
- 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.
- 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.
- 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.