Re: W3C Web Payments, PaySwarn and OpenTransact

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

Looking at the spec on

http://www.opentransact.org/

And on

http://payswarm.com/specs/source/payment-links/

They look pretty similar (and to tipjar and bitcoin).  This also looks
quite close to the json that I'll be using.

Why not try and align the two of this in terms of naming and decide
whether the currency should be a parameter.  I also wonder if asset is
strictly needed.

The authentication layer can then build on top of this simple
standard.  Whether you use OAuth2 via a third party, or direct PKI or
a combination will allow different usage patterns.

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

Received on Monday, 26 December 2011 15:32:44 UTC