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
>
> 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.

Thanks for posting some interesting points.

I read through the spec, and I'm looking forward to the continued
development of OpenTransact, hopefully in a way that is going to scale
to the whole web.

A couple of points:

1. It is the W3C Payments "Community" Group.  Community is an
important in that it is more informal than an incubator or working
group, which are traditionally the tracks for standardization.  A
community group brings like minded people together to create
implementations, prototypes and candidates for standards.  In fact the
W3C has no 'standards', when an RFC is considered ready and well
reviewed, it is given REC (recommendation) status, and it's possible
to have several complimentary recommendations.  So it would be a
mistake to think anything here is a cast iron standard, but certainly
things can move in that direction.

2. The trusted third party (TTP) vs the direct PKI debate has been
going on a long time.  More recently in Oauth vs digital signature
conversation.  Both are have a place.  But if you consider the authors
of OAuth (google, microsoft, facebook) they are understandably going
to push the TTP solution with them being the white listed trust center
(originally microsoft tried this with "passport", but oauth is
essentially a slightly more distributed replacement for that).  This
is fine but I think there's also a good case for the user-centric
direct PKI solution.

In my apps I trying to use both, I'm happy to get a big OAuth user
base, but also glad for the direct connection in case OAuth
(inevitably) becomes more centralized, and also for the simplified
flows, which can present more possibilities.

Enjoyed listening to the healthy discussion in the most recent
telecon, keep up the good work.

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

Received on Sunday, 18 December 2011 15:04:08 UTC