Re: Update: Five Attributes of Payment

On 08/31/2014 01:36 PM, Melvin Carvalho wrote:
> Joseph Potvin wrote: Further discussion and research on this topic 
> (including research in economics and law towards my doctoral 
> dissertation at U Quebec), as well as consideration of various ideas 
> raised on these lists, has led me to include five attributes.
> 
> Thanks for sharing.  I'll give my understanding of the answers to 
> your questions, but it's just my opinions ...

More opinions, some facts follow:

> 1.
> 
> _S__cal__ar __quantity_ (e.g. 10.99; 0.0001099—/Can the parties 
> //specify////micro payments //to //their//chosen//number of decimal 
> places//?/)
> 
> Yes.  xsd decimal is arbitrary precision

All of the technologies that have a serious amount of consideration in
the Web Payments work support arbitrary precision in the expression of
the scalar quantity.

You should note that some technologies like Bitcoin aren't arbitrary
position, precision is at 8 decimal places right now, but can be
extended based on the consensus of the network (most of Bitcoin's limits
can be raised using this approach).

> /Can //contracting //parties //to //implement //algorithmic pricing 
> //to their chosen specifications//? /;

I don't quite understand this question. If you're asking "can an
algorithmic pricing algorithm operate assuming arbitrary scalar quantity
values?", the answer is "yes, assuming that the currency supports
arbitrary scalar values". Most currencies don't support arbitrary scalar
values. For example, USD is really only good to a few decimal places,
having 100 doesn't really buy you much. Bitcoin is a bit better wrt. how
many decimal places you have available to you, but its still not
"arbitrary precision" in practice today.

You should clarify the second question you're asking because it's vague.

> _U__nit-of-account_ (e.g. $ £ € ¥ etc. Are contracting parties free 
> to //price and pay in//their //unit //s////of choice?
> 
> Yes currency is anyURI or a 3 letter ISO code.

They're free to price it in units of their choice. They may not be free
to pay in their unit of choice (depending on if the payee accepts the
units directly). Third parties (such as the payment processor) could be
used to broker the conversion.

> //Can the unit//of payment//be //one that is self-defined//by the 
> contracting parties, and/or //can it be from a non-traditional 
> provider//?//)/;

The Web Payments technologies certainly can allow the unit to be
self-defined or non-traditional (aka a private currency). Keep in mind
that this may be heavily restricted by federal law or international law.
The technology gives the issuer the option, but leaves the legality of
the instrument up to the issuer.

> _V__alue-in-exchange benchmark_ (e.g. WM Reuters Spot Exchange
> Index; Purchasing Power Parity Index; Commodity Index; Earth Reserve
> Index, etc.—/Can//contracting parties benchmark //the scalar quantity
> of //payment to //any//market factors they deem to be relevant //to
> the //duration//and //object//of the contract//?/);
> 
> If someone can create a URI out if it then sure.  Indexes are not 
> always 100% accurate tho.

Yes, but the question remains: is this a part of the standard or
something that's added on after the fact. Joseph has been arguing that
it should be a part of the standard. Digital Bazaar, while agreeing that
this work is important, is concerned that there isn't enough engineering
work behind it to solve this problem along with all of the other
problems that need to be solved. It suffers from a lack of engineering
backing and implementations.

> _Transaction__depositories_ (eg physical wallet; digital wallet; 
> digital bank account, etc.—/Do contracting parties have the ability 
> to decide //upon and control //the origin and destination nodes for 
> their payments?/); and,
> 
> Source and origin are again anyURI so it can be anything.

I believe the answer to this question is "yes", as Melvin said. I'm a
bit concerned that the question is a bit vague. What does it mean to be
a "node"? Is that a bank account? A reference to a bank account? Does
the node contain the actual "true" amount in the account (such as a
cryptocurrency value), or a reference to an account value (such as a
bank account value)?

> _M__edium-of-exchange_(e.g. debit card, credit card, giro, cash, 
> etc.—/Are media-of-exchange options documented effectively to enable 
> informed user choice?

"Documentation" is up to the merchant and the payment processor, no
standard can enforce that things be properly documented. The
specifications that we have right now do allow for the media-of-exchange
options to be offered to the customer and merchant. I don't think we can
safely say that they "effectively enable informed user choice" - that's
a user experience/interface issue (and the spec probably shouldn't
mandate things like that).

> Do contracting parties have //practical //access to choice //amongst
> //medi//a//-of-exchange?/)"

Hard to say until the system is deployed. If a merchant only offers
payments via credit card, then no. If a merchant offers at least 3-5
different options, then we could say "yes".... but what does "practical
access to choice" mean? What number of media-of-exchange options does
one have to offer to meet the "practical access to choice" bar?

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Marathonic Dawn of Web Payments
http://manu.sporny.org/2014/dawn-of-web-payments/

Received on Tuesday, 9 September 2014 00:48:18 UTC