Re: W3C Web Payments, PaySwarn and OpenTransact

On 16 December 2011 21:18, Pelle Braendgaard <pelle@stakeventures.com> wrote:
> 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

Very interesting spec.  One question I have on this.

Why not make currency a parameter, rather than hard coded into the URI?

>
> 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 Monday, 19 December 2011 11:42:29 UTC