Re: Update: Five Attributes of Payment

Some follow-up replies interline, identified with [JRP]:

On Mon, Sep 8, 2014 at 8:47 PM, Manu Sporny <msporny@digitalbazaar.com>
wrote:

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

[JRP]: Agreed, that's part of what makes this work interesting.

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

[JRP]: Of course.

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


[JRP]: And assuming the payments system does not make this terribly
diffiicult to operationalize.



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

[JRP]: What I'm saying is the specification of parameters for the scalar
values is something for the parties to a contract to determine, not the
architects of the monetary system. What this means, however, is that the
architects of the monetary system ought to build "use choice" of parameters
into the architecture. Hard-coding to 2 decimal places is like hard-coding
browsers to 25 colors.


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

[JRP]: Will do.

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


[JRP]:  Normally. But that might not always be the case in parrticular
applications (de facto), or in partciular jusdictions (de jure).


> They may not be free
> to pay in their unit of choice (depending on if the payee accepts the
> units directly).


[JRP]: Payee ultimately trumps payer in choice of unit, that's clear.  If
payee lists 4 currencies as acceptabe, then the payer has a choice amongst
those 4.


> Third parties (such as the payment processor) could be
> used to broker the conversion.
>

[JRP]: Yes, I always recommend to de-construct that process though. It's
not a single step, and not a single 3rd party. It includes the requirement
for a benchmark. Who determines the choice of benchmark? Who designs it?
Who supplies that service?


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


[JRP]:  Some do. In all of this, I'm saying that all these capabilities
ought to show up somehow in the spec. Otherwise, parties to contacts can
find their legitimate market freedoms restricted by "standard-compliant"
web payents servcies providers who are contraining market freedom.


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

[JRP]: Exactly. This is to be determined by jurisdictional authorities, not
by W3C or by payment service providers. It might be useful for generic web
payments specs however to pro-actively accommodate jurisdiction-based
restrictions -- not to impose them, but rather to standardize and ensure
some elegance to how jurisdications implement such restrictions, so that
all the helpful notices to end-users show up in expected ways. This is not
to say that I'm a fan of restrictions, but rather that since countries do
have legal authority to impose restrictions, let's at least make it
structured rather than ad hoc.


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


[JRP]: The ability to attach the payment to a URI for any benchmark of
choice needs to be part of the W3C spec. What's out at those URI is
external to the W3C spec.

Joseph has been arguing that

> it should be a part of the standard.


[JRP]:  No, I'm simply observing that it's logically inevitable. You can't
logically have time-deferred payments without the ability to cite a
benchmark. You can't logically have 2-currency or multi-currency markets
withouth the ability to cite a benchmark. The impression that these are
possible without a benchmark is an impression that comes from taking "the
exchange rate" for granted, as if it's something other than just a
benchmark from an algorithm.


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

[JRP]:  Somehow I'm failing to communicate that the WM Reuters Spot
Exchange Rate is just a benchmark maintained by a group of companies. And
somehow, I guess due to how I'm expressing this, it seems like a
complicated engineering feat to let payees and payers de-couple from the WM
Reuters Spot Exchange Rate, and benchmark their inter-currency transactions
instead to the World Price Index
http://www.worldeconomics.com/WorldPriceIndex/WPI.efp   Or, to some other
index they prefer.  To me this seems exceedingly simple.

Manu, can you explain what's complicated about accommodating payees and
payers to associate their inter-currency payment to the WPI instead of the
WM-Reuters index?
And if they can chose the WPI, what's complincate about letting them set up
their payments preferences to other index they might prefer, availble via a
URI?

When you way "lack of engineering", do you mean that this sort of choice is
complicated in Digital Bazaar's software in particular, so that it needs to
be re-engineered? Do users of Digital Bazaar's payments solution, or
RippleLabs's solution, have no escape from
http://www.bloomberg.com/news/2014-08-13/banks-said-to-get-enforcement-letters-in-fx-rigging-probe.html
??

On what grounds would a W3C spec block payees and payers from benchmarking
their payment arrangements against something other than a known corruptable
index? Because the payment solutions providers haven't implemented this
yet?


> > _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)?
>

[JRP]:  I dunno. Needs thinking.

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

[JRP]: The certainly can be minimum equivalent neutral documentation req's
-- like ingredients labelling in food, and effects documentation that has
to be provided with prescription meds.


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

[JRP]: Of course -- for the merchant. The point here is whether the
payments system accommodates payee and payer choices. Currently here in N
Am we generally can't pay with our smart phones the way they can in Kenya.


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



-- 
Joseph Potvin
Operations Manager | Gestionnaire des opérations
The Opman Company | La compagnie Opman
jpotvin@opman.ca
Mobile: 819-593-5983