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

Re: First Draft of Payment Links spec published

From: Pelle Braendgaard <pelle@stakeventures.com>
Date: Wed, 12 Oct 2011 12:00:17 -0400
Message-ID: <CAHtLsUUyWynN87rw006Rb2oxPRPAzoWipW=6coSioYqhHSxEXw@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: Web Payments <public-webpayments@w3.org>
On Wed, Oct 12, 2011 at 11:19 AM, Manu Sporny <msporny@digitalbazaar.com>wrote:

> currency is left out it is assumed that the the base URI of the payment
>> link itself indicates the currency.
>>
>
> Hmmm... It seems strange to assume anything about the IRI. Taking a page
> out of the Microformats Process, I would expect that if we looked at most
> payment links in use today, the currency is not part of the base IRI.
>
> I'd like to understand your reasoning a bit more on this before changing
> that bit in the spec. Why should we assume anything about the base IRI? If
> we make this part of the spec, why is making the base IRI contain the
> currency a good thing? What use cases does it enable? To put it another way,
> why not assume the target account is the last part of the base IRI?


An asset type is a resource. Thus using standard restful thinking a payment
is an operation of that resource. This is the most fundamental part of
OpenTransact, see this for examples:

  https://github.com/opentransact/opentransact/wiki/OpenTransact

Having a payment url as most services use today as a single url that handles
payments for a bunch of different kinds of assets is not restful and is a
holdback to the old message based approach of payments where the web
interface was simply a gateway that sent a message through the banking
system.

I believe it is fundamental that we try to push towards using a web based
approach here. I don't mind there being a currency parameter as a fallback
for existing gateway like services, but it should be encouraged that new
services follow web conventions.


>  The reason for this being is that the URI is that I would like to
>> encourage the use of the payment url itself as being the currency
>> descriptor.
>>
>
> Why is this a benefit?
>
>
>  The other area is the term "asset". It is a term that means a lot in the
>> world of banking, accounting etc. A currency itself is an asset. So I
>> think it would cause confusion to use this term.
>>
>
> We've been having this discussion over the last several years as well.
> We've cycled through Item, Sellable, Creative Work, Work, (many other terms)
> and finally settled on Asset. The dictionary definition for it expresses
> what we mean by it:
>
> as·set
> noun /ˈaset/
> assets, plural
>
> A useful or valuable thing, person, or quality
> - quick reflexes were his chief asset
> - the school is an asset to the community
>
> Property owned by a person or company, regarded as having value and
> available to meet debts, commitments, or legacies
> - growth in net assets
> - debiting the asset account
>
> I think that in order for the specs to be meaningful to implementers (who
> probably won't have a banking/finance background), we need to stick with
> common dictionary definitions.
>
>
I agree that the choices you discarded were too specific.

Money is also an asset together with property is the most commonly thought
definition of assets. An ebook while an asset is not the first thing people
would think of as an asset. I don't mind the term asset as describing these,
but in a business transaction there are 2 assets trading places, so just
using asset causes confusion and I would be very strongly against that.

While not as semantic the more general 'for', 'reference' or 'ref' can be
expanded to use any kind of business transaction.

Lets remember this is supposed to be used in any kind of commerce and
business transaction, not just purchasing a media item online.

P
-- 
http://picomoney.com - Like money, just smaller
http://stakeventures.com - My blog about startups and agile banking
Received on Wednesday, 12 October 2011 16:00:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 12 October 2011 16:00:56 GMT