Re: W3C Web Payments, PaySwarn and OpenTransact

Hi Melvin,
The main reason for it being implied by the URL was to push the idea of
every value within a specific OpenTransact url as being fungible, meaning a
specific kind of value. Essentially we're taking the the URL literal as
being an identifier of a particular kind of fungible asset. These don't
necessarily have to be monetary, but could be virtual goods in a game, a
SKU in a web shop or other items.

As David Nicol says the main problem is that javascript needs to be used to
pick a currency. I think that in most cases this isn't a problem as most
external payment forms are meant to be used for a purchase with a
preselected currency. However an optional 'currency' parameter could be
added to the spec if need be.

Pelle

On Mon, Dec 19, 2011 at 6:41 AM, Melvin Carvalho
<melvincarvalho@gmail.com>wrote:

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



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