Re: Part 3: PaySwarm vs. OpenTransact Comparison

bcc: opentransact

On 01/10/2012 02:16 PM, Jake Howerton wrote:
> My opinion, that I previously tweeted, is that Manu is confused about
> what a payment is and is not.

The definition of payment that is used for the PaySwarm specification is
the English definition of "payment", M-W defines it as[1]:

a. "the act of giving money for something : the act of paying"
b. "something that is given to someone in exchange for something else"

A further elaboration on the definition as used in English is best
summarized on Wikipedia[2]:

"A payment is the transfer of wealth from one party (such as a person or
company) to another. A payment is usually made in exchange for the
provision of goods, services or both, or to fulfill a legal obligation."

So, what part of the definition of payment am I confused about,
specifically?

> One real example that disproves this conclusion of Manu's, is the ACH
> system in the United States. ACH obviously has none of the features
> that Manu is saying are required for an open payment system. And
> while there are tons of reasons that ACH could now be considered
> inferior, interoperability is not one of them.

The definition of interoperability that we care about is as it relates
to open standards, which is defined by IETF and W3C, and can be
summarized like so[3]:

"Open Standards rely on a broadly consultative and inclusive group
including representatives from vendors, academicians and others holding
a stake in the development. That discusses and debates the technical and
economic merits, demerits and feasibility of a proposed common protocol.
After the doubts and reservations of all members are addressed, the
resulting common document is endorsed as a common standard. This
document is subsequently released to the public, and henceforth becomes
an open standard. It is usually published and is available freely or at
a nominal cost to any and all comers, with no further encumbrances.
Various vendors and individuals (even those who were not part of the
original group) can use the standards document to make products that
implement the common protocol defined in the standard, and are thus
*interoperable by design*, with no specific liability or advantage for
any customer for choosing one product over another on the basis of
standardised features. The vendors' products compete on the quality of
their implementation, user interface, ease of use, performance, price,
and a host of other factors, while keeping the customers data intact and
transferable even if he chooses to switch to another competing product
for business reasons."

ACH does not fit that definition of open standard interoperability, nor
any other "open standard" definition. Yes, ACH systems are interoperable
with one another in a post-facto sense. However, there are only two
organizations in the US that are capable of performing ACH - The Federal
Reserve Banks and EPN... that's it... very centralized.

There is also no public specification on how the network operates... the
file format yes, the network protocol, no... at least, not to my
knowledge. ACH would not fly as an IETF spec, nor would it fly as a W3C
spec. So, I reject the assertion that ACH disproves my interoperability
point - we're talking about an open standard for the Internet, we're not
after post-facto interoperability.

The interoperability that we're after is at least at the level of
SMTP... where you can be on one server and send an e-mail to someone
else on another server. The same sort of interoperability is required
for payments... OpenTransact does not specify how you do that.

Much more on this has been written here[4] and here[5].

> However, trying to model entire systems of commerce, and what amount
>  to business rules inside of a supposed payment standard, and at the
>  same time having a goal of interoperability, seems self detrimental
>  to me.

As stated in the blog posts, we have a set of use cases[6] and we're
addressing those. Any assertion that states that we're doing anything
other than that, "boil the oceans", "socialism", "central planning",
etc., is hyperbole. Your argument about a "supposed payment standard",
and the assertion that "doing anything else should not belong in a
payment standard" is a "No True Scotsman" fallacy[7].

That is, arguing that one of the use cases is not useful or focusing on
the technical concerns will be far more effective than making broad
philosophical generalizations. What would be helpful at this time are
statements of technical concern or issue, not broad philosophical
assertions that will inevitably lead to perma-threads. "seems self
detrimental to me" doesn't help us understand /why/ you think it's self
detrimental - please list the reasoning.

Out of the entire conversation about the technical and philosophical
differences between PaySwarm and OpenTransact, there were 26 technical
features discussed, of which only 6 of them are fully covered by
documents available on OpenTransact. Additionally, other broad technical
design issues were raised on OpenTransact, open standard
interoperability being the greatest issue. I feel that we've been very
explicit about the issues that OpenTransact has.

In Pelle's blog responses, there were no technical concerns raised on
PaySwarm. There were certainly philosophical concerns, business
concerns, and implementation complexity concerns, but no technical
concerns - that is, at no point does Pelle say "This is a bug here or
there is a design issue there or a security vulnerability exists if...".
Rather, most of the responses were "it's out of scope" - which doesn't
actually address the issues I raised, but rather, avoids them.

Here is our take away from the conversation about Pelle's thinking on
PaySwarm:

1. Doing more than just monetary transfer is not necessary.
2. Just about everything that PaySwarm is doing above pure monetary
    transfer is out of scope.
3. Digital signatures in a payment specification is not necessary.
4. Metadata extensibility in a payment specification is not necessary.
5. The specification shouldn't combine all of these things together.

We have responded to points #1-#4, and given our reasoning on why the 26
features discussed in the original blog post matter. We already accepted
point #5 as an editorial issue quite some time ago and will do our best
to split the specs up once we're sure that we have the full picture
outlined in a single spec (which is what we did with the JSON-LD
specifications).

So, please - technical feedback is far better than broad philosophical
statements. I'll write a blog post on the security issues with the
OpenTransact specification, and Pelle's most recent use cases, when I
find the time.

-- manu

[1] http://www.learnersdictionary.com/search/payment
[2] http://en.wikipedia.org/wiki/Payment
[3] 
http://en.wikipedia.org/wiki/Interoperability#Interoperability_and_Open_Standards
[4] http://www.w3.org/QA/2008/05/open-standards-interoperability.html
[5] http://www.ietf.org/rfc/rfc3935
[6] http://payswarm.com/specs/source/use-cases/
[7] http://rationalwiki.org/wiki/No_True_Scotsman

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

Received on Thursday, 12 January 2012 18:59:36 UTC