- From: Pelle Braendgaard <pelle@stakeventures.com>
- Date: Fri, 16 Dec 2011 15:18:59 -0500
- To: Web Payments <public-webpayments@w3.org>
- Cc: opentransact@googlegroups.com
- Message-ID: <CAHtLsUUy+Q2J4vJ3o=61ZaJVKXO_PXwuF8BJBh91bGfC6CRtvA@mail.gmail.com>
This is mainly to the web payments list, but I am cc'ing OpenTransact as well. As I mentioned on todays talk I would like to express my dissatisfaction with the process in the W3C web payments group. While the PaySwarm proposal has many great ideas I strongly believe that the PaySwarm proposal is fundamentally flawed: http://payswarm.com/specs/ED/web-api/2011-12-14/ My objections are: It's a huge monolithic standard designed using waterfall methodology to support a large list of predefined use cases: http://payswarm.com/specs/ED/use-cases/2011-10-20/ I think it's better to create smaller standards using real needs of today. These standards can be expanded on as various real word cases are deployed and or experimented with. PaySwarm rejects the use of standard internet protocols such as OAuth 2, rather builds it's on custom authentication scheme using digital signatures. I believe there is no better option right now than using OAuth 2 for the majority of server to server authentication. With OAuth 2 this is a solved issue and should not be reimplemented. PaySwarm has as it's fundamental model a purchase which is a contract which consists of a digital signed combination of a signed offer and a signed payment. While I believe this is a great pattern to implement, it makes too many assumptions about what a payment is. Not all payments are made as purchases and not all purchases are made where the purchased item will follow the PaySwarm model. At PicoMoney we have implemented essentially the same level of functionality on the application level with a much simpler OpenTransact api on top of it. The digital signature requirement is unfortunate. I have always been a big believer in digital signatures for many things, yet they complicate matters terribly particularly when involving users with web browsers. A simple signature extensions can be added to OpenTransact to handle those instances where it is required. Since I joined this process I have tried hard to push for a layered approach utilizing OpenTransact for the payment specific layers and separate work for creation offers and product listings. So I am now officially proposing OpenTransact to the W3C web payments group. The current draft of OpenTransact is here: http://www.opentransact.org/core.html The main site with a simple overview can be found here: http://www.opentransact.org/ A OpenTransact url represents a unique asset on the web. A provider can provide different URL's for different purposes. The 3 basic requests of OpenTransact are very simple and very similar: - Transfer Request - An website requests payment from a user - Transfer Authorization - A website requests authorization to perform a payment from a user at a later time - Transfer - A pre authorized website performs a payment on behalf a user I believe there are very few of the PaySwarm use cases that couldn't be achieved through OpenTransact url's with different underlying business rules. 3 extensions that could be created on top of OpenTransact if the community desires are: - Signed receipts - Signed transactions - Offers and trading (Already being discussed) OpenTransact builds on OAuth 2 and http. It can coexists well with OpenID Connect (not to be confused with traditional OpenID). Please feel free to comment and ask questions about how specific use cases could be implemented using OpenTransact. Pelle -- http://picomoney.com - Like money, just smaller http://stakeventures.com - My blog about startups and agile banking
Received on Friday, 16 December 2011 20:19:28 UTC