Part 3: PaySwarm vs. OpenTransact Comparison
Manu Sporny
The third blog post of the comparison between PaySwarm and OpenTransact
has just been published. In this post, I respond to Pelle's most recent
blog post about design decisions made for OpenTransact and the
implications of those design decisions:
http://manu.sporny.org/2012/web-payments-shootout-part-3/
---------------------------------------------------------------
Full-text below for the purposes of archival external to my personal blog.
Web Payments: PaySwarm vs. OpenTransact Shootout (Part 3)
By ManuSporny On January 8, 2012 In PaySwarm, Standards
This is a continuing series of blog posts analyzing the differences
between PaySwarm and OpenTransact. The originating blog post and
subsequent discussion is shown below:
Web Payments: PaySwarm vs. OpenTransact Shootout by Manu Sporny
http://manu.sporny.org/2011/web-payments-comparison/
OpenTransact the payment standard where everything is out of scope by
Pelle Braendgaard
http://stakeventures.com/articles/2011/12/21/opentransact-the-payment-standard-where-everything-is-out-of-scope
Web Payments: PaySwarm vs. OpenTransact Shootout (Part 2) by Manu Sporny
http://manu.sporny.org/2012/web-payments-shootout-part-2/
OpenTransact vs PaySwarm part 2 � yes it�s still mostly out of scope by
Pelle Braendgaard
http://stakeventures.com/articles/2012/01/02/opentransact-vs-payswarm-part-2-yes-its-still-mostly-out-of-scope
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.
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:
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.
1. 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.
2. 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.
3. 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.
4. 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.
-- manu
--
Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: PaySwarm vs. OpenTransact Shootout
http://manu.sporny.org/2011/web-payments-comparison/
Pelle Braendgaard
bcc: OpenTransact Mailing List
The third blog post of the comparison between PaySwarm and OpenTransact
has just been published. In this post, I respond to Pelle's most recent
blog post about design decisions made for OpenTransact and the
implications of those design decisions:
http://manu.sporny.org/2012/web-payments-shootout-part-3/
---------------------------------------------------------------
Full-text below for the purposes of archival external to my personal blog.
Web Payments: PaySwarm vs. OpenTransact Shootout (Part 3)
By ManuSporny On January 8, 2012 In PaySwarm, Standards
This is a continuing series of blog posts analyzing the differences
between PaySwarm and OpenTransact. The originating blog post and
subsequent discussion is shown below:
Web Payments: PaySwarm vs. OpenTransact Shootout by Manu Sporny
http://manu.sporny.org/2011/web-payments-comparison/
OpenTransact the payment standard where everything is out of scope by
Pelle Braendgaard
http://stakeventures.com/articles/2011/12/21/opentransact-the-payment-standard-where-everything-is-out-of-scope
Web Payments: PaySwarm vs. OpenTransact Shootout (Part 2) by Manu Sporny
http://manu.sporny.org/2012/web-payments-shootout-part-2/
OpenTransact vs PaySwarm part 2 – yes it’s still mostly out of scope by
Pelle Braendgaard
http://stakeventures.com/articles/2012/01/02/opentransact-vs-payswarm-part-2-yes-its-still-mostly-out-of-scope
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.
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
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”.
http://picomoney.com - Like money, just smaller
http://stakeventures.com - My blog about startups and agile banking
David Nicol
effort into his work; he's detail oriented, thorough, and follows
through on what he says he'll do.
I think the best suggestion in the document is to divide the payswarm
specification into a set of manageable pieces. But it isn't clear that
that isn't there already. What are the use cases -- not for the
specified protocol, but for the specification document? And does the
draft document provide for them all?
The epic nature of the response is evidence of thoroughness, as well
as a monolithic mindset, opposed to a many-little-cooperative-pieces
mindset. And the criticisms about interoperability and completeness
are sound.
as I understand it, OT does not at this time support a party seperate
from picomoney doing transactions in a currency that is headquartersed
at picomoney. Does it? That's what he's insisting is missing, as the
vast and disparate fleet of value added resellers of US Federal Book
Entry Currency aren't going to let themselves get folded up into
essentially proxy servers that have to hit the central bank whenever
they do something.
if OT already supports all the use cases, the request is for examples
of how, in wire-level detail, like the payswarm examples show.
--
Application of Porter's value chain model to the executive function
reveals that the executive process transforms the input of information
into the output of decisions.
Manu Sporny
On 01/09/2012 06:21 PM, Pelle Braendgaard wrote:
> Manu you must have a log of time on your hand writing these epics.
I wish I had a great deal of time on my hands... I do not.
Running a start-up leaves very little time for writing, including
doing thorough analyses of specifications. However, I did promise you
that there would be a thorough vetting of OpenTransact as it pertains
to Web Payments and this is me keeping that promise.
> From a really quick skim almost all the arguments here and in my
> earlier replies are because there is a huge difference in the
> fundamental approach to both standards.
If that is what you are seeing across the three blog posts that have
been written analyzing OpenTransact then you are missing the fundamental
point that is being made, which is summarized at the top of the last two
blog posts:
"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 choose to ignore this advice, but I'm afraid that unless a
number of design changes are made, that these issues are going to come
back to bite OpenTransact when it seeks approval by the various W3C or
IETF standards bodies.
While I do go paragraph-by-paragraph and respond to everything you have
written, those points only bolster the underlying point above - lack of
interoperability, the reasons for which are thoroughly outlined across
all three blog posts.
Let me be clear - there is a difference in philosophy between PaySwarm
and OpenTransact. However, there is also a fatally flawed design problem
with OpenTransact (interoperability) that must be rectified if it is to
succeed as a Web standard.
David Nicol
> Let me be clear - there is a difference in philosophy between PaySwarm
> and OpenTransact. However, there is also a fatally flawed design problem
> with OpenTransact (interoperability) that must be rectified if it is to
> succeed as a Web standard.
>
>
> -- manu
My opinion is that Manu is correct in his assessment
Jake Howerton
what a payment is and is not.
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.
Would love to hear Manu's thoughts on security flaws, and any other
real flaws that OT has. 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.
-Jake
David Nicol
> 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.
>
> Would love to hear Manu's thoughts on security flaws, and any other
> real flaws that OT has. 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.
>
> -Jake
http://en.wikipedia.org/wiki/Automated_Clearing_House says it's
centralized, including Federal Reserve and one private alternative.
And there /is/ a system in place for "interoperator transactions"
which is something AIUI that OT has, in fact, handwaved into the
future.
Also, if there are definitional issues ("what is a payment") those
really need to get ironed out as early as possible otherwise
discussion participants will talk past each other frustratingly.
Jake Howerton
systems in the real world (save Bitcoin), as Pelle has argued. Actual
usage of the protocol and endpoints are totally distributed.
The Interoperator Transactions issue is a perfect example of why you
want to have a simple protocol. ACH clients do not need to know that
2 networks even exist, they just talk the protocol and get the
expected results. The fact that there is some extra leg work and
business rules going on behind the scenes by the provider to make sure
that the transaction gets cleared does not leak into the standard, and
this is a good thing!
Totally agreed on clarifying definitions, and I think it is something
we should work on.
-Jake
Pelle Braendgaard
Having read through the blog discussion history, I would agree that there are serious, substantive criticisms of OpenTransact which boil down to its own self-description, "the payment standard where everything is out of scope". I am all in favor of minimalist, functional standards but reading through your blogs the answer to every problem raised is "this is an implementation detail". The ways things stand today, early 2012, these things are also all implementation details. I have a hard time understanding what OpenTransact is bringing to the table other than a brand
--
Paul Meserve
Pogodan Ltd
| w | www.pogodan.com | t | +44 (0)151 675 3000 | m | +1 860 484 3648
Pogodan is Limited Company Registered in England no. 07429329.
Registered Address: Sherlock House | 6 Manor Road | Wallasey | CH44 4JB | UK
Manu Sporny
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
Jake Howerton
> bcc: opentransact
>
> 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.
You are confusing "the transaction" and "the delivery", which is why
you misunderstood how I categorized ACH. Payment networks cannot
always work like SMTP because SMTP has the benefit of both of these
actions happening in the same medium. If I am paying you with gold
through an electronic system, at some point the gold has to be moved
from my vault to your vault, and unfortunately I can't do that with an
HTTP ;) If I am paying with USD, a bank transfer has to happen at
some point (or someone needs to mail cash). OpenTransact focuses on
recording the transaction, and not necessarily the delivery. In a lot
of the situations we are talking about, the provider is the issuer and
ideally delivery happens instantly, and is irrevocable. Maybe the
provider takes on the risk of delivery and gives instant
confirmation/availability of the transaction being recorded, but there
are obviously thousands of permutations of how this works in the real
world.
Also, there is nothing to hold back two clearing partners in a network
from settling delivery using standard OpenTransact, if it is
physically possible.
> 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.
>
I think you read past my criticism, I am not talking about your use
cases, unless the documentation of your spec is confusing me. I am
talking specifically about "2. The Conceptual Model" The things you
outline here are business rules which will limit interoperability.
Limiting interoperability would be self detrimental since that is one
of your stated goals.
> 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.
The entire point (from my perspective) of specifications and standards
is to get people to come together philosophically around a common
problem, and then decide on a technical document that describes the
philosophy around solving that problem, which is why you are hearing
feedback about these issues instead of technical comparisons/flaws.
-Jake
Manu Sporny
> On Thu, Jan 12, 2012 at 1:58 PM, Manu
> Sporny<msp...@digitalbazaar.com> wrote:
>> bcc: opentransact
>>
>> 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.
>
> You are confusing "the transaction" and "the delivery", which is why
> you misunderstood how I categorized ACH.
I think you think I'm talking about "the delivery" - I'm not. See this
(the transaction-backhaul algorithm):
http://lists.w3.org/Archives/Public/public-webpayments/2012Jan/0025.html
> Payment networks cannot always work like SMTP because SMTP has the
> benefit of both of these actions happening in the same medium.
Why not? A gigantic portion of the world's day-to-day wealth transfer is
electronic. The future will have an ever-increasing amount of
transactions performed electronically.
> If I am paying you with gold through an electronic system, at some
> point the gold has to be moved from my vault to your vault, and
> unfortunately I can't do that with an HTTP ;)
Ah, but how often does that happen? Often it is certificates for gold
deposits that are bought and sold, not the actual gold itself. The gold
is kept in a heavily guarded facility.
> Also, there is nothing to hold back two clearing partners in a
> network from settling delivery using standard OpenTransact, if it is
> physically possible.
Yes, this is what I'm saying that the OpenTransact folks need to spec
out in order to ensure interoperability.
> I think you read past my criticism, I am not talking about your use
> cases, unless the documentation of your spec is confusing me. I am
> talking specifically about "2. The Conceptual Model" The things you
> outline here are business rules which will limit interoperability.
> Limiting interoperability would be self detrimental since that is one
> of your stated goals.
How does it limit interoperability? What use case can you not perform
via the conceptual model?
> The entire point (from my perspective) of specifications and
> standards is to get people to come together philosophically around a
> common problem, and then decide on a technical document that
> describes the philosophy around solving that problem, which is why
> you are hearing feedback about these issues instead of technical
> comparisons/flaws.
Specifically, I was referring to non-actionable statements like the
following:
"OpenTransact vs PaySwarm is like Libertarianism vs Socialism."
"the basic PaySwarm philosophy of wanting to design a whole world view
is very similar to central planning"
"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."
You explained a bit more about this last comment in your previous
e-mail, so that you for that. That was helpful and we can finally start
talking about specifics, of which I've asked you the first set of
questions above. :)
-- manu