Re: Part 3: PaySwarm vs. OpenTransact Comparison

Saying that everything is out of scope may be a bad reaction from me due to
frustration in Manu's original post and the way it was formulated.

A lot of things are obviously in scope. We have defined the 3 basic
building blocks for creating, payments, crowd funding and most other kinds
of applications.

We have not been good enough outside the mailing list to describe some of
these recipes. So we have started to build a list of these:

  http://www.opentransact.org/recipes/

None of these come on their own though. OpenTransact is an attempt at
creating an Internet standard in the traditions of the internet.

We do not aim to redefine things that work well.

So. We build on HTTP, OAuth and TLS. We aim to create recipes for
integrating it with OpenID connect to handle some important areas such as
account interoperability, discovery etc.

These are all great initiatives and allows OpenTransact to focus on it's
part without trying to reinvent:

- Delegated authentication
- Encryption
- PKI

Which are all things PaySwarm have reinvented unnecessarily.

The listing part is interesting as I have said repeatedly and I think it
would form a great part of an associated standard that would work well
together with OpenTransact.

P

On Mon, Jan 9, 2012 at 10:11 PM, Paul <paul@pogodan.com> wrote:

> 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
>
> On Jan 9, 2012, at 6:21 PM, Pelle Braendgaard wrote:
>
> Manu you must have a log of time on your hand writing these epics. I have
> not read this yet and it will take me a while to get through it.
>
> 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.
>
> P
>
> On Mon, Jan 9, 2012 at 4:33 PM, Manu Sporny <msporny@digitalbazaar.com>wrote:
>
>> 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/<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/<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<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/<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<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/<http://manu.sporny.org/2011/web-payments-comparison/>
>>
>
>
>
> --
> http://picomoney.com - Like money, just smaller
> http://stakeventures.com - My blog about startups and agile banking
>
>
>


-- 
http://picomoney.com - Like money, just smaller
http://stakeventures.com - My blog about startups and agile banking