Re: Part 3: PaySwarm vs. OpenTransact Comparison

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