All posts in Standards

Kumar McMillan (Mozilla/FirefoxOS) and I (PaySwarm/Web Payments) have just published the first draft of the Browser Payments 1.0 API. The purpose of the spec is to establish a way to initiate payments from within the browser. It is currently a direct port of the mozPay API framework that is integrated into Firefox OS. It enables Web content to initiate payment or issue a refund for a product or service. Once implemented in the browser, a Web author may issue navigator.payment() function to initiate a payment.

This is work that we intend to pursue in the Web Payments Community Group at W3C. The work will eventually be turned over to a Web Payments Working Group at W3C, which we’re trying to kick-start at some point this year.

The current Browser Payments 1.0 spec can be read here:

http://web-payments.github.io/browser-payments/

The github repository for the spec is here:

https://github.com/web-payments/browser-payments/

Keep in mind that this is a very early draft of the spec. There are lots of prose issues as well as bugs that need to be sorted out. There are also a number of things that we need to discuss about the spec and how it fits into the larger Web ecosystem. Things like how it integrates with Persona and PaySwarm are still details that we need to suss out. There is a bug and issue tracker for the spec here:

https://github.com/web-payments/browser-payments/issues

The Mozilla guys will be on next week’s Web Payments telecon (Wednesday, 11am EST) for a Q/A session about this specification. Join us if you’re interested in payments in the browser. The call is open to the public, details about joining and listening in can be found here:

https://payswarm.com/minutes/

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:

1. Web Payments: PaySwarm vs. OpenTransact Shootout by Manu Sporny
2. OpenTransact the payment standard where everything is out of scope by Pelle Braendgaard
3. Web Payments: PaySwarm vs. OpenTransact Shootout (Part 2) by Manu Sporny
4. 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:

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 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.

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 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.

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.

Crowd-funding

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.

Conclusion

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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

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:

1. The Purpose of a Standard
2. Web Payments – The Hard Problem
3. The Problem Space
4. General Misconceptions
5. Detailed Rebuttal
6. 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 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.

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 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.

The W3C Web Payments Community Group was officially launched in August 2011 for the purpose of standardizing technologies for performing Web-based payments. The group launched at that time because Digital Bazaar had made a commitment to publish the PaySwarm technology as an open standard and eventually place it under the standardization direction of the W3C. During last week’s Web Payments telecon, a discussion ensued about using the OpenTransact specification as the basis for the Web Payments work at W3C. Inevitably, the group will have to thoroughly vet both technologies to see if it should standardize PaySwarm, OpenTransact, or both.

This blog post is a comparison of the list of features that both technologies have outlined as being standardization candidates for version 1.0 of each specification. The comparison uses the latest published specifications as of the time of this blog post, OpenTransact (October 19th, 2011) and PaySwarm (December 14th, 2011). Here is a brief summary table on the list of features supported by each proposed standard:

IRIs for Identifiers

If a payment technology is going to integrate cleanly with the Web, it should identify the things that it operates on in a Web-friendly way. Identifiers are at the heart of most Internet-based systems, and therefore it is important that the identifier work in a way that allows it to be used across the world and beyond and across different systems operating in different locations. The Internationalized Resource Identifier (IRI), of which Uniform Resource Locators (URLs) are a sub-set, provide a globally scale-able mechanism for creating distributed, de-reference-able identifiers.

