OpenTransact the payment standard where everything is out of scope

My complaint

After growing frustrated with the process in the W3C group I started the discussion at last Friday’s conf call and posted the following post to both the OpenTransact and W3C Web Payments List.

Manu Sporny of Digital Bazaar wrote a piece today Web Payments: PaySwarm vs. OpenTransact Shootout. His analysis is not bad and it makes me chuckle that for most of the features mentioned, Manu writes “which is also outside of the scope of OpenTransact”.

That said the comparison table is less than honest and presents a very skewed look at OpenTransact. If you read the sections his explanations are a bit less skewed.

On being out of scope

There is a very good reason that things are out of scope. It has never been a good idea to try to build a standard until a specific need is there and it has been attempted to be implemented.

Basic Authentication (planned) vs Cookie Authentication (ghetto style)

HTTP 1.0 included the Basic Authentication scheme, which was in wide usage for the first couple of years of the web. HTTP 1.1 included a new much more secure MD5 authentication scheme. By the time HTTP 1.1 was out Cookie based authentication had already taken over. I remember being horrified by this back in the day, but being able to style the login screen, include a lost password link and other such things trumped over both Basic authentication and MD5 in the market place.

Most people won’t remember that the http cookie itself is not a core part of even the HTTP 1.1 spec. Rather it was first proposed by Netscape and then released as an RFC yet all browser vendors support it and the web as we know it would not work without it. That is how the web works. We build small simple standards that get adopted or forgotten by the market.

OAuth vs OpenID = OpenID Connect

OpenID was built to allow logging in on your site by asking another site who you are. The standard was very complicated and only saw moderate use mainly through Google. Yet the ideas were good and very valid.

OAuth comes along with the main and very simple use case being allowing an app to access your photos or tweets on a third site. Quickly the main use case which was never planned became for using Twitter as an authenticating party in an ad hoc ghetto version of OpenID. I don’t think Twitter ever planned this and it was certainly never in the minds of us early OAuth implementers.

This became such successful that as OAuth was learning from their kinks and OAuth 2 started to be worked on, Facebook took this approach and rewrote their Facebook Connect proprietary OpenID scheme to use OAuth 2.

Fast forward to today and OpenID Connect is being worked on a very simple extension on top of OAuth2 which solves most of the real world problems people saw from using OAuth to replace OpenID.

Run through of Manu’s sections

I wont be able to go through all of the sections today as it will take me all day. I will come back and do the rest at a later date.

IRIs for Identifiers

Manu’s section

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.

We all agree that URI’s are great universal identifiers and we encourage them for as identifiers.

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.

Basic Financial Transfer

Manu’s section

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.

Payment Links

Manu’s section

I pushed payment links as the first bit of unifying PaySwarm and OpenTransact. We have since chosen the term Transfer Request as it better explains what it does.

Transacted Item Identifer

Manu’s section

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.

Micropayments

Manu’s section

We don’t specify minimum unit size. A payment is a payment regardless of transaction size. However you implement your system is an implementation issue. For example at PicoMoney we allow issuers of their own virtual currency to pick either a national currency as their base unit or some other application specific unit.

Alternative Currencies

Manu’s section

We support alternative currencies at its core. Most alternative currencies (with BitCoin as a notable exception) have one central payment service. There is thus no need for separate payment processors as the currency itself performs the payment.

OpenTransact has several alternative currencies out there through OSCurrency which is used in real alternative currencies today in Austin, San Francisco and Greece. 100s more are coming online soon as popular local currency software providers are adding OpenTransact support.

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

Access Control Delegation

Manu’s section

OpenTransact builds on OAuth 2 for this. OAuth 2 is now relatively well understood, simple to implement and makes it easy for users to revoke permissions given.

You could create your own access control model using Digital Signatures if you wanted to and PaySwarm apparently wanted to. 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.

Machine Readable Metadata

Manu’s section

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.

It should be concerned with the payment and nothing else. It is suggested that you add as much machine readable information as possible but how you do so and if indeed you do so is out of scope of a payment standard.

Recurring payments

Manu’s section

This comes under Access Control Delegation. 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.

Financial Institution Interoperability

This is where Manu starts marking OpenTransact as pink.

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.

However if you want to do so over ACH, PayPal, Swift etc you can do that as well. It is not a core part of the spec as it doesn’t need to be.

OpenTransact expects that a transfer is done within the scope of that asset. If this is a virtual currency there is no other party to interact with.

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.

Digital Signatures

Manu’s section

Digital signatures are a key feature of PaySwarm. It is used for everything from receipts, licenses, signed product listings and access control. I believe signed receipts are a good thing. Possibly even signed product listings. However I am against having it be a core requirement of the standard.

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.

However according to both common law as used in the US and most other law traditions nothing could be further from the truth. First of all a signature does not create a contract it only hints at intent. Intent of both parties is what makes a contract legally binding. For more on this see Technologists on Signatures: Looking in the wrong place by my brilliant friend Ian Grigg.

Secure Communication over HTTP

Manu’s section

The key to this is OpenTransact is about transfers of assets (also known as payments).

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

Service providers already provide ssl support to their users for free.

To be continued

This has now become quite long, so I need to finish it now. I will pick up the rest of Manu’s point in a later post.