W3C home > Mailing lists > Public > public-webpayments@w3.org > December 2011

W3C Web Payments, PaySwarn and OpenTransact

From: Pelle Braendgaard <pelle@stakeventures.com>
Date: Fri, 16 Dec 2011 15:18:59 -0500
Message-ID: <CAHtLsUUy+Q2J4vJ3o=61ZaJVKXO_PXwuF8BJBh91bGfC6CRtvA@mail.gmail.com>
To: Web Payments <public-webpayments@w3.org>
Cc: opentransact@googlegroups.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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:20 UTC