PaySwarm uses IRIs to identify things like identities (http://example.com/identities/jane), financial accounts (http://example.com/accounts/jane/college-fund), assets (http://example.com/ebooks/the-republic), licenses (http://example.com/licenses/personal-use), listings (http://example.com/ebooks/the-republic#half-off-retail), transactions (http://example.com/transactions/2011/12/18/12345), contracts (http://example.com/contracts/2011/12/18/54321), and a variety of the other things that must be expressed when building an open protocol for a financial system.

OpenTransact uses IRIs to identify Asset Services (http://megabank.example.com/current), identities (bill@test.example.com), transfer receipts (http://epay.example.com/transactions/aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d), callbacks (http://epay.example.com/payment-callback), and providers of items for sale (http://vendor.example.com/). While OpenTransact does not detail many of the “things” that PaySwarm does, the implicit assumption is that those “things” would also have IRIs as their identifiers.

Basic Financial Transfer

An open payment protocol for the Web must be able to perform a simple financial transfer from one financial account to another. This simple exchange is different from the more complex transaction, as outlined below, which allows multiple financial transfers to occur across multiple accounts during a single transaction.

PaySwarm supports transfers from one financial account to another both within systems and between systems.

OpenTransact outlines transfers from one account to another within a system. It is unclear whether it supports financial transfers between systems since the implementation details of how the transfer occurs are not explained in the specification.

Payment Links

A Payment Link is a click-able link in a Web browser that enables one person or organization on the Web to request payment from another person or organization on the Web. Clicking on the link initiates the transfer process. The URL query parameters are standardized such that all payment processors on the Web would implement a single set of known query parameters, thus easing implementation burden when integrating with multiple payment systems.

A PaySwarm Authority will depend on the Payment Links specification to specify the proper query parameters for a Payment Link. These query parameters are intended to overlap almost entirely with the OpenTransact query parameters.

The OpenTransact specification outlines a set of query parameters for payment links.

Transacted Item Identifier

Being able to identify an item that is the cause of a financial transfer on the Web is important because it enables the payment system to understand why a particular transfer occurred. Furthermore, ensuring that the item identifier is de-reference-able allows humans and in some cases, machines, to view details about the item for sale.

PaySwarm calls an item that can be transacted an asset and ensures that the description of every asset on the network meet five important criteria; the asset is identified via an IRI, the asset description can be retrieved by de-referencing the IRI, the asset description is human-readable, the asset description is machine-readable and that the asset description can be frozen in time (to ensure the description of the asset does not change from one purchase to the next).

OpenTransact leaves the identification of the item being transacted a bit more open-ended and does not assign a conceptual name to the item. It ensures that the item is identified by an IRI and that de-referencing the IRI results in an item description. The specification is silent on whether or not the item description is required to be human-readable or machine-readable and does not require that the item description can be frozen in time. Since the item IRI is saved in the receipt but a machine-readable description is not, it allows the vendor to change the description of the purchased item at any point. For example, if the buyer purchased an ebook on day one, the vendor can change the purchase to seem as if it were a rental of the ebook on day two.

Micropayments

Micropayments allow the transmission of very small amounts of money from sender to receiver. For example, paying $0.05 for access to an article would be considered a micropayment. One of the primary benefits of micropayments is that they enable easy-to-use pay-as-you-go services. Micropayments also allow one to transfer small amounts of funds at a time without incurring high per-transaction fees.

The smallest amount for a PaySwarm transactions is unlimited. However, most transaction processors will limit payments up to 1/10,000th of the smallest whole denomination of a currency. For example, the smallest transaction possible using the PaySwarm software that Digital Bazaar is developing in US Dollars is $0.0000001 (one ten-millionth of a US Dollar).

OpenTransact is not limited in the smallest amount that is transferable.

Alternative Currencies

Alternative currencies like Ven, Bitcoin, time banking, Bernal Bucks and various gaming currencies like XBox Points are being increasingly used to solve niche economic problems that traditional fiat currencies have not been able to address. In order to ensure that experimentation with alternative currencies are supported, a Web-based payment protocol should ensure that those currencies can be easily created and exchanged.

PaySwarm allows currencies to be specified by either an internationalized currency code, like “USD”, or by an IRI that identifies a currency. This means that anyone capable of minting an IRI, which is just about anybody on the Web, has the ability to create a new alternative currency. The one draw-back for alternative currencies is that there must also be a location, or network, on the Web that acts as the currency mint. The concept of a currency mint will be covered later in this blog post.

OpenTransact supports alternative currencies by creating what it calls Asset Service endpoints. These endpoints can be for the transmission of fixed currencies, stocks, bonds, or other financial instruments.

Access Control Delegation

When implementing features like recurring payments, often some form of access control is required to ensure that a vendor honors the agreement that they created with the buyer. For example, giving permission to a vendor to bill you for up to $10 USD per month requires that some sort of access control privileges are assigned to the vendor. This access control mechanism allows the vendor to make withdrawals without needing to repeatedly bother the buyer. It also gives power to the buyer if they ever want to halt payment to the vendor. There are two primary approaches to access control on the Web; OAuth and digital signatures.

PaySwarm relies on digital signatures to ensure that a request for financial transfer is coming from the proper vendor. Setting up access control is a fairly simple process in PaySwarm, consisting of two steps. The first step requires the vendor to request access from the buyer via a Web browser link. The second step requires that the buyer select which privileges, and limits on those privileges, they are granting to the vendor. These privileges and limits may effectively make statements like: “I authorize this vendor to bill me up to $10 per month”. The vendor may then make financial transfer requests against the buyer’s financial account for up to $10 per month.

OpenTransact enables access control via the OAuth 2 protocol, which is capable of supporting similar privileges and limitations as PaySwarm. However, the OAuth 2 protocol does not allow for digital signatures external to the protocol and thus would also require a separate digital signature stack in order to support things like machine-verifiable receipts and decentralized assets, licenses and listings.

Machine Readable Metadata

One of the benefits of creating an open payment protocol is that the protocol can be further automated by computers if certain information is exposed in a machine-readable way. For example, if a digital receipt were exposed such that it was machine-readable, access to a website could be granted merely by transmitting the digital receipt to the website.

PaySwarm requires that all data that participates in a transaction is machine readable in a deterministic way. This ensures that assets, licenses, listings, contracts and digital receipts (to name a few) can be transacted and verified without a human in the loop. This increased automation leads to far better customer experiences on websites, where a great deal of the annoying practice of filling out forms can be skipped entirely because machines can automatically process things like digital receipts.

OpenTransact describes exactly what receipt metadata looks like – it’s a JSON object that contains a number of fields. It also outlines that implementations could ask for descriptions of OpenTransact Assets and the associated list of transactions that are associated with those Assets. However, there is no mechanism that allows this metadata to be extended in a deterministic fashion. This limitation will be further detailed below.

Recurring Payments

A recurring payment enables a buyer to specify that a particular vendor can bill them at a periodic interval and removes the burden of buyers having to remember to pay bills every month. Recurring payments requires a certain level of Access Control Delegation.

Recurring payments are supported in PaySwarm by pre-authorizing a vendor to spend a certain limit at a pre-specified time interval. Many other rules can be put into place as well. For example, the buyer could limit the time period that the vendor can operate or the transaction processor could send an e-mail every time the vendor withdraws money from the buyer.

While a recurring payments use case exists for OpenTransact, no specification text has been written on how one can accomplish this feat from a technical standpoint.

Transaction Processor Interoperability

For an open payment protocol to be truly open, it must provide interoperability between systems. At the most basic level, this means that a transaction processor must be able to take funds from an account on one system and transfer those funds to a different account on a different system. Interoperability often goes deeper than that, however, as transferring transaction history, accounts, and preference information from one system to the next is important as well.

Since PaySwarm lists financial accounts in a decentralized way (as IRIs), there is no reason that two financial accounts must reside on the same system. In fact, PaySwarm is built with the assumption that payments will freely flow between various payment processors during a single transaction. This means that a single transaction could contain multiple payees and each one of those payees could reside on a different system, and as long as each system adheres to the PaySwarm protocol, the money will be transmitted to each account. While the specification text has not yet been written, the PaySwarm system will not be fully standardized until the protocol for performing the back-haul communication between each PaySwarm Authority is detailed in the specification. That is, system to system inter-operability is a requirement of the protocol.

The OpenTransact specification identifies senders and receivers in a decentralized way (as IRIs). There are no plans to specify system-to-system transactions in the OpenTransact 1.0 specification. The type of interoperability that OpenTransact provides is library API-level compatibility. That is, those writing software libraries for financial services need only implement one set of query parameters to work with an OpenTransact system. However, the specification does not specify how money flows from one system to the next. There is no system-to-system interoperability in OpenTransact and thus each implementation does nothing to prevent transaction processor lock-in.

Extensible Machine Readable Metadata

Having machine-readable data allows computers to automate certain processes, such as receipt verification or granting access based on details in a digital contract. However, machine-readable data comes at the cost of having to use rigid data structures. These rigid data structures can be extended in a variety of ways that provide the best of both worlds – machine readability and extensibility. Allowing extensibility in the data structures enables innovation. For example, the addition of new terms in a contract or license would enable new business models not considered by the designers of the core protocol.

PaySwarm utilizes JSON-LD to express data in such a way as to be easily usable by Web programmers, but extensible in a way that is guaranteed to not conflict with future versions of the protocol. This means that assets, licenses, listings, digital contracts, and receipts may be extended by transaction processors in order to enable new business models without needing to coordinate with all transaction processors as a first step.

OpenTransact utilizes JSON to provide machine-readable data for receipts, Assets and transactions. However, it does not specify any mechanism that allows one to extend the data structures without running the risk of conflicting with future advancements to the language.

Transactions

A transaction is defined as a collection of one or more transfers. An example of a transaction is paying a bill at a restaurant. Typically, that transaction results in a number of transfers – there is one from the buyer to the restaurant, another from the buyer to a tax authority, and yet another transfer from the buyer to tip the waiter (in certain countries). While the restaurant gives you a single receipt, the transfer of money is often more complex than just a simple transmission from one sender to one receiver.

PaySwarm models transactions in the way that we model them in the real world – a transaction is a collection of monetary transfers from a sender to multiple receivers. An example of a transaction can be found in the PaySwarm Commerce vocabulary.

OpenTransact models only the most low-level concept of a financial transfer and leaves implementation of transactions to a higher-level application. That is, transactions are considered out-of-scope for the OpenTransact specification and are expected to be implemented at the application layer.

Currency Exchange

A currency exchange allows one to exchange a set amount of one currency for a set amount of another currency. For example, exchanging US Dollars for Japanese Yen, or exchanging goats for chickens. A currency exchange functions as a mechanism for transforming something of value into something else of value.

PaySwarm supports currency exchanges via digital contracts that outline the terms of the exchange.

OpenTransact asserts that currency exchanges can be implemented on top of the specification, but states that the details of that implementation are strictly outside of the specification. One of the primary features that are required for a functioning currency exchange is the concept of a currency mint, which is also outside of the scope of OpenTransact.

Digital Signatures

A digital signature is a mechanism that is used to verify the authenticity of digital messages and documents. Much like a hand-written signature, it can be used to prove the identity of the person sending the message or signing a document. Digital signatures have a variety of uses in financial systems, including; sending and receiving verifiable messages, access control delegation, sending and receiving secure/encrypted messages, counter-signing financial agreements, and ensuring authenticity of digital goods.

PaySwarm has direct support for digital signatures and utilizes them to provide the following capabilities; sending and receiving verifiable messages, access control delegation, sending and receiving secure/encrypted messages, counter-signing financial agreements, ensuring the authenticity of assets, licenses, listings, digital contracts, intents to purchase, and verifiable receipts.

OpenTransact does not support digital signatures in the specification.

Secure Communication over HTTP

While HTTP has served as the workhorse protocol for the Web, it’s major weakness is that it is not secure unless wrapped in a Transport Layer Security (TLS, aka SSL) connection. Unfortunately, TLS/SSL Certificates are costly and one of the design goals for an open protocol for Web Payments should be reducing the financial burden placed on the network participants. Another mechanism that can be used to secure HTTP traffic is by using AES to encrypt/decrypt or digitally sign parts of the HTTP message. This approach results in a zero-financial-cost solution for implementing a secure message channel inside of an HTTP message.

Since PaySwarm supports AES and digital signatures by default, it is also capable of securing communication over HTTP.

OpenTransact relies on OAuth 2 and thus requires a financial commitment from the participant if they want to secure their network traffic via TLS. There is no way to use OpenTransact over HTTP in a secure manner without TLS. However, this is not a problem for the subset of use cases that OpenTransact aims to solve. It does not address the cases where a digital signature or encryption is required to communicate over an un-encrypted HTTP message channel.

Decentralized Publishing of Items for Sale

A vendor would like to have their products listed for sale as widely as possible while ensuring that their control over the item’s machine-readable description is ensured, regardless of where it is listed on the Web. It is important to be able to list items for sale in a secure manner, but allow the flexibility for that item to be expressed on sites that are not under your control. Decoupling the machine-readable description of an item for sale from the payment processor allows both mechanisms to be innovated upon on different time-frames by different people. Centralized solutions are often easier to implement, but far less flexible from decentralized solutions. This holds true for how items for sale are listed. Allowing vendors to have full control over how their items for sale should appear to those browsing their wares is something that a centralized solution cannot easily offer.

PaySwarm establishes the concept of an asset and describes how an asset can be expressed in a secure, digitally signed, decentralized manner.

OpenTransact does not support machine-readable descriptions of items, nor does it support digital signatures to ensure that items cannot be tampered with by third-parties, or even the originating party.

Decentralized Publishing of Licenses

When a sale occurs, there is typically a license that governs the terms of sale. Often, this license is implied based on the laws of commerce governing the transaction in the region in which the transaction occurs. What would be better is if the license could be encapsulated into the receipt of sale and specified in a way that is decentralized to the financial transaction processor and to the item being purchased. This would ensure that people and organizations that specialize in law could innovate and standardize a set of licenses independently of the rest of the financial system.

PaySwarm establishes the concept of a license and describes how it can be expressed in a secure, digitally signed, decentralized manner. Licenses typically contain boilerplate text which are sprinkled with configurable parameters such as “warranty period in days from purchase”, and “maximum number of physical copies” (for things like manufacturing).

OpenTransact does not support machine-readable licenses, embedding licenses, nor does it support digital signatures to ensure that the license cannot be tampered with by third-parties. License tampering isn’t just a problem when transmitting the license over insecure channels, it is also an issue if the the originator of the license changes the contents of the license.

Decentralized Publishing of Listings

A listing specifies the payment details and license under which an asset can be transacted. Giving a vendor full control over when, where and how a listing is published is vital to ensuring that new business models that depend on when and how items are listed for sale can be innovated upon independently of the financial network. So, it becomes important that listings can not only be expressed in a decentralized manner, but they are also tamper-proof and re-distribute-able across the Web while ensuring that the vendor stays in control of how long a particular offer lasts.

PaySwarm establishes the concept of a listing and describes how it can be expressed in a secure, digitally signed, decentralized manner. Decentralized listings allow assets described in the listings to be sold on a separate site, under terms set forth by the original asset owner. That is, a pop-star could release their song as a listing on their website, and the fans could sell it on behalf of the pop-star while making a small profit from the sale. In this scenario, the pop-star gets the royalties they want, the fan gets a cut of the sale, and mass-distribution of the song is made possible through a strongly motivated grass-roots effort by the fans.

OpenTransact does not support machine-readable listings, nor does it support digital signatures to ensure that the license cannot be tampered with by third-parties.

Digital Contracts

A contract is the result of a commercial transaction and contains information such as the item purchased, the pricing information, the the parties involved in the transaction, the license outlining the rights to the item, and payment information associated with the transaction. A digital contract is machine-readable, is self-contained and is digitally signed to ensure authenticity.

PaySwarm supports digital contracts as the primary mechanism for performing complex exchanges of value. Digital contracts support business practices like intent-to-purchase, being able to purchase an asset under different licenses (such as personal use and broadcast use), and digital receipts.

OpenTransact does not support digital contracts nor does it support digital signatures.

Verifiable Receipts

A verifiable receipt is a receipt that contains a digital signature such that you can verify the accuracy of the receipt contents. Verifiable receipts are helpful when you need to show the receipt to a third party to assert ownership over a physical or virtual good. For example, a music fan could show a verifiable receipt confirming that they purchased a certain song from an artist to get a discount on tickets to an upcoming show. There would not need to be any coordination between the original vendor of the songs and the vendor of the tickets if a verifiable receipt was used as a proof-of-purchase.

PaySwarm supports verifiable receipts, even when the signatory of the receipt is offline. The only piece of information necessary is the public key of the PaySwarm Authority. This means that receipts can be verified even if the transaction processor is offline or goes away entirely.

OpenTransact does support receipts delivered via the Asset Service, using OAuth 2 as the access control mechanism. This means that retrieving a receipt for validation requires having a human in the loop. A verifying website would need to request an OAuth 2 token, the receipt-holder would need to grant access to the verifying website, and then the verifying website would use the token to retrieve the receipt. Currently, OpenTransact does not support digitally signed receipts, and thus it does not support receipt verification if the Asset Service is offline.

Affiliate Sales

When creating content for the Web, getting massively wide distribution typically leads to larger profits. Therefore, it is important for people that create items for sale to be able to grant others the ability to redistribute and profit off of the redistribution, as long as the original creator is compensated under their terms for their creation. Typically, this is called the affiliate model – where a single creator allows wide-distribution of their content through a network of affiliate sellers.

PaySwarm supports affiliate re-sale through digitally signed listings. A listing associates an asset for sale, the license under which asset use is governed and the payment amount and rules associated with the asset. These listings can be used on their originating site, or a third party site. Security of the terms of sale specified in the listings are ensured through the use of digital signatures.

OpenTransact does not support affiliate sales.

Secure Vendor-routed Purchases

At times, network-connectivity can be a barrier for performing a financial transaction. In these cases, the likelihood that a at least one of the transaction participants has an available network connection is high. For example, if a vendor has a physical place of business with a network connection, the customers that frequent that location can depend on the vendor’s network connection instead of requiring their own when processing payments. This is useful when implementing a payment device in hardware, like a smart payment card, without also requiring that hardware device to have a large-area network communication capability, like a mobile phone. A typical payment flow is outlined below:

1. The vendor presents a bill to the buyer.
2. The buyer views the bill and digitally signs the bill, stating that they agree to the charges.
3. The vendor takes the digitally signed bill and forwards it to the buyer’s payment processor for payment.

PaySwarm supports vendor-routed purchases through the use of digital signatures on digital contracts. When the vendor provides a digital contract to a buyer, the buyer may accept the terms of sale by counter-signing the digital contract from the vendor. The counter-signed digital contract can then be uploaded to the buyer’s PaySwarm Authority to transfer the funds from the buyer to the vendor. The digital contract is returned to the vendor with the PaySwarm Authority’s signature on the contract to assert that all financial transfers listed in the contract have been processed.

OpenTransact does not support vendor-routed purchases, requiring instead that both buyer and vendor have network connectivity when performing a purchase.

Secure Customer-routed Purchases

At times, network-connectivity can be a barrier for performing a financial transaction. In these cases, the likelihood that a at least one of the transaction participants has an available network connection is high. For example, a vendor could setup a sales kiosk without any network connection (such as a vending machine) and route purchase processing via a customer’s mobile-phone. A typical payment flow is outlined below:

1. The buyer selects the product that they would like to purchase from the kiosk (like a soda).
2. The kiosk generates a bill and transmits it to the mobile device via a NFC connection.
3. The buyer’s mobile phone digitally signs the bill and sends it to their payment processor for processing.
4. The digitally signed receipt is delivered back to the buyer’s mobile device, which then transmits it via NFC to the kiosk.
5. The kiosk checks the digital signature and upon successful verification and delivers the product to the buyer (a cold, refreshing soda).

PaySwarm supports customer-routed purchases through the use of digital signatures on digital contracts. When the buyer receives the digital contract for the purchase from the kiosk, it is already signed by the vendor which implies that the vendor is amenable to the terms in the contract. The buyer then counter-signs the contract and sends it up to the PaySwarm Authority for processing. The PaySwarm Authority then counter-signs the contract, which is delivered back to the buyer, which then routes the finalized contract back to the kiosk. The kiosk checks the digital signature of the PaySwarm Authority on the contract and delivers the product to the buyer.

OpenTransact does not support customer-routed purchases, requiring instead that both buyer and vendor have network connectivity when performing a purchase.

Currency Mints

A currency mint is capable of creating new units of a particular currency. A currency mint is closely related to the topic of alternative currencies, as previously mentioned in this blog post. In order for an alternative currency to enter the financial network, there must be a governing authority or algorithm that ensures that the generation of the currency is limited. If the generation of a currency is not limited in any way, hyperinflation of the currency becomes a risk. The most vital function of a currency mint is to carefully generate and feed currency into payment processors.

PaySwarm supports currency mints by allowing the currency mint to specify an alternative currency via an IRI on the network. The currency IRI is then used as the origin of currency across all PaySwarm systems. The currency mint can then deposit amounts of the alternative currency into accounts on any PaySwarm Authority through an externally defined process.

OpenTransact does not support currency mints. It does support alternative currencies, but does not specify how the alternative currency can be used across multiple payment processors and therefore only supports alternative currencies in a non-inter-operable way.

Crowd-funding

Crowd-funding is the act of pooling a set of funds together with the goal of effecting a change of some kind. Kickstarter is a great example of crowd-funding in action. There are a number of requirements when crowd-funding; ensure that money is not exchanged until a funding goal has been reached (an intent to fund), if a funding goal is reached – allow the mass collection of money (bulk transfer), if a funding goal is not reached – invalidate the intent to fund (cancellation).

PaySwarm supports crowd-funding. The digital contracts that PaySwarm uses can express an intent to fund. Mass-collection of a list of digital contracts expressing an intent to fund can occur in an atomic operation, which is important to make sure that the entire amount is available at once. Finally, the digital contracts containing an intent to fund also contain an expiration time for the offer to fund.

OpenTransact does not support crowd-funding as described above.

Data Portability

Data portability provides the mechanism that allows people and organizations to easily transfer their data across inter-operable systems. This includes identity, financial transaction history, public keys, and other financial data in a way that ensures that payment processors cannot take advantage of platform lock-in. Making data portability a key factor of the protocol ensures that the customers always have the power to walk away if they become unhappy with their payment processor, thus ensuring strong market competition among payment processors.

PaySwarm ensures data portability by expressing all of its Web Service data as JSON-LD. There will also be a protocol defined that ensures that data portability is a requirement for all payment processors implementing the PaySwarm protocol. That is, data portability is a fundamental design goal for PaySwarm.

OpenTransact does not specify any data portability requirements, nor does it provide any system inter-operability requirements. While certainly not done on purpose, this creates a dangerous formula for vendor lock-in and non-interoperability between payment processors.

Follow-up to this blog post

[Update 2011-12-21: Partial response by Pelle to this blog post: OpenTransact the payment standard where everything is out of scope]

[Update 2012-01-01: Rebuttal to Pelle's partial response to this blog post: Web Payments: PaySwarm vs. OpenTransact Shootout (Part 2)]

[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)]